Eckhard Stolberg

But the 7800 doesn't encrypt anything. It's only validates a signature key. And almost all NTSC 7800 consoles were made in Asia. How could Atari do that, if there were export restrictions for the boot ROM code? Also the Asteroids game in the boot ROM is compatible with PAL and NTSC consoles. It even checks which type of console it is running on. So Atari must have planned to use the new boot ROM with NTSC 7800s as well. The PAL 7800 was released in late 1989. I suppose the Tramiels just thought that it would be cheaper to have a build-in game on a slightly bigger boot ROM than to have a seperate pack-in game cartridge. Also in 1989 having to keep developers away from writing games for the 7800 probably wasn't much of a problem for Atari anymore. Ciao, Eckhard Stolberg

That's -)ST or -)TB for the left port, or -(ST or -(TB for the right port. Spelling is important for z26 command line options, so be sure to use capital letters for the controller identifyers. Ciao, Eckhard Stolberg

That's an error message from the SDL library using DirectX. I've never seen it before in z26. What version of DirectX and what graphic card do you use? Maybe updating DirectX and your graphic card drivers would help. Ciao, Eckhard Stolberg

In France the SCART connector is called péritel. So you should look for that on ebay.fr. On the original question: Some of my PAL 7800s had problems with fading colours in 2600 mode. The problem was the colour adjustment potentiometer for 2600 mode. Removing the glue drop and turning the potentiometer all the way 50 to 100 times for cleaning it before retuning the colours fixed the problem for me. If that doesn't work for you, replacing the potentiometer might help. Ciao, Eckhard Stolberg

The CC audio converter software has an option to skip "empty" data pages to speed up the transfer process. Do you use this feature for the Xevious ROM? The Xevious ROM has some "empty" pages where all bytes are $00. When I patched them to $ff, the game started to act strangely in z26 too. I didn't get "buildings", but the enemies behaved differently and the screen started to jump occasionally. So depending on what the state of the CC RAM is for the not-transferred pages before loading the Xevious binary, you might get strange things like the "buildings" to appear. Ciao, Eckhard Stolberg

The docs are incorrect. Eckhard Stolberg did some testing and determined there are no RAM shadows. That's right. With my 7800 console that was modified to be a cartridge reader I read out the entire 6502 addressing space. And there wasn't anything at $2800-$2FFF. Also I think the manual actually says that the RAM mirror is at $2800-$3FFF, which can't be true, because the HighScore Cart uses $3000-$3FFF for it's ROM. Are you sure about that? The RAM test at $F8E7 is running from within the 7800 BIOS. While the BIOS is enabled, the cartridge is disabled by setting A12-A15 low. So no cartridge should interfere with the RAM test. Also when the RAM test fails, it locks the 7800 into 2600 mode. But it does so in the middle of the BIOS ROM without transfering control to the cartridge. This results in a crash. So if 24 pin cartridges could make this RAM test fail, then no 2600 cartridge should work on the 7800. But if Bruce is right and the mode-select byte reacts to all mirrors of the TIA, then a dual-boot cartridge would be kind of pointless, because you couldn't do much in 2600 mode. Ciao, Eckhard Stolberg

Writing to the ROM isn't a good idea, as it might cause bus conflicts. It's better to use "CMP $1FF9", "BIT $1FF9" or "NOP $1FF9" instead. BTW vdub_bobby, did you already try if changing this would fix the problems with Reindeer Rescue on NMOS EPROMS? Ciao, Eckhard Stolberg

I don't think Dynamics ripped off anyone. Dynamics is a company that imports electronics from Asia and sells them in Germany. In the 1980s they sold the Competition Pro joysticks in Germany for example. So I'm pretty sure that they were officially distributing the OnBase games under the Dynamics name before OnBase decided to go with their own Bomb brand instead. Otherwise the OnBase games in the Dynamics catalog probably wouldn't have come in Bomb cases. Ciao, Eckhard Stolberg

My multistandard-TV is like that that too. In the on-screen menu I can only select various types of PAL and SECAM. But the TV will still display an NTSC picture through RF. Only for sound it expects the same carrier frequency as the selected PAL standard for the channel, which is different from the sound carrier frequency for NTSC. I was able to get sound from my NTSC 2600 and 7800 consoles by tuning the sound carrier frequency like Mitch suggested. I think the sound carrier frequency for PAL-B is the closest to NTSC, so the range of the variable inductor might be big enough to get sound from your 5200. If it isn't, then you need add another inductor to the board like Mitch said. Ciao, Eckhard Stolberg

