Eckhard Stolberg

Unfortunately, you would also need the tapes that (presumably) would have come with the games. Would a special CV version of the KidVid really be nessessary? The KidVid player is pretty much just a normal tape player that connects it's headphone and microphone connector to the 2600 joystick port with a simple cable. Also the tapes don't have any 2600 specific code on them. The data track has a small code at the start so the game can detect which of the three tapes is currently playing. After that there are only codes to signal when a song has finished, so that the 2600 can pause the tape player through the microphone connector while the next game sequence is played. I'm not sure if you could use the 2600 KidVid player directly on the CV, because there are some small differences in the pin usage on the joystick port. But I don't think it would take more that a different connector cable to use the 2600 KidVid player with the CV KidVid games. Maybe one of the CV programmers here could have a look at the code of the two prototypes to find out which pins on the joystick port are read and which are used for output. That might give us an idea how the CV KidVid cable would need to be connected. Ciao, Eckhard Stolberg

You can pause z26 by pressing the backspace key (press the enter key to resume). But for your purpose it might be better to slow the emulator down a bit. The command line option -r1 would make z26 run at one frame per second. The problem seems to be with the pattern of the Cosmic Ark starfield effect. More specificly it's a problem with which scanlines get the double width pixels. We probably don't handle that properly in z26. I'm not sure how accurate Stella is with this. On a real VCS the line with the double width pixels is always the one where the pixel would be displayed right before a new playfield block would start, IIRC. This is independent from where or how you trigger the starfield effect. I think the emulators might start the pattern always in the same way when you trigger the starfield effect, so the lines with the double width pixels might shift when you start the effect in a different scanline or the missile is in a different starting position. Ciao, Eckhard Stolberg

It depends on your TV too. For example I have tried a multi-standard TV with NTSC support, and that one will only show strange colours in the top third of the picture, when I play one of the problematical NTSC games on a PAL VCS. The NTSC games that lose their colours when played on a PAL VCS and TV are the ones that display an odd number of scanlines. You could test that with an emulator. One of those games would be Combat. Also some of the badly hacked games on Atari's PAL 32-in-1 cartridge have this problem. IIRC the 32-in-1 version of Activision's Boxing will go B & W sometimes, while it does display colours in other situations. Ciao, Eckhard Stolberg

If by obscure you mean UA Ltd. bankswitching, then the CC1 doesn't support it. But before people get even more angry about the ROM altering issue: does Gamma Attack use any bankswitching at all? It's the only game from a small company and was created before the crash. So it's more than likely that the game is only 4K big, which means that there wouldn't be any bankswitching code to change anyway. Ciao, Eckhard Stolberg

The model number on the SECAM VCS should be CX-2600 S or CX-2600 AS. Also there should be a French language sticker at the bottom of the console that states that the VCS complies with French electronics regulations. The most notable difference between the SECAM and the PAL VCS probably is the absense of the "channel 2-3" switch on the SECAM console. There is a little bit of plasic covering the hole where the switch should be. Also the power supply is 650 mA on the SECAM VCS, whereas the PAL VCS usually comes with a 500 mA model. Most modern TVs in Europe should be able to display SECAM signals, BTW. Maybe your TV can be switched to SECAM mode too. Then you could test if your VCS displays a colour picture in that mode. Ciao, Eckhard Stolberg

IIRC the Compumate manual has instructions for building a cassette interface. You might be thinking of the Magicard. It's manual has instruction for building a casette interface. The Compumate has two normal audio ports on the side. IIRC it even came with the nessessary cable to connect it to a tape player. I don't think this tape contains any real programs. The BASIC interpreter of the Compumate is very limited. But the Compumate also has editors for melodies and graphics. I think the graphics were 40x25 pixels and monochrome. IIRC the memory would hold six pictures at a time, and you could display them in a slide show while a melody was playing. These slide shows could be saved to tape. At the fastest playing speed the slide shows would almost turn into short animations. The instructions which are shown in the eBay auction seem to require the user to set the Compumate into graphics mode before loading from the tape, so I suppose this PictureMate tape only contains a small slide show of very low-res animal pictures. I guess that explains why it is so rare. Ciao, Eckhard Stolberg

