RespeQt general discussion

[TheMontezuma]

I guess this is an XBIOS issue. Please read this thread.

You kept pressing the OPTION key too long.

The XBIOS controls (or let the applications control) if BASIC is on or off, so it does not matter if you keep the OPTION key pressed when booting (however XBIOS detects it and uses for other purposes - in this case it is endlessly looking for something in the disk directory).

Please re-try without pressing the OPTION key.

Edited March 30, 2016 by TheMontezuma

[GoodByteXL]

There seems to be a difference between the win version and linux version. This demo

 

https://atariage.com/forums/topic/250787-arsantica-3-demo-released-at-revision-2016/

 

won't run through from the linux version of RespeQt 3. It stops at sector 361.

From R3 Win and on real hardware (1050) it works fine.

 

Bildschirmfoto vom 2016-03-30 08:53:15.png

 

Does the custom SIO loader causes this?

 

I guess this is an XBIOS issue. Please read this thread.

You kept pressing the OPTION key too long.

The XBIOS controls (or let the applications control) if BASIC is on or off, so it does not matter if you keep the OPTION key pressed when booting (however XBIOS detects it and uses for other purposes - in this case it is endlessly looking for something in the disk directory).

Please re-try without pressing the OPTION key.

I had read the thread, that's why I got aware of the demo...

 

And no, that's not the issue as I didn't press <OPTION> at all. It is as I wrote:

 

The demo runs well from R3 Win version and stops at sector #361 under R3 on linux. The question however is: What causes this?

When pressing <OPTION> under linux it will revolve at sector #361-362 forever.

Edited March 30, 2016 by GoodByteXL

[TheMontezuma]

I assume that you tested the ATR from the post #14 and that you use a SIO2PC/USB cable with hardware handshaking and that hardware handshaking is selected in the RespeQt settings.

What is the OS version that you use (I mean standard or patched for Hi-Speed SIO, etc.)?

And what is the data rate settings in RespeQt that you used (19200 or more)?

[GoodByteXL]

I assume that you tested the ATR from the post #14 and that you use a SIO2PC/USB cable with hardware handshaking and that hardware handshaking is selected in the RespeQt settings.

What is the OS version that you use (I mean standard or patched for Hi-Speed SIO, etc.)?

And what is the data rate settings in RespeQt that you used (19200 or more)?

At first I was just curious and started the demo from linux as it is my working desktop system. Then tested all three versions on R3 linux and it is always the same: It stops at sector #361 when booted without doing anything like pressing <OPTION>, e.g.

 

Whereas from 1050 floppy disk drive and under Win 7 on R3 it works fine on the same standard OS A8 machine. The speed settings in R3 are of no importance as the loader in the demo defaults to the OS settings, which are standard in my case, 1xSIO. (SDX users do not need a patched OS, not even for BT ).

 

To me it seems that the code in the backend of RespeQt for the win and linux versions is different in SIO handling. At least it would explain why there are hickups on R3 when using SIO that do not appear on win.

 

Hopefully someone with more insight than me can investigate and fix that.

[TheMontezuma]

Thanks for reporting your findings.

I've just checked it with my RPI and see the same problem.

Tommorow I will try to record the communication with the logic analyzer and compare it with Windows.

[TheMontezuma]

Here are my findings:

1) The xBIOS uses its own SIO procedures.

What you see in the first screen shot is that that the ATARI sends a command frame almost immediately after it received the proceeding data frame (a disk sector).

 

The XBIOS needs (in average) less than ~1ms for it (standard DOS and SIO procedures are slower and need ~10ms).

It looks like that XBIOS is too fast or at least too fast for Linux RespeQt implementation.

 

2) The following screen shows what happens when RespeQt does not process the command frame:

 

The XBIOS re-sends the frame (error handling) and this one is answered properly.

This is what you see, when the first sectors are loaded (in the RespeQt log window everything looks OK, since it does not display the first command frame)

 

3) The next screenshot shows the last command frame sent from the xBIOS:

 

Again this command frame is not detected in the RespeQt (~0.5ms between data frame from RespeQt and command frame from ATARI), but this time the xBIOS error handling does not work and the command frame is not re-send anymore (not a single byte is transferred over SIO anymore...).

 

Summary:

There are 2 issues:

- one related to RespeQt, which slows down the communication, but it should not stop from loading the demo

- one related to xBIOS: not reliable SIO error handling (this is why it suddenly stops loading)

 

I have some ideas regarding improvements to the low level SIO communication handling in RespeQt and will report if they worked.

And I will report the issue 3 to XXL.

[TheMontezuma]

XXL explained me that the demo does not use xBIOS.

It only uses xBOOT tool (which uses standard OS SIO). This is the part which is working.

