Eckhard Stolberg

I don't think either of you has a PAL copy of Solaris. On the VCS the games are responsible for synchronizing with the TV themselves. Some games try to use the time it takes to do that properly for other things as well, and Solaris is one of them. Not all TVs are able to recognize the resulting sync signal. But if your TV has a Vhold knob you should be able to adjust the rolling without messing it up for the other NTSC games or the TV broadcast. Ciao, Eckhard Stolberg

Actually PAL is just a different method for encoding colour information into an existing B/W TV signal. The different frequency and number of scanlines comes from the underlying B/W format. Therefore using a NTSC console on a PAL TV (or vice versa) would result in a colourless picture. Since PAL is mostly used on TV systems with a higher resolution than NTSC, PAL VCS games are programmed to generate a higher number of scanlines. So when you play a PAL VCS game on a NTSC VCS with a NTSC TV, the picture might roll, sice the TV can't handle the lower frequency. Playing a NTSC game on a PAL VCS with a PAL TV usually works fine with a stable picture. You would get black bars above and below the picture though. Due to the way how Atari implemented the PAL colour encoding in the VCS you won't get any colours, if the NTSC game does an odd number of scanlines. Some of Atari's older titles and many games from the smaller third party companies suffer from this. But even if you can get a stable picture with colours from a NTSC game on a PAL system (or a PAL game on a NTSC system), the colours will be quite different, since the PAL VCS and the NTSC VCS have a different palette. For most of the VCS games this doesn't matter much though. Ciao, Eckhard Stolberg

I think Atari is only the shirt sponsor for Olympique Lyonnais for their matches in the European competions. This Year OL is playing in the champions league. This league is made up of last year's champions of the national leagues plus some runner-ups from the bigger leagues. So OL has to be quite good to get in there. But even though there still is one game left for them in the first champions league round, OL has lost too often to qualify for the next round. So we probably won't see the Atari logo on their shirts too often anymore this season. Ciao, Eckhard Stolberg

The SAP player is basically a limited emulator of the Atari 800. It only emulates the 6502 and the POKEY. Most Atari computer games set up a periodic interrupt that happens once per frame or so. This interrupt executes a routine that writes new data to the POKEY registers, if nessessary. In this routine you can also increase or decrease the frequency devider value in every frame to simulate a vibrato effect, or create a volume envelope like in the C64. The SAP files basically countain these routines ripped from the games, plus some information for the player, like how often the routine has to be called or which game the routine was taken from. The exact SAP format can be found in the DOC directory of the sound archive, that you can download from the link that OldGuru mentioned above. I'm pretty sure that most of Beethoven's music can be found in MIDI format somewhere on the net. There might also be a free- or shareware version of a notation program available that lets you view MIDI files in sheet form. There were several music editors for the Atari 800 available. For example there was the "Antic Music Processor" in issue 12/88 and 06/89. I think you can download it in an emulator friendly format from the antic archive website or something similar. However I wasn't able to find any information about the file format of the AMP, so this program might not be too much of a help to you. There probably were better tools in the Atari demo scene anyway. And a note to OldGuru: As you probably have noticed yourself, the files in the SAP archive have been taken from PAL games, where the frame rate is 50 Hz. If you use one of these songs in your game, how do you prevent it from running too fast on your NTSC 5200? Thanks, Eckhard Stolberg

Pitfall II already is emulated in z26 and PCAE. The extra chip also provides the spite graphics data, so you can't easily remove the code that reads from the extra chip. You would have to do a major rewrite of most of the display routines, and I'm not sure that even then you would be able to achive a similar result. So I don't think you would be able to get this game going on the Supercharger or the Cuttle Cart. Caio, Eckhard Stolberg

Actually memory chips get measured in bits, because they don't nessessearily have to come in byte width. So measuring ROM based games in MegaBits isn't that far off. Anyway, I think the problem with a 7800 multi-cart is the bankswitching. Sean's 2600 multicart only offers linear games with up to 4KB in size. And I think the 5200 doesn't use bankswitching at all. For those games it's relatively easy to build a multi-cart with dip-switches out of an old game cartridge. But 7800 games used three different types of bankswitching. Also four games require onboard RAM and two games use an extra POKEY chip. To get all of that handled properly you'd need to design a special board and use a programmable logic chip, like Chad Schell did for the Cuttle Cart. This requires special knowledge and tools, and can get very expensive. If you knew you could sell maybe a hundret copies of this device, then a small production run a la Cuttle Cart might be possible, but the "build them as the orders come in" approach that Sean is using now is probably out of question. Also to make the design a little easier, you might have to blow up the size of all the games to the maximum used in 7800 games, which is 144KB. For 65 games that is quite a lot of ROM. As for a combined 2600/7800 Cuttle Cart, I don't see that either. AFAIK the Cuttle Cart uses almost all of the space on the programmable logic chip, and the next bigger chip is quite a lot more expensive. Also you probably wouldn't want to use an audio loading interface for games that big. A 7800 only RAM cart device, might be possible, but Chad Schell has already said on this board, that he currently doesn't have the time to design one, and I don't see anyone else willing and able to pick up the task. As for the price, the Cuttle Cart is selling for $100 and Chad isn't probably earning to much at that price. A 7800 cart would probably need about three times the RAM that the 2600 version currently uses. Also you would have to have a serial interface and you'd need to fit the POKEY chip somewhere on the board. I think there is a reason why Atari's RAM cart still costs $150. Ciao, Eckhard Stolberg

