C64 - A reappraisal 2017

[carlsson]

So in the best of worlds, Atari might've been both the company "causing" the video game crash, and "fixing" it a little later with a new generation of game systems, perhaps before Nintendo came along (and Atari's potential licensing of the NES if it wasn't for the ADAM Donkey Kong yadda yadda).

[Nebulon]

I'm familiar with history documented at http://www.atarimuseum.com/computers/8bits/xl/1450xld/1450xld.html

 

I'm making the assumption Atari without Jack would have keep the 1450XLD but instead of using FREDDIE use the Amiga chipset. And an obvious follow on would be a 68K processor with the Amiga chip set likely called a new name or something like the 1600ST ( ST for sixteen/thirty two).

 

http://www.atarimuseum.com/articles/mickey.html

 

"one was designated the Atari 1650XLD which would have been 6502 CPU based, the other was the Atari 1850XLD which would have been based on the Amiga Lorraine."

 

 

Amiga OS is 32-bit so (assuming Atari also opted for a 32-bit OS for the 1850XLD) that means the 6502 version would have to have a different OS written for it.

[thetick1]

 

http://www.atarimuseum.com/articles/mickey.html

 

"one was designated the Atari 1650XLD which would have been 6502 CPU based, the other was the Atari 1850XLD which would have been based on the Amiga Lorraine."

 

 

Amiga OS is 32-bit so (assuming Atari also opted for a 32-bit OS for the 1850XLD) that means the 6502 version would have to have a different OS written for it.

 

OK that is exactly what I wrote I just used the wrong historical names. No reason why a 6502 based processor could not be used with a modified Amiga Lorraine chipset. It is bit ridiculous to argue hypothetical possibilities though.

 

Actually the 68K processor implements a 32 bit instruction architecture but a 16-bit data path to external components. Thus why Atari chose name Atari ST ( Sixteen/ Thirty two). So depending how you define a 32-bit machine the 68K based Amiga or Atari ST is either a 16-bit or 32 bit machine. The original Amiga OS clearly supports the 32-bit instruction architecture but only 16-bit external data architecture.

Edited February 23, 2018 by thetick1

[Bryan]

The 1650XLD was rumored to have an Intel chip for DOS compatibility.

 

Sure, the Amiga chipset could be modified for 8-bit systems but what good is Amiga hardware in a system that can only see 64K without bank switching? A 320x200x16 color screen is 32K just by itself. Once your graphics get big, you need a big address space.

 

Who knows what Atari would have done if the crash hadn't happened. They sure wasted a lot of money exploring all the possibilities.

[Bryan]

Only a little bit on topic...

 

I would love to have a crowdfunding campaign to design an 8-bit system from the ground up. Design the NMOS chips and everything using ONLY technology from around 1980 (if there's not enough money for chips, then workalike FPGA DIP's could be used in the board). It would be fun to deliver boxed computers from an alternate history, but based on the architecture ideas we'd most like to see in a single machine.

 

Then we'd write a fictional backstory for the machine and its parent company.

[fujidude]

If your urine glistens in all the colours of the rainbow, perhaps you should see a doctor?

 

Nahh, it's what every true computer fan should strive for!

[VladR]

Sure, the Amiga chipset could be modified for 8-bit systems but what good is Amiga hardware in a system that can only see 64K without bank switching? A 320x200x16 color screen is 32K just by itself. Once your graphics get big, you need a big address space.

Unfortunately, this problem certainly didn't stop the Jaguar. What good is it to me that it can address 2 MB, if the GPU is fricking four kilobytes ?

- And it doesn't support stack, so you gotta reserve some space for emulating stack.

- And every variable you use is 32-bit integer (otherwise you fall down to 68000 performance levels once you start extracting separate bytes from those 32 bits, or if you load from main slow RAM),

- thus you burn through those 4K almost instantly

- you fit much less code than on 6502, as you don't have 8-bit instructions like INX/INY/CLC, they're 16-48 bits (2 - 6 Bytes)

- don't get me started on how the GPU performance gets butchered once you start splitting&blitting code chunks to the cache using the infamous 64-bit blitter mode...

 

If I had it my way, I'd rather limit jaguar to 64 KB bank-switching (like on 6502) from those 2 MB, but have those 64 KB for GPU cache. This alone would incredibly upgrade the performance capabilities. If Atari 800 is able to switch banks within 1-2 cycles, I for sure wouldn't mind those cycles if ObjectProcessor would switch to a different bank for each bitmap it processes and displays.

 

