that is some interesting history.
ironically i'm quite the opposite, i have never worked in the Hardware Design/ASCI field, but i've made a dozen of custom CPUs over the last few years.
it's easier than you think, atleast when you don't follow any specific feature/instruction set, or make a RISC CPU... those things are just really easy.


I've seen some softcore comparisons on here, for example: viewtopic.php?f=10&t=4939
and to be honest, i make Verilog code the lazy way. i build my circuits in a Logic Simulator and just click a button that says "Export as Verilog", put that throught Quartus onto my FPGA Dev board, and there you.
and I don't know how auto generated code compares to manually written code in terms of resources and efficency.
so I don't think i would be the best for that job. especailly since i use a completely different internal architecture that is much more resource demanding than the original 6502's.
only good thing about my architecture are the decreased cycle times... which is mostly because I technically have 2 ALUs in my CPU.



why would the cylce times be a deal breaker? i thought having instructions execute faster would not only make programs run faster but also make time critical things easier.
about the 65C02, i can easily expand my 6502 design to a 65C02 without any major changes to the circuit. this is also why i want to start with the 6502, because once i have that working i can add new features without having to worry about any of the existing 6502 stuff.

Cheap FPGAs often don't have a lot of BRAM so i always try to minimize the usage of it.
but i could put the Zeropage or Stack onto the embedded RAM as it would only take up 512 Bytes, and it could speed up cylce times even more (single cycle push/pull instructions, imagine that!).
though for most testing i use BRAM to save myself having to build a circuit to interface with external RAM.

and lastly, i have no idea how i could optimize code for a specific FPGA family. my FPGA Dev board is a Cyclone II but I'm currently looking into Lattice FPGAs because they are basically the cheapest on the market while still fitting a bit into them. (for example i designed a simple color VGA core that fits into this FPGA while only using ~60% of it, making it a very cheap VGA option for any 8 bit computer).


Simulator is always a first step for me. once i got it in there i can easily turn it into Verilog to throw it at an FPGA.
so it was still helpful, though my current focus is to mainly get something working before i tackle any advanced versions of the 6502. (65C02, 65CE02, or something custom)

It's not. For me, original 6502 cores are mainly interesting for emulating vintage systems. For these, exactly matching clocks/instruction matters. If I'm going to make something new I'll reach for a 65C02, discrete chip or FPGA core. If you prefer to start with the simpler instruction set there is nothing at all wrong about that. It's just not the way I would do it.

I have thought for a while that Lattice's ICE40UP5K (http://www.latticesemi.com/Products/FPG ... 0UltraPlus) would make a great platform for retro CPU / system projects. It has tons of logic and RAM for the price, but unfortunately hardly any IO.

I would encourage you to sometime try a more traditional, all Verilog workflow. All of the FPGA vendor tools support this design style.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

really? I didn't think cycle exact execution would matter for a lot of systems... damn i was gonna try this CPU in a C64.
also i just like working from the start instead of the middle. that is why i do the 6502 first.


one problem i got with the iCE40 FPGAs is that most are BGA chips... and i really want to avoid using BGA chips.
which is why i mostly just looked at the MachXO2 and MachXO3 series.
though this one is not bad looking, and should easily fit a whole CPU in it.


I know i should, and i did do that in the past.
but laziness always wins, and so far it worked for me better and faster than just writing in Verilog from the start.
everyone has their own workflow.



my idea was to use Dual-Port RAM, since FPGAs should support that.
so one port is connected to the CPU via the regular address and data bus, making it function like any other piece of Memory to the CPU.
while the other port of each memory is connected via a special address and data bus to CPU for special/fast access.
so basically, over the normal bus, if the address accessed is smaller than 512 it accesses the internal memory, if it's larger it accesses the external memory.
but for data reads/writes within ZP/Stack space (Load, Store, Push, JSR, etc) it only uses the internal memory.

so executing and modifying code from the ZP or Stack is possible, but you would not be able to access an IO device that lies within the ZP or Stack.

You could certainly put a 65C02 or even a 65816 in a C64, if you adapted it to the 6510 pinout. It would even run BASIC and KERNAL code just fine. There's nothing about the C64 hardware that requires an original NMOS 6502 - rather, the other way around, the VIC-II has a specific workaround for an aspect of the NMOS 6502's behaviour.

The problem is that a great deal of the most interesting software written for the C64 relies on cycle-exact timings and undocumented instructions, as part of getting the absolute most out of the C64's intricate hardware design. Quite a few games and basically anything from the demoscene would break, hard, if you altered the instruction timing or used a faster clock.

