Practical steps for using PORTB extended RAM

[morelenmir]

I think I am pretty much up to speed with the theory of using 'PORTB' extended memory on the 130XE. Also and more interesting still its separated ANTIC/CPU access capabilities. However, there are some practicalities which rarely seem to be addressed in the usual books - at least those I have read such as 'Atari Roots' and 'Mapping the Atari'.

 

My current understanding is; you can make use of 16k slices of the extended RAM by reading/writing to addresses $4000-$7FFF. This range is termed the 'access window'. On a standard 130XE there are 4 possible banks of extended RAM - 64k total - and you select which of these you want 'slotted in' to the access window by setting or clearing bits 2&3 of the PORTB byte. The further complexity is you can actually specify that only the CPU or the ANTIC chip 'sees' the currently slotted extended RAM bank or alternately the native chunk of RAM which still resides 'underneath' at $4000-$7FFF via bits 4&5. Therefore you can have effectively two different sets of data occupying what appears to be the same address range! For some reason I find this feature extremely fascinating and compelling.

 

Given ANTIC is the graphics chip of the Atari, the obvious use for the separated access would seem to be in order to keep your display list and its attendant display memory on the extended RAM bank while you put your actual programme on the underlying memory. However, the Display List has to be physically put on this extended RAM in the first place, not to mention any updates made throughout your application's life to the display memory which animates your screen.

 

So, in basic terms this is my current broad outline of how to do this, assuming a setup where the CPU accesses the underlying RAM and the ANTIC accesses bank 1 of extended RAM.

