Old News (12/29)

I've been examining a Pre-System 16 board and have noticed something interesting. The game Body Slam has a MCU for protection. If the MCU isn't present, the game will not run at all. In some System 16A and Pre-System 16 games that are not protected, the MCU is replaced with a small board which I think connects some of the pins together. It looks like this:

It is required for the game to run, as opposed to leaving the MCU socket empty. Does anybody have an idea what this part does? Could someone provide scans of it (front and back) so I could see the connections?

At the moment, it seems that the Body Slam MCU doesn't do a checksum on the code as I can run patched versions of the software. I'll try some of my own test programs later and hopefully the MCU will not interfere too much, but it would be better if I could bypass it entirely.

A few interesting things I've observed is that the SCONT1-0 pins (bits 1,0 of PPI port B) control the horizontal position of the tilemap and text layers, but not the sprites. Setting these bits to zero (normally both 1) offsets the layers to the left by about 256 pixels. Also, the MCU has access to color RAM and text RAM as it generates the warm-up screen that isn't present in MAME, in fact the MCU will show the warm-up screen even if no program ROMs are present.

I've rewritten my Sega System 18 hardware notes, here's the new version:

• s18tech.txt

Also, I have a System 18 sound player in the works that I will release soon, after looking into possible support for System 32 games which use very similar hardware.

I've successfully patched the bootleg version of Alien Storm (supported in MAME) to be almost 100% playable on the original hardware. This was of particular interest to me as the custom CPU battery in my Alien Storm board failed, and it is impossible to get a replacement from Sega.

I won't distribute the patched ROMs, so here's the patching routine from my emulator's source code:

• as_patch.c

There are a few minor problems in the game that I noticed while playing:

• When there are too many sprites on screen, the sprite addresses are trashed until the amount is reduced.
• Row scrolling in the first person stages is off.
• Background scrolling is also off, there are a lot of places especially in the last level where the wrong pages are shown.
  The only real problem this causes gameplay-wise is making the last boss invisible except for it's eye.
• The first player has infinite energy. Not a bad thing. :)
• In the ending, the enemy ship and explosions have the wrong colors.
• The 'THE END' object has correct colors which are incorrectly changed during color cycling.
• The main players float away in a bubble which only shows the top half.
• In the later levels, some sprites 'stick' in the first person stages and disappear much later.

Old News (12/20)

I was able to get quite a lot of work done with the Sega System 18 hardware. Here are general descriptions of two custom chips, and then some specifics about the hardware itself.

I/O chip (315-5296)

The I/O chip has 8 bidirectional I/O ports, three output pins, and provides an chip select and clock output for interfacing with another device like a sound chip. It has an 8-bit data bus and 64 internal locations, used as follows:

    $00-$07 : Port A through H data input/output registers (r/w).
    $08-$0B : Protection ID registers. (read only, returns ASCII text 'SEGA')
    $0C-$0F : Control registers (r/w).
    $10-$1F : Unused.
    $20-$3F : Unused. (/FMCS area)

Register $0E controls the output state of the CNT2-0 pins:

    D7 : ?
    D6 : ?
    D5 : ?
    D4 : ?
    D3 : ?
    D2 : CNT2 (1= high, 0= low)
    D1 : CNT1 (1= high, 0= low)
    D0 : CNT0 (1= high, 0= low)

    D7 : Port H direction (1= output, 0= input)
    D6 : Port G direction (1= output, 0= input)
    D5 : Port F direction (1= output, 0= input)
    D4 : Port E direction (1= output, 0= input)
    D3 : Port D direction (1= output, 0= input)
    D2 : Port C direction (1= output, 0= input)
    D1 : Port B direction (1= output, 0= input)
    D0 : Port A direction (1= output, 0= input)

• Registers $0C,$0D are read-only mirrors of $0E,$0F. Writes do nothing.
• Data written to registers $0E,$0F can be read back from $0C,$0D,$0E,$0F.
• If a port is configured as an input, you can still write to it to set the output state of the pins, which will be used once the port is set to be an output later.
• If a port is configured as an output, reading it returns the last value written to it.
• After reset, all ports are inputs and registers $0E,$0F are zero.
• The chip has a clock output which is the same as the input clock divided by 4.

