Eckhard Stolberg

The ASM source code for the Stella version of the SC BIOS and a tool to convert the binary to the array you mentioned is in the /src/emucore/misc/ folder. scrom.asm is written for the DASM assembler.

When the SC returns from the BIOS, the accumulator contains a random value (a fast running loading counter). I suppose Dragonstomper uses this value to initialize it's random number generator. In the Stella version of the SC BIOS the accumulator contains the bankswitching value EORed with the high and low byte of the startup address for the new load instead. This value is always the same for any given load. You could have the loading routine patch a random value into an address of the SC BIOS ROM and do an LDA from this address before returning from the BIOS in order to fix this problem.

Wicked, I didn't know that, or I am getting so old that I forgot. Thanks. Considering that I mentioned it in your own for sale thread when the question came up only a month ago, it really seems that the hot Californian sun isn't keeping your brain as fresh as our cool Hamburg rain did.

Collisions can only happen when the moving objects are processed. This doesn't happen during HBLANK, so no collisions here. However, the HMOVE puslses are transmitted over the same lines that handle the pulses to process a pixel during the visible part of the screen. So, if you position two moveable objects over the horizontal border and then trigger an HMOVE, their pixels would get processed and therefore you need to check for collisions here. IIRC Pole Position and Fatal Run are affectec by this, as both sides of the curbs might collide in the HMOVE.

Some tapes have more than one load per side. The additional loads still need to be converted. The WAV files that shadow460 posted wouldn't convert with the current version of Makebin, and unfortunately I didn't have time to work on the Makebin code yet.

Yes they do. When I fixed the binaries to work on an EPROM cart, I also included a PAL/NTSC test that adds a couple of scanlines at the top and bottom on PAL consoles to generate a stable and centered display. Of course the games will run a little slower on PAL. But considering how difficult Sirius is that isn't nessessarily a bad thing. The colours weren't changed either. But for abstract space shooters that shouldn't be much of a problem. Except for a slight green touch the PAL palette is the same as the NTSC palette anyway.

16 bit mono at 44.1 kHz is the format that Makebin works with best. It's even recommended in the readme file. In the binary the area from 200h-2007h contains the tape header. The byte at 2003h tells you how many data pages there are. The data pages get stored consecutively from the start of the binary no matter where in the SC RAM the pages would get loaded to. So for a game that has the possible maximum of 24 pages the area from 0000h-17FFh would be used. Also there is one byte per page at 2010h-2027h that tells you where the page will get loaded to. The format also is supposed to have a checksum byte for each page at 2040h-2057h, but Makebin doesn't write them, because Makewav will calculate the checksums itself anyway when converting the binary to audio. Everything else is unused and should be cleared to zero.

You can easily find out if the files are identical yourself. On the DOS/Windows command line prompt type: fc /b filename_side_a.bin filename_side_b.bin and it should either list all the different bytes or tell you that there were no differences found. As for the Communist Mutants filenames, you guessed right. 'l' means left channel and 'r' means right channel. Makebin currently only works with mono signals, and since the tape didn't convert without errors, I modified Makebin to try both channels. Unfortunately that didn't correct all errors. Supercharger tapes have the data stored in pages of 256 bytes, each with a leading checksum. Makebin calculates the checksums for all the pages and gives an error message when the calculated checksum doesn't match the read checksum. That's what the "bad" label means. It's the number of pages with a bad checksum in the file. Mitch seems to have combined both channels into a mono signal before trying to convert the games with Makebin. This made Communist Mutants convert without errors. Now we can see that it is identical to the release version, so it's probably no big loss that the A side of this tape is in such a bad shape. As Mitch already mentioned, Makebin doesn't initialize it's buffers before it converts the audio data. As a result there is lots of garbage in the unused parts of the resulting binary. You might want to clean up in your binaries, Mitch, or ROM Hunter might treat them like different version and keep them in his collection out of principle. Also I've only converted the first load of all the tapes so far. We still need to do the second loads to which shadow460 just posted new WAV files.

