Atari SS1000 "Sylvia"

[maiki]

As for the graphics and memory... in 1980-81 nobody was thinking in "bitmap" terms meaning it would be enough... if I am not mistaken, even Nintendo NES has only 2 kB of video RAM... sprites and tiles... this is the way to go... and has always been...

[kool kitty89]

I'm probably asking a stupid question, but wasn't this when Atari changed CEOs? In it's own right, it sounds like a remarkable console. But, isn't it also possible that, since Atari sued GCC at one point, that GCC might have agreed to help with the console? Given the fact that Sylvia and the 7800 sound similar, it just makes since. Either that, or GCC picked up the project after it was put aside in favor of the 5200. Maybe at one point, GCC was attempting to enter the console market and found out that they didn't have the funds to go it alone? Just some food for thought.

No, Kassar was forced to step down in summer of 1983, so about 2 1/2 years later and well after the 5200's release. The7800 was an independent project started by GCC and then presented to Warner, MARIA has no ties to previous Atari designs, unlike Sylvia's Super TIA and ANTIC derivative. (note that GCC apparenty considdered enhancing TIA initially -namely adding more sprites, but dropped that idea early on)

 

It seems like Atari realized the 3200 design was taking too long and had to get somign out fast with mounting competition from Mattel (followed by Coleco, but that hadn't been a concern when the decision was made to scrap the 3200 afik). Looking at the 5200 itsself, it's an unnecessarily convluted adaptation of the 8-bit line, and the rushed timetable doesn't account for it either.

 

As for the graphics and memory... in 1980-81 nobody was thinking in "bitmap" terms meaning it would be enough... if I am not mistaken, even Nintendo NES has only 2 kB of video RAM... sprites and tiles... this is the way to go... and has always been...

Weren't there a fair number of A8-bit game using the higher resolution grapnics modes though? (not text modes) Given they were uning ANTIC (or a very similar derivative), the vidoe modes should have had similar limitations to the 8-bits. Hmm, can ANTIC get character data directly from ROM? Given the 8-bit's shared bus arrangement, I'd immagine ANTIC would have access to cart ROM, but I don't know for sure; if that's the case though, it should work OK for a fair number of 8-bit games. The shared bus on the 7800 worked that way I think. (either MARIA or the CPU could grab data from ROM, unlike other platforms with dedicated video and CPU busses -usually with the CPU being th eonly one connected to the cartridge space)

Still, with the 8-bits using DRAM, and naturally the 5200 doing the same, I don't see why they wouldn't have gone with 16 kB of DRAM like the 5200, it should be cheaper than 2 kB of SRAM. (again, unless the greater speed of SRAM was necessary for other resons) If they wanted to convert soem of the more memory demanding 8-bit computer games using the bitma modes, the only option would be RAM expansion, most liekly on-cart. (which would have significant cost implications)

 

As for the NES, while it had separate CPU and video busses, and only 2 kB for video and CPU (each), it had the very large cartridges with lots of expansion capabilities, in this context, namely the video bus would be important. (I think there's also a general expansion bus in addition to the main CPU bus as well) The 2kB of VRAM in the NES is hardly enough for most games, thus it uses VROM (or sometimes VRAM) on the cartridge PPU expansion bus to suplament this. In the NES's case it doesn't have any direct bitmap modes at all, just the tilemap (character) display, so that comparison with the 8-bit/5200 doesn't even matter. (for a few game that did need a direct bitmapped display, that needed to be converted to the cell format, so a bit of a pain for that, though there were few games like that -StarGlider and Elite would be one I think, using wireframe graphics, better examples would be polygon based games on the SNES or Genesis)

Again, if ANTIC can get data directly from the cart, the RAM limitation doesn't matter quite as much.

[A.J. Franzman]

Voltrax SC01 Speech Synthesiser

VOTRAX (speech chip) not to be installed.

Just a minor FYI Curt, it is VOTRAX with no "L" (your webpage has the same typo).

[HARMIK]

Thank you again Curt for all your hard work and effort, I really cant thank you enough.

 

Would love to know more info on this what would it have been like compared to the 5200 overall. Also why did the programmers hate it so much, or maybe they didn't. Maybe one or too programmers were shown a very early buggy little documentation version of it and said it was to hard. And it just snowballed into it was to hard to program for as we believe today.

[ATARI7800fan]

Great work. would it be possible for someone to come out with the 3200 and have it as just a homebrew console, with the same case and controllers as the pictures of course. I would defiantly pay big to have a version of the 3200,just to see what the console is made of.

[keilbaca]

I think it's time to reboot Carmel.

 

http://www.youtube.com/watch?v=BP0mi4oMRpo

[Wickeycolumbus]

Great work. would it be possible for someone to come out with the 3200 and have it as just a homebrew console, with the same case and controllers as the pictures of course. I would defiantly pay big to have a version of the 3200,just to see what the console is made of.

 

I'd pay big for just a bare PCB. Getting an unreleased Atari console released would be the coolest thing ever.

[kool kitty89]

Did anything more ever come of this in terms of technical details?

 

I picked up a copy of Curt and Marty's "Atari Inc. Business is Fun" a few months ago, and found some interesting details reguarding the overall situation for development and cancellation of Sylvia, but not added technical details of any kind. (or even a general idea of how it would have compared to the VCS and 5200/A8 hardware)

 

The book also mentions Sylvia was planned to include 8 kB of RAM and not the 2 kB of SRAM referenced in the schematics linked to in this thread (on Atarimuseum). If that's not a typo, I'd have to wonder if they were switching to DRAM for the later design phases of the Sylvia project given that 8 kB of SRAM would have been kind of pricy for the sort of market the 3200 would be targeting. (the 7800 settled for just 4 kB of SRAM over 2 years later)

[Godzilla]

I love info like this!

 

Thanks for sharing.

 

Were there are demos/prototype games in development for this system?

[Kurt_Woloch]

Sorry for reviving yet another thread, but I just yesterday read about the prototype 3200 / SS1000 (as it's called here) system and wondered what it might have been like, gathering as much data as possible.

 

Seems actually like a type of downgraded Atari 400, or 5200... Curt said it shares the ANTIC chip with those systems... it's called FRANTIC here, but it's actually the same. However, there's a STIA in place of the TIA, CTIA or GTIA. I mention the CTIA and GTIA here because ANTIC was created in order to interface with the CTIA/GTIA, so the STIA must have been engineered to interface with ANTIC (FRANTIC) in the same way. Knowing this, I tried to understand the following Wikipedia pages:

 

http://en.wikipedia.org/wiki/ANTIC

 

and

 

http://en.wikipedia.org/wiki/CTIA_and_GTIA

 

which describe the operation of those chips in great detail.

 

Now on the 8-bit systems, ANTIC is the chip that provides the DMA, while the GTIA and CTIA just provides control registers and a static display, like the TIA does. Therefore, the ANTIC would provide roughly the same capabilities as found on the 8-bit systems... tiled or hi-res display modes with horizontal and vertical scrolling, display list processing and DMA for 4 players and missiles each. Sadly, for this kind of operation 2K of RAM is awfully low since the player/missile data, as laid out for the ANTIC, already take up 1.25 KB of RAM. So there's only one way of defining the base address (at the start of the RAM), and then you have the missile and player data from bytes 768 (relative to the RAM starting address) to 2047, leaving only strips of bytes free where the non-displayable lines are, and you probably need much of the other RAM for the tilemap... you can't even display a full 24x40 character map if using missiles because the last lines would overlap with the missile graphics.

 

One obvious difference of the 3200 to the 5200 would be the omission of the POKEY chip, still relying on the RIOT for sound (and probably additional RAM). Other differences would come from replacing the CTIA / GTIA by the STIA. Maybe the STIA was merely combining the capabilities of the TIA and the CTIA/GTIA into one chip in order to add 2600 backwards compatibility? The differences to the CTIA/GTIA must not have been too great in order not to break compatibility to the ANTIC interface. ALl in all, to me the 3200 system seems to be more similar to the 5200 than to the 2600 from its capabilities, so maybe the question should be what's the difference to the 5200 rather than to the 2600?

Edited April 3, 2015 by Kurt_Woloch

[tschak909]

There is a talk that happened at PRGE 2013, when Rob Zdybel and Bob Smith made passing mention of the Super Stella:

 

https://youtu.be/fmqzybUe9m4?t=7m52s

 

Where Rob talks about the reasons that Super Stella was canned, the big one being that the DMA fetch for sprites was badly implemented: Sprites could not overlap, due to the NMI being used to implement the reset for the sprite refresh. This made games that re-used sprites at different points on the screen problematic, because potentially overlapping sprites could cause a race condition that multiple NMIs could be fired before the NMI service routine had completed (for anyone who doesn't know 6502 internals: non-maskable-interrupts CAN NOT NEST on the 6502, and only one NMI can be serviced at a time, if another NMI happens at the same time, it will summarily be ignored.) So, in overlapping sprite cases, The sprite would fetch its data out of memory, ask to be done by raising NMI, and the service routine would either not fire at the right time, or not at all, meaning the DMA fetch doesn't stop, meaning, you get a nice vertical bar of crap after your sprite, or worse, fall off into the hardware and strobe a register and crash. It was a serious bug, and would probably would have been fixed had Doug Neubauer stayed around, but it never got fixed, and nobody wanted to touch it, so... the engineers quietly killed it by attrition.

 

-Thom

[Kurt_Woloch]

OK, I watched this video, and they're actually talking about two issues... the first one was, as you say, the sprite DMA (actually, I think it would be called player DMA because that's what sprites always were called at Atari). As far as I understand it, you could set a sprite to start at any scanline, tell the chip how many lines to display, and the chip would fetch a byte per line from memory until that number of lines was reached, and at that point, it issued a NMI. It's then the task of the CPU to decide if another sprite should be displayed in that slot, possibly in another column... basically, it does what would be vertical repositioning on the 2600, only that it doesn't have to feed bytes into the chip in every line because the gets them by itself. The problem is, there were four sprites (as there are on the GTIA), and each sprite would fire an NMI when it was through drawing. And the CPU would have to be finished servicing one NMI before another one happens. Now if two players end on the same line, this won't work because there are two NMI's at the same time. Apparently the chip normally had a register which would tell which sprite caused the NMI, but in this case, it only contained one of the affected numbers, so the CPU would have to figure out by itself that actually multiple sprites would need to be serviced. Well, I can imagine that this is called "difficult to program for".

 

The second problem they talk about was that the sprites came in pairs, and there was a "master" and a "slave" sprite sharing some registers (Kinda reminds me of the Amiga where two sprites share the same color registers). In this case, it means that the "slave" sprite was supposed to end before the "master" sprite, or else it would be called finished by the chip when the master sprite had finished drawing (maybe there was only a way to tell which PAIR had finished drawing, not which single sprite).

 

Now, if they really used the ANTIC for this chipset, this means further headaches because the shape of the sprites is still laid out in memory so that the ANTIC gives the STIA an address to read the sprite data from which is basically the line number plus a page offset for each sprite / missile. This means that when moving a sprite up and down, its data has to be moved in memory, and in addition to that, the CPU has to have a plan which sprites are shared. Granted, it has to do the same thing on the Atari 800, and it has to reuse the sprites by itself because it doesn't get an NMI when a sprite is finished. So the NMI thing should have made things easier for the programmer, but it turned out it didn't. Maybe it would have been feasible to ignore the NMI or tell the chip not to issue NMI's (if this was possible) and manage the sprite reusing in software, as it's been done on the CTIA / GTIA. On the Atari 800 I noticed that actually the players/sprites weren't really widely used, especially later in its life, because you could do so much more with the playfield graphics. A similar thing happened on the Amiga where sprites are also more complicated than to just draw them into the bitplane graphics. The sprites were much more widely used on the Atari 2600 and the Commodore 64 because they had better capabilities (well, on the 2600 at least better than the background graphics) there.

[+JAC!]

Since Curt's page is down, here's a link to the archive:
https://web.archive.org/web/20160618222211/https://www.atarimuseum.com/whatsnew/2010-JAN-25.html

 

 

[amidarman]

Here's some clean copies of those that I found online.

[Varanis Ridari]

I saw a video on this thing and they mentioned a flaw in the way this system handled sprites.

 

Something to the effect of if they touched or overlapped for any reason, the game would crash.

 

That, and all the politics involved with the company losing money, changing hands and directions, scuttled them from working on it further.

[ubersaurus]

Might've been my video! When I interviewed Bob Smith back in 2021 this is what he said:

 

Quote

 

Then I did some more code-- Here's is another awful story. I did test code for the proportional joystick that they wanted to put on to the 7800 [Actually the Super Stella; Bob got the system names mixed up – Ed.]. The joystick that fit on the 2600 was basically five buttons. One button for each way you push the joystick and one button that you had on your thumb, right? That you pushed with your thumb, so five buttons. The proportional joystick would tell you how far you move the stick in any direction. To do that, they basically had potentiometers, rheostats, something that would give you that proportionality.

The downside was, every time you read them, the reading was slightly different. Even if you held the stick as steady as you could, when you read every frame, you would get a different reading. If you are reading it directly, basically you get a jitter. You wound up having to average the position over several frames, which made the stick very sluggish. The nice thing about the five-button joystick is you got your response immediately and that means in one-sixtieth of a second. Any time you were averaging or using multiple frames, it got sluggish, more sluggish and more sluggish. I wrote the code for the proportional joystick and I wrote the memo that said, "This thing is useless. Kill it."

I don't know what they did because I was gone by the time all this came out. Then the next thing I did, this was while I was supervising, was they were doing 7800 and it was all in wire wrap. You know what wire wrap is? Essentially, they put components on a circuit board and have long leads on them and then wrap it with wire. The chip was made into probably a solid tube about two feet wide, about three feet tall, and these were all circuit boards that were all wire-wrapped. Unfortunately, the funny thing about wire wrap is sometimes the connections don't stay that good, so if it starts misbehaving, you hit it hard with your elbow and that sometimes fixed it.

Anyway, I was doing test code with a wire wrap 7800, and the chip designers had designed this new chip and it was going to replace the 2600. It was called 7800. It was an obvious outgrowth of the 2600. We still had sprites, players, but now a lot of it was in hardware. Every time a sprite finished displaying and caused an interrupt, which would give you control and you could set it up for the next time, reuse and so on. The 2600 had no interrupts.

Anyway, very fancy, and I was writing all the test code and so I said, "We're going do a baseball game." I get test code for a baseball game. It had really nice bitmap, a really nice bitmap. It had nice high-res background and it had all these reusable sprites, so you can get nine players on the screen.

Then, I was doing code and I discovered a case that an interrupt would happen, somebody would pick it up or the code would pick it up, and they would not be able to figure out who did it, which would completely just blow things up, completely. [chuckles].

Interviewer: Oh, jeez.

Bob: Completely. I wrote the memo that killed that chip and I felt bad about it afterward, but I just said, "Okay, here is what I found and here's the situation where you can get an interrupt caused by this player display system and being completely in the dark as to how to handle it." So they killed the chip. We are talking about a year or two of work involving chip designers, and they were not happy campers.

Interviewer: I can see why they wouldn't be, but you know.

Bob: I've had projects shot out from under me before and that's the way it is. Nobody like it but it happens.

 

I'm pretty sure both Bob Smith and Rob Zdybel have talked about this issue in their Portland Retro Game Expo appearances, if you want to check out those panels sometime on YouTube.