The color encoder is basically a DAC connected to the color RAM, which provides analog outputs for driving a monitor. This part is used in System 18,24,32,C2, Galaxy Force, and probably others.

                +----v----+
            GND |01 i i 32| GND
          /GRAY |02 i o 31| B OUT
             B0 |03 i o 30| B OUT 2
             B1 |04 i i 29| /SHADE /ON/OFF
             B2 |05 i i 28| SHADE HI/LO
             B3 |06 i i 27| /BLANK
             B4 |07 i i 26| CLOCK
            VCC |08 i i 25| G0
             R0 |09 i i 24| VCC
             R1 |10 i i 23| G1
             R2 |11 i i 22| G2
             R3 |12 i i 21| G3
             R4 |13 i i 20| G4
        R OUT 2 |14 o o 19| G OUT 2
          R OUT |15 o o 18| G OUT
            GND |16 i i 17| GND
                +---------+

 /BLANK         : Blanks the display, output color is black.
 /GRAY          : Makes the video output grayscale instead of color.
 /SHADE ON/OFF  : Enables shadow/hilight processing.
 /SHADE HI/LO   : Brightness of output pixel is either halved (shadow effect)
                  or doubled (hilight effect) when /SHADE ON/OFF is low.
 CLOCK          : Pixel clock input. Typically 6 MHz for a 320-pixel display.
 R4-R0          : Red color component input from color RAM.
 G4-G0          : Green color component input from color RAM.
 B4-B0          : Blue color component input from color RAM.
 R,G,B OUT      : Amplified RGB output. Can drive a monitor directly.
 R,G,B OUT 2    : Unamplified RGB output.

Typically, the mixer hardware enables shadow/hilight processing and bit 15 from color RAM is the shadow or hilight select bit.

There are at least two variations of the System 18 hardware, here are the ones I know of:

 Game           Main Board      ROM Board

 Alien Storm    171-5873B       171-5874B
 Clutch Hitter  171-5873-02B    171-5987A

Like the System 16 hardware, the 315-5360 chip controls a user-definable memory map which consists of eight regions:

 Region  Alien Storm     Clutch Hitter

    0    Program ROM     Program ROM (sockets ROM0-O,E)
    1    Unused          Program ROM (sockets ROM1-O,E)
    2    VDP             VDP
    3    Work RAM        Work RAM
    4    Sprite RAM      Sprite RAM
    5    Tile/Text RAM   Tile/Text RAM
    6    Color RAM       Color RAM
    7    I/O area        I/O area

Shadow Dancer is an exception; region 2 seems to be unused and region 1 is set to the VDP area at $C00000-$DFFFFF. It doesn't use the VDP for video, but obscures the tile banking routine by storing the bank value in word 0 of VRAM and reading it back later before copying the value to I/O port H. I don't have any information about the main or ROM board this game uses.

For both Alien Storm and Clutch Hitter, region 2 must be mapped to $C00000-$DFFFFF in order to access the VDP. If not, writes do nothing and reads return the prefetch value. The VDP will still oprerate normally, but it's registers will be unavailable.

The I/O area is a 16K space repeatedly mirrored throughout the banks allocated to it:

    Region          I/O chip    
    offsets         offsets     Description

    $0000-$0FFF     $00-$1F     I/O chip registers and unused locations
    $1000-$1FFF     $00-$1F     I/O chip registers and unused locations
    $2000-$2FFF     $20-$3F     Video control register
    $3000-$3FFF     $20-$3F     /EXCS area

Values written to odd bytes in the $2000-$3FFF range are stored in the video control register, explained later. Reads return the prefetch value and do not make the latch load in the contents of the data bus.

Any expansion boards plugged into CN5 will appear at $3000-$3FFF. This is used by the D.D. Crew I/O board.

