EightSixteenEmu - modular 65816 emulator

[GamerFox]

https://github.com/lunarlabs/EightSixteenEmu

This is a dumb little work in progress just for fun thing I'm making. Its major feature that I'm designing this around is modularity in the memory map -- instead of having a hardcoded memory map configuration, you assign devices to memory address ranges. At this stage it's very basic -- I just finished adding all the opcodes, but hopefully I can get it to something that actually functions worth a whit.

[White Flame]

Nice, I did similar in my JS 65c02 emulator. If I'm reading your code right, it looks like you've arrived at the same conclusions: Register each address that a device covers individually in a lookup structure.

For JS, I used a default sparse Array, which happened to currently be faster than its other datastructures when integer keys are involved. People in C♯ land have been dealing with this as well: https://stackoverflow.com/a/76915618

Another big win is if all mappable devices are in a known I/O area, so you can have a fixed range check to see if you need to do a device map lookup at all, or just hit RAM directly, since this is such a performance hot spot.

[GamerFox]

Well, I'm running into a problem while testing -- I'm using https://github.com/SingleStepTests/65816 as the data to test against...

is it just me or are the MVN/MVP test JSONs in that repository just wrong? For example, the first line in 54.n.json starts with the accumulator at 0xEF9B, but finishes with it at 0xEF8B, and the last two cycles seem to be fetching the opcode and the source byte... Is it just me or does it look like it just recorded the first 100 cycles and gave up? I might have to write separate block move tests if that's the case!

[BigEd]

I find it impossible to say, as the json isn't really meant for human consumption.

Perhaps you could say what you think the test sets out to do, and what you find it actually doing - and perhaps submit an issue on github. If there is a mistake or limitation, it would good to have it explained, or even fixed.

[BigEd]

Here's a remarkable thing, which might be useful here, a real 65816 in a lab which you can send a program to - over the web - and get back a trace of 100 cycles of bus activity. 6502 also available.
https://chiplab.emulationonline.com/65816

Of course 100 cycles isn't much, but it's worth the price!

[AndrewP]

BigEd wrote:

Here's a remarkable thing, which might be useful here, a real 65816 in a lab which you can send a program to - over the web - and get back a trace of 100 cycles of bus activity. 6502 also available.
https://chiplab.emulationonline.com/65816

Of course 100 cycles isn't much, but it's worth the price!

Nice!

(Comment mostly just here so that I can find chiplab again)

[Dr Jefyll]

BigEd wrote:

Here's a remarkable thing

Remarkable? I'd say it's priceless!

I have never trusted WDC documentation. Having said that, the '816 datasheet's Table 5-7 (which details cycle by cycle behavior) seems comparatively trustworthy. But even a small omission by them or misinterpretation by me could be enough to upset the apple cart. I really do care about cycle by cycle behavior, especially in corner cases (such as when indexing results in a bank crossing). And here's the ideal solution. Get the answer straight from the horse's mouth!

-- Jeff

[BigEd]

With a real CPU in hand, writing a verification suite is so much easier: if it passes on the real thing, it's right! You still have to cook up an adequate set of tests, of course.

[GamerFox]

Could be interesting. The "initial state" setups wouldn't work so I'd have to write a whole burn in suite.

[GamerFox]

Tests have passed, so at least on a very rough level, it's cycle and logic compatible now.

Now I have to get onto working on devices -- most importantly a UART emulator that has a processor-facing interface similar to a real-world chip. Only question is what UART chip should I emulate?

Edit: I know some of you guys swear by the 28L92 but HOLY COW that's going to be a real bear to emulate!!