Then the "IRQ-Loader by Heaven" takes over and we have a problem with error handling...

[Joey Z]

Here are my findings:

1) The xBIOS uses its own SIO procedures.

What you see in the first screen shot is that that the ATARI sends a command frame almost immediately after it received the proceeding data frame (a disk sector).

 

lin_1.JPG

The XBIOS needs (in average) less than ~1ms for it (standard DOS and SIO procedures are slower and need ~10ms).

It looks like that XBIOS is too fast or at least too fast for Linux RespeQt implementation.

 

2) The following screen shows what happens when RespeQt does not process the command frame:

 

lin_2.JPG

The XBIOS re-sends the frame (error handling) and this one is answered properly.

This is what you see, when the first sectors are loaded (in the RespeQt log window everything looks OK, since it does not display the first command frame)

 

3) The next screenshot shows the last command frame sent from the xBIOS:

 

lin_3.JPG

Again this command frame is not detected in the RespeQt (~0.5ms between data frame from RespeQt and command frame from ATARI), but this time the xBIOS error handling does not work and the command frame is not re-send anymore (not a single byte is transferred over SIO anymore...).

 

Summary:

There are 2 issues:

- one related to RespeQt, which slows down the communication, but it should not stop from loading the demo

- one related to xBIOS: not reliable SIO error handling (this is why it suddenly stops loading)

 

I have some ideas regarding improvements to the low level SIO communication handling in RespeQt and will report if they worked.

And I will report the issue 3 to XXL.

 

The linux serialport-unix checks to see that command went inactive, before it goes active. So RespeQt must detect the *edge* of command, and if it's missing this, then it will wait until command has gone high again (which would be after the command is transmitted) before it is able to process commands again. I suspect this is the cause of the issues, but I'm confused on how .73ms is too short of a time to be able to detect the edge. Looking through the entire process, not anywhere is there a significant delay between where RespeQt sends the last byte of the data, and then starts looking for the next command. Of course, multithreading stuff is going on, so it's possible after RespeQt is done processing the command, it switches to another thread and that causes a delay.

 

If that's the cause, then using 'none' handshaking could solve the issue, and could function as a good test as to what exactly is going on.

Edited April 1, 2016 by Joey Z

[Heaven/TQA]

Thanks. I don't handle errors at all (in terms of retry).

 

As I am using the irq loader basically used in HARD's Joyride and Cool Emotion demo please check them, too? Would be interesting....

[GoodByteXL]

 

The linux serialport-unix checks to see that command went inactive, before it goes active. So RespeQt must detect the *edge* of command, and if it's missing this, then it will wait until command has gone high again (which would be after the command is transmitted) before it is able to process commands again. I suspect this is the cause of the issues, but I'm confused on how .73ms is too short of a time to be able to detect the edge. Looking through the entire process, not anywhere is there a significant delay between where RespeQt sends the last byte of the data, and then starts looking for the next command. Of course, multithreading stuff is going on, so it's possible after RespeQt is done processing the command, it switches to another thread and that causes a delay.

 

If that's the cause, then using 'none' handshaking could solve the issue, and could function as a good test as to what exactly is going on.

No, it doesn't Upgraded yesterday to Linux Mint 17-3 64 bit on my desktop. There is as mall difference now as it does not stop any longer exactly at sector #361. A few more sectors slip through before it stops. See the snippet from the log:

[Disk 1] Mounted 'dsr_arsantica3_revision2016_ED.atr' as 'ED Diskette (130k)'."
Serial port speed set to 19200."
Emulation started through standard serial port backend on '/dev/ttyUSB0' with NO handshaking."
[Disk 1] Get status."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 2 (128 bytes)."
[Disk 1] Read sector 3 (128 bytes)."
[Disk 1] Get status."
[Disk 1] Read sector 361 (128 bytes)."
[Disk 1] Read sector 4 (128 bytes)."
[Disk 1] Read sector 5 (128 bytes)."
...
[Disk 1] Read sector 67 (128 bytes)."
[Disk 1] Read sector 68 (128 bytes)."
[Disk 1] Read sector 361 (128 bytes)."
[Disk 1] Read sector 69 (128 bytes)."
[Disk 1] Read sector 70 (128 bytes)."
...
[Disk 1] Read sector 89 (128 bytes)."
[Disk 1] Read sector 90 (128 bytes)."
Emulation stopped."

