Jump to content
slx

P/M graphics unused memory after PMBASE

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?

 

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

.

 

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

Share this post


Link to post
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.

Share this post


Link to post
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 :(

Share this post


Link to post
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.  

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.
 

Share this post


Link to post
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. ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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. :-)

Share this post


Link to post
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.

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