Old News (12/26)

I've been doing a lot of work on my Sega Saturn hardware notes and will try to get another update out soon. Is anyone familiar with what types of keyboards the Saturn's Netlink PS/2 keyboard adapter supports? I have an enhanced keyboard which stops working once any of the 'lock' keys are pressed, and an old AT-style keyboard which behaves normally.

I tried an interesting but unsuccessful experiment that attempted to get my own code working on a Sega custom 68000. I had removed the tile RAM chips from a System 16B board and replaced them with sockets for flash memory chips, which were loaded with a test program. The idea was to change the level 4 interrupt vector to point to my own code at $400000 which hopefully the CPU would execute, assuming it will not try to decrypt program code outside of the ROM range. The concept worked flawlessly in my test case, using Shinobi with a regular CPU. My code started as soon as the game enabled interrupts. I had then tried the experiment with E-Swat and it's custom CPU, but the game always failed to run.

I think it would be safe to assume that the CPU will always try to decrypt program code with no exceptions, unlike other hardware such as CPS-2 (not that the two are related at all, I realize). Luckily I have a few spare System 16B mainboards, and the modified one would work flawlessly if I could find some RAMs to take the place of the old ones.

I've added a Sega Saturn development section to my website, which is accessible here:

• Sega Saturn Info

I recently picked up an original Sega Master System and have updated some of my technical documentation based on my test results:

• msvdp.txt VDP documentation
  
• smstech.txt Hardware notes

I've been doing a lot of work with the Sega Saturn recently. I have developed a few tools for Comms Link users, written some technical documentation, and made a few other utilities which I'll release soon.

Also, I've gotten plenty of nice feedback from Genesis Plus users. When I have the time, I'll integrate some of the fixes and additions most people wanted for the next release.

Richard Bannister has released a Macintosh port of Genesis Plus, which is a Sega Genesis/Megadrive emulator that I've been working on for a few years. You can get it here:

• http://www.bannister.org

I may work on a DOS/Windows port, and possibly release the source code in the future. Right now the Mac version is the only one available.

Here's a screenshot from a Sega Mega Tech emulator I'm working on:

Big thanks to Pachuka for providing dumps of the BIOS and carts.

From what I can tell the games are identical to the original Genesis versions, they even run fine in an emulator. However, the Mega Tech has an extra Z80 which is interfaced to an SMS 2-style VDP (the menu screen runs in 256x224 mode). Carts have an 8-bit ROM that the Z80 can read which has gameplay instructions.

The Mega Tech hardware isn't as weird as the Mega Play board, which I had done some initial work on emulating a while back. Assuming I can get the rest of this running, it should be very easy to interface it into my Genesis emulator and have the entire system going.

I had been running a few tests with the System 16 sprite hardware and figured out some interesting things. For starters, here's the complete layout of an entry in the sprite table:

        MSB          LSB
    00: bbbbbbbbtttttttt
    02: -------xxxxxxxxx
    04: eh-----fpppppppp    
    06: aaaaaaaaaaaaaaaa    
    08: 1111bbbbppcccccc    
    0A: 000000vvvvvhhhhh    
    0C: ----------------    
    0E: mmmmmmmmmmmmmmmm

    b : Bottom line of sprite
    t : Top line of sprite
    x : Sprite X position
    e : 1= Hide this sprite and remaining sprites in list
    h : 1= Hide this sprite
    f : 1= Flip sprite horizontally
    p : Sprite pitch (width, signed)
    a : Start address of sprite graphics within 128K bank (word address)
    1 : Either unused or more sprite bank select bits
    b : Sprite bank select bits. (implementation dependant)
    p : Sprite priority level
    c : Sprite palette
    0 : Sprite Y zoom information
    v : Sprite Y zoom (0=normal, 31=50% reduction in height)
    h : Sprite X zoom (0=normal, 31=50% reduction in width)
    m : Sprite end address
    - : Unused

Word 7 of each entry is filled in by the sprite generator. It writes the address of the last word it accessed within a sprite bank while rendering a sprite. If the sprite has a pitch of zero, is hidden, or if the bottom line is smaller than the top line, the start address is written as the end address. (so no sprite data accessed)