I have an NTSC Compumate...I'll see what I can do. Dumping this ROM is a bit difficult. The Compumate does it's bankswitching through the controller port, but the cables are too short to fit into the 7800 cartridge reader. When I dumped the PAL ROM, I had to plug the Compumate controller port cables into an extra 2600 with a Supercharger which would run a little program to set a specific bank on the Compumate. That allowed me to read the four banks seperately on the 7800. Ciao, Eckhard Stolberg

This is not a direct conversion of John's code. It's something I wrote myself when I converted the z26 bankswitching code to C. It works with John's test programs, so I hope it handles 4A50 bankswitching correctly. RBank4A50() and WBank4A50() are the read and write handlers that get called at every read and write access of the 6507. ReadHardware() and WriteHardware() are are the functions that handle the TIA and RIOT accesses. The rest should be self-explanatory. It's not as elegant as John's code and is terribly formated, but I hope it helps anyway. dd Bank4A50Low = 0; /* index pointer for $1000-$17ff slice */ dd ROMorRAMLow = 0; /* 0 = ROM -- 1 = RAM at $1000-$17ff */ dd Bank4A50Middle = 0; /* index pointer for $1800-$1dff slice */ dd ROMorRAMMiddle = 0; /* 0 = ROM -- 1 = RAM at $1800-$1dff */ dd Bank4A50High = 0; /* index pointer for $1e00-$1eff slice */ dd ROMorRAMHigh = 0; /* 0 = ROM -- 1 = RAM at $1e00-$1eFF */ db LastDataBus4A50 = 0xff; /* state of DataBus on last cycle */ dd LastAddressBus4A50 = 0xffff; /* state of AddressBus on last cycle */ void RBank4A50(void) { if(!(AddressBus & 0x1000)){ ReadHardware(); if(((LastDataBus4A50 & 0xe0) == 0x60) && ((LastAddressBus4A50 >= 0x1000) || (LastAddressBus4A50 < 0x200))){ if((AddressBus & 0x0f00) == 0x0c00){ ROMorRAMHigh = 0; Bank4A50High = (AddressBus & 0xff) << 8; }else if((AddressBus & 0x0f00) == 0x0d00){ ROMorRAMHigh = 1; Bank4A50High = (AddressBus & 0x7f) << 8; }else if((AddressBus & 0x0f40) == 0x0e00){ ROMorRAMLow = 0; Bank4A50Low = (AddressBus & 0x1f) << 11; }else if((AddressBus & 0x0f40) == 0x0e40){ ROMorRAMLow = 1; Bank4A50Low = (AddressBus & 0xf) << 11; }else if((AddressBus & 0x0f40) == 0x0f00){ ROMorRAMMiddle = 0; Bank4A50Middle = (AddressBus & 0x1f) << 11; }else if((AddressBus & 0x0f50) == 0x0f40){ ROMorRAMMiddle = 1; Bank4A50Middle = (AddressBus & 0xf) << 11; }else if((AddressBus & 0x0f00) == 0x0400){ Bank4A50Low = Bank4A50Low ^ 0x800; }else if((AddressBus & 0x0f00) == 0x0500){ Bank4A50Low = Bank4A50Low ^ 0x1000; }else if((AddressBus & 0x0f00) == 0x0800){ Bank4A50Middle = Bank4A50Middle ^ 0x800; }else if((AddressBus & 0x0f00) == 0x0900){ Bank4A50Middle = Bank4A50Middle ^ 0x1000; } } if((AddressBus & 0xf75) == 0x74){ ROMorRAMHigh = 0; Bank4A50High = DataBus << 8; }else if((AddressBus & 0xf75) == 0x75){ ROMorRAMHigh = 1; Bank4A50High = (DataBus & 0x7f) << 8; }else if((AddressBus & 0xf7c) == 0x78){ if((DataBus & 0xf0) == 0){ ROMorRAMLow = 0; Bank4A50Low = (DataBus & 0xf) << 11; }else if((DataBus & 0xf0) == 0x40){ ROMorRAMLow = 1; Bank4A50Low = (DataBus & 0xf) << 11; }else if((DataBus & 0xf0) == 0x90){ ROMorRAMMiddle = 0; Bank4A50Middle = ((DataBus & 0xf) | 0x10) << 11; }else if((DataBus & 0xf0) == 0xc0){ ROMorRAMMiddle = 1; Bank4A50Middle = (DataBus & 0xf) << 11; } } }else{ if((AddressBus & 0x1800) == 0x1000){ if(ROMorRAMLow) DataBus = Ram[(AddressBus & 0x7ff) + Bank4A50Low]; else DataBus = CartRom[(AddressBus & 0x7ff) + Bank4A50Low]; }else if(((AddressBus & 0x1fff) >= 0x1800) && ((AddressBus & 0x1fff) <= 0x1dff)){ if(ROMorRAMMiddle) DataBus = Ram[(AddressBus & 0x7ff) + Bank4A50Middle]; else DataBus = CartRom[(AddressBus & 0x7ff) + Bank4A50Middle]; }else if((AddressBus & 0x1f00) == 0x1e00){ if(ROMorRAMHigh) DataBus = Ram[(AddressBus & 0xff) + Bank4A50High]; else DataBus = CartRom[(AddressBus & 0xff) + Bank4A50High]; }else if((AddressBus & 0x1f00) == 0x1f00){ DataBus = CartRom[(AddressBus & 0xff) + 0xff00]; if(((LastDataBus4A50 & 0xe0) == 0x60) && ((LastAddressBus4A50 >= 0x1000) || (LastAddressBus4A50 < 0x200))) Bank4A50High = (Bank4A50High & 0xf0ff) | ((AddressBus & 0x8) << | ((AddressBus & 0x70) << 4); } } LastDataBus4A50 = DataBus; LastAddressBus4A50 = AddressBus & 0x1fff; } void WBank4A50(void) { if(!(AddressBus & 0x1000)){ WriteHardware(); if(((LastDataBus4A50 & 0xe0) == 0x60) && ((LastAddressBus4A50 >= 0x1000) || (LastAddressBus4A50 < 0x200))){ if((AddressBus & 0x0f00) == 0x0c00){ ROMorRAMHigh = 0; Bank4A50High = (AddressBus & 0xff) << 8; }else if((AddressBus & 0x0f00) == 0x0d00){ ROMorRAMHigh = 1; Bank4A50High = (AddressBus & 0x7f) << 8; }else if((AddressBus & 0x0f40) == 0x0e00){ ROMorRAMLow = 0; Bank4A50Low = (AddressBus & 0x1f) << 11; }else if((AddressBus & 0x0f40) == 0x0e40){ ROMorRAMLow = 1; Bank4A50Low = (AddressBus & 0xf) << 11; }else if((AddressBus & 0x0f40) == 0x0f00){ ROMorRAMMiddle = 0; Bank4A50Middle = (AddressBus & 0x1f) << 11; }else if((AddressBus & 0x0f50) == 0x0f40){ ROMorRAMMiddle = 1; Bank4A50Middle = (AddressBus & 0xf) << 11; }else if((AddressBus & 0x0f00) == 0x0400){ Bank4A50Low = Bank4A50Low ^ 0x800; }else if((AddressBus & 0x0f00) == 0x0500){ Bank4A50Low = Bank4A50Low ^ 0x1000; }else if((AddressBus & 0x0f00) == 0x0800){ Bank4A50Middle = Bank4A50Middle ^ 0x800; }else if((AddressBus & 0x0f00) == 0x0900){ Bank4A50Middle = Bank4A50Middle ^ 0x1000; } } if((AddressBus & 0xf75) == 0x74){ ROMorRAMHigh = 0; Bank4A50High = DataBus << 8; }else if((AddressBus & 0xf75) == 0x75){ ROMorRAMHigh = 1; Bank4A50High = (DataBus & 0x7f) << 8; }else if((AddressBus & 0xf7c) == 0x78){ if((DataBus & 0xf0) == 0){ ROMorRAMLow = 0; Bank4A50Low = (DataBus & 0xf) << 11; }else if((DataBus & 0xf0) == 0x40){ ROMorRAMLow = 1; Bank4A50Low = (DataBus & 0xf) << 11; }else if((DataBus & 0xf0) == 0x90){ ROMorRAMMiddle = 0; Bank4A50Middle = ((DataBus & 0xf) | 0x10) << 11; }else if((DataBus & 0xf0) == 0xc0){ ROMorRAMMiddle = 1; Bank4A50Middle = (DataBus & 0xf) << 11; } } }else{ if((AddressBus & 0x1800) == 0x1000){ if(ROMorRAMLow) Ram[(AddressBus & 0x7ff) + Bank4A50Low] = DataBus; }else if(((AddressBus & 0x1fff) >= 0x1800) && ((AddressBus & 0x1fff) <= 0x1dff)){ if(ROMorRAMMiddle) Ram[(AddressBus & 0x7ff) + Bank4A50Middle] = DataBus; }else if((AddressBus & 0x1f00) == 0x1e00){ if(ROMorRAMHigh) Ram[(AddressBus & 0xff) + Bank4A50High] = DataBus; }else if((AddressBus & 0x1f00) == 0x1f00){ if(((LastDataBus4A50 & 0xe0) == 0x60) && ((LastAddressBus4A50 >= 0x1000) || (LastAddressBus4A50 < 0x200))) Bank4A50High = (Bank4A50High & 0xf0ff) | ((AddressBus & 0x8) << | ((AddressBus & 0x70) << 4); } } LastDataBus4A50 = DataBus; LastAddressBus4A50 = AddressBus & 0x1fff; } Ciao, Eckhard Stolberg

