Eckhard Stolberg

But aren't the App Store rules incompatible with the GPL? IIRC, Apple's rules forbid you to distribute your application outside the AppStore or allow others to do so. This might mean you can't release the source code in a way that would allow others to compile the application themselves. Also the App Store rules forbit users to copy, modify or create derivative works of an application. This is in direct conflict with the GPL, which requires you to allow just that. I think Gnu Go and recently the VLC media player have been pulled from Apple's App Store because of this problem.

As you can see, I only have Zaxxon. But at least I have more of those than you are expecting.

No, Softgold Computerspiele GmbH was a German publisher who bought Rainbow Arts. Rainbow Arts was the company that created the original C64 version of Jinks. Besides Graftgold games Hewson also published the original C64 version of Tower Toppler (Nebulus in Europe). That one was programmed by John M. Pillips. Graftgold had nothing to do with it. www.graftgold.com lists (all ?) their games and programmers. There is no mention of Peter Pachla or any games for the 7800 on that site. IIRC Peter mentioned being from the Birmingham area and probably still lives there. I think US Gold was from there too. Do you know where Graftgold was from and if they had an office in Birmingham as well? BTW, I saw that there are currently at least two sellers offering several issues of ACE magazine from 1989/1990 on ebay.co.uk. Maybe you could ask them if one of those magazines contains the article about Gauntlet 7800 that you mentioned. Then we would at least know which issue to look for (or not to look for, if it's none of the ones available). (Whoa, that post took long to research and write. high voltage beat me to the answer by almost an hour )

Gauntlet might have been done by Graftgold, since you said in the other thead it was programmed later than the other two. But in this message on the stella mailing list Peter Pachla mentions that he worked at US Gold when he converted games to the 7800. And in this post on rec.games.video.classic he says that Tower Toppler was developed on the desk next to his at US Gold at the same time he created Jinks.

Are you sure about that? In his introduction to the Stella mailing list Peter Pachla said he was working for US Gold in Birmingham when he ported Jinks to the 7800. IIRC he also mentioned in a different post that he never saw a 7800 version of Gauntlet in his time at US Gold (until 1989). He only used the samples because they already were available in a format suitable for 8-bit systems from the other ports of Gauntlet.

Over here it's already the 26th, but since that's a holiday in Germany too: Merry Christmas to you too and thank you for the binary. But just to be precise the original Cuttle Cart doesn't support UA bankswitching, so unfortunately you can't play your game with it.

How do you do that? You wait for VBLANK to start by polling MSTAT. Then you wait for VBLANK to end. Then you count the number of scanlines until VBLANK starts again by triggering WSYNC and increasing a counter. PAL systems have more scanlines than NTSC ones. Here is the routine I used in DevOS. I found it in the version of Asteroids that is build into PAL 7800s. ; This routine waits for the vertical blanking period to start WaitVBLANK: WaitVBoff: bit MSTAT ;Vblank? bmi WaitVBoff ;wait while it is on... WaitVBon: bit MSTAT ;Vblank? bpl WaitVBon ;wait until it comes back... rts ... ; Do this during your init routine to test for PAL/NTSC jsr WaitVBLANK ; WaitVBover: bit MSTAT ; bmi WaitVBover ;wait for the VBLANK to end lda #$09 ;prepare NTSC setup here ldx #$00 CountLines: bit MSTAT ;if not back in VBLANK bmi CompareCounter ; sta WSYNC ; then wait 2 scanlines, sta WSYNC ; dex ; decrease the counter bne CountLines ; and keep counting CompareCounter: cpx #$78 ;if less than 274 lines have passed bcs noPALsetup ; we are on NTSC lda #$00 ; noPALsetup

I finally was able to contact John. He was just so busy that he forgot to renew his hosting contract. He has done that now, so www.whimsey.com is back up.

I haven't spoken with John in quite a while, so I don't know if he really gave up on whimsey.com, or if his hosting company just failed to renew his contract (he had this problem before). In any case, I have a complete copy of the z26 part of his website, which I could upload somewhere. I don't know if my free webhosting service is up to the task, but maybe Al would like to provide a little space on atariage. It's only about 13 MB.

When playing a PAL Pitfall 2 cartridge on a real VCS, Harry's face is white when running/jumping. It's fine when swimming or climbing though. So I suppose $0e is really the value in the cartridge.

Are you sure about that? IIRC from my experiments with the cartridge reader, only the TIA and MARIA get shadowed a couple of times below $400, but the RIOT is only accessible at $280 for the ports/timers and at $480 for the RAM. Everything else was available for the cartridge.

I suppose the colours and sound binaries were done by the emulator author to help sample the VCS palette and all the different sounds a VCS can do. IIRC Atari's VCS emulator was done by Jeff Vavasour who is from Canada. That would explain the spelling of "colours". Jeff is a member here, so it's possible the ROMs are from AtariAge.

Why would a 2600 cart need additional juice? It doesn't. The VCS power cable just gets routed through a button on the back of the cart. By pushing this button you can power-cycle the VCS to select the different games on the cart. That way you could protect the console behind glass in an unattended store display and only allow customers access to a small corner of the cartridge itself.

IIRC it works with the 7800 board but doesn't fit the 7800 case. The Compumate cart has three wires coming out out of the back at about half hight. Since the 7800 cartridge slot is a little deeper than a 2600 one, the cart wouldn't fit. And two of the wires need to go into the joystick ports but are too short to reach the ports on the front of the 7800. If you took the 7800 board out of the case, the Compumate cart would fit, but even then the joystick cables would barely be long enough.

Are you using 78ctrl38.exe that was posted in this thread? I just noticed that this version has support for Graham Percy's bankswitched RAM carts and is trying to use them by default. His Geocities site is gone, but there is a mirror at http://www.oocities.com/gjp57/download.htm. If you are using this version of 7800ctrl with a linear RAM cart like the one you build, you need to specify that with the -c1 switch. So "78ctrl38 -c1 splat.bin" should work better (you don't need to specify the -tSEND option, as this is the default as well). And you only need to move the wire from hole 3 to hole 2, like Mitch suggested, if those aren't connected on the other side of the board, like it is with my RAM cart.

