Eckhard Stolberg

@ Jet Boot Jack: The 320x192 mode was used in 7800 games, but only for text display. The introductory text in Karateka uses this mode for example. And several other games also use the 320 pixel resolution for displaying the score and status, while the rest of the screen is done in 160 pixel resolution. The reason for this is probably that the colour selection is very limited in these modes. You could easily do a high resolution chess game display with monochrome pieces, but games like that probably wouldn't have helped much to convice people that the 7800 is the more powerfull video game system. As for tile based / screen RAM based displays: The beauty of the 7800's approach is, that the MARIA could do both. You would have to add quite a bit of extra RAM for a really usefull screen RAM display though. You can set up the Display List to generate graphics line by line and read the data from the RAM, where you can manipulate it during the gameplay. But you can also set up the Display List in blocks of up to 16 scanlines, where the MARIA would read the data for the next line automatically. This combined with the indirect mode, where the data that the DL points to is interpreted as an index into a character/tile set, allows you to get a tile mode with 8x8 pixel tiles. But you could also get 4x16 pixel tiles or 16x2 pixel etc, depending on the screen mode. The only drawback is that all tiles would refer to the same palette. But you could either use the 160x4 screen mode, where you get 12 colours for your objects, or you could set up seperate DL entries for each tile, which would allow you to select the palette individually. Adding sprites to either type of display is more complicated than on the NES/SMS though, since you have to define them for each line-block seperately. But this also is the reason, why you can have so many sprites in one line. So, if you really wanted to, you could use the 7800 in much the same way as the other video game systems. Unfortunately that didn't seem to have helped the 7800 back then either. Ciao, Eckhard Stolberg

No, in this case 160x4 means 160 pixels with 4 bit per pixel. This would usually give you 16 colour choices for your pixel, but due to the way the palettes are set up in this mode, you only get 12 colours plus transparent. The 7800 has 8 sets of palettes with 4 colours each. But the first colour is always treated as transparent or background colour. In the 160x4 mode the 8 palettes are grouped together in two sets of 4 palettes to build two larger palettes with 16 colours each. But since the first colour in each of the four smaller palettes is transparent, every fourth colour in the larger palette is transparent too. This leaves you with 12 colours for your object. But you can use both 12-colour palettes for different objects in the same scanline, so you can have all 25 colours in the same scanline in this mode too. You could even put two objects with different palettes on top of each other, allowing free choice of all 25 colours for all pixels. But since the DMA isn't fast enough to handle two objects that large, this trick would only work for about 120 pixels. And since most games in the 7800 library were ported from arcade machines or homecomputers with more limited colour handling possiblities, it's no surprise that those games don't show the full potential of the 7800 in this field. Atari's development cartridge came with a colour tester demonstration program. It shows 16 colour blocks per scanline plus some text in a different colour. This is no game, and I don't know which display mode it uses, but I'm sure it doesn't pull off any increadible tricks to get that many colours in one scanline. Ciao, Eckhard Stolberg

Just some small corrections here: The 7800 can easiely display 24 colours (plus the background) in one scanline in different objects. And if you are talking about a pixel-by-pixel base without overlaying objects, you can still get 12 colours (plus the background) per scanline in the 160x4 mode. Two of the 320 pixel modes are pretty useless, as several pixels have to share the same colour. The two other modes are 320A and 320B. 320A allows monochrome objects where each object can choose from one of 8 colours. In 320B mode each object can have 3 different colours, and you chose between 2 different three-colour palettes. In both modes you also can set the colour for the background. And IIRC the C64 320 pixel modes were monochrome too. You could set a different colour for each character and sprite though. Only the 160 pixel modes allowed you to set 4 colours per character and sprite. But you could select the resolution of each sprite independently from the resolution of the background or the other sprites. Some games used that to create the illusuion of having a high resolution and lots of colours at the same time. Ciao, Eckhard Stolberg

