Jump to content
IGNORED

P/M graphics unused memory after PMBASE


slx

Recommended Posts

Any ideas why the memory immediately after PMBASE is not used and the missiles don't start until 384/786 bytes after PMBASE?

Does this have anything to do with how ANTIC memory access works?

 

Is it safe to put code or even a display list list between PMBASE and the data used for the first visible player/missile?

 

 

Link to comment
Share on other sites

Yes, it's safe to do what you want with the unused space. I've put character sets, display lists, whatever there. ANTIC doesn't care.

 

Also, the first and last 4 or 8 bytes of each missile and player are unused by ANTIC depending on resolution. You can use those bytes without the values being displayed as player/missile data and they won't cause collisions.

  • Like 3
Link to comment
Share on other sites

From Basic, I modified a ML routine out of Compute! magazine that originally erased an entire player/missile page before updating the player position. My modification just erased where the "sprite" image was drawn and saved the position right below the missile area. If you write all ML stuff this area is useful for all sorts of tables.

 

I will be honest I am not sure why Atari or the original designers of the Antic/GTIA did set it up that way. Most of the people who created the chip set left Atari not long after, went on to make the Amiga. We did not see any further direct progression after TIA to Antic/GTIA. Atari was trying to consolidate the 2 circuits into one IC. 7800 Maria and ST was totally different style of video display. Amiga had some similarities but still a different style.

  • Like 1
Link to comment
Share on other sites

Pure speculation........ -> the space defined could accommodate 8 player objects. Perhaps the original idea was to have the missiles implemented as players. (Separate bitmaps) Then later design choices for playfield pushed the designers toward less DMA for P/M graphics. So, the four separate missiles were merged into one bitmap.

  • Like 3
Link to comment
Share on other sites

I thought that too, but probably not. More like "it is what it is".

 

Logically you'd either have what we have, or the 4 players first in memory followed by the missiles. That layout would make more sense, but consider some Antic workings:

 

Missiles are DMA'd first, and missile DMA can be active without players but players can't be active without missiles - a design which allows some objects (missiles) with minimal DMA interference.

 

So, logically with the chosen design and the missile DMA occurring first, the memory mapping is like we have - all that's needed is to bump the DMA address by 128 or 256 after each object depending on mode. Alternately they could have put the missiles at PMBASE and just had the players following with PL3 jumping the 1K boundary in 2-line mode.

 

Possibly looking at the Antic decap and schematics could reveal more.

Edited by Rybags
  • Like 4
Link to comment
Share on other sites

Most of the people who created the chip set left Atari not long after, went on to make the Amiga. We did not see any further direct progression after TIA to Antic/GTIA.

Which is a pity as a graphically enhanced but still compatible Atari might have fared better against the C64...something like a C128.

Link to comment
Share on other sites

I am totally unsure why this is the case. I don't suspect any hardware restrictions - order of DMA for P/M, playfield, charset, whatever - because there's not much of a difference in the internal wiring of the ANTIC. Either if the used address space would start immediately after PMBASE or the way it is now with a gap between PMBASE and the missile data.

 

I sense some other intention of doing so. For example in 1-line-P/M-mode you can easily put in an mode-8-charset in there if you are not using the last 32 characters. You can even put in some playfield data and/or the Display List ... just because it starts at least at a 1 Kbyte boundary. I am pretty sure it's because of probable memory usage optimization for the programmer.

Link to comment
Share on other sites

[..] could accommodate 8 player objects. Perhaps the original idea was to have the missiles implemented as players.

 

well, 8 players would have been awesome.

OK, still no competition to the C64, however, having 4 multicolor sprites or 8 single color sprites might have made on or the other game possible for the A8 back in the day.

 

I have no idea for the original question though. Might go with HW stuff, as mentioned already, maybe someone can see something in ANTIC decap.

 

I have used it for a charset when no Missiles are in use.

Honestly, I never had the idea to use it for DLists. As these should start on a 1Kb boundary it might actually possible that it was intended for this purpose.

Link to comment
Share on other sites

