6502.org

Congratulations: the only part of the CPU that is yet untested is that SPI port.
Go, Drass, go.


I think it's sort of a 6502 which "pretends" to be something like a 65816 stuck somewhere between emulation mode and native mode.
To add two points to Drass's nice list above:
the status register still is like in the 6502, and the interrupt vectors still are like in the 6502.

We already had some technical info on K24 somewhere up in the thread .

Point is, that supporting all of the 65816 features would have required a complete redesign of the entire CPU,
so sorry to say this: a 65816 compatible TTL CPU would have to be a new and different project.

On the bright side, any 65816 assembler is supposed to be able to generate K24 machine code,
and when taking a bit care while coding, it might be not impossible to run K24 machine code on a 65816, too.

Thanks for the explanation: agreed, the '816 is a complex beast and would be a demanding thing to build. But bringing in just a few features is a good idea.

Conceptually, there is a big gap between 6502 and 65816.

Hmm... in SciFi literature, if there is a big gap between two of the inner planets of a solar system,
this usually turns out to be an indicator that "something odd" had happened there in the past...

Feels like something (some CPU) between the 6502 and the 65816 is missing,
a design which didn't make it into public or such.
It's just a guess.

You're right - it's the 12 bit version. (!!)

Aha... and how many kBit of Signetics WOM could be attached to that 12 Bit 6502 CPU chip ?

In all honesty, the hardware complexity on the '816 isn't all that much higher than a 'C02. The ALU is still physically 8-bit, since everything it can do (except increments and accumulator shifts) is throttled by the 8-bit external bus. The registers are wider and there's a few more of them, there are more addressing modes and opcodes to handle them, and the interrupt system has a few extra features (to handle bus aborts, for example). Some of the address generating hardware will be wider, and there's something to multiplex the bank address onto the data bus pins.

But compare that to the leap up from the '816 to the ARM2, or from the 6809 to the 68000. It's a much smaller jump in practice, and it allowed keeping a great deal of backwards compatibility.

You can argue that the complexity shouldn't be much higher, but the size of and the need for Bruce's document tells us that it's a beast to implement or emulate. Implementing something a bit like an 816 mightn't be so bad, but that's not the same thing.

As for the ARM, I think we could argue that it is a lot simpler than the 816. They have comparable transistor counts, but one is rather regular and easily modelled, the other not.

The '816 would most certainly have been simpler if it was a legitimate clean room design rather than something striving for binary compatibility.

At the same time, though, it may well have lost a bunch of its performance. It's a fast chip (the clock is slow, but the chip is fast).

From the point of view of the project, going to 16-bit registers would have required reworking the guts of the CPU. Adding an extra 8 bits to the address bus, on the other hand, was very manageable and could be achieved through an optional PCB. ttlworks did a great job of pulling out just the right bits of 65816 functionality, and the result is a very nicely enhanced 6502 that can access lots of RAM. I like BigEd’s “K24-6502”, which is an apt name for it.

I have now added Garth’s 4MB WM-1 module to the mix, and extended the tests to use it. Here is a pic of the SBC stacked on top of the CPU, and the WM-1 module installed (shown just right of center). The LEDs flashing indicates a successful test.Note the ribbon cable carrying the ADX (Extended Address Bus) from the K24 card at the bottom of the stack to the SBC on top.

There is a bug in the address decoder of the SBC, so only the first 16 banks of 64k are addressable at the moment. Still, it proves the point and I can now move on. Next step is to test the SPI port. Currently contemplating using this nifty accelerometer/gyroscope as an easy-to-get-working but kinda cool device for testing. It’s 3.3V, so some level-conversion will be necessary. Still, could be lots of fun, which is after all the whole point!

The real problem when trying to be as compatible as possible to the 65816 are little details like:
What happens when trying to use 65816 instructions related to 24 Bit addressing in emulation mode,
what happens when switching from native mode to emulation mode with M=0 and X=0, //16 Bit registers
what happens when transferring an 8 Bit register into a 16 Bit register in native mode,
does direct addressing take an additional cycle or not when the direct register is not zero,
what are the exact timing and effects when trying to make use of /ABORT,
when telling a block move instruction to move 0 Bytes, does it move 0 or 65536 (?) Bytes...
...and so on.