OK, I asked him and got permission to post the binary. So, here is the version that still does the high pitched sounds. vidlife.bin Ciao, Eckhard Stolberg

You are correct. The three Video Life binaries in Rom Hunter's collection are all the same. The game only has 2K of ROM. But it also has 1K of RAM in the first half of the VCS's 4K game address space. So, if you dump Video Life as a 4K binary, you are getting 1K of random garbage in the file. Since this all that is different between the three files, I think the two 4K versions could be removed. I compared the binary Rom Hunter posted to another one that a friend dumped for me 8 years ago. Back then he made me promise not to release the binary to the public. He probably doesn't care too much anymore now that another Video Life binary is available. But since I promised, I can't post the binary here. My binary is only missing a two-byte instruction which limits the possible frequencies for the random sounds. After having another look at the binary I'm not sure anymore which one came first. The two bytes that the instruction uses are the only free bytes in my binary. So it might be either possible that the intruction was later taken out to give more variety to the sounds, or it might be possible that the programmer decided to use the last two free bytes to do something about the annoying high frequencies. Ciao, Eckhard Stolberg

This binary originally came from the Digital Press collection. You could ask over there where they got it from, but I suppose it's an unmodified dump of the original game. Compared with the other Video Life binary this one has a single instruction added which limits the random sounds that the game makes at each iteration to only lower frequencies. I guess CommaVid released the other binary first and then got complains from customers about the annoying high pitched tones. So they fixed it for the later carts. Ciao, Eckhard Stolberg