The System 18 hardware uses the chip like so:

    Port A - 1P controls

    D7 : Joystick left (0= pressed, 1= released)
    D6 : Joystick right (0= pressed, 1= released)
    D5 : Joystick up (0= pressed, 1= released)
    D4 : Joystick down (0= pressed, 1= released)
    D3 : Button D (0= pressed, 1= released)
    D2 : Button C (0= pressed, 1= released)
    D1 : Button B (0= pressed, 1= released)
    D0 : Button A (0= pressed, 1= released)

    Port B - 2P controls

    D7 : Joystick left (0= pressed, 1= released)
    D6 : Joystick right (0= pressed, 1= released)
    D5 : Joystick up (0= pressed, 1= released)
    D4 : Joystick down (0= pressed, 1= released)
    D3 : Button D (0= pressed, 1= released)
    D2 : Button C (0= pressed, 1= released)
    D1 : Button B (0= pressed, 1= released)
    D0 : Button A (0= pressed, 1= released)

    Port C - Bidirectional I/O port

    D7 : To CN8 pin 3
    D6 : To CN8 pin 4
    D5 : To CN8 pin 5
    D4 : To CN8 pin 6
    D3 : To CN8 pin 8
    D2 : To CN8 pin 9
    D1 : To CN8 pin 10
    D0 : To CN8 pin 11

    Port C is connected to a 74LS245 whose output goes to CN8.
    The CNT0 output pin controls the DIR input of the 74LS245.

    Port D - Miscellaneous output

    D7 : ?
    D6 : To color encoder /GRAY input (0= grayscale, 1= color)
    D5 : To tilemap/sprite generator flip screen input (0= normal, 1= flip)
    D4 : To pin 2 of CN8.
    D3 : Coin lockout 2
    D2 : Coin lockout 1
    D1 : Coin meter 2 (increment counter on 0 to 1 transition)
    D0 : Coin meter 1 (increment counter on 0 to 1 transition)

    Pin 2 of CN8 is a high current output capable of driving a lamp or coin meter.
    Bit 5 enables screen flipping for the tilemap and sprite layers, it is connected to both chips.
    It and bit 6 do not affect the VDP display which is separate.

    Port E - Service / Coin inputs

    D7 : Always returns '1'
    D6 : Select Game button (0= pressed, 1= released)
    D5 : 2P start button (0= pressed, 1= released)
    D4 : 1P start button (0= pressed, 1= released)
    D3 : Service switch (0= pressed, 1= released)
    D2 : Test switch (0= pressed, 1= released)
    D1 : 1P coin meter (0= Coin inserted, 1= No coin)
    D0 : 2P coin meter (0= Coin inserted, 1= No coin)

    Port F - DIP switch #1

    D7 : Switch 8 (1= Off, 0= On)
    D6 : Switch 7 (1= Off, 0= On)
    D5 : Switch 6 (1= Off, 0= On)
    D4 : Switch 5 (1= Off, 0= On)
    D3 : Switch 4 (1= Off, 0= On)
    D2 : Switch 3 (1= Off, 0= On)
    D1 : Switch 2 (1= Off, 0= On)
    D0 : Switch 1 (1= Off, 0= On)

    Port G - DIP switch #2

    D7 : Switch 8 (1= Off, 0= On)
    D6 : Switch 7 (1= Off, 0= On)
    D5 : Switch 6 (1= Off, 0= On)
    D4 : Switch 5 (1= Off, 0= On)
    D3 : Switch 4 (1= Off, 0= On)
    D2 : Switch 3 (1= Off, 0= On)
    D1 : Switch 2 (1= Off, 0= On)
    D0 : Switch 1 (1= Off, 0= On)

    Port H - Tile banking

    D7 : Bit 3 of tile bank 2
    D6 : Bit 2 of tile bank 2
    D5 : Bit 1 of tile bank 2
    D4 : Bit 0 of tile bank 2
    D3 : Bit 3 of tile bank 1
    D2 : Bit 2 of tile bank 1
    D1 : Bit 1 of tile bank 1
    D0 : Bit 0 of tile bank 1

    Output pins (summary)

    CNT0 - To 74LS245 DIR to control direction of port C connected to CN8.
           0= Input from CN8 to port C
           1= Output from port C to CN8

    CNT1 - OR'd with tilemap chip blank screen output, goes to /BLANK input of color encoder.
           0= Screen blanked
           1= Screen shown

    CNT2 - To enable input PAL controlling VDP display enable.
           0= VDP output not shown
           1= VDP output visible

