Funny behaviour on SIO CMD $E0

[XeAtari]

I noticed some funny behaviour when running SIO CMD $E0.

Environment: Atari running SpartaDOS 3.3b
Note: The DOS's built-in highspeed code only processes disk access in highsped but changes to normal speed upon everything else

When I run this command on any host slot but slot 1 (the slot that can be assigned the SD card) things work.
One can see toggling baud rates in the debug monitor.

When I run this command on slot 1 it only works once (every succeeding command times out).

When I run $E0 against any other host slot after it timed out on slot 1 it works for the other host slot.

If then I run it against slot 1 again it works once again.

It does not matter whether slot 1 is assigned the SD card or a server in the internet.

This only seems to happen with command $E0.

Below please find a log snippet:

[11:30:36] CF: 70 e0 00 00 51
[11:30:36] sioFuji::sio_process() called
[11:30:36] ACK!
[11:30:36] Fuji cmd: GET HOST PREFIX 0h
[11:30:36] ->SIO write 256 bytes
[11:30:36] COMPLETE!
[11:30:42]
[11:30:42] CF: 58 e0 70 e0 00
[11:30:42] CHECKSUM_ERROR
[11:30:42] Toggling baudrate from 19200 to 54905
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:42]
[11:30:42] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c
[11:30:43]
[11:30:43] CF: 00 1c 00 00 1c

(Log ends here).

[tschak909]

This is extremely odd, as the command itself is very simple:

// Retrieve host path prefix
void sioFuji::sio_get_host_prefix()
{
    uint8_t hostSlot = cmdFrame.aux1;
    Debug_printf("Fuji cmd: GET HOST PREFIX %u\n", hostSlot);

    if (!_validate_host_slot(hostSlot))
    {
        sio_error();
        return;
    }
    char prefix[MAX_HOST_PREFIX_LEN];
    _fnHosts[hostSlot].get_prefix(prefix, sizeof(prefix));

    bus_to_computer((uint8_t *)prefix, sizeof(prefix), false);
}

_validate_host_slot is:

bool _validate_host_slot(uint8_t slot, const char *dmsg)
{
    if (slot < MAX_HOSTS)
        return true;

    if (dmsg == NULL)
    {
        Debug_printf("!! Invalid host slot %hu\n", slot);
    }
    else
    {
        Debug_printf("!! Invalid host slot %hu @ %s\n", slot, dmsg);
    }

    return false;
}

and get_prefix is simply:

/* Returns pointer to current hostname and, if provided, fills buffer with that string
*/
const char *fujiHost::get_prefix(char *buffer, size_t buffersize)
{
    if (buffer != NULL)
        strlcpy(buffer, _prefix, buffersize);

    return _prefix;
}

I don't know what could be causing that issue?

-Thom

[XeAtari]

I am really puzzled as well because this is totally illogic. But I can replicate this behaviour and a friend of mine could replicate this too. I have recordings taken from the serial bus taken with a logic analyzer where one can clearly see that that FujiNet does not even send an Acknowledge ('A) in reply to the command. I can upload the file in case you want it. The software to manage the data is available for free at pctestinstruments.com Unfortunately the hardware buffer is a bit too small for my taste so there is only a read sector in highspeed and two tries for the E0 command. I think there is something in the routine for switching between normal speed and highspeed but that would affect all commands, but it does not. Did I mention that this behaviour does not occur if I run the file performing the E0 command from a ramdisk? And it does not occur as well if I run the file from a disk using SpartaDOS 3.3a (which has no highspeed) so the SIO speed does not change between the file load and the command being sent. One thing I did not yet test is running the file from a device that is not external to FujiNet. But I am very curious to get to know why that happens. Really strange. Kind regards == Thomas Cherryhomes ***@***.***) schrieb:

…

This is extremely odd, as the command itself is very simple: // Retrieve host path prefix void sioFuji::sio_get_host_prefix() { uint8_t hostSlot = cmdFrame.aux1; Debug_printf("Fuji cmd: GET HOST PREFIX %u\n", hostSlot); if (!_validate_host_slot(hostSlot)) { sio_error(); return; } char prefix[MAX_HOST_PREFIX_LEN]; _fnHosts[hostSlot].get_prefix(prefix, sizeof(prefix)); bus_to_computer((uint8_t *)prefix, sizeof(prefix), false); } _validate_host_slot is: bool _validate_host_slot(uint8_t slot, const char *dmsg) { if (slot < MAX_HOSTS) return true; if (dmsg == NULL) { Debug_printf("!! Invalid host slot %hu\n", slot); } else { Debug_printf("!! Invalid host slot %hu @ %s\n", slot, dmsg); } return false; } and get_prefix is simply: /* Returns pointer to current hostname and, if provided, fills buffer with that string */ const char *fujiHost::get_prefix(char *buffer, size_t buffersize) { if (buffer != NULL) strlcpy(buffer, _prefix, buffersize); return _prefix; } I don't know what could be causing that issue? -Thom — Reply to this email directly, view it on GitHub <#549 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZY3P3F2BQ5WUXCXIWH3JF3WU2JYZANCNFSM6AAAAAAUKFR2IA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[tschak909]

@XeAtari The latest change for APE is now in the latest production firmware. I am still trying to figure out what could be causing the odd bug with the $E0 command.
-Thom

[XeAtari]

Did you have a chance to reproduce the behaviour at your side? I'll perform a firmware update asap. XeAtari == Thomas Cherryhomes ***@***.***) schrieb:

…

@XeAtari <https://github.com/XeAtari> The latest change for APE is now in the latest production firmware. I am still trying to figure out what could be causing the odd bug with the $E0 command. -Thom — Reply to this email directly, view it on GitHub <#549 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZY3P3CODIOFY64S43I727TWVBJA3ANCNFSM6AAAAAAUKFR2IA>. You are receiving this because you were mentioned.Message ID: ***@***.***>