> Have you tried going through the various checkout procedures in the manual > to make sure they all still work? If the 5370 firmware authors *didn't* > bake some timing dependencies into that 6800 code, they were the exception. > Of course, if your emulator is cycle-for-cycle faithful to the 6800 it's all > good. > -- john, KE5FX Most of the front panel functions I tried worked. But not all.
It's possible that the m6800 emulator is not bug-free. I just used one that I found on the net. I have not checked it. Yes, then there are the timing issues. When I first ran the code, and printed every instruction executed, it was clear after a while that a timing loop was running. Now whether this delay is critical to a measurement function or not is unknown to me. Although Poul-Henning can probably tell us with his reverse engineering of the code. Since that poor m6800 is only running at 1.5 MHz you would think that the emulator running on a modern machine would have no problem running many times faster than that. Unfortunately the software stack and USB delays when using that USB-to-parallel adapter in my setup causes everything to run many times -slower- than 1.5 MHz when any I/O is going on. The TI and frequency measurement functions work fine. The slowest effect I noticed is changing the trigger levels. The display update lags by 20 sec or so. Now using a microcontroller with direct bus access is another story. You can clock it from the 5370 10 MHz and use an internal timer to generate the 1.5 MHz bus clock. Then the emulator, now running much faster than the m6800, can count emulated cycles and schedule I/O at the exact time it would have occurred at 1.5 MHz. I will try some more complete testing. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
