Eckhard Stolberg

If you are counting cosmonauts too, then Sergey Volkov, the current commander of the ISS, went into space a couple month earlier. His father Alexander Volkov among other things was commander of the MIR at the time when the Soviet Union collapsed. Richard Garriott and Sergey Volkov will be returning to earth together though. Ciao, Eckhard Stolberg

The differences in the bankswitching hotspots is what you might get when dumping the game with the first and second release of the DevOS 7800. Both versions skip over the hotspot bytes, so the values you'd get in the binary depend on the state of the reading buffer in the PC program. In the second version of 7800CTRL the buffer gets initialized to zero. In the first version however I didn't do that. So if you'd dump a 4K game before you dump a bankswitched game, the bytes at the hotspot addresses might get filled with proper 6502 code. Ciao, Eckhard Stolberg

It is possible to position the sprites at equal distances, but you'd either have to increase the gap between them a bit or fill the entire line using 9 copies of each player. Increasing the gap might be too much for a nice looking grid. But it has the advantage that the sprites could be disabled individually. Christopher Tumber uses this in his game Space Instigators. Filling the entire line with 18 spites allows you to display a nice grid. But there isn't enough time to update the graphics and colours for both players in each scanline. I posted some experiments with this effect to the [stella] mailing list about 10 years ago. Multi5.bin displays a screen filling pattern. Grid2.bin displays a grid that you can scroll left and right. And extra18.bin displays 18 sprites that you can hide with the joystick. The sprites in the last one aren't positioned at equally distances though. multi5.binGRID2.BINEXTRA18.BIN Ciao, Eckhard Stolberg

I don't know the intellectual property laws in Australia, but I think your interpretation of the term "public domain" is wrong. Public Domain means that no-one has any rights to the game and that therefore anyone could do what he likes with it - including distribution for profit. See wikipedia's entry on public domain for more details. Luckily simply posting a binary in a message board doesn't make it public domain. Infact it doesn't give anyone any rights at all (except maybe the right to download the binary). If you wanted to allow people to make copies of your game or even to play it on an emulator or a RAM cartridge, you'd have to include a license text which allows that. Otherwise no-one could legally do anything with your game. Ciao, Eckhard Stolberg

IIRC correctly the pin for "joystick right" goes low when the lightgun trigger gets pulled. The pin for the joystick button goes low when the lightgun is pointed at something bright. When the lightgun trigger gets pulled, the game waits for the next frame to start and then displays one frame filled completely with a bright colour. During this frame the game "races the beam" so to speak, as it keeps polling INPT4 in a short loop untill it goes low. Since a loop like that could only cover very few possible hit spots in a line, the game will repeat the loop in the next couple of lines after a 'hit' detection but shifted by one CPU cycle in each line. If you want to emulate the lightgun, you need to have the DMA cycle stealing work properly, so that the IPT4 reads happen at the right screen position. Ciao, Eckhard Stolberg

IIRC Escape from the Mindmaster part 2 and 3 and Dragonstomper part 2 should load less than 6K. I'm not sure if they use any of the data that doesn't get replaced though. Ciao, Eckhard Stolberg

The 2600 Cuttle Cart doesn't support UA bankswitching. If you don't want to lock out people from trying your games, you'll need to find a different way of protecting them.

z26 automatically detects the FE version of Space Shuttle too, which means that the binary must have been available for quite a while already. And while I dodn't have a text label PAL Space Shuttle to test, I know that the HES release of PAL Decathlon uses F6 bankswitching. Whether that was done to make the game work on the newly released PAL 7800 or just because it was easier for HES to manufacture carts with F6 bankswitching I don't know. Ciao, Eckhard Stolberg

The PAL version of Space Shuttle uses FE bankswitching, so the original NTSC version probably did too. But that would have to be one of the older picture label carts instead of the newer text labels. Ciao, Eckhard Stolberg

Jinks was originally a C64 game and probably got ported to other home computers too. Ciao, Eckhard Stolberg

The only change I made to POLE278.bin was that I'm skipping the BIOS part and jump to the game code directly. I also added an instruction to lock the console into cartridge mode, so that the binary wouldn't crash when being executed as a cartridge instead of a BIOS. As for changes between the proto and the final release, I didn't look into those. But I suspect they were all releated to seperating the BIOS and the game part only. (adding proper startup code for a game, sepearating the graphics for both parts etc.) Ciao, Eckhard Stolberg