For Alien Storm, the lower three bits of each nibble select the tile ROM bank. If bit 3 of either nibble is set, the tile bank is always 0 and the tiles flicker a little. Most likely this is the high order address line which is unused in the ROM board. The bank select is from bit 12 of each word in tile RAM, and is always 0 for text layer tiles.

Tile banking doesn't work at all on Clutch Hitter, though the banking hardware seems identical; the port H outputs are fed into an always-enabled 74LS157, whose output is the tile ROM high order address bits. The select input comes from the tilemap generator. I have the same problem with sprites which are not shown. The actual game itself runs fine, so there's some step I'm leaving out, apparently.

Another oddity is that CNT0 makes the screen flip, even though it is not connected to the flip screen signal and quite clearly goes to the DIR pin of the 74LS245 between port C and CN8. This holds true for both board types. Maybe an actual mistake in the hardware?

Video control register

There is a 82S153 PLA used in both board types used to control how the VDP and System 18 graphics (tilemap, sprites) are mixed together. There are two differently programmed versions of the chip which have the same pinout, Alien Storm uses a 315-5373, Clutch Hitter uses a 315-5430. Here's a incomplete set of pin assignments:

                +----v----+
           CNT2 |01 i   20| VCC
              ? |02   o 19| To enable inputs of analog switch for VDP RGB
              ? |03   o 18| To enable inputs of analog siwtch for color encoder RGB
              ? |04   i 17| From video control latch bit 0
              ? |05   i 16| From video control latch bit 1
              ? |06   i 15| From video control latch bit 2
              ? |07   i 14| From video control latch bit 3
              ? |08   i 13| 315-5313 pin 39 (VDP /YS)
              ? |09   ? 12| 315-5313 pin 40 (VDP SPA/B)
            GND |10     11|
                +---------+

The chip can detect transparent pixels and differentiate between sprite and tilemap pixels in the System 18 video. Some of the unknown pins must be used for that purpose. I figured this information could be taken from the color bus, but it isn't connected to the chip.

The unamplified RGB output of the color encoder and the VDP RGB output go to two analog switches. The switches are controlled by the chip which can independantly enable or disable the System 18 or VDP video. Both switch outputs are connected to an amplifier circuit which boosts the video signal so it can drive a monitor.

If you remove the PLA both switches output the System 18 and VDP graphics which are overlaid on each other. I guess the hardware sums the two signals together, as the output is much brighter. I think the PLA only enables one or the other at any given time.

Some common features of the two chip types are that CNT0 enables or disables the VDP video output. When enabled, the VDP graphics appear behind the System 18 opaque pixels. The VDP backdrop isn't shown, instead the System 18 one (from color RAM entry zero) is shown.

Concerning the video control register, the Clutch Hitter PLA will disable System 18 video and enable VDP video if bit 3 and/or 2 is set. Bits 1-0 have no use.

For the Alien Storm PLA, when bits 2 and 1 are set, the System 18 video appears wherever there are transparent pixels in the VDP video. When bit 0 is cleared, System 18 sprites appear over the System 18 tilemaps and VDP video. When bit 0 is set, the sprites are shown behind the VDP just like the tilemaps. Bit 3 is unused.

Miscellaneous

Here are the pin assignments for CN8:

    1 - GND
    2 - Port D bit 5 (high current output)
    3 - Port C bit 7 (input)
    4 - Port C bit 6 (input)
    5 - Port C bit 5 (input)
    6 - Port C bit 4 (input)
    7 - GND
    8 - Port C bit 3 (input)
    9 - Port C bit 2 (input)
   10 - Port C bit 1 (input)
   11 - Port C bit 0 (input)
   12 - GND

I did all this testing and forgot to check my D.D. Crew board, so I'll have to do that next. ;)