The end address is only affected by the start address, height, pitch, and Y zoom. The sprite X position, horizontal scaling and flip, and actual graphics data from a bank has no effect on it.

In the same way bits 15-10 of word 5 of each entry are also filled in by the sprite generator. Normally zero is written if the Y zoom value is zero, and it changes based on a non-zero Y zoom value, the start address, pitch, and top/bottom line values. I'm not sure what it is supposed to represent, however. It may be the top few bits of a larger internal value, such as the number of words skipped during zooming.

The sprite generator writes this information sometime after the active display period, probably during vblank. If you write a value into the high bits of the zoom word or the end address word, you can read the value back until the sprite hardware renders sprites for this frame and fills in the values itself. I'm going to do some timing tests to see when and how long this whole process takes. If the System 18 sprite hardware works in the same way, I can use the HV counter to get a more accurate measure of time down to units of single scanlines.

I've also done some work investigating the Intel 8751 microcontroller that is used in some System 16B and System 18 games. I couldn't dump the one I have, but it may be possible to replace it with a programmable one (like the flash based Atmel 89C51) which would allow me to write test programs that could see how the 8751 memory map is set up. It seems to have access to the input ports, Z80 sound command register, and 68000 work RAM, at least.

Here's a screenshot from a project I'm working on:

The game plays but with no moving objects, and I'd imagine the original version (Future Flash) should work as well. I found scans of the schematics, so maybe I can figure out what's missing.

I'm almost done documenting the Sega System C2 hardware. I purchased another board (Puzzle & Action 2) to do some additional tests on, and will probably release my hardware notes and some test programs soon. I also expect another minor update to the Sega System 18 document as well.

I've finished up the initial version of my Sega System 18 hardware notes. You can get it here:

• s18tech.txt Sega System 18 hardware notes

Also, I recently picked up an Arcade Card Pro and a Sega System C2 arcade board, and have started doing some tests on these. I'll try to get a few details together for the next update.

I recently picked up a Sega System 18 board with the encrypted version of Clutch Hitter. I've replaced the custom 68000 with a regular one from a partially dead System 24 board, and have tried running some unencrypted software - so far Shadow Dancer (J) works, so that will be my reference for writing test programs.

The ROM board has a lot of jumpers and looks very configurable. It currently supports four 27C020's for the program ROMs, does anyone know of any jumper settings that would allow 27C040's to work? The part number for the board seems to be '834-7917-01', if that helps.

At some point I intend to try getting my own code to run on the Hitachi CPU, but at the moment I'm more interested in figuring out how the System 18 specific hardware works. Just to check the obvious, I tried running encrypted software for a different game with the Clutch Hitter-specific CPU, and they are of course not compatible. :)

Also a small update about the Arcade Card emulation in tgemu, I have ordered a Arcade Card Pro and an ACD game, so I'll be able to run tests on the real thing and verify the emulation.

For Macintosh users, I'll point out that Richard Bannister has released a new version of TGEmu, with vastly improved sound emulation. You can download it from his website.

I've spent a few weeks fiddling with the Turbo's PSG in order to make these changes. I logged audio into my PC which I could then analyze, and used this to compare against audio logs generated by my own test programs. Some of the new things include:

• Noise emulation for channels 5 and 6.
• Fixed frequency range for regular waveform channels.
• Correct volume levels.
• Proper channel panning.

At this point the PSG emulation is mostly complete. I can't work on LFO emulation as no games I have use it, and the noise emulation isn't 100% accurate. However, I have devised a way to extract the pseudo-random noise data, and just need to write a program that will process the results and create a list of what random bits were produced.

I will probably release a new version of hesplay soon - I'm listening to the already completed version while typing this update. ;) And the new sound code will make it's way into the DOS and Windows versions of TGEmu too. I know the Mac users seem to get everything first, but I'll catch up eventually.

I ran a few more tests on my Shinobi board, and figured out some interesting things about the video hardware. Here are my findings, and I'll add them to the System 16 hardware notes later on:

If the horizontal scroll value for the foreground or background has bit 15 set, then the scroll value is ignored. Instead, row scroll mode is enabled for the entire layer, and a table at text RAM offset $F80 (foreground) or $FC0 (background) is used to store the row scroll values.

