P/M graphics unused memory after PMBASE

[+slx]

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?

 

 

[kenjennings]

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.

[snicklin]

I like to put player animation data there and then copy it through to the proper area for drawing it afterwards.

[peteym5]

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.

[kenjennings]

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.

[Rybags]

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 January 11, 2015 by Rybags

[+slx]

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.

[Island2Live]

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.

[Creature XL]

[..] 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.

[kenjennings]

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

.

 

(Character sets start on 512 byte, or 1K boundaries.)

[kenjennings]

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.

[Creature XL]

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

[ricortes]

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.

[Island2Live]

[...] 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.

[Rybags]

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.

[Heaven/TQA]

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

[Creature XL]

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.

 

[Island2Live]

[...] 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.

[Rybags]

The idea for PMBASE=00 seems valid, though it falls over in 2-line resolution.

But remember of course the original plan was that 400 had only 4K and 8K for the 800, so it was worth being able to save every bit of memory possible.

[+JAC!]

The idea it not only but, but may actually be one of the real reasons. I remebered having seen PMBASE=$00 before, I now I even remember where:

 

http://www.atarimania.com/game-atari-400-800-xl-xe-basketball_529.html

 

Runs fine with just 8k of RAM.

[Creature XL]

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. :-)

[TracMan]

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 March 17 by TracMan
Typos

[Ecernosoft]

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.