OT: 68K core emulation (was Re: LisaEm 1.0.0-RC2 Available for download)

gilles wrote:
>
> The castaway Atari ST emulator (previously known as FAST) has it's own
> 68k core. Even if this emulator is not well known, the cpu emulation
> is good. It was the only I found with bus error emulation. Until
> version 0.2 or 0.4 my emulator was built with this core (but a bit
> modified).
> I briefly tested Scream that is also an atari ST 68k core but it
> didn't work well.
> So I moved to musashi that is used in MAME and MESS. Macworks booted
> correctly after that change.
> The UAE cpu core is also interesting and very close to musashi.
>
>

When I first started, there was only the UAE core, and Generator. :-) UAE didn't yet have JIT support, and Generator's core was much fast since it's almost a JIT.

I'm actually running some new 040 CPU core tests for Gwenole Beauchesne on the NeXT slab right now, but they are taking forever. :-) So fairly soon, we should see far more acurare 020 and 040 emulation.

StarScream is an interesting core since it's assembly, but of course that makes it much harder to maintain.

> My 6809 CPU core declares the M pseudo register, so addressing was
> also traced.
> In fact I could not run 2 cores in parallel since one code is C and
> the other is java.
>

Well, you sort of can via native methods, but it's a huge pain.

I don't have an M register, but I do have variables that are set after MMU translation, so I sort of have an M register equivalent.

I think the nicer way of going with it is to keep a cache of the addresses and before/after values that were touched by one core, and expect the other core to touch all of the same, then complain very loudly if the other core tries to do anything different. Of course, the cache would be flushed after each opcode to prevent the test results from bleeding through.

I have the right infrastructure for this in LisaEm - well almost, since I can turn on a flag and have the code go through a set of debugging functions whenever memory is accessed. It should work for I/O as well, but there's no tracking as to what I/O did. So at least for writes, I should be able to track the requests, and almost for reads as well with a bit of modification.

I suppose on I/O calls, I'd want to skip the actual changes for the 2nd core and instead compare the write values between the first and second core; for reads, I'd return whatever the 1st core read, so the cache could be useful here -- if I ran two cores in parallel each with its own memory, I'd still need to deal with I/O, so the cache seems the right way to go.

Of course a parallel set of registers is required too... and interrupting one core would have to interrupt the other as well.

So sounds like the right way to go. I'll give it a whirl against Musashi and see what breaks. Who knows, maybe I'll find bugs in both cores. :-) What's annoying is that each CPU core has its own interface.

Would be nice if there was some unified standard for all CPU cores... well, I suppose MAME/MESS cores would meet that requirement, but I meant 68K cores here, so that way multiple cores could be tested together and bugs in all of them could be found. I suppose #define is my friend here. :-D I could test 3 cores, together, and whenever 2/3 gave the same result, the buggy core would be clear - but of course the two could be wrong, and the 1 could be right.

Testing against a real CPU is the best way to go, but you always need a machine with lots of CPU power and network bandwidth. The NeXTStep is slow when compared to modern PC's, and the 10BT Ethernet is really a big bottleneck for this... the bitfield opcodes which take 3 operands take more than a week to run for example and so far produced about 1GB of output - only got through most of one opcode so far...

Well, the good news is in a few months we'll have fixed most of the 68K CPU cores out there and what we learn from this can probably be reapplied elsewhere.

In terms of the Lisa, ideally, I'd love to have some sort of umbilical cord from the Lisa's CPU to a much faster machine that can analyze what it does in realtime. I have a logic analyzer which works very well, but only for very short runs which is almost exactly what's needed, but it's not "deep" enough and can't interface with another machine in real time to compare the results. I don't think slowing down the host CPU would work too well since I/O would break before anything interesting loads. There are modern USB logic analyzers, but I'd need to use them in parallel with separate USB PCI cards to get enough bandwidth, and even then, it's very tight I/O and requires a very fast set of CPU's to keep up...

(Thanks to James, for the 68k cable and introducing me to HP's analyzers :-)

> When I selected the rom file it was not stored (tried several times
> and path / restart).
> I tried to save to another location to edit the conf file... and it
> worked.
>

Ok, I'll look into this. The ROM path isn't something I set very often, I've set it once in each environment and left it there... so it's likely to be something that isn't tested as well as it should be. :-) Received on 2007-07-10 20:12:47