Row scroll is applied with no influence from the vertical scroll register, so the row scroll values are used for the first 28 rows of the display. The data for rows 29-32 will never be used since the display is only 224 lines tall. If a row scroll value in the table has bit 15 set, then the horizontal and vertical scroll values are ignored and a different name table from tile RAM is displayed for the row selected, with different scroll values. I'll refer to this as the 'alternate' layer.

Here is the updated map for text RAM:

 $000-DFF : Text layer name table (64x28)
 $E00-E7F : Unused
 $E80-E9F : Unused, except for the following addresses:
 $E80     : Foreground page select
 $E82     : Background page select
 $E84     : Foreground page select (alternate)
 $E86     : Background page select (alternate)
 $E88-E8E : Unused
 $E90     : Foreground vertical scroll / column scroll enable
 $E92     : Background vertical scroll / column scroll enable
 $E94     : Foreground vertical scroll (alternate)
 $E96     : Background vertical scroll (alternate)
 $E98     : Foreground horizontal scroll / row scroll enable
 $E9A     : Background horizontal scroll / row scroll enable
 $E9C     : Foreground horizontal scroll (alternate)
 $E9E     : Background horizontal scroll (alternate)
 $EA0-EFF : Unused
 $F00-F3F : Foreground column scroll table
 $F40-F7F : Background column scroll table
 $F80-FBF : Foreground row scroll table
 $FC0-FFF : Background row scroll table

I confirmed the foreground alternate layer registers, but haven't had the time to check the background ones. Also, as far as I know the alternate layers cannot use row or column based scrolling.

There were a few things about scrolling and placement of the name table sections that I wasn't clear about, so I tested these things as well. I found that if the page select register was loaded with $1234, then the display was laid out as follows:

 $4000 $3000
 $2000 $1000

Depending on how you want to treat wrap-around, it could have also been:

 $3000 $4000
 $1000 $2000

The default position of the display with both scroll registers set to zero is no offset vertically, and a 160 pixel offset horizontally. This places the 320x224 viewport over the upper right corner of page $4000 in the above two diagrams. Setting the horizontal scroll value to $00C0 moves the viewport to the start of that page. As far as I can tell setting up the scrolling like this gives me (apparently) perfect alignment between the sprites and background tilemaps in my emulator.

One problem I'm having with the scrolling stuff mentioned above is how it's applied to the System 18 games. I've noticed there are a lot of scrolling problems in Alien Storm where the wrong part of the display is being shown. Anyway, here are a few pictures from my System 16/18 emulator showing the Genesis VDP graphics layer in Alien Storm, minus a few things like sprite scaling and priorities:

The CRT test picture was a little tricky to get working. It turns out that the background layer draws transparent pixels as using color #0 of the selected palette, rather than allowing a backdrop color to show through. The foreground layer does handle color #0 as transparent to allow the background to be visible. In the System 18 hardware, if a background pixel that is color #0 references a zero-value entry in color RAM, then it is truly transparent and the Genesis VDP video layer can be seen underneath. The CRT test has a mix of color #0 pixels, some referencing non-zero color RAM data and other ones that do. In the picture, the upper color bars are the System 18 ones, (using 15-bit color) and the lower ones are the Genesis ones (using 9-bit color).

I recently modified a Sega Saturn "Stunner" lightgun to work with the SMS and Sega Genesis. Here are two test programs for the lightgun which contain some technical details.

• SMS Lightgun Test
• Genesis Lightgun Test

Today I tried adding Arcade Card support to TGEmu. Here's a few screenshots from Strider:

The game itself is unplayable due to some problems with the CD-ROM emulation, but the intro part works fine. In the interest of debugging my HuC6280 CPU emulator, I've made a few modifications so I can run NES software. This also allowed me to implement some things that the TurboGrafx-16 doesn't use, like the NMI feature. I don't really plan on doing much with NES emulation, I just want to see how the CPU support holds up.

