-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Funny behaviour on SIO CMD $E0 #549
Comments
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 |
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:
***@***.***>
|
@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. |
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:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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).
The text was updated successfully, but these errors were encountered: