FujiNetWIFI/fujinet-firmware

Funny behaviour on SIO CMD $E0

Opened this issue · 4 comments

XeAtari commented

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 commented

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 commented
tschak909 commented

@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 commented