Z26 already has auto-detection, but it must not be as extensive as Stella's. Maybe we ought to see if we can figure out the formats that Z26 has trouble auto-detecting, and get a list together? Then maybe someone could try to update it? And if it's possible, maybe someone could even add any newer bankswitching methods that Z26 doesn't emulate yet? z26 doesn't auto-detect the bankswitching types. We only have a default bankswitching type for all given ROM image sizes. Games that use a different format than the default for their ROM size need to be detected on a ROM by ROM basis. If someone was so kind to send me all the ROMs released in the last 4 years which need to be detected for their bankswitching type or their controller, I could easily add their checksums to z26 and make a new official release. I haven't looked too closely at the bankswitching detection routine in Stella, but I suppose it would be pretty easy to adapt it for z26, if there was some demand to do so. As for new bankswitching formats: We have the same problem as Stella. Most new formats would be easy to add, but we'd need a ROM image to test the new bankswitching routine with. So, if you have written a game with a new bankswitching format which you'd like to see supported in z26, all you have to do is to send me a copy of the ROM image for the game. And I'm sure Stephen would like a copy too, so he could update Stella as well. Ciao, Eckhard Stolberg

There isn't really an auto detection for bankswitching types in z26. We calculate a checksum over the ROM image which we then use to identify the games that need special settings for the bankswitching or the controller. So unless we release a new z26 executable with updated checksums you'll have to start z26 from the command line prompt and force the bankswitching setting manually. (z26 -g5 Activision_Decathlon__The__NTSC__white.BIN for the new Decathlon binary). Stella used to use a similar aproach in older versions, but for the current version Stephen added a routine that scans the ROM image for small code pieces that are usually used to trigger a bankswitch. This seems to work astonishingly well. Ciao, Eckhard Stolberg