There's nothing special about the memory between PMBASE and where missiles start. It's just RAM. Atari's graphics hardware has few inconvenient memory limitations. Not like other chips which have inflexible memory maps forcing specific features to use memory from specific ranges. ANTIC is a 16-bit free for all. You want to use 23 character sets? Go for it. You want to use memory from a dozen different places for one screen display? Enjoy. ANTIC's flexible memory design also allows for exceptionally precise and frugal use of memory for graphics. That's why many games on the Atari take less RAM than the comparable game on other computers.

  • Like 5
Link to comment
Share on other sites

Display Lists don't have to start on a 1K boundary. They just can't cross a 1K boundary without using the jump instruction.

.

 

Just to be clear. I know that. I only put them at a 1k boundary to be sure that they do not cross the 1k boundary.

(using ca65 I have some ASSERTs to be sure :) )

 

Before the time of the internet some projects of mine stopped because I had unsolvable bugs because of the "4k ANTIC LMS limit" and the 1k DList limit.

The only book I had, failed to mentioned these :(

  • Like 1
Link to comment
Share on other sites

I thought that too, but probably not. More like "it is what it is".

 

<snip>

 

Possibly looking at the Antic decap and schematics could reveal more.

 

I've been thinking about this. The question probably could be answered by the designers of our chips or at least someone familiar with chips design. For instance, it may be easy and simple from a chip real estate standpoint to set a bit rather then a bank of bits i.e. have 16 bits that can be set so P/M graphics can appear anywhere in the memory map and no boundary. In that case you would just choose a q.s. bit to set.

 

But for all we know, there could have been more then enough room on the die and there would not have been any additional problems with manufacturing fallout due to increased complexity. Heck, I think the layouts were done by hand so the engineers may had just hit the wall from hours of tedious work and decided to KISS.

Link to comment
Share on other sites

[...] For instance, it may be easy and simple from a chip real estate standpoint to set a bit rather then a bank of bits i.e. have 16 bits that can be set so P/M graphics can appear anywhere in the memory map and no boundary. In that case you would just choose a q.s. bit to set. [...]

Yes, a universal 16 bit base address would require a whole 16 bit addition of the base address to the counter. The way it is solved now »just« requires the counter to be wired into the right places of the resulting address (1-line- or 2-line-P/M). And don't forget: We are talking about 70's chip-design with limited resources on chip. Some kind of an ALU had to be implemented to make the addition possible which would boost the transistor count in the ANTIC. Setting a bit for 1-line or 2-line-P/M is way more easy to implement.

 

Which does not clarify the free memory gap at the beginning of PMBASE. The idea of having eight universal players instead of four missiles and four players sounds also interesting. Maybe Jay Miner had that in mind and it was nearly finished when he found out it couldn't be made for some reason ... maybe again chip-resources. So he took part of his design, threw it away and now we have this gap.

Link to comment
Share on other sites

Plenty of Antic functions have latch and counter, that's what gives the limitations, ie need LMS to cross 4K boundary, DList can't cross 1K boundary, character and PM graphics have to start on 1/2, 1, 2K boundary depending on mode.

 

Maintaining counter takes chip space as each bit requires an adder + carry into the next bit. Latch is somewhat simpler.

LFSR can act as a pick/place counter if the locations don't need to be sequential, so are used by Atari for some internal chip functions - they use less components than counters.

Link to comment
Share on other sites

Plenty of Antic functions have latch and counter, that's what gives the limitations, ie need LMS to cross 4K boundary, DList can't cross 1K boundary, character and PM graphics have to start on 1/2, 1, 2K boundary depending on mode.

 

Maintaining counter takes chip space as each bit requires an adder + carry into the next bit. Latch is somewhat simpler.

LFSR can act as a pick/place counter if the locations don't need to be sequential, so are used by Atari for some internal chip functions - they use less components than counters.

 

The funny thing is, and kinda the interesting point of this topic, the only "limit" which isn't explained is the $300 byte gap.

Maybe this is the last unsolved mystery of the A8 chipset :)

Ha! I just got an idea. What if they assumed coders would be so clever and choose PMBASE= $00?

Then the ZP and the stack ($100-$1ff) would be in the "free zone" and the PMG data would start at $0300 and all memory from $0800 is available.

Even using the double-line mode, would work when you init the SP at $7f, right?

Of course that only would work with (easily) with cartridge based games, but on the other hand it would be best choice concerning the 16k Atari 400.

 

Link to comment
Share on other sites