Just a minor update, I wanted to point out a few interesting things about System 16B sprite rendering I discovered. According to the Hang-On schematics, sprites are rendered to the line buffer at 12MHz, while the other buffer is being scanned to the display and erased at 6MHz. The System 16B hardware runs slightly faster, with a 12.5874 MHz rendering clock and 6.2939 MHz dot clock. This gives about 800 12MHz clock ticks per line to render with.

By my estimates, timing is divided up like so:

    8 ticks to process sprite attributes:
        1 tick to read top/bottom word (0)
        1 tick to read x-position word (1)
        1 tick to read control and pitch word (2)
        1 tick to read bank offset word (3) OR current bank word (7)
        1 tick to read bank select / priority / palette / word (4)
        1 tick to read zoom control word (5)
        1 tick to write back unknown data to high bits of word 5
        1 tick to write back current address to word 7
    1 tick per pixel rendered to the line buffer

In my tests, I was able to display a 320-pixel wide sprite three times; the last one was partially cut off due to dropout, so only the first 128 pixels were drawn. Assuming the above timings, this works out to be 792 ticks, which fits nicely within the 800 tick limit. X and Y zooming does not affect timing, and there is an extra 4 tick overhead for any sprite when it's top line is equal to the screen V counter. I think with this information the sprite limitations of the hardware can now be emulated.

I will receive a Pre-System 16 type board soon, and after running some tests I'll document the hardware and release my notes in the next update.

I recently had the chance to do some more Sega System 16B testing and have come up with the following:

By disabling the screen blanking circuit, I was able to examine how the tilemap and sprites are shown in the border areas. Each scanline has a left and right border, which consist of at least 16 pixels each. I tried filling each tile in a row with numbers from 00 to 3F, and the resulting image showed columns 3E, 3F in the left border, columns 00-27 in the active display area, and columns 28-29 in the right border.

The next thing to determine was when the sprite line buffer was being read to the display and from what offset. Because of the lack of blanking, my monitor showed distortion on any scanlines where sprites were displayed. What was interesting is that any X position from $0000 to $01FD caused this, which is a little confusing. This would seem to indicate that there are at least 510 pixels per scanline, but that seems like too many. My calculations show there are ~400 pixels per line, with at least 352 used for the borders and visible display with 48 left over.

Being able to observe the border area finally gave a way to determine the sprite X position in relation to the tilemaps. The last visible sprite X position is $01FD, which draws the first pixel of the sprite in the last pixel of column $28. Working backwards, this makes pixel 0 of the active display correspond to a sprite X position of $00B6. For positions of $01FE and $01FF, no sprites are displayed. Either the sprites aren't being rendered to the line buffer past this point (unlikely) or the line buffer isn't being read to the display, which I think is the case.

Sprites are drawn on scanlines $00-$E7, even though the last 8 lines fall outside the normally visible range of the display. On each line, the sprite generator has a fixed amount of time to render sprites to the line buffer. If it runs out of time due to too many sprites being displayed (e.g. many small sprites or a few large ones) then the last sprite being drawn will only be partially written. Rendering occurs from left to the right, so pixels on the right are dropped when time runs out.

An unusual effect can be seen when remaining sprites to be drawn in a line are not processed. Word 7 of each entry in the sprite attribute table holds the current address to fetch data from. When a sprite is drawn, the hardware reads the word, adds the pitch to it, and stores it back for use on the next line. If a sprite isn't processed, the offset isn't updated and whenever it is processed again on a later line and it's position resumes from the last time word 7 was updated. The exception to this is when the top line of the sprite is cut off due to running out of time; in this case the sprite is shown from the start position in word 3. I would assume the sprite generator knows if it hasn't processed the top line yet and reads word 3, adds the pitch to it, and stores it back in word 7. How it keeps track of this is unknown.

I do think it's possible to do raster effects with the sprites by rewriting word 7 to stretch or shrink them, but CPU access to sprite RAM has priority and makes the sprite generator read garbage data when the two accesses conflict. So it's not really possible with the System 16B hardware, but for System 18 you could use the VDP's V counter and status flags to minimize access to sprite RAM during H-Blank. I also checked and bits 15-10 of the zoom control word which are written in by the sprite generator do not seem to be used for any internal operations like word 7 is, modifying them did not change the related sprite at all.