1. Set the bits of PORTB as follows: 00100000 (ignoring for now the uses of bits 0,1,6&7). This specifies that the first RAM bank will be slotted in to the access window and that the CPU can read and write to it.
2. Copy the Display List and the display memory which comprises your initial screen image to the access window. Because the CPU is currently set to read/write the access window it will copy this data to the physical extended RAM and not the underlying native RAM.
3. Reset the bits of PORTB as follows: 00010000. This now specifies that only ANTIC can read (and presumably write, although I don't know if the ANTIC itself ever writes to memory?) the RAM in the access window while the CPU will now only see the data existing on the underlying native address range.
4. Repeat the process of swapping access rights each time you want to change the display RAM and then once finished swap PORTB back so ANTIC can see it again. A good time to actually do this would be during a VBLANK interrupt handler routine.

Am I on the right lines here? Although immediately I wonder if it makes more sense to set the ANTIC to access the native RAM while you put your programme on the extended RAM. This way, given you are more likely to make frequent changes to the display RAM than to your actual programme then fewer steps are necessary to animated the screen?

 

Also I do understand you don't have to use the separated access. That you can have things set up so both ANTIC and the CPU chip can see the slotted in bank of expanded RAM. Indeed, you can set up PORTB so no extended RAM is slotted in at all!

Edited September 16, 2016 by morelenmir

[Alfred]

Yes.

 

You are better off having Antic use the normal ram and your code going in the extended banks. This way your program will also work on XL machines which have memory expansions, but do not have the ability of ANTIC to address that memory separately.

[GoodByteXL]

Yes.

 

You are better off having Antic use the normal ram and your code going in the extended banks. This way your program will also work on XL machines which have memory expansions, but do not have the ability of ANTIC to address that memory separately.

This is not true for all memory extension for the XL series. There are some (still available) behaving exactly as an unmodified 130 XE. Generally it is a good idea not to use this feature as most of the "customers" cannot use it.

[Rybags]

An additional reason not to use extended Ram for graphics is that there is only one window and you're controlling whether the CPU and/or Antic looks through it.

So, while the display is active, you can't access anything in the extended area except the one that has the graphics in it.

 

The good way to plan the game or application is to use the harder to get to Ram for storing stuff that's used less frequently like level data that's decompressed at game start or maybe even music.

[morelenmir]

Many thanks guys - those suggestions are exactly the kind of insight I was hoping for!

 

I am wondering about using the extended RAM in the same way as using a 'virtual window' in Win32. That is where you do your actual GDI drawing on a piece of memory or 'device context' that exactly corresponds to the client area of the window and then simply blt pieces of this to the actual window surface when sections require repainting. That way you have a super-fast repaint and the drawing operations always happen behind the scenes. In an atari setting you would draw to one of the other 16K banks and then switch to the newly created screen by slotting that bank in to the access window. However that would run in to the problems about changing an active display that Rybags mention.

 

I very vaguely seem to remember listening to a lesson when I was a child that came on a cassette which held both data and audio. It talked about a technique called 'page flipping' which might be something similar to the lines I am thinking along here. However I only had an 800XL at the time, so the programme that ran in sync with the audio commentary cannot have used the XE extended memory to do its thing... Interesting - I'll have to see if I can dig those tapes out again as I think there were maybe four or five in a series of tutorials. If I recall correctly though they were all trying to teach BASIC and not ASM, so not directly appropriate here.

Edited September 16, 2016 by morelenmir

[GoodByteXL]

That way you have a super-fast repaint and the drawing operations always happen behind the scenes. In an atari setting you would draw to one of the other 16K banks and then switch to the newly created screen by slotting that bank in to the access window.

Have a look into the ABBUC PD Library and search for "Solid States" and "page flipping" to see what others already did.

 

Mostly bank switching instead of page flipping is used as it is easier to handle. Page flipping gets more complex when using hires modes.

[xxl]

with a separated ANTIC/CPU access advantage is that you can use the double buffering with the same gfx procedures (no need to change display memory address table)

It is often used - array of objects that is store the position screen memory address - if you change the address of the screen then you have to store the relative address and add the beginning of display memory;

through the split access you can hold absolute addresses - it accelerates subsequent calculations.

[morelenmir]

Another thing that I have not found a concrete statement on is just which parts of the system are considered 'ANTIC data'. Obviously the Display List and the display memory, but for instance are the sections of RAM that hold the Player and Missile bitmaps also something that could go on to the bank of extended RAM dedicated for ANTIC access?

Edited September 17, 2016 by morelenmir

[Rybags]

PMG can also be considered Antic data, also DList. But DLists are usually small and there's no problem putting them in main memory.

PMGs at most take up 1.25K so aren't too obtrustive. In theory you could even mix up the screen memory, e.g. you might want to put score/status stuff where it's always available.

 

It's something you need to weigh up in planning stage. The other downside of using extended Antic access is that it's not supported across all extended memory schemes, so in fact the result there will either be intended accesses stuck in main memory or forced from extended depending on PortB setting.

[xxl]

when using industry-standard introduced by Atari in XE series brings tangible benefits why abandon this? just because there are third part simplified memory extension not holding the standard?

[+CharlieChaplin]

 

when using industry-standard introduced by Atari in XE series brings tangible benefits why abandon this? just because there are third part simplified memory extension not holding the standard?

 

 

Errrm,

 

it is not an "industry standard" and it was not available for the whole XE (nor the XL) series... just in case you did not know...

 

Regarding software using this sep. Antic access, most of this software can or could easily work in normal mode, thus not requiring sep. Antic access. (And personally I do not like programs requiring sep. Antic access and always try to get them patched, so they work fine with any 128k machine even without sep. Antic banking...)

Edited September 17, 2016 by CharlieChaplin

[xxl]

Atari introduced the standard for memory expansion and fortunately this standard adds new capabilities.

 

Use mem extension only as a memory banks because third part extension do not holding Atari standard is a... regress.

[+CharlieChaplin]

Atari introduced the standard for memory expansion and fortunately this standard adds new capabilities.

 

Use mem extension only as a memory banks because third part extension do not holding Atari standard is a... regress.

 

Yep,

 

they introduced RAM upgrades with the 400/800 computers and Axlon upgrades (Axlon chairman was Nolan Bushnell, Axlon a 100% daughter of Atari), then they did it with an external 600XL RAM upgrade known as the Atari 1064... so again, NO! the sep. Antic banking is no industry standard nor an Atari standard...

[xxl]

nice try but:

axlon is not Atari upgrade and not PORTB upgrade :-) PORTB upgrade appeared later (Axlon is not compatible with any PORTB ram extension)

1064 makes 16kb system (600XL) 64 kb system so not bank switch expansion :-)

atari makes only one upgrade. in 130xe. with separet 6502c/Antic access :-)

and that why it is standard :-)

Edited September 18, 2016 by xxl

[phaeron]

That's fine, except that nobody cares whether a memory configuration is "official" or not. Atari isn't making new machines. All people care about is whether the computer they have can run your program. If you depend on separate ANTIC memory access, then fewer people can run your game or demo.

[xxl]

in this case maybe we shouldn't use GTIA modes either?

 

because there are computers that can't show "official" graphics modes and fewer people can run this program.

[GoodByteXL]

 

atari makes only one upgrade. in 130xe. with separet 6502c/Antic access :-)

and that why it is standard :-)

 

 