A few weeks ago I had started some work on a Sega SC-3000H emulator based on all of the tests I have tried on my own SC-3000. It still needs a lot of work before I can release it, but I've already started on a few neat features like basic SF-7000 support and mostly full emulation of all the TMS9918 quirks and undocumented behavior.

Here are some updated and new items:

• sc3000h.txt Updated Sega SC-3000H hardware notes.
• smstech.txt Rewrote SMS/GG hardware notes.
• vrampack.zip Genesis VRAM compression utility for programmers.

I've released a utility for the TurboGrafx-16 that converts HuCard software into CD images which can then be written to a disc. It's mainly for simple programs and small demos, it won't work with commercial games. You can get the DOS binary and source code here.

I've also fixed a few files that only had a link from this page. So the Sega SC-3000H hardware notes document is finally available, again. ;)

Today I was successful in getting a TurboGrafx-16 CD test program to run. It's a modified version of a memory viewer that had some hacks added to relocate itself to $E000 after being loaded by the BIOS.

The following information that I figured out pertains to a US Super System Card Ver. 3.0. I don't recall which version of the Super System Card I disassembled to examine the EX_MEMOPEN routine, but I cannot dump my card to check. The locations $18C5, $18C6, and $18C7 in page $FF return the values $55, $AA, and $C0 respectively. The remaining locations all return $FF. The page mapping is set up like so:

    00-3F : Super System Card ROM
    40-67 : Unused ($FF)
    68-87 : Super System Card RAM (256K)
    88-F6 : Unused ($FF)
    F7    : BRAM
    F8-FB : Work RAM (mirrored at $F9,$FA,$FB)
    FC-FE : Unused ($FF)
    FF    : Hardware page
    

    if( *$18C5 == $55 && *$18C6 == $AA )
    {
        A = *$FFF4; /* Which is $68, the first page of SCD RAM */
        X = $03;    /* Not sure what this represents */
        Carry = 0;  /* Indicate no error */
        return;
    }
    else
    if( *$18C1 == $AA && *$18C2 == $55 )
    {
        A = *$FFF4;         /* Probably $68 in this case */
        X = *$18C3 | $80;   /* Hardware version? */
        Carry = 0           /* Indicate no error */
        return;
    }
    else
    {
        A = ??      /* Any value but not $AA for the 1st test or $55 for the 2nd test */
        X = $00;    /* ? */
        Carry = 1;  /* Error, not a Super System Card */
    }
    

For those of you interested in writing your own test programs, the HuC compiler can create ISO images for you. But if you like to program in assembly like me, all you have to do is take the first two sectors of any PC-Engine game and modify the header in the second one to load up your program. Then append the program to the end, and that's it. I tested the image file first in my PCE emulator just to make sure it would actually work, and then wrote it to a blank CD as a regular Mode 1 data track with 2048-byte sectors. The Turbo CD hardware is smart enough to read the first data track on the disc, not the first track in general. (All commercial games have a warning audio track with the data track typically as track 2. This isn't necessary, as I've shown).