[...] Ha! I just got an idea. What if they assumed coders would be so clever and choose PMBASE= $00?

Then the ZP and the stack ($100-$1ff) would be in the "free zone" and the PMG data would start at $0300 and all memory from $0800 is available.

Even using the double-line mode, would work when you init the SP at $7f, right?

Of course that only would work with (easily) with cartridge based games, but on the other hand it would be best choice concerning the 16k Atari 400.

My current game is intended to run on Atari 400 & 600XL and it should end on a cart. And I've chosen $3800 as PMBASE. I don't see a benefit to let PMBASE start at $0. The opposite is the case: I am loosing compatibility with DOS if, who knows why, later in the development process I am forced to put the game not on a cartridge but as a file on a floppy instead.

 

But the idea is good. ;)

Link to comment
Share on other sites

My current game is intended to run on Atari 400 & 600XL and it should end on a cart. And I've chosen $3800 as PMBASE. I don't see a benefit to let PMBASE start at $0. The opposite is the case: I am loosing compatibility with DOS if, who knows why, later in the development process I am forced to put the game not on a cartridge but as a file on a floppy instead.But the idea is good. ;)

Not a Problem. My game engine ( Heli, ditch) use RAM from $0200 to $fffa AFTER loading. And when using xBIOS it shouldn't be a problem to access the disk. Although till now I have no experience with it.

 

 

@Jac: nice find. :-)

Link to comment
Share on other sites

  • 7 years later...

Started thinking of how Atari design could have been expanded post release of the Commodore C64 in the XL/XE systems to try and bring back some market share.  I don't imagine anyone at Atari knew what Commodore was up to in those intervening years between '79 and '82 with the release of the C64, which was a shame.  The C64 designers don't credit the Atari at all, yet, the machines have a similar font, C64 has a compatible 160 pixel 5th colour mode, provides horizontal and vertical scrolling registers and the joystick port design is copied.  However, this amounted to very little, since what the C64 engineers must have done in those three years was seemingly figure out exactly how to avoid programmatic solutions for the stuff that Atari can do, by adding solutions into hardware.  First they settled on 12 pixel wide sprites leading to artists getting good at drawing detailed sprites for the 160 wide screen.  Despite all Atari's apparent powers, C64 engineers went on to beat the Atari further on display lines, where it now becomes limited by it's unique hardware.  For example, C64 avoids display 'lists' for line based mode selection and can mix hi res and lo res on the same line anywhere within the line.  The only other computer being similarly line based restricted to the Atari I can think of is being the BBC micro.  However, display lists aren't always the worst enemy, since they can be very powerful when scrolling and different screen sections, but they add the problem of being interrupted on a display line, rather than a screen vertical scan line, something again that the C64 engineers include with raster interrupts.

 

The inclusion of Hires/lores on the same lines keeps the C64 graphics very much alive even today with those hi res parallax type scrolls we see in games like R type, at least until the 320 x 200 screens of the 16 bit machines, where everything can be Hi res or the resolution of the early arcade machines.  However, the C64 engineers went on to add colour map (interestingly similar to ZX Spectrum being developed in the UK just around the same time) so that now, there is no need for kernel etc and every C64 colour can now be on the screen.  What also is apparent that as time goes on and the competitive demands on the Atari increase(even now), the lack of available RAM in the machine becomes an issue, so much that, using cartridges as a design to avoid adding extra RAM is required.  Frustrating.  Because the XEGS returned as a cartridge based machine and this kind of design would have lived potentially much longer, like the Nintendo DS did, with cartridges falling in price, but they didn't fix some of the problems that Atari still had.  I guess Jack Tramiel turning up at Atari was a great move for the 16 bit machines but they had made too many mistakes (abandoning the release of the 7800 with it's Maria chip and other elite chip designs).

 