Serial port speed set to 19200."
Emulation started through standard serial port backend on '/dev/ttyUSB0' with CTS handshaking."
[Disk 1] Get status."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 2 (128 bytes)."
[Disk 1] Read sector 3 (128 bytes)."
[Disk 1] Get status."
[Disk 1] Read sector 361 (128 bytes)."
[Disk 1] Read sector 4 (128 bytes)."
[Disk 1] Read sector 5 (128 bytes)."
...
[Disk 1] Read sector 67 (128 bytes)."
[Disk 1] Read sector 68 (128 bytes)."
[Disk 1] Read sector 361 (128 bytes)."
[Disk 1] Read sector 69 (128 bytes)."
Emulation stopped."
Serial port speed set to 19200."

Thanks. I don't handle errors at all (in terms of retry).

 

As I am using the irq loader basically used in HARD's Joyride and Cool Emotion demo please check them, too? Would be interesting....

As it works flawlessly from RespeQt 3 on Win 7 and from real hardware (1050) there must be a difference in SIO handling by the Linux version causing this issue.

[TheMontezuma]

GoodByteXL,

sure, there is a difference between Linux and Windows (OS, FTDI drivers, low level SIO code) and the Logic Analyzer shows that the command frames are not recoginized by Linux RespeQt.

However it should still work, if the IRQ Loader would handle SIO errors (resend command frames).

What we have to do is to find out why RespeQt is not reacting on the command frames if they come so quickly.

[GoodByteXL]

What we have to do is to find out why RespeQt is not reacting on the command frames if they come so quickly.

Exactly :-). It should behave like a normal SIO drive ala 1050.

So I hope fine tuning will be successful.

 

RespeQt has already matured quite properly. See the log file from running SDCS 3.2G 50Hz

[Disk 1] Mounted 'SD32G_HD.atr' as '65535 sector DD HardDrive (16383k)'."
Serial port speed set to 19200."
Emulation started through standard serial port backend on '/dev/ttyUSB0' with CTS handshaking."
[Disk 1] Get status."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 2 (128 bytes)."
[Disk 1] Read sector 3 (128 bytes)."
[Disk 1] Read sector 325 (256 bytes)."
[Disk 1] Read sector 326 (256 bytes)."
...
[Disk 1] Read sector 331 (256 bytes)."
[Disk 1] Read sector 332 (256 bytes)."
[Disk 1] Speed poll."
Serial port speed set to 125000."
[Disk 1] Read sector 333 (256 bytes)."
[Disk 1] Read sector 334 (256 bytes)."
...
[Disk 1] Read sector 361 (256 bytes)."
[Disk 1] Read sector 362 (256 bytes)." [x2]
[Disk 1] Read sector 363 (256 bytes)."
[Disk 1] Read sector 364 (256 bytes)."
[Disk 1] Read sector 365 (256 bytes)." [x2]
[Disk 1] Read sector 366 (256 bytes)."
...
[Disk 1] Read sector 371 (256 bytes)."
[Disk 1] Read sector 372 (256 bytes)." [x2]
...
[Disk 1] Read sector 375 (256 bytes)."
Serial port speed set to 19200."
[Disk 1] Speed poll."
Serial port speed set to 125000."
[Disk 1] Read sector 1 (128 bytes)."
...
[Disk 1] Read sector 664 (256 bytes)."
[Disk 1] Read sector 1 (128 bytes)." [x2]
[Disk 1] Read sector 37 (256 bytes)."
[Disk 1] Read sector 38 (256 bytes)."
...
[Disk 1] Read sector 433 (256 bytes)."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 39 (256 bytes)."
[Disk 1] Read sector 563 (256 bytes)." [x2]
[Disk 1] Read sector 564 (256 bytes)."
Serial port speed set to 19200."
Serial port speed set to 125000."
[Disk 1] Read sector 565 (256 bytes)."
...
[Disk 1] Read sector 665 (256 bytes)."
Serial port speed set to 19200."
[AspeQt Client] Date/time sent to client (02.04.16 12:36)."

Notice the little hick-ups -> 2x. Sometimes there are 3x (but not here). One wouldn't even notice without checking the log file. There will be more hick-ups when running software from an ATR with 512-byte-sectors. Without a FIFO there will be much more hick-ups and frequently a stop.

 

So trying the same on a stock XL/XE probably won't be successful. But at least at PD 3 or 4 it should work on a stock machine.

[Joey Z]

In the past, we've had issues with tcdrain's timing not being accurate when using SIO2PC-USB. At the end of writeRawFrame, there is a call to tcdrain. It should still work if we remove this call to tcdrain, although you'd best get the latest source from git which has a setting to change SIO complete and error response timing, as that may be required to make things work properly (although the default delay will probably work regardless).

As it is, with SIO2PC USB, tcdrain pretty much does nothing for single-byte transfers. We did some tests, and transferring 1 byte, and doing a tcdrain returned pretty much immediately. Doing multi-byte transfers acted pretty weird, though I don't remember exactly what happened.