Rather than saying 'the most interesting' I might say 'the most popular' - it's mostly games, demos, custom loaders which might require cycle exact timing. My preference would be to ignore that whole sector of interest! As you note, Basic and the Kernal should be fine (not sure about disk access).

Backward compatibility is something which can really hold back progress: aim to run games and demos, and you have much larger audience, and a much more critical audience. Ignore games and demos, build a really fast machine, and that's (a different kind of) great!

ok, i just need to program in the instructions and it should be working.
but today wasn't really productive because of something that just arrived in the mail:

it's really clean, but I need a power supply for it so i'll have to look into buying one of those new ones.
but there are many sites and i don't know which are trust worthy/quality.

anyways i don't want to derail this thread into a Noob-C64 thread...

but it could seem like a good testing ground for a 6502 rework... or a Co-Processor. maybe DOOM would run better with that as well.

In fact, someone has made a 65816 work in a C64 - an add-on called the SuperCPU. That's how I know for certain that it can work. It definitely makes the machine vastly more capable. I just had to point out some of the more obvious limitations of such an upgrade.

It is somewhat easier to attach an arbitrary new CPU to a BBC Micro or Master, due to the Tube interface which is specifically designed to do just that.

yea i was thinking of something similar to the SuperCPU, but instead of being a cardridge it's just a straight up PCB that you put into your CPU socket.
i know the 6510 uses 6 of it's 8 IO pins on the CPU. wouldn't it be possible to use the remaining 2 to switch between high speed mode and regular mode (ie all instructions have dummy cycles to make it cycle exact)?

but that is for a future project, right now i just want to get the 6502 done, and then start with the 65C02.

It's not just the cycle timing you need to get right, but the undocumented instructions that NMOS 65xx had. A lot of the stuff that requires exact cycle timings also uses the "illegals", because some of them can be used to do things more quickly than sticking precisely to spec.

A minor example of this can be seen here.

It's not quite true, but it might be useful to say that you can build a faster 6502, or a hyper-compatible 6502, but not both. In view it's a lot more interesting to build a fast machine: hyper-compatibility has been done. Of course, for one's individual journey, building any cpu is a significant achievement.

The other thing is, by not addressing the hyper-compatibility, one cuts the audience dramatically, which cuts the noise too.

yea if i ever make some actually extended 65C02 with a larger addressing space or similar i would likely not make the effort to add any kind of 65C02 emulation mode or something, it just wouldn't really be worth it.
but i think i would keep all of the existing instructions and most of the functionality the same, so it's not binary compatible, but semi-assembly compatible. so as long as you got the source code or a disassmbly of the original program you should be able to either directly or after some minor modifications run it through an Assembler for the new CPU.
which should make porting stuff a lot easier without being directly backwards compatible.

also just wanted to let people know i'm still working on the project, progress is just slow. programming in all instructions is always the most annoying and procrastinated part of any CPU i make.

Alright, i have finished all 6502 Instructions and put all of them with their cycle counts in this neat little Opcode table.

The image should be self-explanatory, but i can still say a few things.
I don't have a 65C02V yet, which is why the Average CPI and MIPS are colored red and have "WIP!" next to it.
Also since this CPU is slightly faster than a 65CE02 running at the same clock speed it should mean this would be >25% faster than the regular 6502,
but if you do the math the difference between the Average MIPS/CPI of the 6502 and 6502V is around 19.1%. so i have no idea how they did their math to get to 25%.

anyways, while I have manually tested the function of a lot of the instructions i still wanted to do a full test, so I tried to use this test program but i'm having some problems.
how are you supposed to identify what instruction failed? the Source file says there is a listing to check what failed, but i couldn't find anything helpful...
I'm obviously missing something, but i don't know what.

Klaus' test suite stops (well, goes into a tight loop) with a PC value that gives a big clue. You do then need to refer to a listing. See for example the *.lst files in this subdir:
https://github.com/Klaus2m5/6502_65C02_ ... /bin_files

oh i see, the LST file that was generated when i assembled it myself was much smaller.
i retried it with a parameter it says in the file itself.

which gives me a listing file, but it's offset by the starting address of the program.
which confuses me a bit. 0x0000 to 0x03FF seem to get filled with data in the assembly file but the actual Binary output file doesn't have any of that and just has the program start (0x0400) at the start of the file (0x0000)...

was that my mistake? i manually added 0x400 bytes in the binary file and also manually added a reset vector to point to 0x0400.

it now gets stuck at 0x0430, which in the listing is just named "failed anyway", it's located after a chunk of DEX's named "backward landing zone"


this test is confusing, plus it's written in Lowercase Assembly, which is a programming sin.