Reconstructed BBC Micro GSX driver source            John Elliott, 2025-09-09
=============================================================================

  This is an attempt at reconstructing the source code for the two BBC Micro
GSX drivers: DDBBC0.PRL and DDBBC1.PRL.

  To the best of my knowledge and belief, GSX is covered by the CP/M open 
source licence:

; "Let this paragraph represent a right to use, distribute, modify, enhance, 
; and otherwise make available in a nonexclusive manner CP/M and its 
; derivatives. This right comes from the company, DRDOS, Inc.'s purchase of 
; Digital Research, the company and all assets, dating back to the mid-1990's. 
; DRDOS, Inc. and I, Bryan Sparks, President of DRDOS, Inc. as its 
; representative, is the owner of CP/M and the successor in interest of 
; Digital Research assets."

How to build
============

  Under CP/M, run BUILD.SUB. You will need a large (by CP/M standards) disk
drive, say 850k, to hold all the files generated by the build.

  Under UNIX, you will need ZXCC installed with the Digital Research 
assembler, linker and librarian (RMAC, LIB and LINK) on the CP/M search path;
then you should be able to type 'make' in the normal way.

Notes
=====
  The bulk of the BBC video drivers was originally written in a compiled 
language, probably RATFOR. I don't have a RATFOR compiler to hand, so I've
made no attempt to reconstruct the original source; everything is in 8080
assembly.

  I have been quite free with the use of macros to try and encapsulate some
of the more repetitive code sequences generated by the compiler. For example,
RDLOCAL reads a local variable from the stack frame into HL, expanding into 
the series of instructions that calculates the variable offset and reads it.

  The use of local variables must be quite the drag on performance; where it
takes one 8080 instruction to read a word from memory, it takes 8 to calculate
its address and read it from the stack. Since GSX functions don't make use of
recursion, I think storing variables in memory rather than on the stack 
would be a good way to improve performance and shrink driver size.

