I was surprised to learn at the beginning of the year that
MAME - the thing that started life as an arcade emulator - has changed over the years to be per-chip signal accurate emulator and supports many workstations such as Sun, MG1 etc.
For the past 6 months I've been battling with getting the MAME Tektronix 4404 emulator to work and I am very close but could do with some advice / ideas.
When I started, the emu would start but do little else. I got it to run and pass its selftest with some input of a couple of folks on the MAME discord but it would not boot the OS.
Over the summer I did manage to fix loading the OS file by adding a
3.5us delay on one of the scsi protocol commands (XFI_OUT_ACK). What was happening is the (emulated) scsi would finish and immediate raise an IRQ. The Tek4404 was not expecting this so quick and would clear the IRQ then busy wait listening for an IRQ that it had just erased. Doh!
Anyway, that allowed it to load the OS (see screenshot) and start the OS proper. Woot.
Once task#0 is running it runs a task that execs the program
/etc/init. How this works is the code is loaded, then its all swapped out to disk, then it starts execution (typically at address 0x0). This immediately page faults (nothing there), brings in the page and continues. This works (with a caveat).
[Tek4404 has a custom MMU that only does address translation in user mode that I *think* I've implemented correctly but wise peeps of MAME tell me the code is not in the preferred place.]
I can then single step the
/etc/init code for a few instructions in the
text section after which it writes a word to its
data section at 0x507e (ie page table entry 5). Only
text is in memory at this point so it page faults, goes off, allocates a new VM page, and (I assume) reads that 1 page into newly allocated memory. The code to restart task execution inspects the task signal to confirm the page has swapped in but never gets the signal it completed, so never makes it ready to run, so never re-starts the faulting instruction.
So it does not halt. Its running the scheduler, doing idle tasks and and a whole bunch of housekeeping. It just never sees the task#1 as ready to run so continues indefinitely.
So I somehow need to work back to figure out why it never gets the signal from scsi that its loaded - my hunch is its a timing issue like when it was loading the OS.
The ghidra file is on my repo if you want to dig around. Its not helped that I don't know alot about scsi protocol implementations - I *think* its just a couple of guys in MAME dev community that sort of
own that code. The Tek4404 uses the
ncr5385 scsi controller chip and its this file that I've been poking at over the months.
Thoughts?
View attachment 1291425
github.com
Rebuilding gcc1.42 is moderately scary and will have to wait for another day.
