Tek4404 wip

[Elektraglide]

REQUIRES -DUSE_TEK4404_CHANGES when compiling in order to work since it requires delays in ncr5385 and backing out resetting the serial interface in diserial.cpp

EDIT: no longer needs special #ifdef to build and run successfully.

[angelosa]

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?

[angelosa]

As above.

[pmackinlay]

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();
 }```

[Elektraglide]

With the above changes I get:

Tektronix 4404
Self Test Error-Keyboard Failure or Not. Attached [02, 0002]
Fatal Error - Cannot Initialize Keyboard_

Any ideas?

[pmackinlay]

The only other place that resets the receive register is when changing the receive baud rate, so it must be that; do the same thing.

[Elektraglide]

In duart_channel::write_chan_reg(), right? (Obv, I have not a clue how this chip works.)

[Elektraglide]

Given we check if any params have changed and early out, I just added a test if its also already syncronized which works but as I said before, I have no idea how this chip works so asking me to make changes like this is probably a bad idea.

	// no params have changed and already syncronised
	if (m_rcv_flags & RECEIVE_REGISTER_SYNCHRONISED)
		return;
		
	receive_register_reset();

[angelosa]

Is this a generic quadrature mouse that needs its own device?

[pmackinlay]

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.

[pmackinlay]

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();
 }```

[pmackinlay]

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.

[Elektraglide]

OK. I've had a few false dawns at being able to just boot. Running a script that does "cp /system.boot /tmp" 20-30 times seems to always flush out timing issues.

[Elektraglide]

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.

OK tried this and my disk thrashing script succeeds. Hurrah. Thank you.

BUT, XFI_ACK delay version takes 1m12s to run the copying script, the hd.hpp changes that to 5m25s.!! 5x slower, I'm guessing I can tweak that 770ns delay?

[Elektraglide]

BUT, XFI_ACK delay version takes 1m12s to run the copying script, the hd.hpp changes that to 5m25s.!! 5x slower, I'm guessing I can tweak that 770ns delay?

Ah no, making the delay less than 770ns hangs the machine on boot...

[pmackinlay]

Trying to speed up something which was failing because it was too fast seems illogical. A 5x slowdown doesn't seem out of order since you're talking about dropping back to ~1.3MB/s from whatever it was getting without limits before; how long does the script take on hardware?

The 770 wasn't random; it was chosen specifically to represent the documented throughput of the ACB-4000.

Again you seem to be ignoring that MAME is fundamentally about accuracy; usability of the end result is a nice side effect. If you want it to run at unrealistic speed, try unthrottling it or make local hacks, but don't expect those to make it upstream.

Another option would be to fix the broken software, which might even allow your hardware to use a modern/fast storage device.

[Elektraglide]

Trying to speed up something which was failing because it was too fast seems illogical. A 5x slowdown doesn't seem out of order since you're talking about dropping back to ~1.3MB/s from whatever it was getting without limits before; how long does the script take on hardware?

I will test on tek4404 h/w; I'm not in the country right now

[Elektraglide]

This PR now builds and works without need for magic #ifdef for Tek4404 and doesn't change ncr5385.
[I noticed tek4404 was using wrong clock frequency for ncr5385 - dont think it materially changes the problem - but good to use the documented crystal.]

[Elektraglide]

Trying to speed up something which was failing because it was too fast seems illogical. A 5x slowdown doesn't seem out of order since you're talking about dropping back to ~1.3MB/s from whatever it was getting without limits before; how long does the script take on hardware?

I will test on tek4404 h/w; I'm not in the country right now

Oh and just so to add some numbers to this:

My ACK hack is a transfer rate of 64k Bytes/sec
Using scsi_data_byte_period(770) is a transfer rate of 14k Bytes/sec

That does seem very very slow.

[Lord-Nightmare]

Trying to speed up something which was failing because it was too fast seems illogical. A 5x slowdown doesn't seem out of order since you're talking about dropping back to ~1.3MB/s from whatever it was getting without limits before; how long does the script take on hardware?

I will test on tek4404 h/w; I'm not in the country right now

Oh and just so to add some numbers to this:

My ACK hack is a transfer rate of 64k Bytes/sec Using scsi_data_byte_period(770) is a transfer rate of 14k Bytes/sec

That does seem very very slow.

which one these is more accurate to the real hardware?