Tek4404 wip #14519
Tek4404 wip #14519
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.
…dding a very short delay to dat_w improves reliability.
… delivered before tek4404 has executed its setup - when this happens tek4404 hangs forever. - making XFI_OUT_ACK delay 10us does not resolve issue; still get IRQ arriving too early..
- consistent formatting of bytes
…at or the port may be stuck into synchronous receive mode due to the default start bits = 0" This reverts commit 9070579.
- appears to be reason VM_tests failed with code 20
… inside memory_rw
…IRQ_6 line when VIntEn==0 - First thing in Vblank processing is reset VIntEn which is the ack for the IRQ
| #ifdef USE_TEK4404_CHANGES | ||
| return attotime::from_nsec(200); | ||
| #else | ||
| return attotime::zero; | ||
| #endif | ||
| } |
There was a problem hiding this comment.
I hate C/C++ compile switches with a passion. attotime::zero is a fallback that obviously needs changing depending on the controller needs.
Also: where this magic number comes from?
There was a problem hiding this comment.
This change does not make sense and will have no effect; ncr5385_device is not derived from nscsi_full_device.
| virtual void device_reset() override ATTR_COLD; | ||
|
|
||
| // ncsci_device implementation | ||
| virtual attotime scsi_data_byte_period(); |
There was a problem hiding this comment.
How this is not overriding the base method and manages to compile anyway? Is this ncr5385_device supposed to be a nscsi_full_device, and this function essentially do nothing here?
| #ifndef USE_TEK4404_CHANGES | ||
| receive_register_reset(); | ||
| #endif |
There was a problem hiding this comment.
Instead of hacking diserial, do this:
index dbefa1507be..e19716e8661 100644
--- a/src/devices/machine/mc68681.cpp
+++ b/src/devices/machine/mc68681.cpp
@@ -1641,6 +1641,7 @@ void duart_channel::write_chan_reg(int reg, uint8_t data)
void duart_channel::write_MR(uint8_t data)
{
+ bool const frame_change = (MR_ptr == 0) ? ((MR1 ^ data) & 0x1f) : ((MR2 ^ data) & 0x0f);
if (MR_ptr == 0)
{
MR1 = data;
@@ -1650,7 +1651,8 @@ void duart_channel::write_MR(uint8_t data)
{
MR2 = data;
}
- recalc_framing();
+ if (frame_change)
+ recalc_framing();
update_interrupts();
}```| // a set not a list | ||
| if (std::find(list().begin(), list().end(), monitor) == list().end()) | ||
| list().push_back(monitor); | ||
|
|
||
| m_monitor_index[monitor->oshandle()] = monitor; |
There was a problem hiding this comment.
These three OSD changes are for a separate PR.
| #define LOG_GENERAL (1U << 0) | ||
| #define LOG_MMU (1U << 1) | ||
| #define LOG_FPU (1U << 2) | ||
| #define LOG_SCSI (1U << 3) | ||
|
|
||
| #define VERBOSE LOG_GENERAL |
There was a problem hiding this comment.
Do not redefine LOG_GENERAL, that's already defined in src/emu/logmacro.h.
Also the canonical way is to express VERBOSE definition with parenthesis.
| if (0) | ||
| if (m_videocntl != data) | ||
| { | ||
| LOG("m_videocntl %02x\n", data); | ||
| LOG("m_videocntl VBenable %2d\n", BIT(data, 6)); | ||
| LOG("m_videocntl ScreenOn %2d\n", BIT(data, 5)); | ||
| LOG("m_videocntl ScreenInv %2d\n", BIT(data, 4)); | ||
| LOG("m_videocntl ScreenPan %2d\n", data & 15); | ||
| } |
There was a problem hiding this comment.
Merge these two ifs, also is this logging really useful? If you subscribed the relevant variables to save_item you can see the live state via the debugger CTRL+M instead.
| // copied from stkbd.cpp | ||
| int tek440x_state::mouseupdate() | ||
| { |
There was a problem hiding this comment.
Is this a generic quadrature mouse that needs its own device?
| palette.set_pen_color(0, rgb_t(0xec, 0xf4, 0xff)); // 2 color tiles | ||
| palette.set_pen_color(1, rgb_t(0x00, 0x00, 0x00)); |
| printf("vblank %d\n", state); | ||
| if (state && m_vint_enable) | ||
| { | ||
| m_maincpu->set_input_line(M68K_IRQ_6, ASSERT_LINE); | ||
| } | ||
| }); |
|
|
||
| I8255A(config, m_printer); | ||
| m_printer->in_pb_callback().set_constant(0x30); | ||
| m_printer->in_pb_callback().set_constant(0xb0); // HACK: vblank always checks if printer status < 0 |
pmackinlay
left a comment
pmackinlay
left a comment
There was a problem hiding this comment.
The ACB-4000 device which acts as a SCSI target used in this system no doubt accounts for the delays assumed by the host software. The ACB-4000 is documented as only sustaining up to 1.3MBps for SCSI data transfers (rather than the maximum 5MBps for a SCSI-I device).
You can simulate such a slow hard disk by overriding scsi_data_byte_period() in a SCSI target and supplying a suitable value. As an experiment, you can modify src/devices/nscsi/hd.h by adding the following:
virtual attotime scsi_data_byte_period() override { return attotime::from_nsec(770); }
This will cause the SCSI ACK signal for the default SCSI hard disk target to be delayed, producing a data rate of ~1.3MBps, and appears to eliminate reported SCSI issues.
Moving forward, adding a new SCSI device which represents a "slow" hard disk is the right interim measure until the ACB-4000 is emulated.
| #ifndef USE_TEK4404_CHANGES | ||
| receive_register_reset(); | ||
| #endif |
There was a problem hiding this comment.
Instead of hacking diserial, do this:
index dbefa1507be..e19716e8661 100644
--- a/src/devices/machine/mc68681.cpp
+++ b/src/devices/machine/mc68681.cpp
@@ -1641,6 +1641,7 @@ void duart_channel::write_chan_reg(int reg, uint8_t data)
void duart_channel::write_MR(uint8_t data)
{
+ bool const frame_change = (MR_ptr == 0) ? ((MR1 ^ data) & 0x1f) : ((MR2 ^ data) & 0x0f);
if (MR_ptr == 0)
{
MR1 = data;
@@ -1650,7 +1651,8 @@ void duart_channel::write_MR(uint8_t data)
{
MR2 = data;
}
- recalc_framing();
+ if (frame_change)
+ recalc_framing();
update_interrupts();
}```| static char const *const nscsi_phase[] = { "DATA OUT", "DATA IN", "COMMAND", "STATUS", "*", "*", "MESSAGE OUT", "MESSAGE IN" }; | ||
|
|
||
| if ((ctrl & S_BSY) && !(ctrl & S_SEL)) | ||
| if (ctrl & S_BSY) |
There was a problem hiding this comment.
I have previously suggested this change, and I confirm it's good; I think this is the only change required to ncr5385.cpp.
|
|
||
| if (m_cnt == 0) | ||
| { | ||
| #ifdef USE_TEK4404_CHANGES |
There was a problem hiding this comment.
I've tested simulating a slow hard disk instead of this change, and it can successfully complete the "diskrepair" and reach a login prompt. I don't have the knowledge of this system to test further, but I believe this change is wrong and the delay occur in the target, not this device.
| #ifdef USE_TEK4404_CHANGES | ||
| return attotime::from_nsec(200); | ||
| #else | ||
| return attotime::zero; | ||
| #endif | ||
| } |
There was a problem hiding this comment.
This change does not make sense and will have no effect; ncr5385_device is not derived from nscsi_full_device.
3 participants
REQUIRES
-DUSE_TEK4404_CHANGESwhen compiling in order to work since it requires delays in ncr5385 and backing out resetting the serial interface in diserial.cpp