Yes, you could do that. Infact in the Pole Position II ROM there is even enough room to fit the entire NTSC BIOS in. That BIOS also includes the cartridge test. But since there is no game in the BIOS to start if no cartridge was found, the BIOS just sets the 7800 into 2600 mode. I guess that means that Pole Position II was originally meant to be part of the BIOS. Ciao, Eckhard Stolberg

Are you using the same type of EPROM for both BIOSs? The first test is for floating data lines and IIRC there were issues with the first version of 2600 Reindeer Rescue depending on whether the game used a NMOS or a CMOS EPROM. Due to a bug the game was relying on the state of the floating TIA pins on a read instruction, and one of the EPROM types was pulling those pins high. Maybe there is a similar issue with your BIOS EPROMs. Ciao, Eckhard Stolberg

I doubt it's possible without a major rewrite of code since it's currently designed to run as a 7800 BIOS. I don't know if it has any PAL code in there either but probably not. Mitch Actually skipping the BIOS part and starting the game directly would be pretty easy. But then all you'd get would be a normal NTSC Pole Position II. Ciao, Eckhard Stolberg

But the people who voted "yes" would probably buy a copy of Plutos and Sirius, so their vote should probably count twice too. And maybe you should mention this poll in the Plutos/Sirius thread. Not everyone asking for cart versions of those games being made might know that a 128K + 16K RAM PCB needs to be developed for that to happen. Ciao, Eckhard Stolberg

Maybe someone else can figure out what you need to do to trigger the built-in game. Congrats Walter, it looks like you have the long lost Pole Position 2 BIOS proto. Why someone stuck it on a cart board is odd, I guess they didn't know what they had. The code to trigger the build-in game is the same as in the NTSC and in the Asteroids BIOS. (The NTSC BIOS would enable 2600 mode when no cartridge was found.) Pole Position 2 should start when no cartridge is inserted. Maybe it's a problem with your modifications to the console. Does Asteroids start when you install the Asteroids BIOS on the same chip in this 7800 console? Good work identifying the proto as a BIOS, BTW. Maybe someone put the code on a cartridge because Pole Position 2 wouldn't start from the BIOS for him either. Since it will be a couple of days before Walter gets his proto back, I'll post some pictures again. Ciao, Eckhard Stolberg

The first games that GCC did for the 7800 were created on modified 7800 consoles that had a special BIOS installed. It would allow transmitting data through one of the joystick ports. Walter's Pole Position II proto is switching to the BIOS several times, which is why I'm assuming that it was writtin for one of those GCC developer 7800s. Since Atari's BIOS doesn't have the code that the game expects, it wouldn't work on a normal 7800 even if the binary was signed. Ciao, Eckhard Stolberg

That's because the Ramona BIOS is just an ugly hack of the DevOS BIOS. I always wanted to change a couple of things before releasing it to the public, but never got around to actually do that. If you or anyone else decides to build a Ramona cart, feel free to contact me privatly, and I'll try to find the latest version of the Ramona BIOS and it's 7800CTRL program for you. Ciao, Eckhard Stolberg

Isn't the AtariVox USB adaptor basically just a simulated serial port? If so, you could comunicate with the AtariVox through the normal serial functions of the OS without the need for any closed source libraries. That way Stella would also be able to access the AtariVox through the old serial port adaptor. You might not be able to access the SaveKey part of the AtariVox that way, but maybe that should better be simulated by a 32K file anyway, so that it would work for people who don't own an AtariVox too. Ciao, Eckhard Stolberg

Actually the CGE-released Snow White carts must use F8 bankswitching too, or they wouldn't work at all. The reason why the title screen is sometimes messed up is because the game was dumped incorrectly. For some reason the system vectors for both 4K banks were swapped. The system vector tells the VCS were to start with executing the code. Luckiely the incorrect system vector in one of the banks still points to valid code, so the game plays properly, if the game gets started in this bank. This is what the emulators and the Cuttle Cart do. On a real F8 bankswitching cartridge Snow White seems to start in the other bank most of the time though, which is why there are problems. I don't know why your other cart doesn't work properly, but if you change the bankswitching for a game, problems are to be expected. If you want to make a properly working Snow White cartridge, you need to swap the last six bytes in both 4K banks of the binary and put that on a F8 bankswitching board. Ciao, Eckhard Stolberg

