I have now disassembled the BBC drivers and have buildable source for them. Not sure I can share the results, though, as I don't know whether the copyright rests with Digital Research (in which case they'd be covered by the CP/M open source licence) or Acorn (in which case, not).Considering I've never used the GSX drivers and have only tinkered with CP/M at all, this is oddly interesting! Are you tempted to disassemble the Acorn drivers or perhaps just write a replacement? I could imagine implementing things like arc segment primitives might be interesting/tedious/difficult, but if you assumed the GXR is present in the host that might make it a lot easier.
Some thoughts / findings:
- Apart from one JR and one DJNZ each, the drivers use only 8080 instructions.
- The reported resolutions are 640x545 and 320x273, which seem a trifle bigger than the actual screen size.
- Both drivers report they have the same aspect ratio, with square pixels. This may be the case for mode 1 but definitely not for mode 0.
- Both drivers also report that they implement function 27 (read cell array - for reading pixels from the screen). They don't.
- The compiler that was used generated pretty verbose code, and it seems to default to storing local variables on the stack. A Z80 or 8080 can load a 16-bit word from memory with one instruction; to locate it on the stack, as they did it, takes 8 including a subroutine call. If it's incrementing a variable, it calculates its address (for the write), saves it, calculates the address again (for the read), and then does a peek-modify-poke. And it ties up the BC register as the frame pointer.
- The biggest source files are for line drawing and arcs/pie slices. Other operations like markers and text are fairly simple wrappers for VDU commands. There are two code paths for line drawing: when the lines are solid it has it easy. It can just convert to a series of VDU25 instructions, one per line, and leave the 6502 to get on with drawing them. But VDU25 can't draw dashed lines, so if a line is dashed it has to split it into a sequence of little lines and draw each one separately. Some of this seems to involve doing a Pythagorean calculation after each dash to see where the next one should go, so for each dash the Z80 has to do two multiplications and a square root calculation. No wonder it slows to a crawl.
Statistics: Posted by JohnElliott — Tue Sep 09, 2025 10:00 pm