Since there doesn't seem to be an emulator for the 65816 that is easy to use with Linux, I've decided to embrace my delusions of grandeur and write my own. Now this all but makes sure it will be horribly crude, so I've named it "A Crude 65816 Emulator" (crude65816). The PRE-ALPHA version is now on GitHub at https://github.com/scotws/crude65816 .

"Pre-Alpha" means that some stuff gets set up and the main loop will run (or single-step). To save everybody the trouble of downloading, this is pretty much the whole extent of the output at the moment:
"go-native" switches the processor to native (16-bit) mode, which reflects in the ".state" command (for non-Forthwrights: Forth commands with a dot by convention print information). All the stuff about "not yet coded" is because the mini-monitor program I'm using -- all still 8-bit code for the 6502 -- just hits a bunch of placeholder routines. The BRK command simply triggers Forth QUIT for the moment.

The memory model is crude as well. The emulator simply reserves 16 MByte of RAM as the whole address space of the 65816 (which is why gforth must be called with "-m 1G" option). There is a configuration file that lets you load ROM into the address space, and define "putchar" and "getchar" (don't work yet). There is no write protection for these ROM areas. The crude65816 will attempt to handle the mode switches with DEFER statements. The devil will obviously be in the details, and I haven't even started to code the addressing modes.

So now I have a chicken-and-egg problem, because to really test the emulator, I'll need a 65816 assembler, and to test the assembler, I'll need an emulator. At some point, I'll be adapting my tasm65c02 assembler (https://github.com/scotws/tasm65c02) to a 65816 version.

Any feedback, corrections or suggestions are of course most very welcome!

Good stuff, Scot! I kind of envy you, because writing an emulator would be sorta fun... most of the time. But I also pity you, because the rest of the time it would be tedious, difficult and crazy-making! -- especially for a chip like the '816, which has a variety of modes to account for.

One thought struck me, and that is that, later on, it would be great if it were possible to use a real, silicon '816 to mediate between your new emulator and your new assembler. The '816 could be in a real system, or it could live in a primitive test jig which single-steps the clock and otherwise just supplies stimulus and records the response. Such a rig could validate both the assembler and the emulator -- not to mention revealing any behavioral details not clearly spelled out in the datasheet.

I realize it'll be a while before you could use such a thing, but it might be worth anticipating as you're writing the code.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Status update: The emulator can now do loops! This works: Which gives us this after all the single-stepping: I'm guessing I have about a third of the opcodes coded, mostly the low-hanging fruit, of course. It's not the coding that is taking all the time, it is the testing. But we're getting there. Size of the emulator Forth code currently 34kb (including comments), hope to keep it under 64kb.

Always good to see progress! Does this mean you're accumulating a 65816 testsuite? That could be very handy!

(Cough) Now I am, I waited too long to start it, and am paying the price. Unfortunately, I don't think it will be of general use, because it's a test suite for the emulator, not the CPU itself, and since this is Forth, it works as an ad-on to the emulator that directly accesses its routines. The code-in-development looks something like this: OPC-E8 is the call to the emulator routine for INX. For giggles, I'm having the results displayed in a matrix output with AT-XY: I have thought about a real test suite for the processor itself, but that should probably wait until I can test it on a real computer instead of only on an emulator written without access to said machine . We'll get there, but it's going to take some time ...

It will be a struggle to get some reuse out of this testsuite! Here's an idea which might help portability: capture the inputs and expected outputs in a datastructure and then exercise tests from that by constructing a preamble, operation, and postamble using the language of your choice. The source initialising the datastructure might then be mangleable into a form useful to other emulators. Maybe even mangleable into a self-testing '816 binary??

Yes, after thinking about it for a while my way does seem a bit stupid; it makes far more sense in the long run to write something in assembler that can be run through real hardware for verification and then through any emulator. I'll start looking into that instead. Thanks for pointing that out.

Once all the instructions are coded, we should be able to run a "normal" 6502 test suite in emulation mode, shouldn't we? I mean, isn't that the whole point of emulation mode ?

Yes indeed, I would expect in emulation mode that (for example) both of Klaus' testsuites should pass - the 6502 one and the 65C02 one. Which will answer the question about the various bits of P too.

(Edit: you might be interested in this 65816 project over on stardot. It's not emulation but a homebuilt system, but there are points raised about the various modes of the 816.)

So this happened:
Torn from the back of the door. Not ready to declare ALPHA quite yet (defined as "Everything does something, sometimes even the right thing"), still missing the interrupt routines. But getting there, getting there.

Interesting all the little problems he had to solve in order to get things working. As an aside, I see the myth about the usefulness of filled planes on computer PCBs was being perpetuated.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Now we're ALPHA: "Everything does something, sometimes even the right thing."

The main known issue is that wrapping rules are ignored, which is the first priorty (once I have understood how it works). Also, flags in Decimal Mode. The code is a total and complete mess, because I have consciously avoided trying to factor and optimize stuff until I'm really, really sure it works as it is. I'm sure there are as many bugs as vowels in the code.

Still, and to my complete amazement, Tali Forth boots out of the box: This was just a "what the hell" test, it's too early to run even the 6502 testing suites, and I don't even have tests for 65816 native mode yet. But very satisfying nonetheless.

So at the very least, I am now the author of an overly complicated 65c02 emulator .

Congrats!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I have now added the wrapping rules, which was seriously unfun for Direct Mode by the way. In theory, the emulator should now work like the real MPU.

(Wait, there is no smily for "laughing hysterically while rolling on the floor"? Darn.)

No, seriously, first I need to clean up the code while resisting the temptation to optimize, because there are bunch of "dead" words there that sounded useful at the time but are now not called, and some really ugly IF constructs. I'll also be renaming some of the words that made sense at the time, which was obviously at three in the morning. Then I need to begin systematic testing, starting with the 6502 suites for emulated mode.

As for the quick-and-dirty stress testing, Tali Forth for the 65c02 does boot and will even let me define loops. But a more careful analysis shows that it isn't loading the compound words such as "IF" that are defined separately, and there are no Tali "splash" welcome lines, only from the Kernel. So something is definitely not working right yet somewhere.

Still, if anybody wants to experiment with the emulator, feel free. At this stage, the source code is probably still better documentation than the manual. I'll probably just recorde any feature suggestions for the moment until the basic code has been tested more, but would definitely welcome them, as of course any other feedback.

Well, that was easy: It turns out that lda.y (LDA absolute Y indexed) was coded completely, absolutely, and totally wrong, in the sense of WTF was I thinking, which is even more perplexing because lda.x was just as it should be. Weird, but now Tali Forth works perfectly as far as I can tell with trivial command-line experiments. Next step is to get emulation mode to pass the 65c02 tests.