Eckhard Stolberg

Yes, I have a Supercharger and a Cuttle Cart to test your program on, so I could have a look at your code, if you want to. Some things I noticed from your picture: IIRC, writes to the SC control register happen immediately, so the NOPs shouldn't be necessary. And the SC BIOS figures out the necessary write pulse delay value at startup and stores it together with the current bank configuration in address $80 when it passes control to the game. Since your game has problems on a real SC, maybe it might be worth a try to keep the topmost three bits of the byte intact instead of setting them always to zero, and ORA them into your bank configuration value before writing it to the SC control byte. Maybe this helps fixing your problem.

The only way to change the content of the registers in the 6502 is by running code on the 6502 that does this. But since the SC BIOS code isn't used for bankswitching, and the ROM bank isn't even mapped into the VCSs address space at the time of the switch, it must be your code that changes the accumulator. If batari's theory is correct, and the SC isn't ready to serve the opcode for the RTS instruction right after the bankswitch, you might not nessessarily get an equal replacement, like you tested his theory with. If the the SC doesn't drive the data bus at the time of the instruction fetch, you'd probably get $00, which is BRK, or $FF, which is ISB absolute,X. Since ISB is a combination of INC and SBC it would definitely change the accumator. Or maybe you's get the value that was last on the data bus, which would be the value that the CMP $FFF8 instruction reads from address $FFF8. Another theory might be a difference in the write pulse delay value which is part of the SC control register. The Stella emulator and the Harmony cart don't use this value for anything, but maybe on a real SC this value has some influence on how fast the SC could switch it's banks after a write to the control register?

The Megaboy ROM is also 64KB and therefore doesn't work on the current version of the Harmony. And does Fatal Run work with 32KB ROM and superchip RAM?

It would be a shame, if you couldn't get this memory configuration to work. Even though the zero page and stack RAM are mirrored in the system RAM, it would be really nice to have so much continuously addressable RAM. The 7800 programming manual mentions that $2800-$3FFF are the same as $2000-$27FF, but since it clearly isn't the case in one of your 7800s, I don't think that it's true. Maybe it's a timing issue. Didn't Atari add a special circuit to later models of the 7800 that changes the timing of the address bus in order to fix issues with 2600 games that use superchip RAM? IIRC, this circuit breaks compatibility with bankswitching schemes that rely on counting address bus changes, like FE bankswitching or the Supercharger. I think it had something to do with pulling all address bus lines low once per cycle in order to make sure that the superchip RAM wouldn't react to incorrect addresses before the address bus was stable. Maybe the internal 7800 RAM is affected by this too. Could something like this cause the problems you are experiencing with your Megacart?

Considering that there recently was discussion of how much RAM the 7800 could address, and looking at the addresses you are changing in your code example, I guess you've been experimenting with mapping cartridge RAM into every bit of unused address space below address $8000. Since the area below $1000 is mostly used for mirrors of the MARIA and TIA registers and the zero page RAM, and since there is 7800 system RAM between $1800 and $27FF, that would make 28K of continuously addressable RAM of which the Megacart+ provides 24K. So the demo program is probably testing if you got all the free address blocks without colliding with the used ones. Is that what we are seeing in your video?

That sounds like "Stroker" and "Sex Games". I don't know who made Stroker, but Sex Games was programmed by two German teenage brothers. I think they were 15 and 13 when they wrote the game.

This is Jim's original post: http://www.biglist.c...3/msg00160.html And this post illustrates the timing of the delay routine a little better: http://www.biglist.c...3/msg00162.html

I knew I should have cleaned up the source code before posting it to the stella mailing list, as this 'problem' comes up every time someone looks at the code. Someone on the stella Mailing list had asked if it was possible to have a free moving 48 pixels sprite. I was curious, so I simply took the 48 pixel sprite routine and quickly merged it with the single cycle delay routine that Jim Nitchals had posted a little while before. Instead of doing proper cycle counting, I simply tweaked all the delay timer values and player position values until all the writes to the graphics registers lined up perfectly and I was able to move the sprite everywhere on the screen. Back then I was still working with MS-DOS, which meant that I had to exit the text editor in order to compile the code and test the binary. Therefore I always used things like the ;????? as bookmarks for the place in the source code that I was currently working on. So there is nothing magical about those values. These are simply the lines where I had to tweak something to make the two routines work together properly. Sorry about the confusion.

Sure, if Rastignag wins all those auctions and is willing to send the cartridges to Germany, I'll gladly dump the ROM images for him.

You can't tell from the box, manual or label, as they were identical for PAL and NTSC during part of Atari's red label period. But PAL and NTSC use different colour palettes. If you play the PAL Solaris ROM in Stella and press CTRL-f to switch the emulator into NTSC mode, the colours will look pretty much like in your left picture. Therefore I would be surprised, if it wasn't a PAL cartridge on a NTSC console. If you still use the same TV as with your old 7800, then maybe the cartridge connector on that 7800 wasn't working properly anymore. If it was a different TV, it might be possible, that it didn't like the 50Hz signal and would blank out the picture completely. IIRC several years ago there were other people complaining about getting a PAL Solaris in North America. So it might be possible that your's came from the same source.

If by useless you mean that the screen was rolling, that is because the left game is a PAL cartridge. It produces too many scanlines for your old NTSC TV to handle.

