-
Notifications
You must be signed in to change notification settings - Fork 12
Source code structure
Makes the 68000 code/data block used by the game. The binary block of data generate will be included into the 32X side at the proper place.
Main start of the 68000 code. The 68000 jumps to _start after the 32X has been started. _start clears the ram, copies the data segment into ram, initializes the MD hardware, and then calls the 68000 _main entry. It contains all the assembly routines needed by the 68000 to handle communication between the 32X and SCD.
Holds the main() entry point. It tries to initialize the CD, if present. It also tries to initialize the MegaSD cart (allows playing CDDA music like the CD) if present. then calls do_main, which is in crt0.s.
The code loaded into the SCD program ram that controls the SCD. Currently just checks for an audio CD and waits for commands from the MD to play tracks.
Initializes the MED, if present. This sets a flag that tells the game we can use MED Pro resources for bank selection, save ram, etc.
The default ASCII font used by the MD side of things.
The Kosinski decompression routine used to decompress the SCD BIOS when initializing the SCD.
Initializes the MegaSD, if present. Also holds the routines to play CD tracks on the MegaSD instead of the SCD.
Some VGM helpers routines. Initializes the lzss decompression used to decompress the compressed VGM files that D32XR uses. Also has a function to fetch the next buffer worth of decompressed VGM data.
Chilly Willy's VGM player code. Was derived from the player code I wrote for the NeoMyth cart menu. It's aimed at playing v1.60+ VGM files (no individual PCM store commands, instead it uses the new stream commands).
A stripped down vprintf() function for faster debug string printing on the MD side.
The main makefile. It will make the 68000 block, then make the 32X code (which includes the 68000 block inside it), then concatenate the wad file, then pad the rom to the closest 512KB to keep the size nice and round.
Most of the 32X hardware includes for the IO and SH-2.
This starts the rom. It starts with a standard Sega MD rom header, followed by a vector table for the 68000 that redirects the normal 68000 exceptions to the new location of the 68000 code in the 32X. That is followed by the standard 32X header that tells you things like where the data is at, where the primary and secondary SH-2 start vectors are, and where the primary and secondary SH-2 exception tables are. This is followed by the 68000 security block, which is merely code that initializes the 32X, then fall into the 68000 _start, which is where the 68000 block is included at. This is then followed by the primary and secondary exception tables. Then follows all the SH-2 exception handling code, as well as the startup code. The primary startup code does some initialization, then jumps to main() on the 32X side of things. The secondary startup code does some initialization (less than the primary), and then jumps to secondary().
Has much of the low-level 32X functions, like setting up the frame buffers, flipping the frame buffers, polling the mouse, the main 32X initialization routine, and lots of glue routines that interface between 32X C functions, and sending commands to the MD and receiving responses back.
Holds all the system specific functions Doom uses to interface with the specific system Doom is running on. Things like processing the controller input, getting the tick count, setting the palette, doing network functions, etc. This file also holds Mars_Secondary(), which is where the secondary SH-2 runs. This initializes any secondary SH-2 hardware like the DMA, then enters a loop to process commands sent by the primary SH-2.
This corresponds to jagonly.c - the main entry point of the Doom game. It has the 32X side main() function entry point. This does any system setup, reads the save ram, sets up the video, and calls D_DoomMain(), the start of Doom proper. This file also holds the secondary() function, which just calls Mars_Secondary().
Holds the save/load functions used by Doom. Calls lower level load/save functions to do its work. Nothing really 32X specific here.
This holds the Doom sound effects and music function routines, converting them to 32X code to send commands to the MD/CD side to play music, and builds a list of channels for playing sound effects via the 32X PWM. This file has the DMA done interrupt handler function that drives the PWM sound double buffer. It also handles command interrupts sent by the 68000, which are used to send info about PCM streams to play from the VGM file. Those are mixed with the sound effects.
The main hand-tuned assembly for drawing in Doom. This is important for people doing their own drawing as it shows how to place mov commands on the proper boundaries for better speed.
Fixed point multiply and divide code. The divide uses the hardware divider in the SH-2 rather than the normal divide program code the SH-2 uses. Note that the Doom code doesn't call these very often as we made different inline code for doing these. In fact, the divide is sometimes broken into two pieces - starting the divide, and then a separate function to fetch the result so that you can do other things before fetching the result of the divide.
The main sound mixing code. It will mix normal 8-bit PCM samples, and 16-bit ADPCM samples, which are decompressed on the fly by the SH-2 while mixing. We suggest not trying to mix more than 5 or 6 ADPCM samples at the same time as that can consume some cpu time, slowing the secondary SH-2 elsewhere in the game.
And that's pretty much all the 32X specific files and what they handle. The rest is Doom code.