GMod4

This page is work in progress. Please check back later.

GMod4 is a C64 flash cartridge primarily aimed at OEM for use with games. It contains 4MBytes to 16MBytes flash (depending on the version) that can be programmed from every C64/C128 model.

As opposed to GMod2, this cartridge can map in 8k ROM chunks in $8000, $a000 and $e000. Each of the three ROM areas can be switched off, so RAM below those ROM areas stays available, and a "cart kill" (=switch to standard READY prompt) is possible. Having ROM in $e000 is particularly powerful, as IRQ vectors are located in that ROM, giving authors the possibility of faster IRQ service routines than with GMod2. A 256-byte page of flash is visible in the $de00 area, offering code space for even faster NMI service routines or a trampoline area for bank-switching and RAM/ROM switching.

Registers

Address		Description
$DE00	write	Common bank (sets both banks at once)
$DE01	write	$A000 bank
$DE02	write	$8000 bank
$DE03	read	SPI data (bit 7), if bitbanging is enabled
$DE04-$DE07	write	Control register (see below)

This layout of 8 registers is mirrored 32 times in the $DExx area. We recommend not to make use of these mirrors, so it'll be possible for us to make follow-up cartridges with more registers that are backwards-compatible to GMod4.

When bitbanging is disabled, reading from the IO1 page will return the ROM from offset $1e00 in bank 0.

Control register ($DE04)

Bit	Mode
	bitbanging disabled (RUN mode)	bitbanging enabled
7	unused	SPI CLK signal
6	unused	SPI Din signal
5	Flash A23	SPI Flash chip select
4	Flash A22	unused
3	0=enable, 1=disable $e000 ROM	must be 1 (ROM disabled)
2	0=enable, 1=disable $a000 ROM	must be 1 (ROM disabled)
1	0=enable, 1=disable $8000 ROM	must be 1 (ROM disabled)
0	0=disable bitbanging	1=enable bitbanging

The Control register is initialized with $00 on every power-cycle and reset, enabling all three ROM areas and putting the unit into RUN mode. Bits 1 through 3 let you switch the individual 8k ROM areas on (bit is 0) or off (bit is 1). Toggling these bits will have no influence on the presence of the $de00 page, and it also won't change the contents of the banking registers.

Banking registers

The flash is divided into 512 8k-banks, giving GMod4 a "natural" size of 4MBytes. Even banks are mapped to $8000, and odd banks are mapped to $a000. The $e000 area and $de00 page are not banked; $e000 will always show content from bank#1, and the $de00 page will always show the $1e00 page of bank#0.

The contents of the two bank registers are NOT initialized on power-up, and may contain random data after a power cycle or reset. It is required to initialize both banking registers upon every reset.

Writing to $de01 will set the $A000 bank, which is calculated by (value)*2+1, so $a000 can show contents of all odd flash banks from 1 to 511.

Writing to $de02 will set the $8000 bank, which is calculated by (value)*2, so $8000 can show contents of all even flash banks from 0 to 510.

Writing to the common bank register results in both the $A000 and the $8000 registers to be written with the same value. This is especially powerful, as it allows you to use the whole area from $8000 to $bfff as a single 16k ROM bank. With the bank layout of the two separate registers, the resulting mapping inside the flash chip could also be considered "256 times 16k".

Note that banks 0 and 1 (and thus the first 16k bank) have their special use in $e000 and $de00.

$DE00 read-page

When in run mode, there's always a 256-byte page visible in $DE00-$DEFF. The location of this page is a mirror of bank 0, C64 address $9E00 (chip address $00.1E00). This is independent of the contents of the banking register; the page will always stay the same, and it will remain visible, even if all of the 8k ROM banks have been switched off. This can be used for trampoline code, but also for quick banking to fixed banks without losing the contents of A, X and Y: By placing strategic read-values to $DE00-$DE02, you can use INC, DEC, ROL, ROR, ASL and LSR to switch to specific banks and keep all register/accu contents. If you really need to, you can place different read-values to the different mirrors to have more "quick banks" available. In such a case, please let us know which mirrors you're using, so we can avoid placing essential registers there in future versions of GMod.

In BitbangMode, this page contains 256 mirrors of the flash_Dout signal, which is mapped to bit#7. Bits 0-6 are random in that case.

8MByte and 16MByte versions of GMod4

The larger versions of GMod4 have one (8MB) or two (16MB) additional address bits outside the banking registers. Bits #4 and #5 of the Control register should be kept at 0 for the 4MByte version of the cartridge, although it is likely that the smaller flash chip(s) will ignore these upper address bits. The actual size of the flash chip can be read using the "read JEDEC ID (0x9f)" command using the Bitbang mode (see further down). If a chip larger than 4MB is installed, the banking bits will switch whole 4MByte banks, meaning, it's like you've inserted a different 4MByte GMod4. All banks will be mapped to the new 4MByte bank, and even the $e000 and $de00 areas will be fetched from the different 4MByte-bank. If you require these areas to stay the same when switching to a different 4MByte-bank, you need to put copies of the contents to the beginning of each 4MByte-bank.

GAME and EXROM control, effects of $01

GMod4 controls the GAME and EXROM lines dynamically in order to achieve maximum flexibility. These lines are only pulled for CPU read accesses, but not for VIC accesses or CPU writes. This means that for the 8k area starting at $8000, only EXROM is pulled low. For the 8k area starting at $a000, both the GAME and EXROM lines are pulled low. For both these areas, behaviour of the $01 register (specifically the Loram bit) is "as expected". Writes to this area will always reach the underlying memory.

For the 8k area starting at $e000, only the GAME line is pulled low, so the system is in Ultimax mode for this region. This means that the contents of $01 have no effect on Reads from this memory region. Writes will reach the memory "under" the ROM, so this region can be used for VIC display.

