-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tek4404 work_in_progress. #12574
base: master
Are you sure you want to change the base?
Tek4404 work_in_progress. #12574
Conversation
- 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few stray blank lines, some possible accidental whitespace changes, and some instances of inconsistent formatting that should be cleaned up prior to merging, but since this is a WIP asking for assistance, I haven't tried to nitpick those here.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- 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?
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.