For those who _believe_ that datasheets\manuals are 100% correct: it's hardware design, not religion.
Either you know for sure, or you don't.

That's quite a can of worms, and all this would have to be carefully and throughly tested with a real 65816 chip first.
Another problem is, that there seem to be less test suites for the 65816 than for the 6502\65C02.

So after 3 years and a half of tinkering, I think it's better/safer to get the design we have now into dry bags,
and to make building a 65816 compatible TTL CPU a new and different project, sorry.

But it's not as if these can't be tested. Some are simply software tests, easily checked with a monitor. Others require a bit more analysis.

There's also the case a actual compatibility, and real world compatibility. If your '816 emulator can run every game published for the SNES or Apple GS (or any other piece of software), how important is compatibility with the untested edge cases? For example, of the few '816 emulators I've looked at, none of them check if they're in native mode when they get a JML (JMP LONG) instruction. I have no idea what the chip will do if it sees that instruction in emulated mode. It's arguably "undefined", it could be a NOP, who knows. It may simply be a JMP instruction that takes 4 bytes instead of 3. But in any event, it's clearly not doing anything interesting enough to where someone chimed in how they use it as an OP code hack, so it simply never comes up in actual, tested programs. It would be nice to know to be completely compatible (i.e. so it does the correct wrong thing the CPU does), but in practical experience, it's not an issue. Sure, but, you have 6 issues listed above. How many more are there? 1? 10? 100? You make it sound insurmountable. It can be argued that folks may not know the answers to these simply because they're questions that aren't being asked by those who use the chips. I only know of a single test suite for the 6502, are there others?

Meanwhile there are lots of real world emulators for both the 6502 and '816 that seems to accurately run off the shelf software for their respective platforms. While not necessary fully tested, it's clear these system demonstrate enough compatibility to apparently do well in the demanding video game emulation community.