That wouldn't work, because there are only 2K of RAM at address $2000, and part of it is used by the DevOS transfer routines itself. So writing something there would crash the console. You could try writing a 2K ROM to address $1800. Also does using the -f switch make a difference, when writing to your RAM cart? The normal transfer routines try to verify if each byte was written correctly, while the fast (-f) routines don't do that. If writing works with the fast routines but not with the normal ones, it would indicate a problem with your RAM cart or your DevOS modification. If it fails in both normal and fast mode, then it's probably a problem with the LPT cart or the virtualization.

Wait... the jumper pads make a difference? What are they supposed to be set at? I just checked the jumper pads on my C100339 48K cart. They are a little difficult to see, but I think W1, W4, W7 and W8 are closed, and W2, W3, W5 and W6 are open.

Where can the newest version of 7800ctrl be downloaded? Your site only has v0.2. Sorry, I never publicly released anything newer than that. After v0.2 7800CTRL has always been in a work-in-progress state with plenty of lose ends. Whenever someone contacted me with a problem, I tried to fix it and send him an updated version. I'm not really sure what the last halfway stable version is, but if the one Shawn posted already has the -a switch implemented, that should help with your unstable games.

FTDI also offers an USB cable with the FT232RQ already build in, so that you'd only need to solder an Atari joystick plug to it. That's what I used when I was trying to change DevOS to a serial protocol. Since the FTDI driver has a bit-banging protocol I tried it with 7800CTRL and the current version of DevOS. It worked, but was very slow (about 60 bytes per second instead of about 6000 bytes per second, that the DOS version does). It's so slow, because the DevOS protocol acknowledges every single bit, which means you need to switch between reading and writing to the port a lot. You need to access the driver twice for every bit, and each access takes a little while. I suppose it would be the same with the parallel port drivers mentioned above. Therefore we still need to change DevOS to serial. I still plan to do that, but I'm pretty busy at the moment, so I don't know when I'll find time for it. As for the original question: I don't think it's a problem on the PC side. The DevOS protocol is very simple. If the transfer was unstable, it would probably just lose sync and timeout, especially on the larger games. From my experience there are some bankswitched 2600 cartridges that don't like to be accessed at 7800 speed. That's what the -a option is for in the newer versions of 7800CTRL. It tries to read the game at 2600 speed. If that doesn't help, I don't know what might cause such a strange behavior.

Since you are from Finland, I suppose you are using a European 2-prong PSU. Did you try plugging it into the wall outlet upside down from what you normally use? I don't know if a different polarity could cause the kind of interference that you are experiencing, but it might be something that was different between the test at your place and your mom's, so it might be worth a try.