During the logo screen the NTSC 7800 among other things tests the signature key in the cartridge ROM. Since none of the PAL 7800 games have a valid signature key, the test fails and the BIOS locks the console in 2600 mode. Depending on what TIA registers the bit of 7800 game code accesses that gets executed in 2600 mode, you might get a black screen or some TIA garbage. So what you are experiencing with your PAL games is normal. But if you are really testing homebrew games, you could just sign the ROM image, and the game should start on your console. But since a PAL game is setting up a display for 312 scanlines while the NTSC 7800 is only processing 262 of them, the game might not work properly as Mitch explained above. Ciao, Eckhard Stolberg

Actually what I said was that the PAL re-release of Decathlon by HES was changed to use F6 bankswitching. The original Activision PAL version uses FE. Ciao, Eckhard Stolberg

Yes, I know what you're talking about. I've never found the ROM of this one. This binary is a hack of one of my scrolling text demos where Bob Dodson replaced my example text with the first part of "The Rime Of The Ancient Mariner". Bob sent me a copy of the binary in 1999, so I guess it's OK, if I post it here. ALBATROS.BIN BTW, the original scrolling text programs plus a lot of other demos from the Stella mailing list aren't included in your collection either. I suppose without the poem they didn't quite meet your quality criteria. Ciao, Eckhard Stolberg

Yes, that is how it works. But if you only had one 7800 and wanted to be able to still use Atari's original BIOS, you could put the code for both BIOSs on the same EPROM and add a switch to select which BIOS your 7800 should boot up with. This is what shadow460 meant. But since you are using a spare 7800, that isn't really nessessary. When you have installed the DevOS BIOS in your 7800 you can also modify a 7800 game cartridge to contain RAM instead of ROM or EPROM chips. Then you can use DevOS to transfer your game code from your PC into the RAM of the cartridge and play it on your 7800. (The PC program to do so is very old and only works reliably in DOS or DOS-based versions of Windows.) You wouldn't need to burn a game EPROM for that. So, if you'd ask someone here to burn a DevOS EPROM for you, you wouldn't need to buy an expensive EPROM programmer yourself. Burning the games on EPROMs is only nessessary, if you want to build real 7800 game cartridges that don't lose their program information when you turn the 7800 off. But if you want to do that, you don't need to install the DevOS BIOS in your 7800, because EPROM cartridges work in unmodified 7800s too. Graham Percy has designed several different versions of RAM carts for the DevOS system. You can find his instructions at http://www.geocities.com/gjp57/atari.htm. Among them are some RAM carts that don't need the 7800 to be modified, because they have the transfer code build-in. But I don't think I ever published the nessessaary 7800 binary and PC transfer program for those carts. So, if anyone here really wanted to build one of the Ramona carts, I'd have to try to find a copy of these files in my backups for you. Ciao, Eckhard Stolberg