There is a bit in the mode-control byte which switches between BIOS-ROM and cartridge. I think when the BIOS is selected, the console will pull A12-A15 low on the cartridge port. So you could disable the cartridge at any time until the mode is locked. The RIOT RAM is mapped in at $0480-$04FF in both modes (7800 and 2600). So you could run code from there to switch between modes. I'm not sure if the internal RAM keeps it's data in 2600 mode though. You would have to test that yourself. Since games weren't supposed to freely switch between modes, there is no hardware support for that. But there is a flag in 7800 mode that lets you test if the console is in the vertical blank. You might be able to use that to find out when it might be the best time to switch modes. On the 7800 it's the console that decides how many scanlines a frame should have. PAL consoles do more lines than NTSC consoles. Since you can find out when the 7800 is in vertical sync and there is a WSYNC command in 7800 mode too, you can easily count how many lines the console does between two vertical sync periods. The Asteroids game that is build into the PAL 7800 uses this method to find out what type of console it's running on and to set up it's output accordingly. Ciao, Eckhard Stolberg

Did they all use the same board type from PixelsPast, or did someone use his own design? And did they all have problems with the cartridges on their systems too, or do the games only fail on your consoles? Very strange. Did you try different power supplies with your VCSs, or did you always use the same? And what exactly happens when the game doesn't "start"? Ciao, Eckhard Stolberg

The mode-select byte is mapped in at $0000-$001F. Therefore you can't do TIA sound in 7800 mode when the mode isn't locked. In 2600 mode you could use the TIA mirror at $0040-$007F though. The RAM is mapped in at $1800-$27FF. Therefore only half of it would conflict with a cartridge that doesn't use A13-A15. Parts of the not-conflicting RAM are used for zeropage RAM and stack RAM though, so you really wouldn't have too much RAM left to create your display lists in. Unfortunately the RAM is tied with the MARIA. If you disable MARIA support, you also don't get the 4K of internal RAM. Also in TIA mode you get the same TIA mapping as on a 2600. This means that the TIA and the RIOT are mirrord at every even 4K page. Therefore you can only use the odd 4K pages for your code. Atari did develop some bankswitched 2600 games on their 7800 development cartridge this way. In the Cuttle Cart 2 you could use the 48K 7800 game type and put your code only in the odd 4K pages of the ROM image. Ciao, Eckhard Stolberg

The 2600 starts the game right away while the 7800 first goes through it's BIOS. So maybe your cartridge is a little too slow with setting the initial bank? Then the startup vector might get read incorrectly on the 2600. Also I think vdub_bobby had some strange problems with Reindeer Rescue when using CMOS EPROMs for the cartridge. They might be caused by using write instructions for triggering the bankswitching hotspots. Do you use CMOS EPROMs, and/or do you trigger the hotspots with STA instructions? And did you verify that the game really does start from both banks? The Cuttle Cart and z26 allow you to chose the starting bank for F8-bankswitching games. BTW, did you try your cartridge on more than one VCS? Ciao, Eckhard Stolberg

No-one would stop Paul from saving song names in his files, if he feels they are useful. And his tracker could easily check all 128 files in the background for it's file signature and only let you select proper tracker files by name in it's loading dialog. You only wouldn't be able to display these names in other programs, because they all would use their own format for naming and identifying their files. Having a standard file naming scheme would only be useful when you need to be able to delete other program's files to be able to save your data to the file area on the MemCard. But if for example you wanted to create a savegame state for a RPG, but your MemCard was already filled with tracker songs that you created months ago, then filenames like "MUS.MYSONG23" probably wouldn't be too helpfull for deciding which file to delete anyway. Ciao, Eckhard Stolberg

Are filenames or standardized file identifyers really nessessary. Each file has the same size and each memcard has the same number of files. So it would be quite easy to identify each file by it's index number. If programs just let the user select which file number to save data to or load data from, users could keep track of the contents of their memcards on a sheet of paper. Richard could even have an official printable memcard directory sheet for download on his website. No matter how clever you design the file identifiers, there is still a possibility that a program accidentally loads invalid data. And if the program has to check the data anyway, why not allow it to freely identify it's own files too. That way batari could for example put $BB in the first and last byte of each bB file, and supercat could put the ASCII representaion of "GEMS" at the start of each Strat-o-Gems play save file. If filenames were used, every program that wanted to be able to overwrite other program's files would have to include a text based file browser. I think that this would be unnessessary complex considering how limited the VCS is with processing power and RAM and how bad it is with displaying text. If files were only selected by their index number, even a simple 4K program could use the file area in the memcard. The only thing that might be helpful would be a 128 bit list in the Atarivox/memcard status block to mark used files. That way a program could have a "This file is already in use. Do you really want to overwrite it?" type of warning when the user selects a certain file. Ciao, Eckhard Stolberg