Where they could have made improvements to Atari 8:

  1. M0 - M3 2nd version.  Looking at the PMBASE memory map discussed above, I figured a simple extra bit somewhere in an existing HW register could have enabled a second set of missiles M0'-M3'.  Using one of the free spaces in the memory map, these extra 2 bit wide missiles could have automatically appeared at HPOSPM0+2 , HPOSPM1 + 2 etc, eliminating the need for any new HW registers for X positioning.  This would have made doing 12 pixel wide sprites in one bitplane colour far more doable.
  2. Multiplex existing HW registers.   This idea would be to simply allow the spare slots to be full 8 sprites (x 8 pixel wide).  Everytime a HW register was written to, a new HW multiplexing register would have had to be written to in advance, to select the correct PMG 'bank' to apply the changes to.  So, without more RAM or HW registers, there would have been far more HW sprites to display from within the Antic chip.
  3. Using the now limited PMBASE memory map as a new 'display list' instead of a memory map.  To preserve backward compatibility, PM memory could still be scanned down by Antic, but in a different mode, instead of copying the data directly via DMA straight into the GRAFPx and GRAFM registers on each line, it would now check for 'load' or other instructions, where there would be an indirection to another memory address, where the sprite image was read from.   The graphics chip would then spend the next N scan lines copying from the new location to the GRAFx registers.   This allows at it's simplest, the chip to do vertical positioning of sprites and to do a fixed size C64 like sprite (say N=21) which would free up the work needed to be done by the CPU, typically which is in Vertical Blank.  A more advanced version as an alternative to method 1 would have been to read 3 bit planes from the same place in a C64 style encoding of (21 x 3 bytes) + 1 byte padding and displayed these here, without using new GRAFx registers, thus, bypassing the limit of 1 byte for the sprite width.  Using the PM 'display list' memory further, it could have had 3 independent HW colour values in there which were used for the sprite display (thus eliminating the need for more registers or using the regular display list interrupts) so this could beat the C64 which relys on 2 extra HW registers and fixing the number of colours per sprite to be 1 unique and 2 sprite shared colours.

 

What they might not have achieved on Atari in an upgrade was:

  1. Mixed Hi res and lo res
  2. Colour map
  3. Hi res sprites

Still, any revised machine could still have been amazing graphically, ahead of virtually all other competitors and possibly better as a gamers machine of choice.  For music specifically, a passthrough cable in the catridge port could have been added like the 7800, while still being backwardly compatible with the existing cartridge port.  This would have allowed superior synth chips to be powered from the cartridge port.

 

Clearly, the Atari 8 is still my favourite machine to develop for, but in the end, it takes a lot longer to achieve the sort of things C64 does 'simply', hence sadly, we often think in envy of games that we can see aren't easily convertible from the C64 back catalogue rather than concentrating on whole new graphically stunning designs.

 

Edited by TracMan
Typos
Link to comment
Share on other sites

On 1/10/2015 at 10:37 PM, Rybags said:

I thought that too, but probably not. More like "it is what it is".

 

Logically you'd either have what we have, or the 4 players first in memory followed by the missiles. That layout would make more sense, but consider some Antic workings:

 

Missiles are DMA'd first, and missile DMA can be active without players but players can't be active without missiles - a design which allows some objects (missiles) with minimal DMA interference.

 

So, logically with the chosen design and the missile DMA occurring first, the memory mapping is like we have - all that's needed is to bump the DMA address by 128 or 256 after each object depending on mode. Alternately they could have put the missiles at PMBASE and just had the players following with PL3 jumping the 1K boundary in 2-line mode.

 

Possibly looking at the Antic decap and schematics could reveal more.

Anyone wish that the ANTIC DMA stuff was on a seperate Memory chip? Or have 32K of Non-antic space where the 6502C could run at full speed? that would've been nice.

On 1/10/2015 at 9:59 PM, kenjennings said:

Pure speculation........ -> the space defined could accommodate 8 player objects. Perhaps the original idea was to have the missiles implemented as players. (Separate bitmaps) Then later design choices for playfield pushed the designers toward less DMA for P/M graphics. So, the four separate missiles were merged into one bitmap.

Yes. I bet you it did. But to save on transistors, instead we got what we got. They then went about changing ANTIC to support the new system, but I think they just left it in this weird setup. Probably a hardware thing. 8 players would've been amazing and would've helped the Atari hold up against later computers. Then again, it was the first to include sprites.

 

3 hours ago, TracMan said:

Started thinking of how Atari design could have been expanded post release of the Commodore C64 in the XL/XE systems to try and bring back some market share.  I don't imagine anyone at Atari new what Commodore was up to in those intervening years between '79 and '82 with the release of the C64, which was a shame.  The C64 designers don't credit the Atari at all, yet, the machines have a similar font, C64 has a compatible 160 pixel 5th colour mode, provides horizontal and vertical scrolling registers and the joystick port design is copied.  However, this amounted to very little, since what the C64 engineers must have done in those three years was seemingly figure out exactly how to avoid programmatic solutions for the stuff that Atari can do, by adding solutions into hardware.  They settled on 12 pixel wide sprites as artists got better at drawing for these 160 wide screen.  Despite all Atari's apparent powers, they even go on to beat the Atari further, where it now becomes limited by it's unique hardware.  For example, C64 avoids display 'lists' for line based mode selection and can mix hi res and lo res on the same line anywhere within the line.  The only other computer being similarly line based restricted to the Atari I can think of is being the BBC micro.  However, display lists aren't always the worst enemy, since they can be very powerful when scrolling and different screen sections, but they add the problem of being interrupted on a display line, rather than a screen vertical scan line, something again that the C64 engineers include.

 

The inclusion of Hires/lores on the same lines keeps the C64 very much alive even today with those hi res parallax type scrolls we see in games like R type, at least until the 320 x 200 screens of the 16 bit machines, where everything can be Hi res or the resolution of the early arcade machines.  However, the C64 engineers went on to add colour map (interestingly similar to ZX Spectrum being developed in the UK just around the same time) so that now, there is no need for kernels and every C64 colour can now be on the screen.  What also is apparent that as time goes on and the competitive demands on the Atari increase(even now), the lack of RAM in the machine returns as a problem, so much that, using cartridges to avoid the extra RAM returns.  Frustrating.  Because the XEGS returned as a cartridge based machine and this kind of design would have lived potentially much longer, like the Nintendo DS did, with cartridges falling in price, but they didn't fix some of the problems that C64 had.  I guess Jack Tramiel turning up at Atari was a great move for the 16 bit machines but they had made too many mistakes (abandoning the release of the 7800 with it's Maria chip and other chip designs).

 

Where they could have made improvements to Atari 8:

  1. M0 - M3 2nd version.  Looking at the PMBASE memory map discussed above, I figured a simple extra bit somewhere in an existing HW register could have enabled a second set of missiles M0'-M3'.  Using one of the free spaces in the memory map, these extra 2 bit wide missiles could have automatically appeared at HPOSPM0+2 , HPOSPM1 + 2 etc, eliminating the need for any new HW registers for X positioning.  This would have made doing 12 pixel wide sprites in one bitplane colour far more doable.
  2. Multiplex existing HW registers.   This idea would be to simply allow the spare slots to be full 8 sprites (x 8 pixel wide).  Everytime a HW register was written to, a new HW multiplexing register would have had to be written to in advance, to select the correct PMG 'bank' to apply the changes to.  So, without more RAM or HW registers, there would have been far more HW sprites to display from within the Antic chip.
  3. Using the now limited PMBASE memory map as a new 'display list' instead of a memory map.  To preserve backward compatibility, PM memory would still be scanned down by Antic, but instead of copying the data directly via DMA straight into the GRAFPx and GRAFM registers on each line, it would now check for 'load' or other instructions, where there would be an indirection to another memory address, where the sprite image was read from.   The graphics chip would then spend the next N scan lines copying from the new location to the GRAFx registers.   This allows at it's simplest, the chip to do vertical positioning of sprites and to do a fixed size C64 like sprite (say N=21) which would free up the work needed to be done by the CPU, typically which is in Vertical Blank.  A more advanced version as an alternative to method 1 would have been to read 3 bit planes from the same place in a C64 style encoding of (21 x 3 bytes) + 1 byte padding and displayed these here, without using new GRAFx registers, thus, bypassing the limit of 1 byte for the sprite width.  Using the PM 'display list' memory further, it could have had 3 independent HW colour values in there which were used for the sprite display (thus eliminating the need for more registers or using the regular display list interrupts) so this could beat the C64 which relys on 2 extra HW registers and fixing the number of colours per sprite to be 1 unique and 2 sprite shared colours.

 

What they might not have achived:

  1. Mixed Hi res and lo res
  2. Colour map
  3. Hi res sprites