Don't know the answer to either of those, and it wouldn't surprise me if the Jr. and 7800 had different results. Probably wouldn't hurt to get some others to take photos of Stay Frosty and post it with which Atari it was on. As you probably know, the position counters for all the objects get advanced once every colour clock during the active part of the screen. Horizontal motion works by advancing those counters once every four colour clocks during the inactive part of the screen until the HMOVE counter matches the value in the HMxxx register for an object. The trick in the starfield effect is to change the HMxxx value just in time so that it never matches with the HMOVE counter and therefore the object's position counter will keep getting extra clock pulses. On the TIA77 the extra HMOVE pulses will simply overlap with the normal clock pulses that advance the position counters and therefore have no effect during the active part of the line (That's different on the TIA89, but that's a different subject.) The problem is that the same clock pulses are also used to advance the counters in the display circuit of the movable objects. And there the two different clock pulses happening at almost the same time might cause some side effects due to some race conditions. The visual consequences of these side effects might differ due to the chip revision, the age of the TIA, the temperature etc. That's why you are getting different starfields on different VCSs. IIRC the by far most common starfield pattern I have found is like this: The missile gets shiftet 17 pixels to the left in each scanline. When the missile is supposed to be displayed over the first pixel of a PF block, it gets extended one pixel to the left. So the missile is two pixels wide and connects two PF blocks. In the next line where the missile would be displayed at the last pixel of a PF block, it doesn't get displayed at all. What happens when you use wider missiles or the player or the ball still needs to be researched. Also what happens when you trigger a HMOVE in the active part of the scanline when there are still objects to be displayed in that part of the line also needs researching. Just mentioning it so you know that you'll still have lots more fun until you can consider Stella's TIA emulation to be perfect.

It's been a while since I measured it, but IIRC it was about 4kb for the normal mode (which is what was used in DevOS 0.1) and somewhere between 5 and 6kb for the fast mode of DevOS 0.2. That was for a PC using DOS though.

Yes, that's correct. However, in Stella you can't do this (or can you?), that's why I asked how you got it emulated. Well, if that's all there is to it, I'd just need to find what register is storing this value, and have Stella update it every time the ROM is loaded. The latter part is quite easy; figuring out where it's stored is the hard part. It's just a counter in the cartridge for the higher address line which is buffered by a capacitor. When you turn the console off for a while, the cartridge always starts with the first game. If you really want to support the 32-in-1 cart with it's own bankswitching scheme, you could simply load the next 2K part of the ROM image into the VCS memory map every time someone hits CTRL-R to reload the ROM in Stella.

Yep, sorry I couldn't provide more info in the header file, but I didn't actually write the X07 support for Stella, and I never actually received a test ROM. Now, it was written by someone infinitely more knowledgeable about bankswitching that I probably ever will be (Eckhard Stolberg), so I have no doubt it works, but I can't document it properly if I've never tested it myself ... Ok, the description probably is a bit sparse, but there really isn't anything else to this bankswitching scheme. The hotspot addresses above are given as binary numbers. A '0' or a '1' means that this address bit has to be in this state for the bankswitching to trigger. A 'x' means that this bit isn't checked by the bankswitching logic and therefore can be in either state. A 'n' means this bit is part of the new bank number to switch to. There are 16 banks each 4KB large for a total ROM size of 64KB. So for the first type of bankswitching hotspots address $081d would switch to bank 1 as would address $091d, $0a1d ... $0f1d. Address $085d ($095d etc.) would switch to bank 5 instead for example. For the second type of hotspots address $0000 would switch to bank 14 ($0e), if the cartridge currently was in bank 15 , while $0040 would switch to bank 15 ($0f), if the cartridge currently was in bank 14. The same goes for $0001 / $ 0041 or $073f / 077f for example. No bankswitch would happen if the cartridge was in banks 0 to 13 when these hotspots get accessed. This is important, as it allows you to switch between the last two banks in the ROM while reading from or writing to the TIA. It was used to create more room for the sound driver in the Stella's Stocking game select menu. This bankswitching type was only used for Stella's Stocking, the 2007 Christmas cart (hence the name of the bankswitching scheme: X07). I don't think the binary for Stella's Stocking has been released yet, which is why there isn't a binary to test the emulator support for X07 with.

The values for X and Y are correct. But while you are at it you might also want to check if the object positions and colours are set correctly when leaving the SC-BIOS. Some loads, like the evaluation screen in Escape from the Mindmaster rely on the this.