Actually MESS does support the POKEY in the 7800 emulation. Ballblazer does all of it's sound output through the POKEY. You wouldn't hear anything without this chip. Commando on the other hand only uses the POKEY for the music. The sound effects are done through the TIA. I know this because I have tried both games on my POKEY-less RAM cart, and unfortunately these were the results I got. Ciao, Eckhard Stolberg

quote: Originally posted by King Atari: Geez Eckhard! How do you know this stuff?!?! Basically, I just read the manual. Ciao, Eckhard Stolberg

quote: Originally posted by Mitch: The reason it sounds odd is because the 7800 OS used 4K, leaving 48K for non-bankswitched games. Actually the 7800 boot ROM (16K for the PAL model due to the build-in Asteroids game) uses the same address space as the games. It copies some testing routines to the build-in RAM and then disables itself. And I think the largest linear address space for games is really 54KB. It can reach from $2800 to $FFFF. Ciao, Eckhard Stolberg [ 02-17-2002: Message edited by: Eckhard Stolberg ]

@Albert: 52KB is only the largest consecutive chunk of unused address space. There are some more empty spaces, that could be used for mapping in cartridge RAM, ROM or coprocessors like the POKEY. I think the reason for the strange size is that Atari needed an easy way to map in the internal RAM in such a way that it wouldn't interfere completely with 2600 games, which only have a smaller number of address lines to decode. This is important, because the BIOS needs to run in the RAM when it is checking which type the game is. The largest linear 7800 games use only 48KB, but bankswitched games went up to 144KB of ROM, or 128KB of ROM + 16KB of RAM. The Highscore cartridge uses some of the other free parts of the address space to map in it's 4KB of ROM and 2KB of battery backed RAM, though. I don't think packing the 7800 with the proline joypads would have helped much. Compared to the NES pads Atari's pads still feel very uncomfortable IMHO. @ Gunstar: The NTSC 7800 actually has a maximum resolution of 320x243 (PAL has even more lines), but just like with the NES and the SMS only about 200 lines are visible on a NTSC TV. The rest of the vertical resolution can only be used to set up some extra data to allow smooth vertical scrolling of large areas. The colour selection in 320 pixel modes is very limited. These modes are only usefull for text displays or low-colour games like chess. Many 7800 games use the 320 modes for displaying texts or scores and game status information. Also it is noteworthy that the horizontal positioning resolution is only 160 pixels. So for actual in-game graphics resolution both, the NES and the SMS, have an advantage over the 7800. The 7800 only has 25 colour registers. If you want to display all 256 colours at once, you have to rewrite the colour registers on a line-by-line basis, which limits the usability for real graphics. More than 25 (24 for the objects and 1 for the background) colours per line is rather impractical. The 7800 doesn't have any specific video memory per se. You just set up a list in RAM with the desription of what to display in each scanline, and then point the MARIA to this list. You can even add a large RAM chip to your cartridge and put the display lists there. The MARIA has some internal memory for keeping the pixels for exactly two scanlines though. But the programmer has no direct access to this memory. There are no real sprites in the 7800. All graphics are the same type. A display list, which contains all objcts to be displayed in a scanline, can be valid for a maximum of 16 scanlies, so that's the maximum vertical resolution for an object. An entry in the display list can define a maximum of 64 graphics bytes (in indirect mode). How many pixels a byte defines depends on the video mode that the 7800 is currently in. And if you set up the display list to define lots of one-byte objects, then the DMA has only time to display less than 40 different objects per scanline. You can set up the display list to have that many objects in each scanline though, as long as you provide enough RAM on the cartridge to hold that many data, since the 4KB internal RAM won't be enough for that. But if you do set up your display like that, then the 90% CPU availability probably isn't true anymore, since the DMA halts the CPU when it processes the graphics creation. Ciao, Eckhard Stolberg