Speaking of, does anyone know a thing or two about copying Turbo CD games? Some of my oldest discs (Y's and Dragon Slayer) are quite scratched but playable after all these years, and I'd like to make backups as they will stop working eventually. I've tried to read the discs with two different drives, an old Mitsubishi CD-ROM and a LG/Samsung CD-RW. Both report an error reading some of the last few sectors of tracks 1 and 2, but will read the rest of the disc fine. I don't know how to get around this, does anyone have some suggestions?

I've been quite busy taking care of some computer problems, after I bought a new computer to replace (or rather work alongside) my old one. But now that things are working out, I've had some time to use the SDL library along with MSVC, and tried porting SMS Plus to the SDL/Windows environment. Even though there's already a great SDL port by Cyx, I may release my version just for fun. It's based on the original SMS Plus source code from the last public release, and doesn't have any special features or sound support, beyond a full-screen option. I may try porting my Genesis emulator and tgemu as well, time allowing. :)

I've updated my SMS VDP documentation with more details about how the Game Gear video hardware works.

• msvdp.txt

A hint at the final encounter	This one can fend for itself

I recently decided to take a shot at enabling some of the disabled menu items in Light Crusader for the Genesis, and discovered a few interesting things left in by the developers. Apart from the 'extra' dungeon floor shown above in the right image, there are a lot of options such as a sound test, message and graphics viewer, language select, mouse control support, and an ability to warp between save points.

My new CPU emulator for tgemu is coming along quite nicely. Except for possibly one bug which breaks a few games, it now runs most all of the same software that early versions of tgemu based on the MAME core do. The overall performance is about 10% slower, but I've got plenty of ideas about how to speed things up. A few games which I thought had problems due to CPU issues are misbehaving because of a bug in the VDC emulation. When I can track this problem down, it will fix a number of games that have bad or missing graphics, but otherwise work fine. I can't really say when the next version of tgemu will be finished since there's still a lot of work to do, but I will most likely release the CPU emulation as a stand-alone library and also update hesplay with the improved PSG emulation (from the Mac port of tgemu) and the new CPU core if it fixes any of the existing music rips that didn't play right.

To follow up on the information below, I ran a few more tests and found that all instructions that modify the I flag, except RTI, cause interrupt processing based on the new state of the I flag to be delayed by one instruction. When RTI pops P off the stack, the new value of the I flag is immediately taken into effect, so there is no delay. BRK cannot be interrupted and has no special behavior related to interrupts, either.

I've made a lot of progress with tgemu, I wrote my own HuC6280 CPU emulator from scratch, and it's actually working minus interrupt support (my test programs run, and games at least initialize themseleves before waiting for the frame interrupt). The code is generated by an emitter program that uses several tables to describe the instructions, addressing modes, timing, and so forth. This also allows different levels of accuracy and certain speed hacks to be enabled as needed. The output is in plain "C", so there are no portability issues.

I'm also thinking it shouldn't be that hard to have the emitter make an assembly optimized version that would have some of the more computation intensive instructions (like ADC, SBC, etc.) replaced with 80x86 assembly code which can do this kind of thing much faster. Right now I'm concentrating on accuracy over speed, so the code isn't optimal.

Over the last two days I've been running a lot of tests on my Turbo to get an idea of how interrupt processing works. I've uncovered some interesting stuff, which I will discuss here as it may apply to the 6502 and 65C02 (plus other variants) as well.

The CPU seems to delay interrupt processing depending on the state of the I flag. There are four instructions that can modify it, which are SEI, CLI, PLP, and RTI. If interrupts are pending and the I flag is set, clearing it causes the interrupts to occur after the instruction that modified P. For example:

    ; interrupts are pending
    cly
    cli
    iny
    sei
    

    ; interrupts are pending
    cly
    cli
    sei
    iny
    

The delay only occurs when changing the state of the I flag from 1 to 0 or 0 to 1. A series of CLI or SEI instructions would not delay interrupt processing. I don't know the exact reason for this, it could be that the CPU examines I before executing an instruction, executes the instruction, and then processes interrupts based on what it saw I set to, even though the instruction itself may have modified the current working copy of I.

I've also found that interrupts are processed all at once when they are enabled. For example:

    ; Timer, IRQ1, and IRQ2 interrupts are pending
    cli
    nop
    sei
    

As for priority levels, the order for the TurboGrafx-16 is as follows:

    Highest                             Lowest
    RESET > NMI > [BRK?] > TIMER > IRQ1 > IRQ2
    

From what I've read BRK comes before the timer in terms of priority. However, in my tests where I had multiple interrupts pending, they always occured before BRK did. The original 6502 had a bug where BRK could be interrupted by a NMI, and the NMI vector would be fetched instead of the BRK vector. This was fixed in the 65C02, and all instructions on the HuC6280 are uninterruptable. (including the block transfer ones) So I believe BRK is treated the same way as any other instruction in terms of when pending interrupts are serviced.

I will add all of this information to my TurboGrafx-16 hardware notes, in due time. Also, here's a page that has pictures of some console related projects I've worked on:

• Projects

Cyx has informed me that SMS Plus has been adapted to use the SDL library, allowing it to run on other platforms supported by SDL. His work is available here:

• http://cyxdown.multimania.com/smssdl/

I've also been working on a big update to SMS Plus, which I'll give some details about later on. :)

