Tek4404 work_in_progress. #12574
Open
Tek4404 work_in_progress. #12574
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- some comments in trying to understand how to attach a target scsi device
…sent in m_videocntl
- MAP_SYS_WR_ENABLE eppears to really mean read/write enable - page table needs to be accessible without MAP_VM_ENABLE
- need to find a way of faking a connection so we can get debug output
…lftest mamedev#20 before failing
- mouse position (gray codes?) seems borked
…lftest now passes but not sure this is right solution - Timer selftest fails; need a way of resetting interrupt when writing to 0x1xx
- hook writes to m_timer 0x1xx and clear IRQ1
- helped by Lord Nightmare; Interval Timer now passes
- added 8255 mapped to 0x7b2000 to handle Centronics interface; not working
…ing something else
…ide the main CRT box.
- rename irq1_w irq1_raise - resets m_led_disk state on machine reset
…e code path for DATA OUT is missing some things - done by DATA IN. WIP adding them doesn't help.. - STATUS REQ is never STATUS ACKed; unclear what is missing
|
Can you fix the conflicts with the already-merged ncr5385 changes? |
- testing CMD_INT check is correct
|
DATA IN finishes with a STATUS REQ shown below DATA OUT finishes with a STATUS REQ shown below and never gets a STATUS ACK |
- added a tap as suggested by pmackinlay for driving disk LED
pmackinlay
reviewed
Jul 15, 2024
| m_screen(*this, "screen"), | ||
| m_acia(*this, "acia"), | ||
| m_printer(*this, "printer"), | ||
| m_prom(*this, "maincpu"), // FIXME why is the bootrom called 'maincpu'? |
There was a problem hiding this comment.
The region can be called anything, it just needs to match the name given in the ROM_REGION macro, and the parameter to the .region() function in the memory map.
| m_led_1(*this, "led_1"), | ||
| m_led_2(*this, "led_2"), | ||
| m_led_4(*this, "led_4"), | ||
| m_led_8(*this, "led_8"), |
There was a problem hiding this comment.
It's better to combine these into a single output_finder<4>, and use the m_led(*this, "led_%u", 0U) syntax here, and m_led[N] = ...; elsewhere.
| m_led_8.resolve(); | ||
|
|
||
| m_led_disk.resolve(); | ||
| m_maincpu->space(AS_PROGRAM).install_write_tap(0x7be002, 0x7be003, "led_tap", [this](offs_t offset, u16 &data, u16 mem_mask) { m_led_disk = !BIT(data, 3);}); |
There was a problem hiding this comment.
Since the tap is 16 bits wide and the ncr5385 is hooked up to the high byte on the bus, you should probably be testing bit 11 instead of bit 3 here.
| } | ||
| } | ||
|
|
||
| u8 tek440x_state::rtc_r(offs_t offset) |
There was a problem hiding this comment.
If it's really an mc146818, then it's already in the machine config should be added to the memory map and these stubs won't be required.
| @@ -245,6 +246,9 @@ u8 ncr5385_device::aux_status_r() | |||
|
|
|||
| if (!m_int_status) | |||
| { | |||
| // AB mask out any bits | |||
| data &= ~(AUX_STATUS_MSG | AUX_STATUS_CD | AUX_STATUS_IO); | |||
There was a problem hiding this comment.
I don't think this should be necessary; resetting and latching of these bits should be properly controlled by changes to the interrupt status. Did you find a bug in the logic?
src/devices/machine/ncr5385.cpp
Outdated
| // clear data and ACK | ||
| scsi_bus->data_w(scsi_refid, 0); | ||
| scsi_bus->ctrl_w(scsi_refid, 0, S_ACK); | ||
| #else | ||
| // clear ACK except after last byte of message output phase |
There was a problem hiding this comment.
I don't think this is correct; this logic only applies for the message input phase, to allow the initiator the chance to raise ATN to reject a message from the target if necessary. The same thing does not apply during message output.
added 13 commits
August 17, 2024 10:25
- clearing bits before regenerating
… tek4404 to continue booting..
…now the blocking issue - I had added some logic that treated pte 0 as special but that appears wrong..
… is written on first user access of memory - added set_emmu_enable(true) to handle inst restarts.. - wrapped memory_r with !side_effects_disabled() - on bus error, sets inbuserr so service routine can get autovector without translation - mapcntl_w() logs current page table contents / flags
…ized data somewhere that causes failures?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.