Besides, the memory controller in Jaguar burns few cycles anyway upon crossing the 64-KB boundary, so again - what good is it then again (other than for hibernated-turtle-slow 68000 code)? It only appears as a linear 2 MB system (and only for the arguably hypothetical corner case of 68k coding), but at a significant performance cost the moment you start crossing the 64 KB boundaries with your data (which can be very easily tested).

 

I would love to have a crowdfunding campaign to design an 8-bit system from the ground up. Design the NMOS chips and everything using ONLY technology from around 1980 (if there's not enough money for chips, then workalike FPGA DIP's could be used in the board). It would be fun to deliver boxed computers from an alternate history, but based on the architecture ideas we'd most like to see in a single machine.

Eclaire XL is attempting something similar, though obviously not to the degree that you want (via FPGA). But I hear ya and agree.

 

I don't believe we'd be able to find a hundred people, though...

 

 

 

A 320x200x16 color screen is 32K just by itself. Once your graphics get big, you need a big address space.

No, you don't. Now, it may be more convenient from coding perspective, but you don't really need it.

 

I'm going to see soon myself, as I'll be working with Eclaire's 4x Antic modes (e.g. 320x192x16), but basically the rasterizer needs to be able to work in zones and access one zone at a time. There's some overhead, of course, but same technique has been used at original XBOX where they had to split rendering in certain gfx modes into zones.

 

Besides, one bank is 16 KB, so we're talking only 2 banks here anyway, so the overhead will be minimal and highly likely masked by fake clipping (e.g. it costs the same amount of cycles whether I clip against scanline 96 or 192 - does the rasterizer really care if that scanline is the last one in bank one or two ? I could ask, but suspect I know the answer to that already ), thus very likely - free.

[Deteacher]

Me, personally, I love both machines. I've always thought the Atari had better sound (4 channels, vs. C64's 3 channels) but games on the C64 look better. Also, like the OP said, there are some games that were strictly for the C64, like Space Taxi and Dino Eggs.

 

I prefer the Arcade ports on Atari. Pac-Man, DK, etc. are so much closer to the arcade than the C64 versions. However, the C64 versions of Ultima III and IV have the soundtracks, which the Atari versions are sorely lacking.

 

All in all, I can't pick one over the other. Everyone should own both.

Edited February 23, 2018 by Deteacher

[Bryan]

Unfortunately, this problem certainly didn't stop the Jaguar. What good is it to me that it can address 2 MB, if the GPU is fricking four kilobytes ?

- And it doesn't support stack, so you gotta reserve some space for emulating stack.

- And every variable you use is 32-bit integer (otherwise you fall down to 68000 performance levels once you start extracting separate bytes from those 32 bits, or if you load from main slow RAM),

- thus you burn through those 4K almost instantly

- you fit much less code than on 6502, as you don't have 8-bit instructions like INX/INY/CLC, they're 16-48 bits (2 - 6 Bytes)

- don't get me started on how the GPU performance gets butchered once you start splitting&blitting code chunks to the cache using the infamous 64-bit blitter mode...

 

Yeah, I was a Jag developer for a short while. It was an ambitious design slaughtered by the need to keep it all really cheap (and by insufficient hardware testing). Even though you could do some fast things with it, nobody in the game industry has got the time to figure out how to squeeze every last ounce of performance out of a complicated architecture. Especially if the docs are sparse.

 

No, you don't. Now, it may be more convenient from coding perspective, but you don't really need it.

 

Well, when you saddle a 6502 with a screen that big you've got two problems:

 

1. Most of your RAM will be consumed with graphics. Double buffering will consume all of it.

2. It's slow to update large bitmaps with a slow processor. This is one of the things that hurt the Apple IIgs. It had modes like an ST, but couldn't draw anywhere near as fast.

[thetick1]

 

Yeah, I was a Jag developer for a short while. It was an ambitious design slaughtered by the need to keep it all really cheap (and by insufficient hardware testing). Even though you could do some fast things with it, nobody in the game industry has got the time to figure out how to squeeze every last ounce of performance out of a complicated architecture. Especially if the docs are sparse.

 

 

Well, when you saddle a 6502 with a screen that big you've got two problems:

 

1. Most of your RAM will be consumed with graphics. Double buffering will consume all of it.

2. It's slow to update large bitmaps with a slow processor. This is one of the things that hurt the Apple IIgs. It had modes like an ST, but couldn't draw anywhere near as fast.

 

