I had a quick look and couldn't find an existing disassembly, so if anyone's interested they can take a look at what I've done so far in my github repository. This is a py8dis disassembly so the .py files are what I'm actually editing, but the output is checked into the source directory so you can read it without needing to run py8dis.
I'm disassembling what is (I hope) the most recent version, v1.10, after reading this thread. I've tested myself (briefly) and it does seem to work on a BBC even if it was released as a Master cartridge, and I figured it might have some additional bug fixes.
I don't plan to take this that much further, at least not yet, so if anyone is interested in doing more with it please feel free. I might write a post or two in this thread with some notes on the implementation later.
Just for reference, this thread has lots of ISO-Pascal information.
A lot of the internal messages in the interpreter ROM are compressed to save space. Bytes <&80 represent normal ASCII characters. &80+0 to &80+31 represent a fixed set of tokens, although not all of these are used. &80+n for n>=32 (ASCII space) represents ASCII character n following by a trailing space. The same compression scheme is used for OS errors generated via BRK - the BRKV handler uses the same output code as other print operations so it is able to expand them. For example:Unsurprisingly, the compiler ROM is almost entirely taken up by the bytecode for the Pascal compiler itself. The other main feature of interest in the compiler ROM is its half of the mechanism the two ROMs use to coordinate their actions. The ROMs never appear to explicitly enter each other as languages (using *FX142) or to try to work out the bank number of the other ROM. Instead the core mechanism is issuing *FX163,192,n commands for 0<=n<=3, with each ROM claiming the OSBYTE call for certain values of n. The high bits of the "last break type" flag (as read/written by OSBYTE 253) are used to track state as the ROMs switch back and forth. I need to sit down and analyse this properly later and may write it up here if I get round to it.
The ROMs actually use OSCLI to execute *FX163,192,n commands instead of calling OSBYTE, presumably because this generates a "Bad command" error if only one of the ROMs is present, which is quite a neat touch.
Both ROMs have a "degenerate" copyright string in the header, with just a 0 byte followed by "(C)" followed immediately by code, which probably upsets any utilities that try to show the copyright strings. (It certainly upsets py8dis's ROM header auto-disassembly!)
I'm disassembling what is (I hope) the most recent version, v1.10, after reading this thread. I've tested myself (briefly) and it does seem to work on a BBC even if it was released as a Master cartridge, and I figured it might have some additional bug fixes.
I don't plan to take this that much further, at least not yet, so if anyone is interested in doing more with it please feel free. I might write a post or two in this thread with some notes on the implementation later.
Just for reference, this thread has lots of ISO-Pascal information.
A lot of the internal messages in the interpreter ROM are compressed to save space. Bytes <&80 represent normal ASCII characters. &80+0 to &80+31 represent a fixed set of tokens, although not all of these are used. &80+n for n>=32 (ASCII space) represents ASCII character n following by a trailing space. The same compression scheme is used for OS errors generated via BRK - the BRKV handler uses the same output code as other print operations so it is able to expand them. For example:
Code:
brk equb 2 ; error code equb 128 + 2 ; "Bad " (token 2) equs "mode" equb 0 The ROMs actually use OSCLI to execute *FX163,192,n commands instead of calling OSBYTE, presumably because this generates a "Bad command" error if only one of the ROMs is present, which is quite a neat touch.
Both ROMs have a "degenerate" copyright string in the header, with just a 0 byte followed by "(C)" followed immediately by code, which probably upsets any utilities that try to show the copyright strings. (It certainly upsets py8dis's ROM header auto-disassembly!)
Statistics: Posted by SteveF — Sat Sep 21, 2024 2:41 am