I finished testing the multiplication feature of the 315-5248 chip used in Afterburner/Thunderblade and on the 171-5797 ROM board. Nothing too special here, it does the same thing as a 'muls.w' instruction with the advantage of completing fast enough to not need any delays. I also figured out how the compare feature of the 315-5250 chip works, here is some "C" pseudocode to show how the result is calculated (optimized for readability and not speed :)

 A   = Value written to offset 0 (lower or upper bound)
 B   = Value written to offset 2 (lower or upper bound)
 C   = Value written to offset 4 (value to test)
 MIN = Smaller value of A and B (unsigned comparison)
 MAX = Larger value of A and B (unsigned comparison)

 All values are unsigned 16-bit words, and the return values from the
 compare chip can only be 0, $4000, or $8000.

 // Both values are zero
 if(A == 0x0000 && B == 0x0000)
 {
    if(C == 0x0000) return 0x0000; 
    if(C <= 0x7FFF) return 0x4000;
    if(C >= 0x8000) return 0x8000;
 }

 // Both values are -32768
 if(A == 0x8000 && B == 0x8000)
 {
    if(C == 0x8000) return 0x0000;
    if(C == 0x0000) return 0x4000;
    if(C <= 0x7FFF) return 0x4000;
    if(C >= 0x8000) return 0x4000;
 }

 // Both values are positive
 if(A <= 0x7FFF && B <= 0x7FFF)
 {
    if(C >= 0x8000) return 0x8000;          
    if(C < MIN) return 0x8000;             
    if(C > MAX) return 0x4000;
    if(C >= MIN && C <= MAX) return 0x0000;
 }

 // Both values are negative
 if(A >= 0x8000 && B >= 0x8000)
 {
    if(C <= 0x7FFF) return 0x4000;
    if(C < MIN) return 0x8000;
    if(C > MAX) return 0x4000;
    if(C >= MIN && C <= MAX) return 0x0000;
 }

 // Signs are different
 if((A & 0x8000) ^ (B & 0x8000))
 {
    if(C <= MIN || C >= MAX) return 0x0000;
    if(C > MIN && C <= 0x7FFF) return 0x4000;
    if(C >= 0x8000 && C < MAX) return 0x8000;
 }
    

It would take too long to test all possible input values, so I checked all of the special cases and have been running random values through the hardware registers and my result-generating code to check for any errors for a few hours. I am quite confident that the above code is correct, however I tried altering the After Burner driver in MAME to use the new compare logic, and After Burner II has some unusual gameplay problems after the refuel screens. The original After Burner seemed to run fine. I don't know if this means there is a problem on my end, or if having the "corrected" code exposes other problems in the emulation. The 315-5250 does have a second set of compare registers which I can't check, as they are unconnected on the 171-5797 board and may act differently.

This chip is also used to manage the two 68000's in After Burner, it allows the main CPU to access a 1MB window into the second CPU address space, at which time the second CPU is halted. It can access any of the memory, registers, or RAM this way. To get better synchronization between the two CPUs, it may be necessary to emulate this "cycle-stealing" behavior. Anyway, I'll try to put all of this together in my documentation, time allowing.

I've done some work on documenting the System 16B sound and I/O hardware. I was able to make a lot of progress after realizing I could dump the 315-5214 chip (used for Z80 address/port decoding) by wiring it's inputs to the address lines of a 27256 socket and the outputs to the data lines. By reading the chip in a device programmer as a 27256 EPROM, it ran all possible values through it's inputs and saved the resulting outputs. This gave me 100% accurate information on how the chip is used.

Here's the current version of the sound hardware notes:

• s16sound.txt

I have released an experimental version of SMS Plus, which has a number of internal changes which will eventually support features like PAL systems and other VDP types. I would like to get feedback on any games that do not work any more, the only one I have noticed is Cool Spot which now has some graphical problems. Some users may want to continue to use the previous version, since this one is really more of a beta.