I've updated the TurboGrafx-16/PC-Engine information page with new versions of the following:

• PC-Engine Hardware Notes
• HuC6280 Instruction Set documentation

I had recently noticed an interesting transparency effect used in the PC-Engine game "Jackie Chan's Action Kung-Fu". After some investigating I figured out how the trick was done, and decided to try it on the Genesis. Here's a screenshot from the demo program:

The transparency isn't created using shadow/hilight mode, instead the sprite and background priorities are set up to force the background (the dark colored columns) over the sprites (the light colored columns) whenever the "SEGA" logo sprites are between the two. I've seen this effect used in other games to cut out sections of sprites, but never to intentionally force graphics to replace other sprites.

• mdtrans.zip

I've released a new version of my Sega System 16 Hardware Notes, this time with a lot of information about sprite rendering and how the sprites work in general.

I had been working on ADPCM hardware emulation in tgemu and fixed a very weird but unique bug in Monster Lair. During startup, the game uses the AD_TRANS function to copy sprite graphics from the CD-ROM into ADPCM memory, and then during gameplay the ADPCM read pointer is set to different address to read out the sprite patterns, and store them into VRAM. So this fixes the missing sprite graphics for the player character:

I noticed the version of the PC-Engine notes that are available are quite old, it must have been overwritten with an earlier copy the last time I updated. It's my intention to go back to the PC-Engine stuff once I'm mostly done with the System 16 testing, so I'll be able to clean up the "in progress" version of the notes and get that uploaded. (I don't have a copy of the previous document at the moment) Sorry for any inconvenience..

I've made another update to my Sega System 16 Hardware Notes, this time with a pinout for the wire harness, input port mapping, and other goodies like screen flip and lamp control information added.

News (12/29)

I made an interesting discovery today about how the sprite bank works in the System 16 hardware. The original System 16 emulator uses the lower four bits of sprite attribute byte 9 as an offset into a 16-entry table. The table holds the high bits of an address into the sprite ROMs. However, the table changes between most games rather than being static, so each GCS file has a different layout for it. This had always seemed a little unusual to me, as the sprite hardware appears to be identical between most all games. (with exceptions for bootleg and System 16A games)

I was examining the values of byte 9 in Shinobi, and noticed only four values were used, $F7, $FE, $FB and $FD. If you look at these in binary, they each control the state of one bit:

        FE = 1111 1110        
        FD = 1111 1101        
        FB = 1111 1011        
        F7 = 1111 0111        

I had seen something quite similar to this while working on BIOS support in SMS Plus, one of the hardware registers enables different slots (e.g. cartridge, card, expansion port, built-in BIOS, etc.) and these bits are all set to '1' with the enabled slot set to zero.

Shinobi happens to have four sprite banks (a pair of ROMs for each bank), and it occured to me that the above bank values didn't select a table entry, but rather enabled each bank. I tried modifying my emulator to handle banking like this, and Shinobi worked just fine. This also worked for Alien Syndrome. It would appear that these four bits therefore work as bank enable switches.

There are two other interesting things which I feel validate this point; if the lower four bits of the bank are set to $F (no sprite banks selected) then no graphics are shown at any address. The sprite generator will remember the last word present on it's data bus if you enable and then disable a sprite bank and it displays that single pixel across the entire display and at the specified sprite height. (the end markers aren't present so it doesn't know when to stop drawing, the sprite width is not taken into account)

The other thing is that if you enable two or more banks simulataneously, the sprite data from the enabled banks is combined together. I tried displaying the Sega logo and then enabling other banks, and out of the sprite you could clearly see four pixel wide areas that were from the Sega sprite data, and then every other 4-pixel chunk was garbage from the other banks. If byte 9 only supplied the upper bits of an address into the sprite ROM, the combining of data from two different banks would not occur.

Of course this doesn't solve everything, I couldn't figure out how this works for games with sprite ROMs large than 64K. But at least this gives a little more insight into how the sprite data is accessed. I'm going to add this information to my System 16 hardware notes later, in the meantime I made a minor update with some information about sprite positioning.

Old News (12/29)

I've decided to release my Sega System 16B hardware notes, which you can get here:

• s16tech.txt