.2021-12-30%2014.23.08.png)
This is a page about the "bonus games" included in the AtGames Sega Genesis Flashback console. They don't seem available anywhere so I thought I'd put them here.
All of the following games only work on the console's internal emulator and Genesis Plus GX-Cyclone. See the section below for technical information.
LightCorp provides another larger collection of AtGames ROMs, available here.
This is a fork of Genesis Plus GX I have created that can play the more graphically sophisticated games. There are still some issues, but every game is fully playable.
You can build it as a core for use with RetroArch. There is a precompiled DLL on the Github page.
If you port it to anything else, or write a better emulator, please contact me so I can put it on this page.
The emulated Mega Drive has some special features which allow for higher-quality graphics. All of the following was verified on the system using a test ROM (binary). You need vasm (m68k CPU, mot syntax) to assemble it. See this guide if you own a Flashback and want to put the test ROM on it.
$18The emulator adds an extra VDP register, which controls the extended display. If bit 7 is unset, everything is exactly like a regular Mega Drive and none of the below applies. More on the other bits later.
VDP Register $18: Extended Display Control Eb..SWBA || |||| || |||+-- Background layer A palette base (0: $000-$3ff / 1: $400-$7ff) || ||+--- Background layer B palette base (0: $000-$3ff / 1: $400-$7ff) || |+---- Window palette base (0: $000-$3ff / 1: $400-$7ff) || +----- Sprite palette base (0: $000-$3ff / 1: $400-$7ff) |+-------- 1: Bitmap mode / 0: Tilemap mode +--------- 1: Extended display mode / 0: Standard display mode
The VRAM size is upped to $1ff7c bytes. Higher addresses (up to $3ffff) are accessible, but reliably crash the system when written. It is likely that the console does not protect against out-of-bounds RAM writes and is trying to overwrite other RAM used by the console. The games themselves never write past $17fff, so you probably shouldn't either.
If extended display is off, the first $10000 bytes are simply mirrored throughout the entire region.
The tile data format is different, and tile graphics are 6 bits per pixel. Each tile row is 6 bytes long, meaning that each tile is $30 bytes long.
The row data makes more sense if you reverse the order of the words, and when you do, a single tile row looks like this:
byte 4 byte 5 byte 2 byte 3 byte 0 byte 1 77777766 66665555 55444444 33333322 22221111 11000000 <--- Rightmost pixel Leftmost pixel --->
Rows are laid out from top to bottom, as normal.
Like a standard Mega Drive, the tiles for both backgrounds and sprites always start at VRAM $00000.
CRAM is at a completely separate $800-byte block. This data holds 8 palettes of 64 colors, where each color is laid out as follows:
byte 0 byte 1 byte 2 byte 3 GGGGGGGG RRRRRRRR ........ BBBBBBBB
Byte 2 of each color is unused and does not affect display.
Name tables/sprites are still limited to 4 palettes at once, and which $400-byte CRAM block they use is selected with the respective bits in VDP register $18.
Extended CRAM and standard CRAM are stored separately, so to access the RAM for the other display mode you must toggle bit 7 of VDP register $18.
Due to the extended palettes, VDP register 7 is extended:
VDP Register $07: Background Color PPCCCCCC | | | +-- Background color +-------- Background palette
The background color is always obtained from the first CRAM block.
When extended display is off, any value written here is masked with $3f. So, if you are setting a background color in palettes 1-3, you must make sure extended display is on first before you perform the write.
The extensions to the VDP address registers ($02, $03, $04, $05, and $0d) follow the same general pattern:
$c000+ now sets the address to $12000+.Interestingly, the emulator keeps the addresses, NOT the values, which means it IS possible to set an address within $c000-$ffff, if you disable extended display mode before you make the write. However, it is not possible to set an address within $10000-$11fff, since when extended display mode is off, any values written which would make the address fall outside of the first 64k of VRAM are masked off.
It is possible to set the address to $20000+, but this area of VRAM is buggy so it's not recommended.
DMA lengths are measured in longs as opposed to the usual words.
DMA source data is now allowed to cross 128k sections.
Bit 6 in VDP register $18 enables a bitmap mode, which allows the display of very colorful static screens. I doubt the games ever use it, but it's there.
Bitmap data always starts at VRAM $04e00. It is laid out row by row, left to right, where each long controls the display of a 2x2 block of pixels. Colors are in the YUV color space, and all pixels in a block must share the same U and V, but Y is customizable per pixel.
Like the tile data, the format makes more sense if you swap the words:
byte 2 byte 3 byte 0 byte 1
UUUUUUVV VVVV3333 32222211 11100000
| | | |
| | | +---- Upper-left Y
| | +--------- Upper-right Y
| +--------------- Lower-left Y
+--------------------- Lower-right Y
Bitmap mode has the following limitations:
The system appears to be able to control ROM mapping. Most of the games work absolutely fine if "weird" writes are ignored, but Firecore multi-game units will simply reset back to the menu upon selecting a game. Unfortunately, details are unknown as of yet.
The D-CAT16 unit uses the following code to remap the ROM area of CPU space to a different starting location in the actual ROM:
move.w #$8001,$a11310 move.w $ff160a,$b01028 ;lower word of ROM base offset move.w $ff160c,$b0102a ;upper word of ROM base offset (yes, the words are swapped) move.w $b0100a,d0 ori.w #2,d0 move.w d0,$b0100a move.w #$8000,$a11310
The functions of some (but not all) of the new registers are documented (in Portuguese) here.