Hm, this is difficult to agree on as the "standard" set by Atari is to use PIA's Port B to address extended memory in chunks of 16 KiB, that's it. Thereafter other developers adapted that and designed memory extensions of different kinds following this idea for compability reasons.

 

Though I use and prefer memory extensions providing separate access of CPU/ANTIC I have to realize that most memory extensions ever developed for the XL/XE line do not provide this feature. Therefore software making use of it is very limited. Of course one can use this option for programming, but shouldn't expect too much positive feedback when it comes to run it on real hardware.

[xxl]

 

Hm, this is difficult to agree on as the "standard" set by Atari is to use PIA's Port B to address extended memory in chunks of 16 KiB, that's it.

with separate 6502c/Antic access ... that's it.

 

 

Thereafter other developers adapted that and designed memory extensions of different kinds following this idea for compability reasons.

makes his modification only partially compatible with standard

[Mathy]

Hello guys

 

If software is easy to convert to "no-separate access", why not test for separate ANTIC and CPU access? We have software that tests which banks are available, so checking for separate access and using the appropriate routines from that point on shouldn't be that hard. Those of us that prefer separate access would have the benefit of the software running faster, that rest would have the compatibility they want.

 

Sincerely

 

Mathy (who prefers separate access!)

Edited September 18, 2016 by Mathy

[morelenmir]

I did not realize this was such a vexed topic! Obviously many of you chaps have very clear ideas on the utility of separated ANTIC access. I personally think that it would be a shame not to write programmes for it as the mechanism is so fascinating and brings new possibilities to the machine. I am rather childish though and I like shiny new things that catch my eye; the idea the machine can be doing different things with what appears to be the the same chunk of memory address really appeals to me! However I do appreciate the compatibility argument as well. That is certainly something that any professional and - these days perhaps more relevantly - Demo programmer should bare in mind.

 

On the broader topic I think it is unfortunate that any of the third-party expansions - primarily RAMbo I guess? - didn't support it and in fact I think only the various 'COMPY' expansions did? Does anyone know why that was?

 

I read Hias monograph from the SRAM v1.3 application notes with great interest on how the separated addressing works at the electrical level. He really does explain it there very clearly and it was obviously possible to replicate the effect with larger amounts of RAM - at least up to 256k. That said the Ultimate1MB does it with 512k, although that requires the CPLD to perform some clever tricks with setting and then clearing the PORTB bits mid-cycle. Was that kind of manipulation perhaps not possible until programmable logic came along?

[Mathy]

Hello morelenmir

 

My XEGS does it with 1MB of extended memory. Read all about it in an article from 2001.

 

If I'ld do it all over, I'ld use SRAM instead of DRAM. SRAM wasn't available (or not at reasonable prices/sizes) back then. SRAM would make the design a lot easier.

 

Sincerely

 

Mathy

[Kyle22]

(sort of off topic), but:

 

It seems a bit odd to me that someone who likes the "official" way of doing things would support the use of non-"official" opcodes. Some consider those opcodes to be illegal. Atari would never "officially" do anything illegal, would they?

 

[xxl]

rather doing things non standard way using official hardware.

 

and undocumented opcodes works on official hardware :-)

[Kyle22]

Well, I thought it was a good try...

 

[1050]

On the broader topic I think it is unfortunate that any of the third-party expansions - primarily RAMbo I guess? - didn't support it and in fact I think only the various 'COMPY' expansions did? Does anyone know why that was?

Newell and wizztronics come to mind but the wizz is just a copy of the Rambo so

no wonder it doesn't do ANTIC access either. Main reason as I can gather it

is because on the XL where these upgrades were aimed for there is no 2nd PAL

chip to do the 4 modes of ANTIC access with to then claim 130XE compatibility.

And not sure on the time line of these offerings but it could have been the

case where the 130XE 'standard' had not been revealed because they hadn't

shipped yet.

 

Retro fitting one of the add to memory type, such as the

newell to an XE might be done thru the 2nd PAL chip doing 4 mode

ANTIC access and actually have it work there. But without that chip or

an equivalent gob of glue logic doing that, it's not ever going to happen

on an XL. So in the why they didn't, is the issue where they didn't know

they were supposed to and after that then they really didn't know how

as well. Newell claims to be ANTIC access with an inverter trick, but

I suspicion it takes a whole lot more than just that. I read in the

Rambo manual where they claim 130XE compatibility but turn right around

and say it doesn't do ANTIC access -- so which is it? Newell and Rambo

are trying to redefine the word 'if' for us is what it amounts too.

 

Short answer is, it's hard to come by.