All true but I thought I typed modified Amiga chipset which would imply a coprocessor to handle the additional resources needed for the improved graphics. The economics might not make sense as it might be cheaper just use a 68K then a 6502 (more likely 65816 ) with an added coprocessor with the Amiga chipset.

Edited February 23, 2018 by thetick1

[carlsson]

It is true that the first 65C816 was finished in March 1984, which is right in time for when Atari was into the Amiga, but I have no idea if WDC's chip was cheaper than Motorola's, in particular if the Amiga chipset already had been developed in conjunction with the 68000. We probably should not neglect the NS 32016 as well, since Atari in real life was considering that chip for the ST line before they did like Apple, Sinclair, Commodore and went with the 68K line.

[thetick1]

It is true that the first 65C816 was finished in March 1984, which is right in time for when Atari was into the Amiga, but I have no idea if WDC's chip was cheaper than Motorola's, in particular if the Amiga chipset already had been developed in conjunction with the 68000. We probably should not neglect the NS 32016 as well, since Atari in real life was considering that chip for the ST line before they did like Apple, Sinclair, Commodore and went with the 68K line.

 

WDC was cheaper but that may have more to do with the existing infrastructure for mass production.

I think it is pretty well documented National Semiconductor would not be able to meet demand.

Edited February 23, 2018 by thetick1

[carlsson]

But anyway, would an imagined 1450XLD that contains a 6502 or 65816 plus rest of the Amiga chipset be possible to simulate the Atari 8-bit line? While conceptually I understand Jay Miner et. al went in the same direction with both systems, unless you can set up display lists or whatever on the Amiga that will correspond to what programmers expect from e.g. the 800XL, it is a bit of a moot point. In particular as we already concluded that by 1984, the 8-bit computer generation was starting to dry out. Atari might have "milked" their existing tech for another generation or two like they really did, but releasing two different systems featuring the same custom chipset but incompatible CPUs, and which neither was backwards compatible anyway, would have confused the market even more than a souped-up C64-II had at the same time.

 

For that matter, Commodore were already developing the 900 series before they got their hands on the Amiga so likely that had evolved to their next generation systems. No need to think that they'd be the last one stuck with 8-bit computers in a world where everyone else had moved onto 16/32-bit ones.

 

Edit: Oh, I saw you proposed a 68K machine with TED graphics for Commodore's next model. That sounds like one step beyond the Sinclair QL but not by much.

Edited February 23, 2018 by carlsson

[Foebane]

 

 

I believe "Commodore: A Company on the Edge" by Brain Bagnall has some good quotes from Al Charpentier on the design of the VIC-II sprites. He said they looked at all the machines on the market with sprite capability (TI-99, Intellivision, and Atari) and analyzed the good and bad points of each system before designing the VIC-II sprites. So, yes the Commodore designers were inspired by Atari's sprites. And it is not surprising the C-64 has a better sprite system, given the number of examples Commodore had to work from.

 

Answer me one question: Why are the C64 sprites 24 hi-res (or 12 lo-res) pixels wide and 21 pixels high? Why specifically 21? Why not 24? Some kind of hardware limitation?

 

On the other hand, I remember trying to program sprites on the A8 back in the day and finding it ridiculously awkward for vertical movement, and then reading about how it was much more easily done on the C64 in both X and Y directions, and I was impressed. I can see why so many programmers loved the sprites.

[TMR]

Answer me one question: Why are the C64 sprites 24 hi-res (or 12 lo-res) pixels wide and 21 pixels high? Why specifically 21? Why not 24? Some kind of hardware limitation?

24 pixels across is three bytes so multiply that by 21 and you get 63 bytes per sprite definition; they're arranged on 64 byte boundaries in memory so you get 256 sprite definitions to each of the four 16K VIC-II banks. S'hard to know if that's an actual hardware limitation or merely the designers saving themselves a little space by going for a multiply by 64.

[FifthPlayer]

If you look at what Joe Decuir has said and written on the subject, the Amiga started out for both him and Jay Miner as a 68000 machine, and the chipset followed from that. It was always designed with a 16-bit CPU in mind - not just for the memory addressing required by the chipset, but for the architectural features in the OS as well. An Atari system based on the Amiga chipset would have shipped with a 68000 as the main CPU.

Edited February 23, 2018 by FifthPlayer

[Foebane]

24 pixels across is three bytes so multiply that by 21 and you get 63 bytes per sprite definition; they're arranged on 64 byte boundaries in memory so you get 256 sprite definitions to each of the four 16K VIC-II banks. S'hard to know if that's an actual hardware limitation or merely the designers saving themselves a little space by going for a multiply by 64.

 

