mame
mame copied to clipboard
Tek4404 work_in_progress.
This is a WIP getting Tek4404 to run. It now passes all the h/w tests apart from mouse. ( RAM, MMU, Serial, Timers, Sound, Video, Storage Devices) A boot manages to load the OS from "system.boot", starts up and tries to write some swap data. After writing 512 bytes, it never receives a STATUS ACK and just spins forever running the idle job and checking whether the write has completed.
It implements a derived ncr5385 that drives an LED for disk activity
I do not have the knowledge around scsi and new_scsi_bus to understand what the emulated devices are not doing that Tek4404 expects, so this is where I have got to. Very close but no cigar.
Can you fix the conflicts with the already-merged ncr5385 changes?
DATA IN finishes with a STATUS REQ shown below
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x029 phase DATA IN REQ
[:scsi:7:led_ncr5385] aux_status_r 0x88 (':maincpu' (747ADC))
[:scsi:7:led_ncr5385] xfi_in: data 0x75
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x049 phase DATA IN ACK
[:scsi:7:led_ncr5385] xfi_in: 0 remaining
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x00b phase STATUS
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x02b phase STATUS REQ
[:scsi:7:led_ncr5385] xfi_in: transfer complete
[:scsi:7:led_ncr5385] update_int 1
[:scsi:7:led_ncr5385] update_int 1 pc((no context))
[:scsi:7:led_ncr5385] aux_status_r 0x1a (':maincpu' (747E12)) <= AUX_STATUS_CD | AUX_STATUS_IO | AUX_STATUS_PAUSED??
[:scsi:7:led_ncr5385] int_status_r 0x02 (':maincpu' (747E18))
[:scsi:7:led_ncr5385] update_int 0
[:scsi:7:led_ncr5385] update_int 0 pc(':maincpu' (747E18))
[:scsi:7:led_ncr5385] cmd_w 0x54 (':maincpu' (747964))
[:scsi:7:led_ncr5385] transfer info (pio, single byte)
[:scsi:7:led_ncr5385] aux_status_r 0x9a (':maincpu' (747CD0))
[:scsi:7:led_ncr5385] xfi_in: data 0x00
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x04b phase STATUS ACK
DATA OUT finishes with a STATUS REQ shown below and never gets a STATUS ACK
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x028 phase DATA OUT REQ
[:scsi:7:led_ncr5385] aux_status_r 0x00 (':maincpu' (01258C))
[:scsi:7:led_ncr5385] dat_w 0x00 (':maincpu' (01259C))
[:scsi:7:led_ncr5385] xfi_out: data 0x00
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x048 phase DATA OUT ACK
[:scsi:7:led_ncr5385] xfi_out: 0 remaining
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x00b phase STATUS
[:scsi:7:led_ncr5385] scsi_ctrl_changed 0x02b phase STATUS REQ
[:scsi:7:led_ncr5385] xfi_out: transfer complete
[:scsi:7:led_ncr5385] update_int 1
[:scsi:7:led_ncr5385] update_int 1 pc((no context))
[:scsi:7:led_ncr5385] aux_status_r 0x1a (':maincpu' (012844)) <= why is the same as for a READ?
[:scsi:7:led_ncr5385] int_status_r 0x02 (':maincpu' (01284E))
[:scsi:7:led_ncr5385] update_int 0
[:scsi:7:led_ncr5385] update_int 0 pc(':maincpu' (01284E))
[:scsi:7:led_ncr5385] aux_status_r 0x1a (':maincpu' (012866))
Is this in a state where we could look at getting it applied as a checkpoint?
Because it's very difficult to review a PR with this much churn I went and looked directly at your source branch, and I have a few notes. I think Vas touched on some of these already but I want to reiterate them.
- Use LOGMASKED() so that logging can be controlled by category instead of being all or nothing.
- Always use braces with if statements. memory_translate() and similar functions are very hard to track when you're reading them because of the lack of braces.
- Because the Tektronix MMU is external to the 680x0 it should not be a superclass of the 68K core. I realize I set a poor example here with the Mac II and LC external MMUs so I won't hold that against merging this right now, but it's something to keep in mind for later. sun3.cpp is a better example of what an external 68K MMU should look like.
And addressing some comments I see in the code:
- The boot prom is called "maincpu" because a ROM region with the same tag name as a CPU will inherit that CPU's endianness and bus width properties.
- .mirror() is an inverse AND mask on the address. "1" bits in the .mirror() field are ignored when looking up the address.