OK, I finally found some time to test your program on my SECAM VCS. I can't attach pictures here, but it seems that red is a bit tricky to get on SECAM. In the title screen the exclamation point after "Timmy" and the word "RED" turn out to be a light gray, whereas the word "START" is red when it's not selected. In all levels the platforms where red is mixed with something else it also ends up as gray, while the 'R' blocks and the ladders / chutes really are red. All other colours seem to be as intended, as far as I can tell. I hope this helps.

OK, here is a screenshot of your program running on a SECAM VCS. As expected it's a bit different from the emulator screenshot. The top left corner is a lttle too dark in the first picture, so I did another screenshot of that area with more detail.

I have a Harmony and a Cuttle Cart, but unfortunately the picture quality of my SECAM VCS isn't that great. If you want to see all colours a SECAM VCS can display, you'll also need to test for single line colour changes in odd and even scanlines. As you can see in the Boulder Dash in SECAM thread, the tiles that start displaying in odd scanlines show different colours than the tiles starting in even scanlines.

My PAL copy of Snoopy and the Red Baron is like that too. Atarimania has this box variation, but lists it as NTSC. http://www.atarimani...aron_18341.html

I suppose you meant to thank our very own EricBall, which is Eric's username here. GroovyBee's name is Mark.

No, that wouldn't improve the situation much. The timing in the emulator is frame based. This means that you need to render the frame entirely before you can display it. Therefore there will alway be a one frame delay between when the code for reading the controller is emulated and when the resulting output gets displayed.

Since the auction even includes a Bentley Bear's Crystal Quest cartridge, this must be him. It's sad to see him leave the hobby. I wonder what caused this. Hopefully it's just a misunderstanding like the last time he wanted to give up 7800 programming. Does anyone know what happened?

Unfortunately this is a problem that is inevitable on frame-based emulators. On a real VCS the controllers are read directly while the console draws the current frame. But on an emulator you first have to read the PC controller, then feed it's data into the emulator to render the next frame, and only then can you display the output. So depending on how you read the PC controllers, there always is a one or two frame delay between when you move the controller and when you see the objects move on the screen.

No, IIRC, the problem with the Starpath games was in a much older version of Stella from the time when Brad was still the maintainer. The problem in Mindmaster is that the evaluation screen at the end relies on the player positions to be set by the SC BIOS during the loading routine. This is why the fake SC BIOS in Stella sets the player positions before each new load. I suppose the SC handler in the Harmony could also add this to fix the problem.

The tapes are stereo. One channel has the audio part and is played out through the speaker of the KidVid player, and the other channel has encoded information about which tape it is, when a song ends and when the tape ends. This one gets decoded over the joystick port. The emulator files only have the audio channel. The data channel is left out. Also some of the songs are used several times on the tapes. To save even more space the emulator files only contain one version of each song. The information about which song has to be played at which point in the game is stored inside the emulator. And yes, the files are only 8-bit mono at 31 kHz. That's what the DOS version of z26 used for the TIA output, so it's easy to mix the song data in.

Keine Ahnung wie sich das in Zukunft entwickelt, aber die erste Ausgabe ist nur eine Übersetzung der "Retro Gamer Collection Volume 5" mit den besten Artikeln aus 2010 oder so. Da du die vermutlich eh schon alle hast, lohnt sich die deutsche Ausgabe für dich wohl wirklich nicht. Achja, die englischen Retro Gamer Collection Hefte kosten auch GBP 9,99. Da ist die deutsche Ausgabe auch in dem Punkt schon recht nah am Original.

I'm as much a German perfectionist as Thomas is. So of course I would never distribute a known imperfect binary. But what do you mean with product-recall? I thought Albert has always wanted to do a world trip anyway. And since Melody carts can be reprogrammed without opening them, this would be the perfect opportunity for him to visit members of AA from all around the world and update the BD cartridges with the fixed binary right in their homes. To keep the costs low we could declare Al to be part of the programming device and mail him from one AA member to the next in a nice big box. But since BD cartridges were held up in customs for quite a while in some countries, we should first find out how many packaging peanuts we need to feed him a day so we can pack enough for him to make sure he won't bite anyone when they open the parcel.

I can't claim to have a proper binary of Boulder Dash unless you'd care to verify it, but it wasn't too difficult to get "something" out of the cartridge with my ROM dumper. It produces the same binary every time, which seems to play fine on Stella. So unless you have some really sneaky copy protection that changes the binary when it detects an attempt to dump the ROM so that the game would fail on higher levels, your copy protection isn't working too well. But it's a good thing that I had a look at the binary, because now I can inform you that you deleted one blank character too many in the last sentence of the copyright message when you changed it from the demo version to the release version. And knowing that Thomas and you are both perfectionists, I'm sure we'll now get a new release of Boulder Dash which fixes this and add all the other things you wished you had done differently after the game got released.

This post is about the German version of retro GAMER, so I'll continue in German ... Falls ihr's noch nicht mitbekommen habt, die retro GAMER gibt's seit kurzem auch auf deutsch. Die erste Ausgabe ist ein netter 260seitiger Querschitt der Artikel aus der englischen Ausgabe, die von den Leuten bei GamersGlobal übersetzt wurden. Das Format und die Druckqualität sind identisch mit dem Original, allerdings scheint das Papier leicht dünner zu sein. Eine 22seitige Leseprobe könnt ihr euch auf der Ankündigungsseite bei GamersGlobal als PDF runterladen. Ausserdem gibt es von der Chip ein Sonderheft zum 30. Geburtstag des C64. Da das Ganze haupsächlich von alten Power Play und 64er Redakteuren geschrieben wurde, interessiert es ja vielleicht den einen oder anderen hier auch wenn's nichts mit Atari zu tun hat.