Interesting. What is the 64th byte used for?

Edited February 23, 2018 by Foebane

[carlsson]

Usually nothing, I would think. I would think there are 16 bytes between the screen matrix and sprite pointers that often is wasted too, unless the programmer is really tight for storage and uses those as storage space.

[TMR]

Interesting. What is the 64th byte used for?

The hardware doesn't use it, but some sprite editors - SEUCK and Sprite Pad spring to mind - stick a colour value in there which avoids needing an extra table.

[Nebulon]

now to my US friends as in Europe (?) except of the Dragon 32/64 I never have seen a Tandy Coco... how is that rated in terms of games etc? I mean Atari 800 must be shocking to industry when presented 1978 at CES...

 

Here's something you might like; a good Color Computer 2 emulator. Plus, it has the advantage that it supports artifact colors (something that PAL systems had trouble with on these machines):

 

http://www.colorcomputerarchive.com/coco/Emulators/Coco%201-2/David%20Keil/

 

In my case, I took an old Pentium II machine, loaded Windows 98se on it, and plugged a D-pad controller into the joystick port on the back of a SoundBlaster card. The controls and sound both work really well.

 

When you get it running, F4, F5, and F9 will get you to the more important configuration screens. Shift F4 resets the machine. Shift F10 quits the emulator.

 

Recommended games:

Time Bandit

Cashman

Rommel 3D

Galagon

Qiks (the Spectral Associates version)

Grabber

Color Car

Calixto Island

Trekboer

Sam Diamond

Downland

Dungeons of Daggorath

Speed Racer

Marble Maze

Shock Trooper

 

Step 1 is to plug in the virtual disk controller.

Step 2 is to insert a virtual diskette into drive zero.

And the rest of the command info is here:

 

http://www.blitter.com/~nebulous/coco.html

 

http://www.classiccmp.org/cpmarchives/trs80/mirrors/www.discover-net.net/~dmkeil/coco/cocodoc.htm (docs)

 

http://www.classiccmp.org/cpmarchives/trs80/mirrors/www.discover-net.net/~dmkeil/coco/index.htm (main emulator page)

[Nebulon]

 

I think it's fair to say that the majority opinion is that the SID is a fantastic sounding sound chip and ranked higher overall than the POKEY in that regard (which, to be fair, is usually ranked second in such comparisons against everything else available at the time). Of course, I have a minority opinion of my own in that I think the Atari 8-bit in-game color palettes tend to be too dark and muted for my liking. The consensus is clearly against that idea, though.

 

Some of the A8 games have dark/muted color palettes (like Asteroids). But looking beyond examples like that, there are many that have much brighter colors than what the C64 can create. This (combined with the wider range of possible colors on the A8 is likely why most perceive it as more colorful than the C64. To my eye, the A8 definitely has more examples of bright and colorful displays whereas the C64's palette reminds me more of the NES.

[kiwilove]

It is that simple. Where you have a fixed colour palette - you can only choose from what colours are there in the fixed palette. That's why some C-64 games appear to have muddy colours - or they have a rather samey look to them - you can't change the colours in it's palette.

Whereas on the Atari - you can choose what colours (in whatever brightness you like) to have in the palette on screen. So - the colours are chosen.

 

But I think where you have a non-scrolling screen - the C-64 has the advantage of using different colours present - within each redefined character as such. So that there is more than say 5 colours on screen. This is used to advantage in such games as the Last Ninja series.

 

Harvey

[Heaven/TQA]

Being in commodore land for sometime now (you have to code for the evil to see the pro/cons yourself... ) the color palette of the C64 is not that bad as it looks on a first glance as they have chosen 16 most usable colors I have to admit...

[emkay]

Being in commodore land for sometime now (you have to code for the evil to see the pro/cons yourself... ) the color palette of the C64 is not that bad as it looks on a first glance as they have chosen 16 most usable colors I have to admit...

But, if you chose only the color for a picture use, you never could use the 16 colors together, except you like strange color settings. Not to forget that the colors changes 3 times on the C64. The colors themselves were not the point, but they changed the brightness of the colors. Which means, if you create a game on a C64 2 , it may look wishy-washy on a C64 of the 1st generation.

[emkay]

There is one thing, I'm jealous about the C64 : Because SID is created for musician, C64 got a huge amount of real musicians, pulling the whole thing MUSICALLY to the outer limits. And, as it seems, that will never happen to the Atari. As soon as the sound creation points to real music, the further development stalls. And, I have no idea how to change that.