EDIT: I ran the timing test Hias wrote again, trying with 129 bytes transferred. At 19200, 129 bytes, 10 baud per byte, you get that it should take 67188us to transfer the data. Using Hias' drain-timing tester (http://atariage.com/forums/topic/239954-respeqt-fork-of-aspeqt-100-preview7r79/?p=3285939) I measured 68645us (and more or less close to that on subsequent tries) which is a good 1.5 ms or so more than the time it should take to transfer 19200. However, it would be best to measure the actual time it takes to transfer the data with an FTDI on a logic analyzer or a scope, because while the transfer rate should *typically* be 19200, it's possible it varies enough that in fact tcdrain returns closer to the actual time the last bit is sent.

Edited April 2, 2016 by Joey Z

[TheMontezuma]

 

The linux serialport-unix checks to see that command went inactive, before it goes active. So RespeQt must detect the *edge* of command, and if it's missing this, then it will wait until command has gone high again (which would be after the command is transmitted) before it is able to process commands again. I suspect this is the cause of the issues, but I'm confused on how .73ms is too short of a time to be able to detect the edge. Looking through the entire process, not anywhere is there a significant delay between where RespeQt sends the last byte of the data, and then starts looking for the next command. Of course, multithreading stuff is going on, so it's possible after RespeQt is done processing the command, it switches to another thread and that causes a delay.

 

If that's the cause, then using 'none' handshaking could solve the issue, and could function as a good test as to what exactly is going on.

 

The "NONE" and "SOFTWARE" handshake show the same problem...

And it looks like it is related to tcflush().

This call is needed to clear the bytes in the input buffer when we detect the /CMD.

If the previous command frame was "write data frame" to any other (not emulated) SIO device, these bytes would stay in the input buffer and need to be cleared before we try to read the next command frame.

 

As for the "NONE" and "SOFTWARE" handshake, there is a call to tcflush() when the readCommandFrame() is entered.

In my opinion it is actually superfluous and only causes problems.

I removed (for testing) the call to tcflush() and the demo worked well.

Edited April 11, 2016 by TheMontezuma

[GoodByteXL]

 

As for the "NONE" and "SOFTWARE" handshake, there is a call to tcflush() when the readCommandFrame() is entered.

In my opinion it is actually superfluous and only causes problems.

I removed (for testing) the call to tcflush() and the demo worked well.

 

Sounds good - any bad side effects on other parts or usage in general?

Edited April 12, 2016 by GoodByteXL

[TheMontezuma]

No, there are no side effects, but it only helps if you select "NONE" or SOFTWARE" handshake.

I have already commited my changes.

Edited April 12, 2016 by TheMontezuma

[GoodByteXL]

When testing different A8 software there is often a need to change the "high speed mode pokey divisor" to settings accepted by the respective A8 soft.

The current way to do this is to go via the menu "Tools" or use the key combo Ctrl+O. Wouldn't it be nice to have another mouse click option?

The status line at the bottom would be a perfect place for it as it has already a box showing the speed:

 

 

Could that box made being active to open the same menu as with Ctrl+O?

 

(OK, I admit being mouse addicted ...)

[TheMontezuma]

I like it and it would be a very small change (2 lines of code).

So if there are no objectives I could commit the change.

[TheMontezuma]

Is there any chance of putting a toggle for printer emulation in the settings dialogue so it can be turned off by default? I asked about this years ago re: AspeQt when I found that printer emulation messed up output to a real printer, but the idea was rejected.

 

Sure, it is a minor thing.

[flashjazzcat]

Sure, it is a minor thing.

Great - appreciated.

[TheMontezuma]

a toggle for printer emulation in the settings dialogue so it can be turned off by default

 

1) Shall clicking the printer icon in the status bar toggle printer emulation without changing the (persisted) settings?

 

2) Or shall the current printer emulation status be always persisted (as a new default) independent if it was changed via status bar or in the settings dialogue?

 

3) Or maybe we don't need a new checkbox in the settings dialogue at all and simply persist the status of the printer emulation, which can be changed only by clicking on the status bar?

 

 

Which option do you prefer?

Edited May 10, 2016 by TheMontezuma

[TheMontezuma]

No opinion on that?

[flashjazzcat]

No opinion on that?

 

Sorry... I noticed the question earlier but decided to think about it before responding. In any case, after all that I guess the option which is most consistent with existing settings would make most sense, although there aren't really any status bar icon settings with comparable functionality. I guess at the end of the day any will do as long as the printer emulation can be permanently shut off.

[TheMontezuma]

Then I decided for option (3).

You can enable/disable printer emulation by clicking on the icon in the status bar (current implementation), but now your choice will be persisted.

[flashjazzcat]

Perfect.