HLIST is a 16-bit address, which you can't load into a 8-bit register. I think you are trying to generate the high-byte and the low-byte of this address here, right? DASM has special operators for this. The "greater-as" sign gets you the high-byte of a 16-bit values, and the "smaller-as" sign gets you the low-byte. (Sorry, but this message board doesn't allow you to post these characters, as it seems to interpret them as html code or something.) Ciao, Eckhard Stolberg

The 160x4 mode is pretty simple actually. The 7800 has 8 palettes with 3 usable colours each (colour 0 in each palette is transparent or background). In 160x4 mode you are grouping palettes 0-3 and 4-7 together. Usually the display list entry selects one of the 8 palettes for your object. In this mode only the highest bit is used to select one of the two palette groups. Each byte of graphics data specifies two pixels. The low-nibble of the byte lets you select one of the 4 palettes for either pixel, and the high-nibble selects the colour in the chosen palette. The left half of the nibbles is for the left pixel, and the right half of the nibbles is for the right pixel. So lets say you have a graphics data byte of %01_10_00_11. For the left pixel that would select palette %00 and colour %01. If you had chosen the first palette group in the display list entry, this would mean that the left pixel would use the colour from P0C1. Likewise the right pixel would use the colour from P3C2. If the display list entry would point to the second palette group, the colours would be P4C1 and P7C2. I hope this makes it a bit more understandable for you. Ciao, Eckhard Stolberg

quote: Originally posted by Thomas Jentzsch: AFAIK, the extra buttons of those controllers don't work with the 2600. Eckhard will know better. This is correct. The buttons on the 7800 Proline controller are wired, so that they will give the same signal on the 2600. On the 7800 you have to enable the two button mode for the joysticks as well, and this is not possible on the 2600. But somehow I don't think using the Proline controller and the driving controller together would work very well for most people anyway. Ciao, Eckhard Stolberg

OK, I tried out the new version, and I can say that you are not accidentally switching to b/W mode or something. The shodows of the bases are always visible in full colour. But the other part of the bases turn black, once they have been buzzing. After that they stay black and only turn white, when the button is selected. Maybe you are messing up the palette value for the objects, when you try to change their colour? Also the title screen still asks for the START button while expecting the SELECT button. And the game screen asks you to push the button to start a game, while it seems that you have to move the joystick to achive that. Ciao, Eckhard Stolberg

There already is the 160x4 mode which provides 12 colours for the graphics. (Colours 0, 4, 8 and 12 are transparent.) But since the 7800 has 24 colour registers, you can select between two sets of 12 colours each in this screen mode. The DMA isn't fast enough to cover a full line with both palettes, but about 120 pixels in 24 colours should be possible without any tricks. But when you asked about hires graphics, I thought you meant a 320 pixel mode. For those modes it would be very difficult to squeeze out more colours, since you need to proceed more data, and because the colour setection is very limited in all 320 pixel modes. Ciao, Eckhard Stolberg

Isn't KLAX one of those games that requires the SARA extra RAM chip? The PAL version definately is. Does your homebrew cart contain one of those? Otherwise that might explain, why it doesn't come up correctly. BTW, does anyone know how many levels the arcade version of KLAX has? I think it only has 100 levels too, so the VCS version is probably acurate in this respect. Ciao, Eckhard Stolberg

Wo wir gerade bei Atari Spielen auf deutschen Musiksendern sind: Vor einigen Wochen hatte MTV einen Hinweis auf einen Snowboard- und einen Skateboardwettkampf laufen, den die glaube ich gesponsort haben. Für den Snowboardwettkampf hatten sie eine Szene aus dem Skislalom aus der VCS-Version von Winter Games, aber mit einem Snowboarder statt des Skiläufers. Für den Skateboardwettkampf hatten sie die Halfpipeszene aus der VCS-Version von California Games, aber der Hollywood-Schriftzug war ersetzt durch einen Seefeld-Schriftzug, da der Wettkampf glaube ich in Seefeld war. Ciao, Eckhard Stolberg