Also, the save state format has changed and is incompatible with previous ones. This had to happen eventually and there will probably be more changes to the state format in the future. Perhaps in the next version I'll add the ability to import old states files from previous releases of SMS Plus.

Here's the current source code and DOS port:

• sp-101903-dos.zip DOS binary
• sp-101903-src.zip Source code

I've made a number of changes to the website, including switching over to PHP instead of plain HTML, removing the banner ads, and adding a new counter. If you notice any broken links or missing pages, please let me know.

I've updated my Super Magic Drive transfer utility with an option to dump SMS cartridges through an adapter:

• smdutil-080503-dos.zip DOS binary
• smdutil-080503-src.zip Source code

• m5test.zip

I've updated my Super Magic Drive transfer utility with some new features such as a DRAM test option and support for loading programs in BIOS mode, as well as improving the error handling.

• smdutil-071703-dos.zip DOS binary
• smdutil-071703-src.zip Source code

I've recently made some progress emulating an arcade game called "Alien Command" made by Jaleco in 1990. Here are a few preliminary screenshots:

Alien Command seems like a fairly unique game compared to other Jaleco games of the same time period. It's a gun-based shooter like Alien 3, featuring a ticket dispenser, and apparently has moving objects in the cabinet controlled by magnets and motors, according to the test mode.

If anybody owns the PCB for this game and could provide some part numbers for the various chips and other components, could you please get in contact with me? There was no information file included in the dump, and being able to ID some of the parts would really help. Any general information about the game (number of buttons on the gun, DIP switch settings, other outstanding features, etc.) would also be nice to know.

Pascal Bosquet has ported SMS Plus to the Dreamcast. You can get it from the official website:

• www.pascalorama.com

I've updated the DOS and Windows/SDL binaries of Genesis Plus to be up to date with the previous source code release. I also removed some debug stuff from the source which is also updated, but is functionally the same as the last version.

• gp-062203-win.zip Windows/SDL binary
• gp-062203-dos.zip DOS binary
• gp-062203-src.zip Source code

I've made a quick fix to the Genesis Plus source code which prevented Altered Beast and Alex Kidd from working. Any other games that access the VDP through the Z80 banked memory area will also now work.

• gp-052503-src.zip

I've updated some of my documentation again:

• Saturn hardware notes
• Saturn VDP1 hardware notes

I've spent a lot of time running tests on a Sega System C2 board, and have written up some technical documentation on the hardware:

• c2tech.txt

I have been making a lot of improvements to the Sega System 24 emulator, adding linescrolling, better sprite rendering, and fixing some bugs in the memory handling. I will try to release the emulator (source too) as well as an updated set of hardware notes soon.

The other project I've been putting effort into is developing a specification for storing ripped Genesis sound code/data, which allows for music playback just like SID/NSF/HES files (no more bulky GYMs). I've been able to successfully extract the music from about 20 games so far, and plan to release some tools, a player, and a document outlining the file format when possible. Currently I'm testing out the music rips using a conversion utility which appends a player to the file, allowing it to be run on any Genesis emulator or a copier.

It turns out that my System 24 emulator does actually play a game to some extent, I had started up Tokoro San no MahMahjan and let it sit at the information screen for a while, and much to my surprise the title screen, and in-game demo work. You can also skip the delay by entering and exiting service mode. It locks up eventually, but this means I was able to get enough data to work on sprite emulation and double check it against the Hot Rod object test sequence. Here are some screenshots:

(Click on an image to see it displayed at full size)

I still need to work on layer priority and scrolling for the tilemaps, which is why some of the screenshots have the background out of place. I've also updated my Sega System 24 hardware notes with some corrections and all of the new sprite information:

• s24tech.txt

I'll update the System 24 emulator source code and Windows binary soon, apart from cleaning up the sprite emulation I wanted to throw in some optimizations for the tilemap rendering and a frameskip feature.

I've modified a Super Nintendo Street Fighter II Turbo cartridge to support flash memory, allowing for development of HiROM programs. Here's a link to the instructions:

• sfcdev2.php

I've also completed a FAQ for the Super Famicom game "Psycho Dream", which I tested on the above cart. :) Check the FAQ section for details.