N is "Sur le pont d'Avignon". I don't know if there is an English text to this French song, but it would translate to something like "over the bridge of Avignon". Ciao, Eckhard Stolberg

In DASM you need to set up your code like this to reach your goal: SEG.U variables ORG $300 v_variable1 DS.B 1 v_variable2 DS.B 1 ... SEG code ORG $4000 l_StartCode: SEI ... The SEG command defines a segment for your code or data. For the 6502 this is usually unnessessary, since this processor doesn't use segments like the 8086 for example. But by defining a segment as undeclared (SEG.U) you can define variable or code space that doesn't get included into the binary, which is usefull for defining variables in the internal RAM.

You are right. The ST based devcart uses games in Motorola S-record format or in MADMAC .O format. And you need to have different files for each bank, if you want to use bankswitched games with it. The advantage of these file formats is that you can use the symbolic debugger in the devcart. But if one day someone really starts working on a new bankswitched 7800 game, I think we would have to look into the possibilities for creating a bankswitched RAM cart too. Ciao, Eckhard Stolberg

I'm not sure if this has already been brought up here, but the music video for Tom Novy's "music is wonderfull" is basically about a couple of people dressed up as Atari VCS joysticks dancing around some female dancers who are playing some generic arcade machines. Ciao, Eckhard Stolberg

The ROM works nicely on z26 1.50. Just as you described it for your console, including the screen flashes and sounds. Maybe you are just using the wrong emulator. Ciao, Eckhard Stolberg

quote: Originally posted by Mitch: I think the problem is poor coding. I tried several different guns on this game and none of them worked very well. So, how many lightguns do you have? I'm asking because I was experimenting with lightgun programming on the 2600 a while back. I wrote a little test program based on the gun detection routines from 2600 Sentinel. But even when I held my lightgun directly on the screen, the hits were detected a little bit away from the gun. So I changed the code to work nicely with my gun, but now I'd like to know if it was my gun that is off, or the one used at Atari for programming the games. Maybe you could try out my little test program on the 2600 or 7800 with all your guns, if I'd send you the binary? Thanks, Eckahrd Stolberg

It would probably be possible to build a RAM cart from this, but we haven't had access to one of these boards yet, so we haven't a design available for it. You would have to figure it out yourself. But a friend of mine is currently working on some other designs for better RAM carts. It will definetely still take quite a while before we have anything to release and I think all of his designs require different boards, but you might probably still like to wait before building yourself a RAM cart. Since the Scrapyard Dog cart is useless for this purpose, you might want ot follow Mitch's advice for building a Sentinel or KLAX proto, though. BTW Crossbow, did you get the e-mail I sent you some days ago regarding your timeout problem with 7800ctrl and Win2K? Ciao, Eckhard Stolberg

The "limited" in the company name might be a hint that the copany is from somewhere in the British empire. And with a programmer named Andrew Choi, who writes his name with the family-name first, I'd guess that UA is from Hong Kong. That would also explain, how the ROM for an unreleased game could get into a pirated multi-game system. If the company was from somewhere in south-east Asia, it might also explain why there are so many PAL clones of the Arcadia, even though the Emerson version wasn't much of a success, and why there were several games released for the system, that weren't available from Emerson. If Funky Fish was licensed properly from Sun Electronics, then someone who speaks Japanese could ask them, if they know anything about UA Ltd. The software devision of Sun Electronics is now known as Sunsoft, and on one of their webpages I think there was a message about how they even had their games on the early Atari consoles, which refers to Kangaroo, which was licensed to Atari. So there might be a chance, that they still have information from that far back available. Ciao, Eckhard Stolberg

Actually the company is from Germany. You can find out more about them on their homepage. Ciao, Eckhard Stolberg

The socket only has 24 pins, so it can only hold EPROMs up to 4KB. The switch might allow you to select between two 2K games on a 4K EPROM, it might enable/disable the inverter for the chip select line, so that you can use EPROMs and normal ROMs in this cart, or it might disable address line A11, so that you can play 2K EPROMs with games that are mapped in at $F000 instead of $F800. But as Dan has said, you'll only know, if you open the cart and look how the switch is wired. Ciao, Eckhard Stolberg

switch to bank 1: $1ff8 = 8184 switch to bank 2: $1ff9 = 8185 What do you need the decimal addresses for? Ciao, Eckhard Stolberg

