To provide some background: The emulator is based on original code by Tom Skibo and the sections for IO and the IEEE emulation are still pretty much his code. This really only implements what’s necessary for LOAD and SAVE on device 8, but nothing else. I’ve since tagged on additional functionality onto this, like interpretation of disk and tape images, virtual directories, file drag-and-drop, etc, but here I do hit a wall.
My first idea was that this would be much like LOAD “$”,8, because that’s what was already implemented in the drives and available out of the box. And I do see (in the current implementation) a LOAD state with filename “$”, which may be also, as we call it nowadays, a hallucination.
Symptoms:
- I get a status code (system var. “ST”) of 2, indicating an input timeout (device is not responding in less than 64ms). Meaning, there’s some miscommunnication.
- The first 6 bytes are “eaten away”, meaning, they are consumed by some other mechanism
- The first line is misinterpreted (small wonder, given that the first bytes are missing)
- The timeout happens on the first line (or immediately after this)
The bytes being consumed by something (maybe reading the device status, which isn’t really implemented.)
The timeout indicates that we’re missing a change of state, maybe a command send over the bus. This hints at this not using a LOAD command, but rather OPEN.
Meaning, something along the lines (pun intended) of this BASIC program for listing a directory without overwriting the program in memory:
10 OPEN 1,8,0,"$"
20 GET#1,X$,X$
30 GET#1,A$,B$,C$,D$
35 IF ST THEN CLOSE 1:END
40 PRINT ASC(C$+CHR$(0))+256*(ASC(D$+CHR$(0)));
50 GET#1,X$
60 IF X$="" THEN PRINT:GOTO 30
70 PRINT X$;:GOTO 50
(Line 20 consumes the load address, line 30 reads a line header: 2 bytes line-link and 2 bytes for the line number. Line 40 prints the line number [actually the number of blocks] from the binary format, line 50 gets the next byte. If this is a zero-byte [end of line], we continue for a new input line at line 30, else we print this character and continue for the next character at line 50. This loops until the status variable “ST” is anything than zero, when reading the next line, probably a code of 64, end of file.)
Without anything mounted, the emulator will emulate an empty virtual directory:
0 "PET MOUNT POINT "███████
0 BLOCKS FREE.
Running the above program results in:
4608 PTMUTPIT"
16896 OK RE
Note how we’re missing every second character, as well!
This is similar but not exactly the same as what we get with the “DIRECTORY” command:
DIRECTORY
8722 E ON ON >
Still, I’d attribute the missing bytes in the disk name to a similar mechanism using the protocol for OPEN rather than the one for LOAD.
Conclusions: I’ve to re-implement the entire IEEE stack, with explicit support for OPEN and SAVE, etc, and device channels (something that’s missing, as well). Fixing things up on the cheap won’t help. Since I wanted to to do this anyway, this is probably the way to go.
(I’ll post anything of note, if I’m encountering any along the way…)
[Edit]:
Why are we missing every second byte?
Probably there’s a bus command for GET#, requesting the next input (not just the IO handshake being held down.) If we have a state mismatch, the IEEE emulation would send the next byte, where it is supposed to receive one. Mind how this also matches the 6 missing bytes and the 6 reads at the start of the above BASIC routine. And there we are…
