Eckhard Stolberg

z26 can do that, if you use the phosphor effect and BMP screenshots. Also the emulator has to run in a high colour video mode. High colour video modes are -v10 to -v18 for windowed mode and -v20 to -v28 for fullscreen. These modes will use the colour resolution of your desktop. To set the phosphor effect to a maximum you need to use the -f99 command line switch. This will combine the two last frames into one. Also you need to use -B to enable BMP screenshots, because PCX screenshots can't handle the colour resolution nessessary for the phosphor effect. So a command line like z26 -v20 -f99 -B gamename.bin should allow you to generate nice screenshots of games flickering with 30Hz. Ciao, Eckhard Stolberg

Actually, depending on which bank is currently mapped in and which bank the current state of the databus would select, a STA WSYNC would trigger a bankswitch on a 3F cart. That's why the Tigervision games access the TIA through addresses $0040 to $007C. Ciao, Eckhard Stolberg

Yes, all colours should be visible in this example. This can't be the problem then. Did you already try different colours, just to make sure that your red isn't simply too dark on your TV? Also it might be good, if you could post your source code. That would make it easier to look for other potential proplems. Looking at the binary, it seems that you have your DLL set to select palette 1. The manual says that in mode 320B only the most significant palette bit is read, and that you therefore can only choose between palette 0 and palette 4. Maybe setting a different palette can cause problems on a real 7800. Maybe that's why colour 1 doesn't get displayed? Ciao, Eckhard Stolberg

I was experimenting with Activision's FE bankswitching, but couldn't get the autodetection to work on the 7800. So I never put support for it into the release version of the DevKit. If you want, you could email me, and I could see, if I can still find a version of 7800CTRL with FE bankswitching as a command line override. Ciao, Eckhard Stolberg

As Kevin Horton's bankswitching guide says, 3F games react to accesses to all addresses between $0000 and $003F. But the switch will only happen when this access is followed by an access to an address between $1000 and $1FFF. Did your hardware handle that as well? I don't know if the games themselves are accessing the bankswitching addresses in a way that the next address on the bus in not $1000 or above. But maybe the VCS is accidently putting an address between $0000 and $003F on the bus for a short time. Maybe that's why Tigervision added the check for the $1xxx addresses? As for extended 3F bankswitching, there are demos that have the 4th bank as the fixed bank and there are demos that have the last bank in the ROM as the fixed bank. If you are only able to add one version to your cart, you should use the last bank. That seems to be what a real cartridge would use, if anyone ever decides to write a full game for extended 3F bankswitching. The method with the 4th bank as the fixed bank was only used for some early demos, because the Cuttle Cart 1 supports it for up to 64K. Ciao, Eckhard Stolberg

I haven't tried your demo, but depending on how your graphics look, this is normal in mode 320B. As the programmer's guide says, in mode 320B transparency doesn't work as expected when Kangaroo mode is turned on. The two pixels that would make up one pixel in 160 pixel modes are seen as a unit here. Only if both of theses pixels are turned on, they will show their selected colours. If both are turned off, they will be transparent. But if one is on and the other is off, then both pixels will show the background colour. When Kangaroo mode is turned on, then pixel colouring will work as normal. So if your graphics are designed in such a way that the third colour is only used for the pixels that are supposed to have a transparent pixel next to them, then they will not show in mode 320B with Kangaroo mode turned on. Ciao, Eckhard Stolberg

It's nice that the board clock is finally working correctly again and that it can handle daylight saving time now. But is there a way to set the displayed clock format somewhere, like the old forum did? I always get confused by the AM/PM format, because all my other clocks use the 24 hour format. Also the old board allowed you to hide your user name when you were logged into the forum. The new board seems to list the number of anonymous users too, but I can't seem to find a way in the settings to enable/disable this feature. Is it still available? Ciao, Eckhard Stolberg

That's good. But please note that all TIA read registers always drive the two topmost bits, even if only one of them has a meaning. So for the TIA part of the controller inputs (INPT0 - INPT5) for example only bit 7 is used, and bit 6 will always be pulled to zero. Ciao, Eckhard Stolberg

