DR GSX Graphic Extension

Post Reply
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

DR GSX Graphic Extension

Post by stefano »

Here's a function set to interface to the GSX extension for CP/M, which was available on a limited number of systems back in the eighties.

https://github.com/z88dk/z88dk/issues/1715

After compiling a program needing to use the GSX functions, a special stub must be added to the generated COM file by using the GENGRAF command usually present in the system disk.

I checked it on the PCW-9000 and TS-803 target and I must say that the 2 outputs are very close.
The Televideo target is not disabling the cursor automatically, but it is probably a bug in the MAME emulator which is barely booting the TS803H, giving odd disk error messages on the second drive, badly reacting to the keyboard, etc..

by the way.. woo hoo! it works!
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

I managed to emulate the z88dk graphics output on the GSX devices. ( -lgfxgsx :) )

Please consider that it was intended for static pictures, e.g. to be sent to an external plotter, etc..
I chose a reduced resolution which, when addressing the single pixels, will be cropped or shrinked, depending on the target device.

The Joyce emulator boosts the graphics at a (probably fake) 800x600 resolution, thus it gets slightly shrinked:
gsx_shrinked.png

The TS803 in turn had 720 pixels, thus the output is slightly cropped:
gsx_cropped.png

As said, don't try to use this thing for action games and sprite animation, it will be slow and messy !
You do not have the required permissions to view the files attached to this post.
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

I still need to sort out the libraries and the configurations for mainly 2 conflicts:

- those targets like "Bondwell2", "Amstrad PCW" move the code_graphics page at the memory bottom. The same thing is done by GENGRAF to append the support for the extended BDOS calls. I'll probably shortcut the problem by increasing the entries in 'cpm.cfg', but it will get quite crowdy.

- Some of the 'wide' version of the graphics libraries have an odd conflict with 'draw_c' and 'plot_c', which I wasn't able to spot on the libsrc directories. For putsprite, I replaced plot() with plot_callee() as a workaround, the 'stencil' stuff and others needs still to be fixed, here's a sample error message:

symbol '_draw_callee' already defined in module 'draw_c'


By the way.. the GSX version of the 'globe' demo is cool !
pcw_gsx_globe.png

..on TS803, the text console and graphics mixing is not supported, a possible evolution is to get a minimal console support based on DRAW_TEXT.
GSX has also its own APIs to deal with the real text mode and cursor but I'm afraid it wouldn't solve.

ts803_globe.png
You do not have the required permissions to view the files attached to this post.
User avatar
dom
Well known member
Posts: 1407
Joined: Sun Jul 15, 2007 10:01 pm

Re: DR GSX Graphic Extension

Post by dom »

Can we not do the gengraf thing ourselves? I think it loads GSX.SYS and puts it at the appropriate place in memory? So, if we link with the library it fiddles with our GRAPHICS_ORG_ADDR to get into the right place?
- Some of the 'wide' version of the graphics libraries have an odd conflict with 'draw_c' and 'plot_c', which I wasn't able to spot on the libsrc directories.
draw_c and plot_c in target/cpm/graphics are the source of the problem - there's a #define in graphics.h that #define draw draw_callee which means that the code in those files is exported as draw_callee etc, so there's no draw() label available.
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

We surely can, but the GSX heavily depends on the host system configuration in any case.

EDIT: I understood your suggestion only after a second "translation pass".. it's a good idea, but .. let's think at it a bit more. Couldn't it be rather possible to use appmake manually to put a COM file in a disk image? I promise I won't mess the config, at a second though it was a bad idea.

The good thing is that probably the picture above could be easily adapted to be sent to a plotter or a printer. clg() opens the output device #1, but the number can be changed by using gios_open() , or assign.sys can assign another device to #1 directly.
I'd rather focus a further effort in:
- finding a way to REMOVE the GENGRAF stub from an old application
- creating a bridgde to replace the GSX BDOS entry with a new one built with z88dk on the graphics library we already have


EDIT2: we must definitely try to run it on the BBC micro!
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

doh.. it could be easier than expected !

http://www.cpm.z80.de/roche/GENGRAF.ASM
It seems to me it lists the PRL files to compute the total size it needs to allocate.

There's also gsx.sys, which should install the device driver (PRL format) listed in ASSIGN.SYS:
http://www.cpm.z80.de/roche/GSX.ASM

And a driver for the uPD7220 !
http://www.cpm.z80.de/roche/NCRGRAF.ASM
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

Fast box drawing and square area cleaning are now supported. Sprites will always be slow, but now the picture distortions are drastically reduced.
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

I'm on the 'gengraf thing' now, I finished decoding the disassembly of gengraf.com and gsx.sys, which were not commented rightly in few relevant parts.
My prototype should, when finished, load a requested driver by specifying the PRL file name, allocate it in 'himem' at the appropriate byte boundary after lowering SP, patch it for its assigned position and export the new entry point to be used in place of M_GSX().
If everything will go the way I'm hoping M_GSX could become a function smart enough to work in both GDOS mode (via gengraf + BDOS) and direct GIOS calls.
stefano
Well known member
Posts: 1678
Joined: Mon Jul 16, 2007 7:39 pm

Re: DR GSX Graphic Extension

Post by stefano »

The bugs I found in the way delayed my work a bit.
Having now the fcntl and parameter parsing components fixed is very positive, though!
I'm still verifying the way a GSX driver works, I suspect that it doesn't work on a virtual 32768x32768 pixel range, it could be gsx.sys the one converting the coordinates.
If confirmed, the current gios* functions should be renamed to gdos* and leave space for the native GIOS calls :/
Post Reply