CP/M pages
Home -> CP/M -> GSX drivers

Amstrad GSX drivers

Amstrad PCW and CPC implementations of CP/M include GSX drivers for the computers' respective screens. This page compares the various drivers' features and internal implementation.

CPC drivers: DDMODE0, DDMODE1, DDMODE2

The three drivers on the CPC6128 CP/M disc are very similar, differing only in two or three places. A number of GSX features aren't implemented:

[CPC mode 0 screenshot]
CPC mode 0, showing 'filled' rectangles.

[CPC mode 0 screenshot]
CPC mode 1, showing 'filled' star shapes.

[CPC mode 0 screenshot]
CPC mode 2, showing 'filled' star shapes.

Internally, the drivers implement GSX operations using CPC firmware calls. So, for example, to draw a line, the driver will call GRA SET LMASK to set the pattern, then GRA MOVE ABSOLUTE followed by GRA LINE ABSOLUTE to draw the line.

PCW8256 driver: DDSCREEN

DDSCREEN, supplied with the PCW8256, takes the same sort of approach to the CPC -> PCW transition as the CP/M system file. The driver is clearly divided into two sections: the first half corresponding more or less to the CPC driver, and the second half providing the PCW-specific drawing code to replace the CPC firmware.

One quirk of the PCW implementation is that the screen size isn't fixed; it uses whatever window is reported by the TE ASK system call, and (thanks to GSX scaling) all output will be restricted to that window.

The list of features implemented by the driver is pretty much the same as the CPC version.

[PCW screenshot]
PCW driver, showing 'filled' star shapes.

Enhanced PCW driver: DDSCREEN

Digital Research supplied an enhanced version of the PCW driver with DR Draw and DR Graph, and this was the version shipped with CP/M for the PCW9512 and later PCWs. I don't know if there were similar enhanced drivers for the CPC range.

The enhanced driver contains the string PCW8256 GIOS #8 at offset 0102h.

Additional features in the enhanced driver are:

While testing, I was able to provoke a few crashes by passing what seemed, to me, to be perfectly reasonable parameters to the 'fill rectangle' call. Either these were caused by bugs in my programming, or there isn't sufficient parameter validation on this call.

[PCW screenshot]
PCW driver, showing filled rectangles that are actually filled.

Mouse/tablet is implemented using the following BDOS calls, which must be implemented by an RSX already present in the system:

Detect tablet: Call 0005h with:
	C = 3Ch
	DE = address of RSXPB:
		defb	1,1	;Function 1, one parameter
		defw	1	;On return, will be set to 0 if driver
				;initialisation failed.

Read tablet: Call 0005h with:
	C = 3Ch
	DE = address of RSXPB:
		defb	2,3	;Function 2, 3 parameters
		defw	bmask	;Button mask to detect
		defw	x	;Current X-coordinate
		defw	y	;Current Y-coordinate

	On return, A should be 0 if the selected button was clicked, 0FFh if 
	it was not. What I'm not sure is how mouse movements are reported.

No Spectrum +3 Driver

No GSX driver was provided for the Spectrum +3. I think it would have been reasonably straightforward to create a monochrome driver based on the PCW8256 codebase, replacing PCW-specific parts of the second module with Spectrum versions (once I had building source for the PCW version, it took me a couple of hours to get something that looked vaguely plausible on the +3). My guess is that this wasn't done because of disk space; adding GSX to the +3 CP/M distribution would have required a second floppy disk to be added to the package.

[+3 screenshot]
Prototype Spectrum driver. Since this is based on the PCW driver, it's under Locomotive's copyright and I can't distribute it.

JOYCE

JOYCE includes built-in GSX support based on the GEM VGA driver.

[JOYCE screenshot]
JOYCE, showing filled star shapes.


John Elliott, 21 June 2012