The starpath binary only uses 6K of those 32K. A simple file compare wouldn't work in this case. But the starpath version of Rabbit Transit uses the supercharger type of bankswitching and also some of the supercharger RAM for selfmodifying code. If the Atari version is running on a normal EPROM cart, then the binary must have been modified. Ciao, Eckhard Stolberg

quote: Originally posted by -^Cro§Bow^-: Also notice that the errors in the hi bits are spaced evenly throughout the whole rom image. Interesting. Too bad it would appear this rom isn't working...here I was wanting a Scrapyard dog...oh well. Very strange indeed. It could be a problem with overspeaking between some of the address lines and one of the data lines. Maybe you should check all the solder joints and the connections. BTW, what board does this game use and how are the jumpers (labeled W#) set? And this is a used game, that has been working before, right? I'm asking because I once traded a shrikwrapped copy of Crossbow from a guy in Denmark which didn't work. The guy was nice enough to find me another copy of that game, which showed the same problems. So I opened one of the carts up, and it turned out that they soldered the wrong jumper close, so that the bankswitching wouldn't work and I was getting the graphics all messed up. After fixing the jumpers the game now works nicely. Ciao, Eckhard Stolberg

I don't think so. You'd have to buy a copy from Randy Criehfield and read out the ROM yourself, if you want to play their games on an emulator. Ciao, Eckhard Stolberg

Since it was brought up in this forum, I thought I'd let you know that we have fixed the colour changing problem in Desert Falcon and a couple of other things. As always you can get the latest version of z26 on John's site. Ciao, Eckhard Stolberg

It's not a PAL version, it's a bad dump. Did you try to dump it a couple of times in a row to see, if you would get different results each time? Anyway, comparing the ROMs shows that the differences are only in the higher bits of the bytes. This means either some dirty contacts or a timing problem when accessing the ROM, I think. Ciao, Eckhard Stolberg

Matt: Yes, I believe I have your prototype ROMs. Unfortunately some of the more interesting ones seem to be bad dumps. But if you like you can post screenshots of the others on your website now. Christian: Sorry, but I don't quite understand what you mean with your PC programming question. But the source code for z26 is available at the site mentioned above. Maybe you can find something usefull in there. Scott: The new ROMs are just the Degital Press version of Video Life and some NTSC/PAL variations of already supported games. The problem with Desert Falcon seems to have somthing to do with the automatic PAL detection. It seems that the game does some frames longer than normal, which makes the emulator believe that it is a PAL game. Untill we fix this problem, you can enforce the right TV type with the -c0 command line switch. When you use it, z26 will not try to autodetect the game. As for the other requested features, I'm not sure we'll try this anytime soon. We are currently still doing too many internal changes between the versions, so a state save feature might suffer from incompatible file formats. And the chating feature would probably require a lot of new code for the user inputs, and I'm not sure if John or I have enough time for that right now. Ciao, Eckhard Stolberg

OK, I guess you should have a look at Nick Bensema's site and download his "How to draw a Playfield" example. It is very well commented and demonstrates nicely how to get the TIA to display anything and still do some game game calculations. That would already answer a lot of your questions in part one. Also you should join the Stella mailing list, as this is where most of the VCS homebrew programmers hang out. You would probably get much better responses there than here. But now to answering your other questions: On 2: Yes you can make the moving objects as large as the screen. But you can also reposition them during the screen and get one sprite for top part of the screen and another sprite for the bottom part of the screen, that are essentially the same object. Kaboom uses that for the bombs for example. On 3: Yes, that is exactly how it is done. You can change any of the registers at anytime. That way you can change the shape or the colour of an object during the scanline. On 4: All registers are 8 bit wide. But some of them don't evaluate all of the bits. Writing to the unused bits has no affect. On 5: You can read the state of the joystick buttons directly from bit 7 of INPT4 and INPT5. However you can also enable the latching feature for these registers. If this is turned on and someone pushes the button and releases it, then INTP4/5 will report a pushed button as long as you don't disable the latching feature through the VBLANK register. Ususally it is not nessessary to use the latch feature, so you can just ignore this part of the manual. On 6: The only other devices that use the output on the joystick port are the Compumate Keyboard and the KidVid tape drive, AFAIK. But you probably won't be able to use either of them in your homebrew games, so no need to worry about that. On 7: There is no special manual on the driving controller. But this device just uses a quadrature encoder on the pins for left and right. On these pins you will see a signal like 00/01/11/10/00 etc. Depending on which way you turn the dial, it will cycle forward or backward through this list. A full turn of the dial has 16 state changes. Ciao, Eckhard Stolberg

I'm not sure if anyone here feels like continueing with this type of discussion today, but if any of you prototype owners feel like sharing some screenshots of your rare gems with us, I'd like you to know that we have improved the screenshot support in z26 for you now. You can get the newest version of z26 here. Ciao, Eckhard Stolberg