retrohimpi
Member
Well, I've made some progress in understanding the problem, even if I'm no nearer a solution. I set a breakpoint in OS65D's generic character output subroutine, rebooted and wrote down the ASCII value in the accumulator each time it was called. I saw banners from OS65D and OSI 9 digit BASIC, a '25985 bytes free' message, an 'Ok' prompt, and a 'RUN"BEXEC*"' command. Clearly, OS65D was silently launching BASIC, which initialised and then ran the BEXEC* program from disk before the system locked up.
Buried in a heavily commented disassembly of OS65D v3.2 I found the following:-
The BEXEC* listing in the OS65D Tutorial & Reference Manual begins:-
I haven't worked out what the POKEs in line 5 do, but line 20 should PEEK the device code (2 for onboard k/b and screen) correctly detected by OS65D and POKE it into both I/O distributor bytes, just as it said in the disassembly.
So, my problem is narrowed down to BEXEC* never reaching line 20, and I now know that nothing will appear on the screen or be read from the keyboard until after it executes. I'm hoping that, if I can hack the disk image to start off with a 2 in both I/O distributor bytes, I'll not only see what's happening but also get a usable BASIC prompt from which I can try loading and listing BEXEC*, as well as some immediate PEEKs and POKEs, before running it manually.
Above is a screenshot of the 8Kb cassette-based version of my emulator. You can see the D/C/W/M? monitor prompt, BASIC prompts and banner, then the code listing as it loaded. On the right-hand side is my front page which, after clicking the Stop button, shows the internal state of the CPU and stack and allows the setting and display of breakpoints and various kinds of memory watches during a debugging session.
Buried in a heavily commented disassembly of OS65D v3.2 I found the following:-
The I/O distributor bytes appear to work like Applesoft's PR# and IN# but, with one bit per device, can support simultaneous I/O on up to 8 devices. The input distributor on disk is 16, which is memory, and points to BASIC's input buffer (preloaded with the 'RUN"BEXEC*"' command).
The BEXEC* listing in the OS65D Tutorial & Reference Manual begins:-
Code:
5 POKE 133,92: CLEAR: POKE 14172,8: POKE 1470,16
10 POKE 2888,0: POKE 8722,0
20 X=PEEK(10950): POKE 8993,X: POKE 8994,X: ...So, my problem is narrowed down to BEXEC* never reaching line 20, and I now know that nothing will appear on the screen or be read from the keyboard until after it executes. I'm hoping that, if I can hack the disk image to start off with a 2 in both I/O distributor bytes, I'll not only see what's happening but also get a usable BASIC prompt from which I can try loading and listing BEXEC*, as well as some immediate PEEKs and POKEs, before running it manually.
Above is a screenshot of the 8Kb cassette-based version of my emulator. You can see the D/C/W/M? monitor prompt, BASIC prompts and banner, then the code listing as it loaded. On the right-hand side is my front page which, after clicking the Stop button, shows the internal state of the CPU and stack and allows the setting and display of breakpoints and various kinds of memory watches during a debugging session.