It's a problem with the data bus. All TIA read registers will only drive the two topmost bits. The six lower bits will be left floating. Therefore they will read whatever data was on the data bus last. Usually the TIA collision registers are read with zeropage addressing mode, so the last data on the bus usually is the low byte of the address of the TIA read registers. Video Pinball relies on the state of the lower bits when it compares the collision values. That's why collision detection with the paddles will fail, if your hardware always sets these bits to zero. That indeed did take us some to time to figure out and emulate correctly in z26. Accessing the secret kingdom in Mountain King also depends on the state of the lower bits in the collision registers. This game (accidently) interprets data from the TIA read registers as pointers for the level data. If the lower bits in the read registers are set to zero, the level data for the secret kingdom is created in such a way that there always will be some platforms in the way when you try to jump to the entry point of the secret kingdom. Therefore you won't be able to access it. Ciao, Eckhard Stolberg

The mouse pointer should only be stuck in the center of the screen when mouse capture is turned on. It's strange that disabling it has no effect for you. BTW, what video mode are you using for fullscreen display? The default fullscreen video mode in z26 is 400x300 in 256 colours. A laptop might not support this video mode, especially if it already is a bit older, like your's seems to be. If a video mode isn't available, the SDL tries to find the next best one and automatically converts the game's output to it. In such a case it might be possible that there are problems with the display. Maybe you could try starting z26 with a different video mode? -v1 for 320x240 or -v2 for 320x200 should work on most graphics cards. Ciao, Eckhard Stolberg

The SDL.DLL in the Windows directory should only matter, if you are starting z26 from a different directory than the one where the other SDL.DLL is located. I don't have access to a Win2K machine, so I can't experiment myself. Does anyone else with a Win2K machine have similar problems with z26? I'm wondering what might cause the hourglass. When I disable the mouse pointer hiding in z26, I always get a normal arrow mouse pointer. And it gets drawn over with the rendered VCS screen immediately, as long as I don't move the mouse. Could you try disabling other things, like the joystick support or the audio output, to see if any of that might cause the hanging? And did you try using windib for output by setting the SDL_VIDOEDRIVER variable, to confirm that the problem is not in Direct-X? Ciao, Eckhard Stolberg

That's a strange problem. We haven't had anyone else complain about this yet. z26 is telling the graphics library to hide the mouse pointer in fullscreen mode, so it shouldn't be visible. But on your computer something in the initialising process of z26 must be hanging, which causes the hourglass mouse pointer. As it seems this can't be hidden by the graphics library. By default the SDL library uses Direct-X for accessing the hardware on Windows. So maybe upgrading your drivers, Direct-X and/or the SDL DLL might help with your problem. Since you mentioned that the problem doesn't occur in window mode, did you try switching between fullscreen and window mode with ALT+ENTER? Does that make any difference? In window mode Direct-X is indeed a bit slow. You could get better speed by forcing SDL to default to using the nomal Windows drawing routines. They are slower in fullscreen mode though. If you are starting z26 form a command line prompt, you can select the video driver by setting the SDL_VIDEODRIVER variable before starting z26. "set SDL_VIDEODRIVER=windib" should do the trick. "set SDL_VIDEODRIVER=directx" will change the default back to Direct-X. The best speed for window mode and windib you will get, if you start the emulator with the default fullscreen video mode and then switch to window mode with ALT+ENTER, because then z26 will run in 256 colour mode. I guess we'll have to do something about selecting video modes in one of the next versions. Ciao, Eckhard Stolberg

Steve is right. The delay depends on the size of the audio buffer. In z26 we have chosen a default buffer size that should work on slower computer too. If you have a fast computer you can reduce the buffer size with the -s command line switch. The number that you specify with the -s switch is the size of all buffers combined. Since we use tripple buffering for audio, you must specify a number that is three times the desired buffer size. So -s1536 would give you a audio buffer size of 512 bytes, which is about the smalles I can get on my Windows system too. Ciao, Eckhard Stolberg

But why would you want to run DevOS on a Cuttle Cart 2 or a Krokodile Cart? Both devices have their own (much better) way of transferring 6502 programs to them, so you can use them for 2600 (and 7800 in the case of the CC2) game development without installing a DevOS ROM in your 7800. Ciao, Eckhard Stolberg