While we're at it: There is another "did you know" item that says that the 2600 has 128 bytes of "screen" RAM. This isn't quite correct. The VCS has 128 bytes of gneral RAM. It doesn't have any screen RAM per se, unless you want to count the 8 TIA registers for half of the playfield, two player graphics, and the enable states for the missiles and the ball. And these can only hold data for one scanline. Ciao, Eckhard Stolberg

I think the distribution outside of Europe was done by U.S. Gold, who changed the name on many of the titles they brought to the USA. Maybe it was so that US customers wouldn't notice that they were just getting old Euro titles. They also changed "Barbarian" to "Deathsword" or "Thing on a Spring" to "Coil Cop". These games were distributed in the US by EPYX, which is where I think Atari got the 7800 rights for Nebulus/Tower Toppler and Jinks from. And this is also why the 7800 versions of these games were programmed by U.S. Gold in the UK. Ciao, Eckhard Stolberg

SECAM 2600s only do 8 colours normally. (There have been reports on some strange colour effects in some games). Also the Colour/BW switch will alway be read as BW. The BW switch itself still would allow you to turn off the colours in hardware though. There are no special SECAM 2600 games. Atari put a special SECAM colour mode into most of their PAL games, which gets selected via the Colour/BW switch. The French 7800 with the SCART output (there also are models with normal RF output in France) is just a modified PAL 7800. The PAL RF modulator circuit has be replaced with a special RGB daughter-board. I think khryssun had some fuzzy pictures of his Frech 7800 console including with the pinout of the RGB connector on his website. I don't remember the url right now, but a search in the AtariAge message board data base should help you to find it. BTW, another advantage of the SCART 7800 is that it doesn't suffer from the colour-loss problem, that the normal PAL 2600/7800 consoles have with some NTSC 2600 games. The colours would still be wrong, but at least they won't go away completely anymore. Ciao, Eckhard Stolberg

quote: Originally posted by jahfish: no, there's may ways of playing pal games in usa. you can make a modification on your console, buy an adapter, use a TV where you can fix the rolling image, or just use a TV or a VCR that supports both modes .... there's many way to easily solve the problem can somebody stop those US collectors that always try to keep PAL games in the dark? No, Mitch is right about this. 7800 consoles won't play 7800 games for the other TV standard properly, no matter what. On the 7800 it's the console that sets the number of lines per frame and the number of frames per second. A PAL 7800 will always do 50 frames at 312 lines, and a NTSC 7800 will always do 60 frames at 262 lines. The games have to set up their display accordingly, or there will be problems. The best result you will be able to get is a a picture that has the wrong colours, that is positioned either too high or too low on the screen and that plays at the wrong speed. But most games will just crash completely. For NTSC users there is also the difficulty that the NTSC 7800 checks a signature key in the game ROM. If this isn't present (like in all PAL games) the 7800 won't allow the game to switch into 7800 mode. You can get around this by replacing the BIOS chip inside the 7800 console, but given the fact that the results you would get from most PAL games are rather limited, it might not be worth it to most people. The only way to play PAL 7800 games is on a PAL 7800 console connected to a PAL capable TV. And the only way to play NTSC 7800 games is on a NTSC 7800 console connected to a NTSC capable TV. The rolling picture problem that you mentioned exists only for PAL 2600 games played on a NTSC 2600/7800 console. For that combination your suggestions would work. Ciao, Eckhard Stolberg

Hello Christian, I too hope that you will get well soon, and that you don't have too hard a time until then. Gute Besserung , Eckhard Stolberg