I think Marco has one of those too. IIRC you connect the Atari power cable to the cartridge. Then you connect the cable form the cartridge to the power connector on the VCS. There should also be a button on the back of the cartridge that lets you interrupt the power to the VCS. By turning the VCS off and on again you change between the the 6 games. So the button on the back of the cartridge lets you cycle through the games as well. As Marc said, this is a store demo cartridge. In the VCS demo stands in the shops the VCS was locked behind glas. Only the button on the cartridge and the controllers were accessible to the customers. That way customers could try out the different games on the cart without being able to mess up the console itself. Ciao, Eckhard Stolberg

Syriana and Underworld Evolution are indeed scheduled for late february / early march. With Corpse Bride you are out of luck though. This one came out two month ago. I suppose you'll have to wait for the DVD release. But don't be sad. The good news is that Domino came out last week, and that it is even showing in Augsburg this week. And on top of all this it's Kinotag today! So how fast can you find a babysitter? BTW, I use www.filmstarts.de for finding German movie release dates. Ciao, Eckhard Stolberg

I might be interested. But I'm wondering if the keyboard and the programs would work with the PAL 7800. Or will special PAL versions of the programs be available? Ciao, Eckhard Stolberg

You are correct. Pin 14 needs to be soldered down too. BTW, you might want to go here and get the second version of the devkit. It contains newer software. Pin 14 is still not mentioned in the manual though. Ciao, Eckhard Stolberg

z26 is probably not finding the Kid Vid audio files. It only looks for them in the current working directory. So depending on how you are starting the emulator you should put the audio files in the same directory as the binaries or in the same directory as the z26 executable. Ciao, Eckhard Stolberg

I think the Stella nightly builds still come with SDL.DLL version 1.2.8. Did you try to go to www.libsdl.org and download SDL.DLL version 1.2.9 and see if it works better with Stella on Win95? This should work on real hardware, since the ROM bank at the hotspots is fixed and wouldn't change when the hotspots get accessed. This won't work on real hardware and it probably will not work in fututre versions of z26 either. In the emulator we have to handle read and write accesses seperately. No E7 game tried to write to the extra RAM by read accesses to the write hotspots. Therefore we didn't implement a handler for this case in the E7 handler for read accesses. This is why you can still read from the ROM there. On real hardware there is no difference between read and write accesses. So a cartridge shouldn't return anything on an access to the extra-RAM write addresses. Ciao, Eckhard Stolberg

The changelog for SDL 1.2.9 (which was released in August) says that the SDL.DLL was fixed to work in Win95 again. So there probably only was a problem with how SDL.DLL 1.2.8 was compiled. Ciao, Eckhard Stolberg

Most modern PAL TVs also support SECAM. But they usually wouldn't autodetect a SECAM signal. You have to maually enable it for each channel in the on-screen menu. If you don't do that, you wouldn't get a picture from your SECAM VCS at all. Ciao, Eckhard Stolberg

A game would probably read one sample value per scanline at most. So you'll have at least 76 cycles to generate a new sample value. But in the display kernel scanlines it would be difficult for a VCS game to spare the cycles needed to trigger the sample generation. Therefore it would be better, if you could return the current sample value immediately and then generate a new sample value for the next read later. The game would need 3 cycles to write the sample value into the TIA volume register, and it takes a couple more cycles to set up a new instruction to read from any of the hardware registers on your cartridge, so you should have enough uninterrupted time to generate a new audio sample after a value was read. Ciao, Eckhard Stolberg

RAM refers to $F000 and RAM+$FF refers to $F0FF. With the Y-register ranging from $00 to $FF you will never cross a page boundary in the first case, but you will always cross a page boundary in the second case except when Y=$00. In the absolute-indexed addressing modes the 6507 will first add the contents of the index register to the low byte of the destination address and access this address. Only if the addition has overflown, it will increase the high byte of the destination address and access the corrected address too. This is were the extra cycle comes from. So if Y = $80, then a LDA $F0FF,Y will first read from address $F07F (triggering the SC write) and then read from $F17F (the extra cycle after fixing the high byte). You can save a zero, but you can't save a $FF. And you always have to add 1 to the value that you want to store. If you can live with these limitations, it's a clever way to save a byte for the NOP. But it probably is only really usefull for storing fixed values at fixed addressed. Or for easily decreasing values at fixed addresses as supercat pointed out. Ciao, Eckhard Stolberg