Eckhard Stolberg

PhredreekePhredreekeI I don't know if anyone will ever really play Boulder Dash on a SECAM 2600, but since you took the effort to optimize the colours for this TV standard, I thought you might like to see how it turned out. So I took some pictures of the game playing on a SECAM VCS connected to my multi-standard TV. Unfortunately Phredreeke was right. SECAM VCSs don't like striped displays too much. When you use single line colour changes, the colour may even be different depending on which scanline you display it in (odd or even). This is most noticeable in Rockford's face, which has a different colour when he is displayed in an odd row then he has in an even row of tiles. But it also shows in the colour pattern of the dirt tiles or the boulders, where the red and blue lines differ depending on which row the tile gets displayed in. Another thing to notice is that using PAL colours the look-around mode doesn't show the dirt tiles in some caves, while this works fine using NTSC colours. Nevertheless all tiles are still easily recognizable in both colour modes on a SECAM VCS, so the game is still just as playable as it is on NTSC or PAL colsoles. PAL 50 PAL 60 NTSC

I don't know if you are able to write a game, but the necessary C64 to SC audio player can be found here.

The reason for the difference is that Stella randomizes the RIOT RAM, while z26 sets it all to zero. The game only initializes certain parts of the RAM and accidentally relies on the rest to be zero. Therefore it might not work on a real VCS either. Elf Adventure has a routine where it copies the address for an indirect jump from a ROM table to RAM. It reads the index into this table from one of the uninitialized RAM addresses. Therefore the index is incorrect in Stella most of the time, so when the game does the jump it ends up in the wrong code and crashes.

I had a that problem too, when I tried to log in for the first time after creating an account in the store. When you chose a password for the store, it's probably best to use one that consists of only letters and numbers but no punctuation marks and stuff like that. When you try to set a password that contains special characters, the store will tell you everything is fine, but then it won't let you log in with this password, because some of the special characters seem to get messed up when they are stored in the database. The forum can handle these characters nicely though.

Strange. I'm wondering what's going on there. What speed were the EPROMs that worked and the ones that didn't?

I've tried the ROM on my PAL VCS, and it plays fine. I haven't looked closely enough at the code to tell if it should be executed like that. But if a game were to turn on VSYNC for 4 lines, then turn it off for 4 lines, and then turn it back on for another 4 lines, that would be essentially the same as turning on VSYNC for 12 lines. When you turn on VSYNC you are telling the electron beam to return to the top left corner of the screen an to stay there. So during the 4 lines where VSYNC is turned off, you really are generating a blank frame. But it is only 4 lines tall, which is completely in the invisible part of a TV frame. So when you turn VSYNC back on an tell the electron beam to return to the top of of screen, the 4 line frame wouldn't have been noticeable. Therefore the code in Pick'n'Pile is the same as holding the electron beam at the top of the screen for 12 lines by turning VSYNC on for that long. IIRC in z26 we simply ignored a second VSYNC when it came too soon after the first. I know that's a cheat, but it's easier than trying to deal properly with 4-line frames and works quite well.

It might be a speed problem with the EPROMs, but since you mentioned that you tried the same EPROM in both boards, I doubt it. BTW, which bank does come up on the problematical boards? It might be a speed problem with the logic chips though. Did you check if they are the same type on both boards? If it indeed is a problem with the bankswitching logic trying to latch the bank number too soon or too late, you could try to make the pattern on the data and address bus stay longer. You could try to trigger the bankswitching by using absolute indexed addressing. On a STA $8000,X there will be a read from $8000+X before the write happens to the same address. And if you have a byte to spare in each bank, you could make the byte that gets read from $8000+X the same as the bank number. Then all the lines on the address and data bus will already be in the correct state when the R/W line changes which would trigger the bankswitching. Maybe that helps. And about the control scheme: Maybe pressing both buttons together is easier on Nintendo's or Sega's controllers, but I find it difficult to do on both Atari's joysticks and joypads. I like your suggestion about using "up" for the jump. Then it would be possible to play the game with a single button joystick too.