Does the Gameline work on a 7800? If so and there still are a couple of weeks before you need to send your module to Leipzig, you could send it to me first and I could try to dump the ROM for you. I'm not sure there are that many screens build into the gameline though. Most things probably had to be loaded from the Gameline server.

Since it hasn't been mentioned yet: the program you need to convert the tapes to binaries is Bob Colbert's Makebin. It's a simple command line tool that takes WAV files with 44kHz 16bit mono. For more information look at the makebin.txt file in the ZIP archives on Bob's site.

Thanks for the info on MESS testing. I can't get my version of MESS set up correctly. Any hints on what an 7800.u7 file is? I've no idea why it squeals on MESS because sounds aren't played until you've started the game after the title screen. I've used ProSystem v1.3 (without the 'd') during the development of the game and it works fine in that. I'll download the latest 'd' version and try that this afternoon. I ran your game in the MESS debugger and found the problem. It's at the start of your first initializing subroutine where you are trying to lock the 7800 into MARIA/ROM mode. You seem to have gotten the equate for INPTCTRL wrong, because instead of writing the #$07 to address $01 you are writing it to address $2f, which is colour register P3C3. As a result the 7800 doesn't get locked into a mode, so that writing something to one of the sound registers later on probably disables the ROM, which makes the game crash in MESS and on a real 7800. After patching the $2f to $01 and re-signing the ROM with a78sign, it plays fine in MESS.

If the games are playing, but you don't get any tape audio, then z26 isn't finding the WAV files. z26 is expecting the WAV files to be in the current working directory. If you are starting z26 from the x26 front end, then the x26 directory probably is the current working directory. You could try putting the KidVid WAV files there. Or you could put them into your binary directory and start z26 from the command line there. BTW, you shouldn't have to specify the controller for the KidVid games. z26 should be able to autodetect it.

That's not a different ROM. It's a different cartridge reader, that still needs a little work on the bankswitching. The 6 different bytes in the first bank were accidentally read from the last bank. You are probably triggering the bankswitching hotspot at $fff8 to switch to the first bank and then read the entire 4K. But doing it that way means that you'll trigger the hotspot at $fff9 before the last 6 bytes in the bank are read. As a result the cartridge gets switched to the last bank, and the 6 bytes are read from there. To read bankswitched games successfully you could either skip the bankwitching hotspots when reading the data, or trigger the corresponding hotspot before reading each byte from a certain bank.

There are 76 cycles in every scanline, so the sample rate I used already is a factor of the 2600 clock speed. The advantage of using a sample rate like this is that exact timing in the 6507 code can be done with STA WSYNCs. When I worked on this demo, I still used a 486 with a simple DOS-based sampling program. The program didn't support any complicated pre-processing of the sample data. You could probably get much clearer results with modern sampling programs. I only had a Supercharger for testing the binaries, and 2600 emulators didn't support sample playback back then either, so I didn't do any other demos. If you have a way to test binaries with larger bankswitching schemes, you could easily use 7860 or 15720 Hz.

I did a program like that to convert the data for my "Stella says" experiments. I posted it together with the sound demo to the Stella mailing list. You can find it in the Stella list archives. It's pretty simple though, and I was using Bruce Tomlin's assembler instead of DASM back then, so it might be better to write your own tool in Perl anyway.

I'm not sure yet. At first I thought the TTL-232R-5V-WE cable would be best, because you only need to solder a DB9f connector to it in oder to get a working cable for the DevOS system. But I'm not sure there are DB9 connectors that would fit nicely into the 7800 controller ports. So maybe the TTL-232R-5V-PCB might be a better option, as you could solder an old Atari joystick cable with the proper plug to it?