There are plenty of graphic file converters out there that can handle PCX files. A free one that's available for many platforms is XnView. Ciao, Eckhard Stolberg

Does this affect all consoles or just those 7800's that have the 'Dark Chambers' fix? Also in your blog you mentioned that there is a chance of a random bank switch before the cart is set to a known state by the first bankswitching instruction. How likely is that to happen, and how many cycles could the game run before such a random switch is almost certain to have happened? You are righ though. For programmers it would be good, if the emulator informs them when they are doing something that they shouldn't do or that might cause compatibility issues on certain consoles. It might even be a good idea to have a seperate TIA handler to emulate the TIA89 consoles (the ones that have problems with Kool Aide Man). But seeing how slow emulator development is these days, I wouldn't expect too many of these features to be included in the emulators anytime soon. Ciao, Eckhard Stolberg

No idea who wrote it, I just saw who commited it. Maybe it even is yours I didn't release it, so either it's a duplicate effort or he hacked into my computer Hm... now you're puzzling me. Eckhard is the #1 2600 guru on this planet to me, but even he can't write a X07 driver when you didn't at least provide him with the specs, no? Or were they published somewhere in a public area? My theory is that he got ahold of Supercat's z26 code, and reverse-engineered it and adapted it to Stella. But... it may be better this way, as my code probably isn't as good as his There already was code for Stella and z26? If you guys keep discussing emulator related things in the holiday cart forum and even improve the emulators there, I guess I should join too. So, how do I join the holiday cart programmers club, and what's the secret handshake? You and Supercat mentioned X07 bankswitching somewhere in the public discussion of the holiday cart, so I asked Supercat for details. And since I was helping Steve with 4A50 support for Stella anyway, I thought I'd add support for X07 too. Most of the work was spend in getting my old Stella programming setup to work again. Writing the actual X07 class was only a couple of minutes of mostly cut & paste. Sending you an email to ask for a copy of your code probably would have taken longer. Ciao, Eckhard Stolberg

It could be bit rot. Or it could be a problem with the cart reader. Is the bit always different, even if you read the game several times with the alternative reading method? The normal version of the 4K ROM is identical to the [a] version of the 2K ROM, and the [a] version of the 4K ROM is identical to the normal version of the 2K ROM. Therefore the two 4K ROMs are unnnessessary. The different byte in the two 2K ROMs is the low byte of the BRK vector. When the VCS executes a BRK instructions it reads the address where it's going to continue execution from the last two bytes in the ROM address space. So it might be possible, that these two binaries were indeed read from two different version of the prototype. Or maybe someone patched the binary to fix it. Ciao, Eckhard Stolberg

1. That depends on the ROM type. If you have a prototype or a game from a smaller company that used EPROM chips for the game code, then the bankswitching logic is done with extra chips. Therefore unsoldering the EPROM chip will allow you to read out the ROM image entirely without having to deal with hotspots. If you have a maked ROM chip, then the bankswitchinglogic is build into the ROM chip directly, so unsoldering the chip won't help in this case. 2. 2K games have their data accessable at both halves of the 4K cartridge address space of the VCS. Therefore it doesn't matter which half you read out, as they are identical. 3. Hotspots don't need two bytes. In Atari's bankswitching (there are more complicated bankswitching formats by other companies) you need one hotspot for each bank that you want to map into the cartridge address space. But the hotspots are located in this address space too. You need to read the entire cartridge address space in order to read out a certain bank. Therefore the data for the hotspots will be missing in all banks that you read out. 4. CommaVid games don't use bankswitching, as there are no ROM banks to switch. The ROM fits entirely into the cartridge address space of the VCS. Therefore it doesn' t need any bankswitching hotspots. But two CommaVid games have 1K of RAM. If you read out these games as 4K images, you would also read out the RAM. Reading the RAM might get you random results, which means that you might get many different binaries that are functional identical too. Ciao, Eckhard Stolberg