Your code should work for properly setting the bank. But on the 2600 different boards or different types of EPROMs can change the value you would get from reading the unused bits in the TIA read registers. Therefore problems like the one you are experiencing usually indicate a case of accidentally using zeropage addressing instead of the intended immediate addressing. Maybe that's a problem on the 7800 too. Did you check if the level counter gets initialized properly?

This looks like an early version of the Telepathy prototype, which can be played with the MindLink or the joystick. The top half of the picture is similar to the first screen in Telepathy where you move your character left and right collecting those triangular shaped things until you reach the hole that's the entrance to the mine. The lower half in the picture looks like the second screen in Telepathy where you move the character left and right to get further down into the mine trying to avoid moving spiders on the way. There are two more screens in the prototype ROM that is available. Maybe they had an early version for the show where only the first two screens were ready, and this screen lets you select between them?

You'd still need to address the issue with Omegamatrix's ROM though. I think the problem could be fixed if you filled the remainder of the internal screen buffer with black pixels if necessary when VSYNC is triggered. That might also be useful if a badly programmed game occasionally does too little scanlines.

There are several loads on the SongMate and PictureMate tapes, but I don't think it's as complicated as the Supercharger format. A new load must always be triggered by the user pressing Func-H. It doesn't happen automatically. Also I don't think the CompuMate can load data to only certain parts of the RAM like the SC can.

OK, now I'm confused. In fact, PAL systems have always confused me, since I've never actually seen one before. Is a PAL TV higher than an NTSC one? Or are they the same height, and each line is thinner on the PAL TV?? I'm having a hard time understanding how the NTSC image could be stretched. If there's a 1-to-1 correspondence between NTSC and PAL scanline 'height', I would think an NTSC image would be closer to the top of the screen on a PAL TV. But if it fills out the same area as a PAL image, then the scanline heights must be different. In any event, the former is easy to do (Stella already does it), the latter much less so. I wonder, is there something else going on in this TV, where it stretches the image for you (sort of like how a fullscreen image can be stretched horizontally to get rid of black bars)? The aspect ratio is 4:3 or 16:9 on PAL TVs as it is on NTSC TVs. So the lines on a PAL TV are thinner than on a NTSC TV. But Alex's TV isn't a PAL TV, it's a multi-standard TV that is capable of displaying many different TV standards from all around the world. This is why it can change the thickness of the lines when switching from 50 Hz images to 60 Hz images. Most TVs in Europe are like this nowadays. On an old PAL-only TV things would be as you expected. The 60 Hz image would be displayed at the top of the screen with black filling the bottom.

According to Kevin Horton's 2600 mapper text the CompuMate uses bit 7 of SWCHA for tape input and bit 6 for tape output. When you press Func-H in the Stella CompuMate emulation, the screen flashes 8 times, so I assume the CompuMate always saves the entire 1K RAM to tape in steps of 256 bytes. You could modify Stella to trap Func-H and Func-J. When Func-H gets pressed you would recored changes to bit 6 of SWCHA and how many cycles have passed since the last change. When Func-J gets pressed you could feed this information back into bit 7 of SWCHA. Maybe this would help to figure out how the CompuMate converts bytes to audio. BTW, SongMate and PictureMate aren't real programs. They are just a collection of sample songs / pictures for the build-in music editor / paint program of the CompuMate ROM.

OK, I finally had some time to try the NTSC binary on one of my PAL Jrs again, and I can confirm your findings. On the first test with RESP0 set to 1 the screen sank and shifted when I changed RSYNC from 37 to 38 though. But when I changed it back to 37 the screen was still in the same position until I changed RSYNC to 36. Also when I'm counting RSYNC upwards the top of the screen gets skewed more and more to the right. This is until RSYNC 38, when the top of the screen gets skewed to the left. Changing it back to 37 still has the top of the screen skewed to the left. At 36 it gets back to right.