If one of the three areas is disabled with a 1-bit in the Control register, the GAME/EXROM lines are not pulled at all. If all three areas are switched off, the computer will behave just like a normal C64, with the only change that the bank/control registers are still there, and reading from $dexx will return flash contents, provided that the cartridge is in RUN mode.

Bitbang mode

With BitBang mode, you can write to the SPI flash chip and use it for saving highscores of a game. Since the whole chip can be accessed, the size of your save-area can be as big as the cart itself, if desired. This will not only allow large highscore lists with long names and comments, but also game updates (field updates, bugfixes), adding new levels or even provide a level-editor for the user to play with. Some level of care should be taken, as Bitbang mode can mess up the contents and status of the flash chip to a level where the computer won't start any more with GMod4 inserted. This state is commonly called "bricked", as the cartridge appears to be only good as a paper weight. See chapter "de-bricking" for that case.

When bit#0 of the Control register is set to 1, the upper three bits become direct bit-bang bits for direct communication with the SPI flash chip that is installed on GMod4. Going into Bitbang mode will immediately switch off the possibility to read from the 8k ROM areas, so your code MUST run from RAM if you want to use Bitbang mode. Since you only have control over three lines of the SPI flash chip, you cannot use any Dual- or Quad-SPI commands. For reading the Data-out line of the SPI flash, read $de03: Bit#7 will contain the status of the serial output line.

We further recommend to put all SPI signals into "idle" state, which is 1, before switching to Bitbang mode. This will ensure that the SPI flash chip will be in a known state and you can immediately send a command. Sending a command is done by first selecting the chip (set CS bit to 0), then set the bit you want to clock in on the Din bit, and then cycle the CLK bit from 0 to 1 (rising clock edge). After sending the command and parameters to the chip this way, the SPI chip will output it's data on the falling edge of the CLK signal. The real-time state of the DO signal is visible in bit#7 of $dexx (all 256 addresses). This lets you react to the status using the BIT command, or you can build a byte by ROLing data through the Carry flag. However, you should not use any address, but ROL $de03, as the command will also execute a write to the address. Choosing $de03 will not alter the contents of Bank registers or the control register, and it'll keep the accumulator available for shifting the byte.

All serial communication with SPI flash chips is MSB-first. While reading data, you still send bits into the SPI chip, which are ignored. For good measure, you should set the Din signal to 1, pumping $ff-bytes into the chip while getting data.

Flash cannot be written per-byte (as can be done on EEPROMs), but only on a per-page basis, so if you only want to alter a few bytes, you should copy the complete page to RAM, switch to Bitbang mode, and then do a page-erase/page-program sequence once you have done your changes in the RAM buffer.

Before switching back to RUN mode, the flash chip should be de-selected by raising all three control bits to 1.

de-bricking GMod4

If you do not have the mass-flasher hardware from iComp (which can write to the SPI flash regardless of it's current contents and state), some hardware modification will be needed. You have two options - either modify GMod 4, or modify the C64 that will be used for de-bricking the cartridge. The easiest mod is to disconnect the GAME line from the cartridge port of the C64. This will eliminate both the $e000 and $a000 ROM areas and restore the standard Kernal and Basic ROMs, so the computer will start fro there. Since it's very unlikely that you're using a CBM80 identification in any of the $8000 banks, the computer should start with 30719 basic bytes free. You should be able to launch your de-brick software from this state. If there's a CBM80 signature in the $8000 bank, you may need to cut the EXROM line as well, reducing GMod4 to the $de00 area only.

Your second possibility is modify GMod4: There is a solder bridge "BR1" on the bottom of the circuit board that is normally closed. Right next to that solder bridge, there's an unpopulated resistor "R1". If you assemble the resistor with a 10k/0402 part and cut the connection between the two solder pads of BR1, the computer will launch normally with 38911 bytes free and only the $de00 read window and bank/control registers are active. This is equivalent to opening the connection to both GAME and EXROM lines inside the computer From this state, your de-brick software has access to the SPI chip through Bitbang mode. After de-bricking is completed, you can close the solder bridge BR1 with a glob of solder, and R1 can remain in place; it has no function when BR1 is closed.

Mass flasher hardware

Flashing 4MBytes of content to a C64 cartridge can't possibly be made with a C64, as there is no fast-enough mass storage device that does NOT the cartridge port. We'll therefore offer a USB device with a 44-pin cartridge port that is hot-pluggable. The current development status is that a 4MByte image is programmed in 2 minutes and 40 seconds. The mass-flasher has enough local flash memory to also work as a stand-alone device, just getting power from a USB power supply. For highest throughput, we recommend to use multiple of these mass-flasher devices.

Software for the mass-flasher hardware is available as command line tools only. The protocol for talking to the mass-flasher will be open, giving developers the possibility to add support to their personal toolchain on the operating system of their choice.

The mass-flasher hardware also supports other models of GMod, such as GMod2 and the Megadrive versions of GMod.

Downloads

• The GMod4 repository contains example code

• Preliminary VICE patch (against SVN Trunk) is here.

Credits

Large parts of the GMod4 concept have been implemented after extensive e-Mail exchanges with Chester Kollschen (Knights of Bytes), who consistently made the point that 16k ROM banks will make an author's life much easier, and also requested a possibility to replace the kernal ROM, especially for having custom IRQ/NMI/Reset vectors in the cart. Further details have been added after getting requirements from publisher Protovision. The hardware of GMod4 and the Mass-flasher is (C) Jens Schönfeld. VICE emulation, example sources and GMod4 support software are made by iComp staff. VICE emulation code is published under GPL. Other code is licensed under the condition of being used for our hardware.