I didn't do any programming last weekend, because I got a bit side-tracked. Since you seem to be looking for a USB version, I was looking into the possibilities of building one. After some searching I found out that FTDI offers a serial-to-USB cable that works at TTL levels. It would be ideal for this purpose, since it would make building the serial cable as easy as building the old parallel cable was. But ordering a single cable from FTDI directly would be quite expensive due to the high costs for shipping and money transfer. Therefore I wasted the rest of the weeking trying to find a cheaper source. Unfortunately I haven't really found one yet.

There already is a frontend for DOS and one for Windows. I'm not sure how well they'd work on non-ancient versions of Windows though.

OK, I'll try and see how far I can get over the weekend. But a proper release might take a little longer. The problem is that the PAL and NTSC 7800 run at slightly different speeds. It's a bit tricky to get the timing right for both consoles at hight serial transfer speeds. Also some bankswitching formats need to be read with code running in RIOT RAM at 2600 speed, so you need a really compact version of the transfer code too. And the 7800 menu code is an ugly mess. I'll better clean that up too, if I'm working on it anyway.

Here is a screenshot of the Cuttle Cart loading screen. The only other visual thing there is to this program are the Supercharger-style progress bars. But I suppose you don't need screenshots of those. I don't think Chad Schell wants the binary to be distributed, but you'd have to ask him yourself to find out for certain.

I started working on a serial version of DevOS a while ago. I've build a serial cable and got some basic transfer code working. I was planning to buy a new computer myself and thought it would be a good idea to be prepared for the case that it doesn't come with a parallel port anymore. But since I haven't found a computer I really like yet, I never included the new transfer code into DevOS. But if there is a demand, I could try to finish the modification. Ciao, Eckhard Stolberg

NTSC, no. I think there might be a Decathlon that was converted by HES. The player does see a visible difference on some 7800's with Robot Tank, Decathlon, and Space Shuttle. Effects may vary. There is a converted PAL version of Decathlon by HES, but it uses F6 bankswitching as the game had to be expanded to 16K. Ciao, Eckhard Stolberg

That's correct. Both alternate version for those games are bad dumps. Ciao, Eckhard Stolberg

You could try a little more patience, because a proper analysis might take a while. Most of the ROMs differ only in the unused bytes. The data found in those bytes sometimes even contains Windows code. I think we can assume an uninitialized ROM buffer in the tape conversion program and therefore consider these ROMs to be bad dumps. For all games exept Killer Satellites you already found the good dump. There are two ROMs that have some small changes in the game data too. Swords of Saros mostly differs in the unused bytes but also has one bit in the game code different. The normal ROM has the corect checksum for that part of the ROM, while the [a] version doesn't have checksums at all. Therefore I think we should consider the [a] version a bad dump. "Escape from the Mindmaster part 4 of 4" only differs in some bytes in the used part of the ROM. I haven't checked what that data table is used for in the game, but the normal ROM has all correct checksums, while the checksum for that part of the ROM doesn't match in the [a] binary. So it's most likely a bad dump too. So, For Killer Satellites you should keep the [a] version while for all other games you should remove the [a] ROMs. Ciao, Eckhard Stolberg

Interesting. Thanks. Ok, I checked all the Arcadia / Starpath ROMs and renamed some of them. None removed, though. The differences in the Killer Satellites binaries are probably due to the buffer in the tape conversion program not being initialized to zero either. Starpath games can have a maximum of 6K per load, so all the data above 0x1800 never gets sent to the Supercharger. The header data above 0x2000 contains information like what address to load each 256 bytes page to and where to start execution of the code. Only 56 of the 256 bytes in the header are actually used. There is no reason why there should be anything but zero stored in the 200 unused bytes of the header in the binary. The 'full' version of Killer Satellites not only has all this garbage data in the header, it also has incorrect values for the checksum bytes for all 24 pages of game code at 0x2040. Therefore I would say that the preview version is actually a good dump and the other version could be deleted. And if the other questionable Starpath ROMs also only differ in the data above 0x1800, then you can delete the ones that don't contain mostly zeros there as well. Ciao, Eckhard Stolberg