Still, any revised machine would still have been amazing graphically, ahead of virtually all other competitors and even better as a gamers machine of choice, specifically, if a passthrough type cable in the catrridge port could have been added like the 7800, while still being backwardly compatible with the existing cartridge port.  This would have allowed synth chips to be powered from on a cartridge.

 

Clearly, the Atari 8 is still my favourite machine to develop for, but in the end, it takes a lot longer to achieve the sort of things C64 does 'simply', hence sadly, we often think of games that are convertible from the C64 back catalogue rather than whole graphically stunning new designs.

 

I must say, the only system that beats the 800 for me is the 7800. 7800 is a powerhouse. And with those amazing sprite capabilities (Atari did their homework :) )it really shines.

Now, reminder that when the 800/400 came out in '79 it was the MOST POWERFUL COMPUTER out there, except maybe the TI-99/4, but that didn't have the game library of the 800/400.

While other computers had color graphics (The AII and the TI-99/4), they didn't have sprites (Minus the TI-99/4) or a 128 color palette that if I'm not wrong, would get upgraded to 256 colors. None of these computers (Before '79) could do what the Atari 800 does easily. And- the best feature in my oppinion- ANTIC's 16 modes. Other computers didn't have that.

And while I agree with you on the C64 being superior, that CPU is slow. Sure, the ANTIC DMA can get a little crazy but even at the worst the CPU in the 800/400 seemingly runs at 1.074 mhz, STILL FASTER than a C64 WITHOUT video.Most of the time it is much faster however, usually running at about 2600 speeds or more. 

Plus. the C64 can't do multiple modes at once and doesn't have an easy Scanline counter based interrupt or 256 colors. Just saying.

  • Like 1
Link to comment
Share on other sites

  • 1 year later...
Posted (edited)
On 1/16/2015 at 12:44 PM, Creature XL said:

well, 8 players would have been awesome.

OK, still no competition to the C64, however, having 4 multicolor sprites or 8 single color sprites might have made on or the other game possible for the A8 back in the day.

8 sprites on the C64 still feels restrictive, even though any or all of them could individually be made multicolor.  But these days, that's part of the fun, isn't it?  Back in the day, though, having more sprites and things like that made development easier, quicker, and cheaper, which had to have made a difference back when money was tight.

 

On 1/16/2015 at 4:47 PM, kenjennings said:

There's nothing special about the memory between PMBASE and where missiles start. It's just RAM. Atari's graphics hardware has few inconvenient memory limitations. Not like other chips which have inflexible memory maps forcing specific features to use memory from specific ranges. ANTIC is a 16-bit free for all. You want to use 23 character sets? Go for it. You want to use memory from a dozen different places for one screen display? Enjoy. ANTIC's flexible memory design also allows for exceptionally precise and frugal use of memory for graphics. That's why many games on the Atari take less RAM than the comparable game on other computers.

True, albeit the C64 specifically offers similar flexibility for everything but the color RAM, which is sometimes aggravating, to be honest--arguably a design flaw.  And it can't match the A8's address resolution and flexibility concerning the screen RAM (ANTIC LMS command), since there is a requirement for it to start on a 1K boundary, making scrolling playfields more cumbersome and CPU-intensive on the C64.  Every 8-bit computer had annoying limitations.  The Atari 8-bit is so feature-rich and powerful, and relatively orthogonal, yet the way its PMGs are defined can be pretty annoying and somewhat limiting.  And on occasion its 128 character definitions per character set can be limiting.  When you need more than that, it can make a significant difference in complexity and the amount of RAM required.

 

On 1/17/2015 at 11:47 AM, ricortes said:

Heck, I think the layouts were done by hand so the engineers may had just hit the wall from hours of tedious work and decided to KISS.

Or they ran out of time and money (obviously tied together), which is always a thing in any business, but especially in this business back in the day, in which it was a recurrent theme that helped explain many strange things that happened.

 

On 1/18/2015 at 1:32 AM, Heaven/TQA said:

Still I think compared to the banking of VIC antic is less restrictive ;)

It is less restrictive, although it's only a little trouble to switch banks on the fly.  Hopefully there are a sufficient number of cycles to make the switch in a timely manner, though.

Edited by Robert Cook
Link to comment
Share on other sites

On 12/17/2022 at 9:43 AM, TracMan said:

...