I've updated my Sega System 24 documentation based on all of the findings that came about when updating my emulator:

• s24tech.txt

Regarding the Genesis link cable below, it doesn't seem to work on any of the Genesis systems (1,2,3) unless a copier is plugged in to the cartridge port. I don't know why this is, but it's extremely unfortunate as I was hoping to put together a package to do program development using only the Comms Link and a modified Genesis cartridge so you wouldn't need a copier in the first place. Also, this would have allowed testing of special cartridge hardware (e.g. Virtua Racing) through use of a modified Game Genie, with test programs being uploaded through the joystick port.

I've done some work figuring out how the Comms Link card sends data to the PAR, and have written up a few notes about it:

• comminfo.txt

• gencom.zip

Here's a new version of my SuperGrafx hardware notes. The main points of interest are an explanation of the VDC #2 interrupt management and more details about the VPC priority settings.

• sgxtech.txt

I recently wrote up an example program to test an idea about triggering the VRAM to SAT DMA transfer more than once per frame. It worked, and apart from the amount of time taken by DMA there is no limit to the number of times you can re-load sprite table. This program shows three unique tables of 16 sprites each on a single frame. A more realistic use of this feature would be a split-screen game where up to 128 sprites could be utilized at once.

• pce-obj.zip

I've been running some tests on the TurboGrafx-16 CPU and found an interesting undocumented feature. It seems that it always fetches two bytes from the current address it is executing data from, even if the instruction has no operands. This may be to speed up the fetch/decode step during execution. I was able to determine this by execting code from the VDC data port and seeing what address MARR was set to afterwards. Here are some examples:

    VRAM data: 00 EA AA BB
    Instruction: JMP $0002

    The CPU reads $00 from $0002 which is BRK. After returning from BRK, the
    data from VRAM is 'AA BB' meaning that $0003 had been read.

    VRAM data: 60 EA AA BB
    Instruction: JSR $0002

    The CPU reads $60 from $0002 which is RTS. After returning, the data
    from VRAM is 'AA BB' again, meaning that $0003 was read.

    VRAM data: B0 EA AA BB
    Instruction: CLC / JMP $0002

    The CPU reads $B0 from $0002 which is BCS. The branch isn't taken, but
    the CPU reads and discards the byte at $0003 anyway. It then reads $00
    from $0004 which is BRK. The data from VRAM is 'AA BB' again, which
    shows that either the CPU fetched a dummy byte from $0003 for it's
    own purpose or because it was retrieving the branch displacement,
    despite not being used.

    VRAM data: EA EA AA BB
    Instruction: JMP $0001

    The CPU reads $00 from $0001 which is BRK. It may read $0002, but this
    doesn't change anything so the VRAM data is 'EA EA AA BB' when read.

It would be interesting to find out if any other CPUs from the 6502 family have this behavior too, or if it's specific to the HuC6280 only. It's not very important to emulate, but I've shown that some kinds of memory mapped hardware can be affected by the extra read.

I've been figuring out how to use MinGW+SDL and have been porting some of my projects over from DOS. I've made a lot of progress with TGEmu and will probably release a new version soon. While still in a WIP state, the Windows/SDL versions of SMS Plus and Genesis Plus also work quite well.

In the meantime, I've decided to release my incomplete Sega System 24 emulator. I've cleaned up the source and added a few features. It doesn't play any games, but the service/test modes are mostly all accessible. Here's a Windows binary and source code:

• s24emu-win.zip
• s24emu-src.zip

I recently did some testing on a NEC SuperGrafx console and have finished up my notes about how the system works. Here's the current version:

• sgxtech.txt SuperGrafx Hardware Notes

There's no time like the present for an update, and I've decided to release a new version of SMS Plus, with a few minor improvements. What will probably be of interest to end users is the inclusion of Mitsutaka Okazaki's EMU2413 sound chip library for vastly improved FM sound, and several minor fixes to the VDP emulation. Check out the emulators page for more details:

• SMS Plus

I've made a big update to my Sega System 16B hardware notes. The new version is available here:

• s16tech.txt