The PAL 7800s can use either an EPROM or a masked ROM for the BIOS. To handle the different pinout of the chips there are two jumpers in the front-right corner of the board labled W5 and W6. One of them is closed with one of those parts that looks like a resistor with only a black ring. The other jumper is open. If W5 is open and W6 is closed, then the board uses a masked ROM. If W5 is closed and W6 is open, then the board uses an EPROM. So moving the W6 jumper to W5 and sticking a DevOS EPROM into the BIOS socket should be all that is needed for your modification. You should remember though that the PC transfer software is pretty old by now and only really works on DOS or DOS-based versions of Windows. Ciao, Eckhard Stolberg

Here is a scan of the missing "Im Schutz der Drachen" game. Also I made a scan of a short "PAC-KONG" cart which probably also belongs into this category. I'm not really sure these games deserve a category of their own though. They are probably just cartridges from the "Double-Game Package" with a different font on the label. Ciao, Eckhard Stolberg

I think you also need to use !A7 in there to avoid conflict with the RIOT timers. I wonder if there is a photo of the UA prototype boards out there? I think the UA prototypes belong to Albert now, so he might be able to provide you with a picture, if you asked him. IIRC, the UA prototype boards use two 4K EPROMs plus a 7470 and a 7404. Ciao, Eckhard Stolberg

Which version of the Tigervision 3F bankswitching does the Tron Man Picture Cart use? There is one version where the last 2K in the binary are used for the fixed bank at $f800-$ffff, because this is how a normal 3F cart would work. But z26 also supports a 3F mode where the 4th 2K page in the binary is used for the fixed bank at $f800-$ffff. This was added because it's how the original Cuttle Cart works with Tigervision games up to 64K. I think Stella only supports the first 3F bankswitching method but not the second one. And IIRC Andrew Davie's ChronoColour picture demos were developed on a Cuttle Cart using 3F bankswitching. So if the Tron Man Picture Cart is based on this code, it might be the reason why it doesn't work in Stella. Ciao, Eckhard Stolberg

Actually you have to speed up the game play, because you only get 50 frames per second on PAL instead of 60 on NTSC. Splitting up the extra scanlines evenly at the top and bottom of the display will center it. That would probably look best. You probably don't have to adjust the colours though. The palettes of the PAL 7800 in 7800 mode is very similar to the one on the NTSC 7800. The only real difference is that PAL TVs don't have a tint control, and that the red-green balance seems to be fixed a bit on the greener side. Therefore the PAL palette will look like the NTSC palette with the tint control on the TV shifted so much to the green side that the turquise colours will move one row in the colour chart program. Ciao, Eckhard Stolberg

How I detect PAL in my games is set up a blank screen with a DLI set to fire at a number of scanlines greater than the count displayed for NTSC, but less than PAL. The DLI just sets a flag. I let the thing go a frame or so. Is the bios rom even available once the game gets started? Then for PAL add some blank lines at the start and end of the screen and adjust game speed as necessary. Without the above, at the very least adding enough blank lines after the normal lines should at least eliminate any garbage, and any crashes probably usually attributed to DLI's being triggered you don't want. --Ken You can switch to the BIOS ROM until your game locks the mode of the 7800. But what PacManPlus is talking about is the Asteroids game that is build into the PAL 7800. It detects which type of console it is running on and adjusts it's display accordingly. For the test the game waits until VBLANK ends and then counts the scanlines until VBLANK starts again. Adding all the extra blank lines (50 to be precise) at the bottom of the normal display only would prevent the game from crashing on a PAL console, but the top of the normal display might not be visible on some PAL TVs. So you shouldn't have any important information there, if you used this method. Ciao, Eckhard Stolberg

I never made an official CD release myself, but I think Randy once offered a compilation CD with Supercharger homebrews which included my games too. Ciao, Eckhard Stolberg

Voice recording was pretty difficult to do with my old DOS based computer, so I didn't make any other speech demos. And about "the lightbulb lightens": I think the guy who wrote that ROM renaming tool for the 2600 ROMs got all the demos from the Stella mailing list without knowing where they came from. So he made up the names himself. There are quite a lot of the early Stella list demos with strange names out there. I suppose "the lightbulb lightens" is what he heard from my voice demo. Ciao, Eckhard Stolberg