I don't have a Falcon or know how build a VGA adapter, but I have a magazine with a Falcon test, that says that the Falcon is supposed to come with an adapter for connecting it to VGA monitors. So it should be possible. Also the magazine described the monitor connector on the Falcon. Maybe this helps you a bit to figure out the connection yourself. The connector is a male DB19. The top row of pins is numbered 10 to 1 and the bottom row is numbered 11 to 19. The pins are: 01 Red 02 Green 03 Blue 04 Mono/Overlay 05 GND 06 Red GND 07 Green GND 08 Blue GND 09 Audio Out 10 GND 11 GND 12 Composite Sync/V 13 Horizontal Sync 14 Vertical Sync 15 External Clock Inp 16 External Sync Er 17 +12V 18 M1 19 M0 Ciao, Eckhard Stolberg

Ob das der ist den du suchst weiß ich nicht, aber im hamburger Telefonbuch steht Klaus Ollmann immer noch drin. Zu Ataris aktiver Zeit war ich nie in der Bebelallee, aber vor einigen Monaten habe ich da mal vorbei geschaut. Nummer 10 ist ein großes zweigeschossiges Backsteinhaus. Als ich da war standen am Briefkasten und an der Klingel keine Namen dran, deshalb weiß ich nicht, wer da jetzt drinsitzt. Allerding glaube ich das Atari seine Büros vorher auch schon mal an einer anderen Adresse in Hamburg hatte. Im ST Magazin stand mal drin, dass Jack Tramiel in 1985 einen gewissen Les Player nach Deutschland geschickt hat um die Firma zu sanieren. Der hat den Laden dann gleich ganz zu gemacht, und mit drei Ex-Commodore-Deutschland Mitarbeitern in Raunheim neu angefangen. Übrigens, die Firma Dynamics gibt es auch immer noch in Hamburg. Die haben damals u.a. die Competition Pro Joysticks in Deutschland vertrieben. Ob das auch die Firma ist, die die Bomb Spiele unter ihrem eigenen Namen verkauft hat weiß ich nicht. Aber wenn ich jemals eins von den Modulen auf dem Flohmarkt finde, so dass ich was zum vorzeigen habe, werde ich bestimmt mal fragen gehen. Ciao, Eckhard Stolberg

quote: Originally posted by MattyXB: Jr. long Rainbow, Jr. small Rainbow, Jr. black. Just a small correction: the small rainbow Jr. came out before the big rainbow Jr. I think it was 83/84 for the small rainbow and 86/87 for the big rainbow. Ciao, Eckhard Stolberg

BCD numbers are really easy. They just store one decimal number per nibble. So one byte can hold numbers from 0 to 99. When the decimal bit is set you can add and subtract these numbers in decimal mode. If you have a score of $09 $99 $99 for example and you want to add $00 $00 $01 to it, the result in decimal mode would be $10 $00 $00. Then you can use your method for converting these into displayable characters, or if you have more processor time than ROM space, you can mask out the 6 nibbles individually and convert them to ASCII by adding $30 (in hex mode) to them. Ciao, Eckhard Stolberg

quote: Originally posted by -^Cro§Bow^-: I just feel that the Infograme could use the Atari Logo and name on the old rereleased arcade cabinets and still keep the image of the Atari success without the Atari nastiness... But the rights to the Atari name and logo for arcade usage still belong to Atari Games which still belongs to Midway. And since Midway felt the need to change the name of their Atari Games devision to Midway West when Hasbro reanimated the Atari name for their computer games, Midway probably wouldn't be too open for suggestions by Infogrames. And I don't think they could have used a 2001 copyright on the rereleased arcade games, like someone in a post further up suggested, as that might have been a risk for some of their copyright claims. Ciao, Eckhard Stolberg

The 7800 games that probably were never released in PAL format are: Tank Command and Water Ski, as Froggo was a too small company to afford releasing games in foreign markets Summer Games and Winter Games, as these were the only games that required 16K extra RAM which I think was quite expensive back then Realsports Baseball and Touchdown Football, as these sports never were really popular outside of the USA Rampage and Robotron (I'm not sure about the reason for not releasing these, but I think it might be possible that the licenses Activision and Atari had didn't cover regions outside of North America, and the 7800 wasn's selling well enough to get a new one.) Ciao, Eckhard Stolberg