Porting Virtual 2600
To encourage people to port Virtual 2600 I am constructing a set of documentation about the various drivers needed to run Virtual 2600. If you are just porting to another version of UNIX then some new stuff in configure.in will usually fix it.
If you are not using gcc then there will be some differences. The only major one for most ANSI compilers is the inline directive which can be disabled with #define inline in config.h.
If you are not using GNU/Linux C library then there will be some differences, but there should be no major problems if you have the standard ANSI library functions.
You need one of these to see anything! The main graphics code is driven from XXX_disp.c where XXX is the name of your driver. The routines to have are:
tv_on()
This initialises your virtual TV. On simple systems this may just set the graphics mode and clear the screen.
tv_event()
Is called to poll for screen events, this is typically only needed in windowing environments.
tv_display()
Your routine to copy a 320x200ish bitmap to the screen.
A nice simple example is svga_disp.c
Essential for using the emulator properly, but not for the very first stage of porting when you will only want the graphics drivers. I may add an simple ANSI C keyboard driver for this early development work. The basics you need to write are in a file called XXX_keyb.c which has just five main functions in it.
keybdrv_init()
Initialises your driver
keybdrv_close()
Closes your driver
keybdrv_update()
Polls your driver (may be left null if you do a fancy event driven driver)
keybdrv_pressed(int key)
Returns none zero if a the key is pressed
keybdrv_setmap()
Maps your keyboard to V2600's internal representation of an IBM PC keyboard.
Not essential, can use the no_joy.c stubs until the rest is working.
Not essential, you can use the no_sound.c stubs until the rest is working.
Once you have your port running, I would be delighted to merge in any bug fixes, improvements and new drivers you have written. The V2600 code is formatted using the "indent -gnu" command, and it would help if any code you write is also formatted this way. If possible please send you changes/updates as patches produced with diff(1). If you don't have access to indent and diff then I will accept full source files, but it may take longer for your changes to make it into the main release.
If you'd like your name up in lights please include an entry for the CREDITS file.