One of my Eishockey-Fieber carts is like that too. I got it at a local flea-market several years ago. Since we had a Quelle store here, I suppose that's where it came from. The label is the same as on the normal Quelle carts. The case is similar to the black Homevision carts and the German label version of Parker Frogger. The lines on the sides and the dust cover mechanism is the same, but the Frogger cart also has lines on the back, while my Homevison 4 neither has the lines nor the 1234 on the back.

That's true, but as you pointed out, writing $03 into the HMPx registers is the same as writing $00. Therefore writing $00 into HMP0 later doesn't change anything. Even though the write occurs during the time where the HMOVE updates are still in progress, it has no effect, since no HMOVE pulses are fed into the position counter for player 0.

OK, I did a quick test of both binaries on one of my PAL Jr. consoles. It also is a late model which has problems with Kool Aide Man, but I don't expect any differences in running your demos on different versions of the TIA. The differences with those are mostly in how they react to HMOVE pulses that happen during the visible part of the screen, which your demo doesn't use. Triggering RSYNC in the first 24 CPU cycles after an HMOVE might be worth trying out too though. When I run the NTSC demo, I also get a rolling screen at RSYNC on cycle 22 too. In the PAL demo this happens at cycle 38. In both demos the screen occasionally gets stable at these RSYNC counts depending on when RESPx gets hit. I did experience PAL colour loss in both demos, but couldn't find a pattern for when it did or didn't happen depending on when RSYNC and RESPx got hit. When RSYNC gets hit at cycle 24 or later the first couple of lines at the top of the screen get shifted to the side a bit. It's more visible in the NTSC version on my TV, but happens in both versions. The objects always get positioned three pixels further to the right after a WSYNC than they do after a RSYNC, but this is to be expected. Triggering WSYNC will halt the CPU until the horizontal sync counter wraps around to zero. Triggering RSYNC will reset the horizontal sync counter to zero immediately. But the warp-around will actually happen after one more cycle of this counter. Since the horizontal sync counter counts once every 4 pixels, one more CPU cycle occurs before the counter warps around to zero. Therefore the positioning code will hit RESPx one cycle sooner after a RSYNC than after a WSYNC.

The difference is that the other games all do a WSYNC again before positioning the players. Therefore Stella knows where in the line it is supposed to be when RESPx gets triggered. I think RSYNC is the same as WSYNC except that the CPU isn't halted, because the new scanline starts immediately. When you look at the loop at L13AF you'll notice that it triggers RSYNC 10 cycles or 30 pixels (I miscounted the loop in the last post) after it triggers WSYNC. This effectively starts a new scanline, which Stella doesn't notice, because it doesn't handle accesses to RSYNC. The emulator still counts it's current position in the line from the WSYNC not from the RSYNC. Therefore it positions the players 30 pixels too far to the right. To fix the problem in Stella you could execute the same routine for RSYNC as you do for WSYNC. But since you don't have to halt the CPU emulation, you only need to render the current scanline to the position where the RSYNC happens and fill the rest with black pixels before resetting the TIA emulation for the next scanline. I'm sure there are plenty of sideeffects when triggering RSYNC in the middle of the scanline, but since almost all current games only trigger RSYNC during their initialization loop, I guess Fatal Run would be the only one that might have problems with changing Stella this way.

The loop at L13AF triggers RSYNC at it's mirror at $0103. And again I agree with you that the ROM image should have distinctive name. Maybe we could also put a little ASCII text into the unused space of the ROM that indicates it's state as being modified from the original. But right now it's too late over here to dig out the VCS and test the patched ROM on a real console. That'll have to wait until tomorrow.

While I agree with Stephen that this issue should eventually be fixed in Stella, I also agree with him that it would require a lot of research work. Fixing the ROM on the other hand would be relatively simple, because the problem is in the startup code and there is plenty of unused ROM space. I think it might even be possible to get the ROM to display properly by moving only 4 bytes.