The C64 designers don't credit the Atari at all, yet, the machines have a similar font, C64 has a compatible 160 pixel 5th colour mode, provides horizontal and vertical scrolling registers and the joystick port design is copied.  However, this amounted to very little, since what the C64 engineers must have done in those three years was seemingly figure out exactly how to avoid programmatic solutions for the stuff that Atari can do, by adding solutions into hardware.  First they settled on 12 pixel wide sprites leading to artists getting good at drawing detailed sprites for the 160 wide screen.  Despite all Atari's apparent powers, C64 engineers went on to beat the Atari further on display lines, where it now becomes limited by it's unique hardware.  For example, C64 avoids display 'lists' for line based mode selection and can mix hi res and lo res on the same line anywhere within the line.  The only other computer being similarly line based restricted to the Atari I can think of is being the BBC micro.  However, display lists aren't always the worst enemy, since they can be very powerful when scrolling and different screen sections, but they add the problem of being interrupted on a display line, rather than a screen vertical scan line, something again that the C64 engineers include with raster interrupts.

...

Clearly, the Atari 8 is still my favourite machine to develop for, but in the end, it takes a lot longer to achieve the sort of things C64 does 'simply', hence sadly, we often think in envy of games that we can see aren't easily convertible from the C64 back catalogue rather than concentrating on whole new graphically stunning designs.

Many here probably know this, but for those who may not, the C64's default lowercase characters (in ROM) are, in fact, exactly pixel-for-pixel identical to those of the A8. 😂  They were obviously cribbed to save some time, which was perfectly legal because it had already been established that you can't copyright or patent a font, only its name.  I think Commodore had intended to create a unique character set for the C64, and did with the uppercase and other characters, but clearly they found the A8's lowercase characters perfectly satisfactory.  The C64's uppercase characters are quite distinct from those of the A8, however.  I think the latter really tries hard to avoid NTSC artifacts, while the former didn't have nearly as much of an issue because of its deliberately skewed dot clock (one side-effect of which was a rather narrow pixel aspect ratio).  I guess they also might have thought it was fair enough because the ATASCII graphics characters were so similar to the PETSCII ones used earlier in the PET computers and carried over into the VIC-20 and C64.

 

Some from Commodore, I think including Chuck Peddle himself, have praised and credited the A8 as being ahead of its time and beyond what they were thinking in terms of graphics architecture, although admittedly most have tended to "point at the scoreboard" because they can (real gracious, guys).  To be fair to Atari, Commodore was very much influenced by the A8, although to be fair to Commodore, they did many things in rather different and noteworthy ways.  They weren't going to give the lower-end C64 (except for its amount of RAM) two LSI graphics chips and all of that functionality the higher-end (but older) A8 had, but they did, as you said in different words, find very simple ways to offer similar capabilities (except for the size of the color palette, obviously) on far less silicon.  They had to because the improved sprite system took half of the VIC-II's die!  Rather than being similar to a coprocessor with numerous DMA modes like the ANTIC, the VIC-II's front-end DMA driver circuitry (whatever you want to call it) is a simple state machine that only accesses RAM/ROM in one way--a single mode, in ANTIC terms.

 

So in A8 terms, the C64's 5 official graphics modes could all be considered color/data interpretation modes.  And as you mentioned, raster interrupts on any scan line were used to switch modes, change color registers, and character sets and such (even the VIC-II bank if necessary, since it could only access 16K at a time).  This is really simple, takes up little silicon, gives us a lot of the same functionality as Display Lists and DLIs, and is even more flexible because we get to choose which exact scan line the interrupt occurs on.  It's not as cool or slick or beautiful as the ANTIC+GTIA architecture, but it offers so much for so little--"elegant" in its own crude sort of way.  This not only made the sprite system possible, it left room (and time and money) for some of the C64's other tricks.  It's like the MOS/Commodore engineers scrutinized the A8's design, thought it was really, really brilliant, but then found ways to do much of the same in very cheap and pragmatic ways, which helped keep the C64's cost low.  Atari tried to use improved chip fabrication technology to put the ANTIC and GTIA on the same die to reduce the cost, but for whatever reasons, it never worked out.  Commodore also omitted the low-resolution modes (although they are easily emulated with other modes), because the C64 obviously came with 64K of RAM--certainly another advantage of having been designed and released later.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...