Hello Ed, looking at your Cosmic Ark screenshot, it seems that you are not doing the starfield effect quite right (z26 doesn't either). On a real VCS the extra clocks from the HMOVE, that are happening during the visible part of the screen, somehow interfere with the output logic for the movable objects. This might be because the clock line for HMOVE is used for different things during the visible part of the screen. If you cause the starfield effect for a one pixel wide missile (like Cosmic Ark does), then you need to look at the scanlines where the missile would be drawn over the first pixel of a playfield block. In the scanline after that the missile will not display, while in the scanline after that the missile will be two pixels wide. If you cause the starfield effect for a player graphics and it's first pixel displays over the first pixel of a playfield block, then the player will only move 16 pixels in the next scanline. It will move 18 pixels in the scanline after that though. Therefore I think it's not the object's position that is affected, but the output logic for the object. I don't know what is going on there exactly, so if you find out by studying the TIA schematics how the object display logic works and how it could be affected by extra HMOVE clock pulses, please let me know, so that we can fix z26 too. Thanks, Eckhard Stolberg

"Pirates!" is mostly the same game it was 17 years ago, but with todays graphics. There are a couple new minigames as well as small additions to just about every aspect of the game, but overall it still plays and feels like the original. So, if you (like me) are happy with a game that can fascinate you for a couple of hours every now and then, then you probably would enjoy "Pirates!". If your game-taste has changed since the 1980's, and you prefer games that that can fascinate you for a couple of weeks in a row until you have beaten it, then you might prefer one of the other games from your list. Ciao, Eckhard Stolberg

Yes, David Crane's actual patent is available in PDF form from the US patent office. I can't find the link at the moment though. Besides the sample generators for the three sound voices, the DPC also has 2K of ROM with graphics data, that can be read through several pointers. These pointers have auto-increment and auto bounds-checking. So in theory it's possible to recreate the DPC for a multicart. But the chip is so complex that you would need a pretty expensive FPGA or microcontroller to emulate it. That's the reason why the Cuttle Cart 2 has no support for the DPC, BTW. It's design wouldn't have fit on the FPGA, that Chad was using, and a bigger FPGA would have cost much more and be more difficult to fit on the small CC2 cartridge board. Ciao, Eckhard Stolberg

The way Harry Dodgson got his Monitor Cartridge signed was by sending the code to Atari and paying for having it run through the key generator. That's how he got permission for including the sample programs and programming manuals too. And I think the manual for the Monitor Cartridge also included schematics for a simple serial cable that lets you transfer data from your PC to the MC's RAM though the 7800's joystick port. And what Eric was referring to was that you can create unsigned homebrews for the PAL 7800, because it's BIOS doesn't check for a signature key. Also the NTSC BIOS allows you to have as little as 4K of your ROM signed. The BIOS does make sure that the startup vector points into the signed part of the ROM, but it doesn't check what your code actually does. So many 7800 programs only had those 4K signed and then the first instruction would jump right out of the protected area. That way the programmer could make changes to the game without having it being resigned by Atari. So if you really really wanted to write a homebrew for the 7800 before the encryption key was found, you could have included the last 4K of one of those games into your hombrew and arranged your code in such a way that the initial jump and the interrupt vector would hit the right routines in your game. And the parallel port transfer in my BIOS replacement is bi-directional. Also we included plans for hacking a 7800 game board into an all-RAM cart. That allowed you to try out your code on a real 7800 console. There were a few people who were using this setup to experiment with 7800 programming, but none of them got far enough to dare showing their results in public. Of couse the parallel port connection wouldn't have worked for a Mac user like yourself. And the Cuttle Cart 2 and the 7800 emulators are a much more convenient setup to use than having to modify your 7800 console first. They actually motivated programmers to try out programming for the 7800 and share their results here. So I agree with you, that modern 7800 homebrew development really started last year. Ciao, Eckhard Stolberg

If your desktop is running with more than 8 bpp, then you can easily use z26 to take nice Chronocolour screenshots. You just have to run z26 in a video mode that uses the same bit depth as your desktop, enable BMP screenshots, and set the phosphor effect to maximum persistency. Then you would get 16, 24 or 32 bit BMP screenshots (depending on your desktop) that show both frames simultaniously. Running z26 -v22 -B -f99 qb.bin should do the trick. Ciao, Eckhard Stolberg

Here is a quote from my backdoor example code: ; Differences between the NTSC and PAL 7800 consoles' output: ; NTSC PAL ; 15 15 automatic VBLANK lines ; 25 33 output lines, that can't be seen on many TVs ; 192 228 actual display lines ; 26 32 output lines, that can't be seen on many TVs ; 4 4 automatic VBLANK lines ; ; 262 312 total number of lines per frame ; 243 293 total number of DMA output lines per frame ; 60 50 frames per second ; ; So to make a NTSC game run properly on a PAL console, you can simply ; set up 25 extra blank lines before and after the normal NTSC display. ; Also you would have to adjust anything that is timed by counting the ; number of frames, since PAL consoles do less frames per second than ; NTSC consoles. The following routine detects if it is running on a ; NTSC or a PAL console by counting the number of scanlines per frame, ; so that you can make your game compatible with both TV standards. The program demonstrated how to get around the signature key check, which isn't nessessary anymore, now that we have some proper signature key generators. But the code also contains a PAL/NTSC test. It was taken from the Asteroids BIOS, so it's known to work. Ciao, Eckhard Stolberg

Probably not. And if I did, I guess my return wouldn't be that triumphant anyway, because it seems that I would have to be competing with you. Ciao, Eckhard Stolberg

Is there any information about the AtariVox protocol available? Or could you post the code you use to detect the AtariVox in your game please, so that we can try to fix the problem in z26? Thanks, Eckhard Stolberg

While it would be possible for a 2600 game on a 7800 board to use 32K of somewhat linear ROM or even a large amount of linear extra RAM on the cartridge, I don't think it would be that easy to use the 7800's system RAM from a TIA game. If you enable the 7800's system RAM, you'll also enable the MARIA registers. And those will overlap with some of the TIA graphics registers. Therefore you'd have to be really carefull with what you write to the TIA registers to not trigger some unwanted interference from the MARIA DMA. Also the RAM support enables the faster CPU speed, which slows down for every access to the TIA. Therefore cycle counting your TIA accesses in the display kernel would become quite difficult. Ciao, Eckhard Stolberg

There were five games released with RAM in the cartridge. The three games by Epyx (Impossible Mission, Summer Games and Winter Games) and the two games by US Gold (Jinks and Tower Toppler) had 8K or 16K in the same address space as the POKEY in Ballblazer and Commando. Also the Rescue on Fractalus prototype has a weird 2K RAM setup. The 7800 itself only had 4K of RAM build in. Adding RAM to the cartridge is probably a little cheaper and simpler than adding the POKEY, because the chips are smaller and easier to find. Only if you wanted to have POKEY and RAM on a board, things might become a little complicated. You might need to add a jumper to select between both setups. But you probably might need jumpers anyway, if you wanted to support many different ROM setups with the same board. Atari's bankswitching boards were like this, so you might be able to learn from their design. And if you wanted to support the POKEY and RAM in the same game, you could easily map the POKEY into a different free spot in the 7800's memory map. There are plenty of spaces where the 16 registers of the POKEY would fit in. Since no homebrew games with POKEY support were finished yet, it probably wouldn't be a problem if the registers were moved to different addresses than in Atari's own games. Ciao, Eckhard Stolberg

Acid Drop and Pick'n'Pile were both programmed by Dennis Kiss. I suppose they were both programmed in the UK then? Or were only the graphics artists for Acid Drop from the UK? My Golf is a PAL only game. To find it in the AtariAge data base, you have to set the region to "All" in the search dialog. It defaults to finding North American releases only, because it was voted to be that way by AtariAge users in the early days. But as it seems the results of that poll have changed in favour of showing all results over time. Maybe the default region setting in the search feature should be changed to avoid confusions like this in the future. Ciao, Eckhard Stolberg