This needs some experiments on a real VCS to verify, but I think the problem is that the emulators don't handle accesses to the RSYNC register at all at the moment. If you compare the game on a real VCS and on Stella, you'll notice that the players are positioned about 30 pixels too far to the right on the emulator. And when you play the game, you'll see that all collisions are handled as if the players were positioned these 30 pixels further left. A VCS game normally would do the coarse positioning the players once per frame in a timed loop and then fine shift them to their final position. Extra Terrestrials only does the coarse positioning once at the start of the game and then shifts the players when they need to be moved while playing. The accesses to the RESPx registers for the coarse positioning happens during the initializing routine right after all registers and the RAM have been cleared. During this clearing loop the game accesses RSYNC 9 CPU cycles (or 27 pixels) after it accesses WSYNC. It doesn't access WSYNC again before triggering the RESPx registers to position the players. Triggering the RSYNC register resets the horizontal sync counter, and triggering a RESPx register seems to set the position of the player to the current value of this counter. In a normal line without a RSYNC the counter would reach that value 27 pixels later, which would explain why the players in Extra Terrestrials are off by that amount.

One of the difficulty switches is used for a pause feature on Kool Aide Man. When the switch is in the pause position on startup, the game freezes on the title screen. If you flip the switch, the game should start normally. The difference that might appear on your console is the score display. On some consoles (like Thomas Chinese Jr.) the score digits overlap. This constantly triggers the collision detection which results in Kool Aide Man constantly bouncing back and forth in the top left corner of the screen. This makes the game unplayable. On all (?) 2600 Jr. consoles (NTSC and PAL) that are made in China after late 1989 the signal timing in the TIA for the shifting pulses for the movable objects seems to be a little off from older versions of the TIA. Therefore when a game starts the shifting process in such a way that some of the shifting pulses happen during the visible part of the screen, the movable objects might be positioned slightly differently. This affects all PAL 7800 consoles too, BTW. Something similar seems to be going on in your "unicorn" console too. You can see tis in your Pitfall II video. The game doesn't do an HMOVE in every line, so not all lines start with an eight pixel blank. Pitfall II tries to hide it with displaying a black eight pixel wide copy of missile 1 in those lines where it doesn't do an HMOVE. On your 2600 these missiles are shifted one pixel to the right. If you run Pitfall II in Stella and disable missile 1 with ALT-V, you can see that there are gaps in exactly the same scanlines where the one pixel shifts are in your video. Other games worth testing for compatibility would be the starfield effect in Cosmic Ark, the tile screen in He-Man and the cobra head in G.I.Joe / Action Force.

The scrollbar demos were something I posted to the stella mailing list in june / july 1999. Bob disassembled one of the demos and replaced my text with the mariner poem. Here is a link to the post that contains the source code to the last version of the scrolling text demo. If you like, you can make your own version of it and put it on your website.

Seems like you forgot to attach the new source code again. In the timer loops you also changed the INTIM to TIMINT (which is a different register), right? Because otherwise the bpl would end the loop immediately if the value loaded into the timer was bigger than 127 (which is the case in the lightgun position test). Anyway, the reason why you are generating too many scanlines has nothing to do with the timers. It's simply because your ScanLoop takes more than 76 cycles in some cases. That means some instructions will be executed in a second line. These extra lines add up quite a bit in your program. If you make sure that your ScanLoop never uses more than 76 cycles between (and including) two "sta WSYNC"s in every possible case, then your display should be fine.

I don't think accessing XM RAM would be possible like this for a 2600 cart. The 2600 only has an address space of 8K total with the first 4K being used by the TIA and PIA and the second 4K being used by the game ROM. IIRC this is true for the 7800 in 2600 mode too. So all XM RAM would either conflict with a mirror of either the TIA/PIA or the ROM. It might be possible to access RAM at $5000-$5fff and $7000-$7fff (can the XM map it's RAM there?) if you'd put the 2600 game on a 7800 board. I think the hacked version of Save Mary does something similar, but uses it's own RAM on a 7800 board.