When we had started with trying to make the TTL CPU "bug compatible" to the NMOS 6502\6510,
we had the VICE source code, a nice article about the UFOs, and some info from Visual6502.org,
(that's more info than we have on the 65816),
nevertheless, this part of the project took us a year or so.
And we still had no time to back_annotate these hardware modifications into the schematics,
the PCB layout and the documentation.
Other hobbyists might be wanting to build that CPU too, so it's better to get what we have now into dry bags.

I would say, that the design we have now physically is at its limits (regarding signal trace length and grounding).
Adding any more circuitry probably would affect speed... and/or that neat 160mm*100mm Eurocard form factor.
So for adding more circuitry and registers, and for trying to push the CPU speed a little bit,
IMHO it's better to start a new and clean design.

With a bit luck, building a 65816 compatible CPU only could take 3 years+.
Sure, you could calculate and simulate a lot of stuff,
but the hardware won't be aware of your simulation results... and somewhat careless about them, too.
In our recent project, we had to take a logic analyzer trying to capture on the bus what went wrong,
then to write our own tools for translating the bus activity back into machine code and to mark
the interesting/offending parts of the capture.

_If_ building TTL CPUs would be as simply as it looks, probably more hobbyists would be doing it.
To put it this way: somewhere up in the thread, I had referenced Apollo 13 by making a joke
about building a CO2 filter by resorting to duct tape and the envelope of a C64 manual.
Really, building CPUs is a fascinating and entertaining hobby.

To quote Murphy: what can go wrong will go wrong. //As in: hope for the best, but plan for the worst.
The later you add changes (especially conceptual changes) to a design, the bigger the chance this backfires.
In the world of software design, you could say: "Oh, we are going to take care of that little bug later, after the release".
In the world of hardware design, things are different... and sometimes there is no "later".
That sort of hardware design is quite labor and time intensive stuff (not to mention the cost of components and PCBs),
so you at least try to do what is possible not to have too many "untested edge cases"
when starting a project.
//Pretty much like when you try to toss out some of the variables before trying to solve a big and complicated equation.


But back on topic: making a list of all the possible 65816 issues would take a PC and some spare time,
and these two things I lack at the moment, might be turning to the better in a few months.

My point is, that I'm no longer into building things.
I'm sitting in the "second line of the battle", trying to cover Drass's back...
...because when I had been building CPUs, I had a few arrows sticking in my back too many.
Not to sound rude or offending, but is there a test suite which checks the _full_ functionality of a 65816 ?
If there is one, please post a link.

There's a selection of 6502 test suites: see for example the visual6502 wiki for a list.

For 65816, a quick search led to some SNES test ROMs. It didn't look like a full test was in there. Bruce's document almost has a set of examples which could be machine-extracted into a set of tests.

It's not decided yet, if Drass is going to start another CPU project after finishing this one,
of course.

But just in case he goes for it, I would like to put a provoking thought to discussion here.
With K24, we have a mechanism for switching the instruction set (selecting a different microcode)
during run time... but it all is 6502 related.

What, if one would be trying to switch to a non_6502 related instruction set ?
I'm not talking about trying to be cycle or timing compatible to a non_6502 CPU,
it's just about the possibility of being able to run the legal instruction set of a non_6502 CPU.

;---

Let's start with the 6800.
Simply because the design team that did the 6800 later had some 6502 relevance...

Unlike the 6502, 6800 is big endian (high Byte first).
Stack operations seem to be post_decrement and pre_increment, like with the 6502.

What happens during the interrupts still needs to be investigated.
Conditional branches are a little bit more sophisticated than with the 6502,
on the other hand there is no decimal mode: just DAA and a half carry flag.
To me, the rest of the 6800 instruction set looks somewhat trivial:
;---

6800 would open a vector to implementing something like the 6809.
A TTL CPU designed to run the 65816 instruction set almost would have enough registers for a 6809 emulation.

6809 is big_endian, too.
But unlike with the 6502 and 6800, Stack operations seem to be pre_decrement and post_increment, like with 68k.
6809 is NOT binary compatible to 6800, because some of the opcodes have moved places in the table.

6809 is a complicated beast, with two prefix Bytes, and with two post Bytes (PUSH\PULL, and indirect addressing).
Some time ago, I had sent BigEd a scan of a flow diagram from SGS Thomson about the EF6809 bus activity,
which (to me) looked complete, and it was rather big.
IMHO the microcode sequencer of the TTL CPU we have now won't be up to the task of cutting something like this:
;---

8080, and sorry for posting this heresy in "the 6502 forum of all 6502 forums".
Just ahd to post it because the C128 has a Z80 inside for running CP/M.

A TTL CPU designed to run the 65816 instruction set almost would have enough registers for an 8080 emulation.
8085 is something like 8080 plus the instructions SIM and RIM.

It's an interesting question whether CP/M would boot with an 8080 compatible TTL CPU,
looks like nobody had tried this yet...
Anyhow, a lot of the software which runs on CP/M would insist in having the Z80 instruction set present,
and just trying to take a look at the Z80 instruction set hurts my brain, so let's change topic.

Now for a crude block diagram for the status register area of a hypothetical TTL CPU,
able to run 6502, 6800 and 8080 machine code.

We need an additional flag, the half carry flag.
Regarding the Z80, the V flag we know from the 6502 now also works as a parity flag.

//Parity checking could be done with a tree of XOR gates tied to the ALU output).

Basically, the "data bus connection" for the Bits of the status register just is "formatted"
by using buffers to fit to the CPU instruction set which currently is selected.
A crude (but more detailed) block diagram for handling the conditional branches,
which BTW does not include the 65C02 "test Bit and branch" instructions.
Maybe in a few years from now, maybe somebody picks up the concept and tinkers with it,
but for now I'm happy with having this stuff parked here.

Looking forward to see, how debugging the rest of our TTL CPU continues.
Cheers.

;--

Edit: back in 2011, I did an internet search, and found some references which might be useful:

"Bit-slice emulation of the INTEL 8085, Carson R. Stuart, New Mexico State University 1982, 380 pages
"Bit slice emulation of the 6800, 8080 and Z80 microprocessor", K. I. H. Fashim, Electrical Engineering and Electronics, UMIST 1979
"Super MC6809 microprocessor emulation using AMD bit-slice technology and products", Hossain Vahidi, California State University, Sacramento, 1987, 170 pages
"Emulation of the MC68020 on a 2900-based bit-slice host", Erin Handgen, Bryan Robbins, Veljko Milutovic, published in the book: "introduction to microprogramming", Prentice-Hall inc. 1992, ISBN:0-13-488917-7