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 https://github.com/FujiNetWIFI/fujinet-platformio/issues/549#issuecomment-1407706093, 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 https://github.com/FujiNetWIFI/fujinet-platformio/issues/549#issuecomment-1409542520, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZY3P3CODIOFY64S43I727TWVBJA3ANCNFSM6AAAAAAUKFR2IA. You are receiving this because you were mentioned.Message ID: @.***>