Brainstorming: Extended Memory 3D Engine Design

[ivop]

Alfred means that with most 256+kB expansions there's no separation between CPU or Antic access. They always see the same RAM, either the base RAM or an extended bank. The separation bits are reused to access more banks.

Edited January 6, 2019 by ivop

[Alfred]

Wait, so does that rule out mode 2 (Cpu: Ext, Antic:Main) for certain specific RAM extensions (like, say, Rambo) ? How is that even possible ? I mean, at the very least, the CPU itself must be able to access extended RAM, so even if the Antic cannot access ext.ram, Antic can at least function as by default - e.g. access whole Main RAM.

 

I mean, mode 1 and 2 are surely non-negotiable, right ? There's no way some particular HW implementation wouldn't be able to access extended RAM for CPU, as at that point, what's the point ?

 

Yeah, that's usually a nice small bonus, but most importantly, the unrolled code for ClearScreen, isn't duplicated for both framebuffers - which is huuuuge and really limits what you can realistically do within just base 64 KB (and it's a reason why I use 160x96 for all my 3D coding).

 

Mode 2 is not available. If memory swaps, then Antic sees the swapped in memory. Antic loses the ability to see a different bank than the cpu with most of the upgrades. It always sees what the CPU sees.

[VladR]

Alfred means that with most 256+kB expansions there's no separation between CPU or Antic access. They always see the same RAM, either the base RAM or an extended bank. The separation bits are reused to access more banks.

So, those that have the "separation" issue, they support the Atari 130XE's Mode 4 (General Extended), but do not support Mode 3 (Antic Extended). Got it!

 

So, as long as I write code that doesn't attempt to access Main Ram's $4000-$7FFF from 6502 (while Antic is accessing that range from any of the four banks), it will basically work on 100% of RAM extensions, correct ? I guess I can store some Menu gfx and level load-time data into Main Ram's $4000-$7FFF, as it'll be virtually inaccessible (via 6502) during gameplay, then...

 

Here's the table again, as it's on previous page of the thread:

 

According to the Mapping The Atari, Appendix 16, Page 238-240, the 130 XE supports four distinct modes (VBE/CPE bits 5/4) via PORTB $D301:

1. Compatibility            CPU: Main     ANTIC: Main
2. CPU Extended             CPU: Ext      ANTIC: Main
3. Antic Extended           CPU: Main     ANTIC: Ext
4. General Extended         CPU: Ext      ANTIC: Ext

Note, that I personally don't need Mode 4 for this particular application, I really only need ANTIC to access the Extended RAM, that's all. Do all HW extensions support at least that ?

 

I am unclear which of the following is true for most common RAM upgrades:

1. Neither Mode 3 and 4 are supported (e.g. Antic simply cannot access Extended RAM at all - I hope that's not the case and I'm simply misreading other threads)

2. Mode 4 is not supported (e.g. Antic can access Ext.RAM, but CPU cannot access same extended bank at the same time)

3. Mode 3 is not supported (e.g. Antic can access Ext.RAM, but CPU is forced to access same extended bank at the same time in Access Window Address range $4000-$7FFF)

 

I guess that begs the question - are there also some common RAM upgrades that would support Mode 3 but NOT support Mode 4 ? The HW landscape of upgrades is incredibly fragmented...

[VladR]

I see, so I did initially interpret the separation incorrectly ! Thanks!

 

So, here's the final table of the generally supported modes across all RAM extensions (meaning, including those that have separation issue):

1. Compatibility CPU: Main ANTIC: Main

2. CPU Extended CPU: Ext ANTIC: Main

3. Antic Extended CPU: Main ANTIC: Ext

4. General Extended CPU: Ext ANTIC: Ext

 

 

 

It always sees what the CPU sees.

That is definitely much easier for me to remember than go back to the table above and try to figure out what's what

[Alfred]

 

 

I guess that begs the question - are there also some common RAM upgrades that would support Mode 3 but NOT support Mode 4 ? The HW landscape of upgrades is incredibly fragmented...

 

Since almost nothing supports Mode 3, and everything supports 4, I would hazard that anything that did support 3 would also support 4.

[VladR]

Yeah, that seems logical, as once they can handle separation, there's no reason why they wouldn't both handle Ext.Ram access. But, of course, there might be HW considerations that could necessitate one-way connection (not a HW guy, so what do I know).

 

In all the PORTB threads that I searched yesterday, there were countless arguments that coder should "simply patch" his code to support the extensions without separate Antic access.

 

 

 

I have spent 2 hours yesterday, rearranging all tables and data in RAM and Ext RAM, and it's most definitely not a "simple patch". By not having Mode 3, I'm practically loosing 16 KB in main RAM that become inaccessible (outside of Loading screen, but I don't have 16 KB of level data, it's much much less, as it's vector gfx, so it doesn't help),so instead of 128 KB, I now have only 112 KB accessible at run-time. That's basically butchering the whole thing.

 

The miniscule few cycles during the vblank (when I could access those 16 KB at run-time) don't help either, as I need full 2 frames worth of CPU time to catch up (49,000 cycles), so that would butcher the framerate on 130XE (if I refactored it to access those 16KB), which is not fair to standard 130XE, just because majority of all upgrades is nonstandard (funnily enough, a lot of people ridiculously claim that 130XE is in itself non-standard :- ) ).

 

The best compromise I can come up with is that 130XE would have framerate of 30fps and all those RAMBO et al extensions with 256-1024 MB could only have 50% framerate of 15 fps, which sucks. All because of those 16 KB.

 

Third alternative means I'd have to fragment the code and data all over $C000-$FFFF, and that's so much work and issues and bugs (plus that would erase the DOS, various drivers, etc - requiring reset) that it would not double, but easily quadruple (and realistically, more) the total coding effort. Yeah, right - of course I'd rather not have another 2 or 3 demos done in the same timeframe (same coding effort, really) : )

 

 

 

The more I think about it, the more I'm sure that I'd rather have, say, 5% (or whatever the actual number of 130XE is) of all players play it at 30 fps, than 100% at 15 fps.