Jump to content
IGNORED

Brainstorming: Extended Memory 3D Engine Design


Recommended Posts

I would like this thread to serve as a summary of all considerations one has to make when making an engine that runs as optimally as possible on as wide range of memory extensions as humanly realistic. This is the list of relevant areas as I see them with my current level of understanding on the Atari's Memory Extensions:

 

1. Memory Access

1.1. Linear memory access : Antonia / 65816

  • while eventually I would like to make the switch to support 65816, this will not happen yet [for several years, most likely], so we can ignore it
  • How many extensions like Antonia 4 MB are there that support Linear memory access and / or 65816 ?

 

1.2. Non-Linear memory access : Bank - Switching

1.2.1 Platforms:

  • 130 XE : 4 banks

  • 192 KB : 8 banks

  • 320 KB : 16 banks

  • 576 KB : 32 banks

  • 1088 KB: 64 banks

1.2.2 Access Window mechanics

  • via PORTB bits, we select index of the bank we want to access
  • The 16 KB Window at $4000 - 7FFF is lost from the Main 62 KB, as this is where the indexed bank is mapped to

1.2.3 Accessor selection : 6502 vs ANTIC

  • Looks like certain extensions allow you to select whether ANTIC is reading from same selected bank or whether it reads from Main Memory

  • Apparently, certain extensions allow or do not allow this behavior

  • Implication being that if I choose a certain route, then the affected extensions will not be able to run the game

  • Is there a route which will work 100% on all extensions - e.g. both 6502&Antic reading the mapped bank ?

  • How many % of users will be affected if I choose to go the other route ?

2. Testing

2.1 SW Testing

  • Altirra - does Altirra support all the [many] available memory extensions ? Page 37 in the manual mentions only 4 configurations.

2.2 SW Emulation

  • I am thinking of having a set of compile-time flags that will limit the amount of banks, thus at least partially "emulating" the fragmented HW space

2.3 User-selected choice of RAM available

  • In the beginning, it appears to me that the easiest option of selection / detection which extension is available (on the system it's running on), is really just a simple GUI window that will let player select the amount of RAM he has. Of course, if he chooses wrong, tough luck.

2.4 HW Testing

2.4.1 Private Testing

  • I recently bought a U1MB Atari, so that's what I will be able to test on, and via options 2.2 and 2.3 (above) at least test the behavior of the game that runs on a system with less RAM.

2.4.2 Public testing

  • There really is no substitute to public testing on real HW, so I'm going to try to ask people to try the builds as often as possible. Unclear, if there will be interest...
  • Is there somebody (or, say, few people that would together have them all) who actually has all different extensions available and all plugged in ? Unlikely, I know, but doesn't hurt to ask...

3. Engine Design

3.1 Core features

  • Generic 3D Flatshading
  • Double Buffering
  • Resolution: 3,840 Bytes for 160x96x4 (potentially narrow mode : 128x96x4 -> 3,072 B). Later down the road (next few years), I'd like to branch out and try out flatshading in GTIA modes, but not now.
  • NTSC, target is 4 vblanks (e.g. 60/14 = 15 fps), but of course, 3D rasterizing is highly variable task, so framerate down to 1 fps for very complex scenes is entirely possible...
  • Using 64 KB - 2 KB ($D000-$D7FFF) = 62 KB for code (minus 16 KB for the bank)

3.2 Content vs RAM

  • The most logical and manageable option to me right now [from coding standpoint] appears to be to assign each RAM bank to level data.
  • So, on one end of the spectrum - 130 XE could still run the game (although have just 4 levels), but on the other end of spectrum : U1MB could have up to 64 levels.

3.3 Separate 2D screens in separate banks

  • If game will feature things like maps, menus, separate views (etc.) - it looks like the most logical thing to do is to merge the code+gfx into a separate bank so that they don't clutter the main 62 KB

3.4 Speed of Bank Switch

  • How many cycles does it take to switch the bank ?
  • This will define whether it's possible to keep switching between various lookup tables during the frame or not. Which is a big thing (the old RAM vs Speed consideration), as every single doubling of LUT size improves performance and accuracy

3.5 Framebuffer-specific code in a bank

3.5.1 Yes

  • Idea is that both framebuffers would be in main RAM
  • Two banks would be devoted to have rendering code hardcoded to those 2 addresses
  • This gives me 16 KB (not really much, but better than nothing) of unrolled code, hardcoded to specific framebuffer
  • This is the fastest rasterizing option, as it allows removing all indexing modes, and just use fastest-possible STA $502F addressing mode
  • This means that Antic has to be able to read from RAM, while CPU from bank, so it won't work on all memory extensions.
  • I already tried, and this simply cannot fit in its full unrolled glory into 62 KB - 16 KB (for bank) = 46 KB with all LUTs and framebuffers

3.5.2 No

  • This means we have to use direct and indirect addressing, so we can have just 1 codepath that can cover both framebuffers
  • Since the code is generic, there's a considerable loop performance overhead (INY+DEX+BNE = 2+2+3 = 7 cycles per iteration for forward addressing and DEX+BNE=5 cycles per iteration of backwards addressing (which, however, results in significant one-time initialization cost)) and indexing overhead (50% more cycles for STA).
  • This would work on all memory extensions, as that code is short (as it's not unrolled, though it could be partially unrolled (just not fully as in 3.5.1)) so it can be in Main memory.

 

Thank you for any feedback on any of the points.

  • Like 3
Link to comment
Share on other sites

A long long time ago, in another universe, I collected some available A8 information and wrote something like this:

 

http://www.atarimania.com/faq-atari-400-800-xl-xe-what-kinds-of-extra-ram-and-ramdisks-can-be-installed_73.html

 

Have not updated that list for more than a decade and do not really want to. Owned two 800XL computers with U1MB and gave them away, still own two 800XL computers with 512k SRAM (and I'm planning to upgrade two more 800XL computers with 512k SRAM).

 

Note: When creating a program that requires more than, say 128k RAM, one should consider that not every A8 owner is using emulation or real A8 + harddisk (e.g. Black Box, MIO, My-IDE, SIDE, IDE+/IDE-2, etc.). There are still Atarians loading programs from diskette or emulated diskette (SIO2xxx). Loading 320k programs from disk(s) takes quite some time, loading 1MB programs from disk(s) takes some 10-15 minutes (and several disk-swaps), too long for most users...

 

So it would be nice to have alternative options, like: a) bank-switching program loaded from disk (e.g. with a floppy-disk speeder) into XRAM/Ramdisk, b) bank-switching program loaded from cartridge, c) non-bankswitching program loading into 16MB (65816) linear memory. Furthermore, if I have to load the program from "slow" diskette and have to wait for 15 minutes, but die after one or two short levels of play, I will not play the program very often... (playing time vs. loading time). I am also quite sure, that if you code a very big A8 program nowadays, VBXE users will ask for support of their enhancement, as well as the already mentioned 65816 users...

Edited by CharlieChaplin
  • Like 2
Link to comment
Share on other sites

Ultimate 1 Meg and some other modern expansions means there's plenty more people's machines satisfying the top requirements.

 

Still, you'd probably get a much bigger audience limiting Ram requirements to 320K.

 

But really, with large flashcarts available there's not really reason to need huge amounts of Ram. Entirely possible to get the same or better result using a 1 Meg cart on a 128K Ram system as using a peripheral loaded program on 1 Meg Ram.

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

1.2.3 Accessor selection : 6502 vs ANTIC

  • Is there a route which will work 100% on all extensions - e.g. both 6502&Antic reading the mapped bank ?

In my opinion yes, if you go that way. All A8's with port-B XRAM ($D301) do support CPU& Antic reading the same bank, so it will work 100% on all Ataris with XRAM. (As long as you have the correct banks / the correct setup/config for your type of XRAM.) The only thing I am not sure, is what will happen on Ataris where the base 64k RAM is replaced with XRAM, since I never owned such an Atari. Most XRAM detection programs do falsely detect part of the base RAM as XRAM there (e.g. if you replace 64k base RAM with 256k RAM, you end up with 64k base RAM and 192k XRAM, but most XRAM detection programs see something else, e.g. 48k base RAM and 208k XRAM or something like that; as said before I never owned such XRAM). So it is absolutely required to make the available XRAM configurable !

  • How many % of users will be affected if I choose to go the other route ?

I cannot tell in numbers or percentage, but afaik all RAM enhancements that use Rambo-style (8ACE) banks do not have sep. Antic access (it is not possible there!) and therefore the program will not work. Even some (most?) Compyshop compatible RAM-enhancements do not have sep. Antic access out-of-the-box available it seems. When I only had 256k XRAM in my 800XL, it was Compyshop-compatible, used the banks 26AE (=Compyshop type!) and still none of the programs that required sep. Antic access worked. (Maybe I would have had to install an extra cable or add the Gate Array chip or whatever, I do not know.) I would *guess* that more than 50% of the Atarians using real Ataris will be unable to run a program using sep. Antic access... but it is only a guess. Waiting for Mathy to get angry at me, errm, to tell you more here... ;-)

 

.4.2 Public testing

  • There really is no substitute to public testing on real HW, so I'm going to try to ask people to try the builds as often as possible. Unclear, if there will be interest...
  • Is there somebody (or, say, few people that would together have them all) who actually has all different extensions available and all plugged in ? Unlikely, I know, but doesn't hurt to ask...

 

I do own two 800XL with 576k SRAM. So a program requiring 1MB will not work ! None of my Ataris do have VBXE, U1MB or 65816, so that is something I cannot test. The two upgraded Ataris do have the 576k always present - so all programs requiring either Compyshop (26AE) or Rambo (8ACE) or any of the available 32 banks (8 blocks with four 16k banks each) will work on them. But programs requiring sep. Antic access do not work on these upgraded Ataris. I would be willing to test your program, but can never say, it works on Compyshop or it works on Rambo, since I have both standards available at the same time. My "bank account":

 

block 0: 03, 06, 0b, 0f

block 2: 23, 26, 2b, 2f

block 4: 43, 46, 4b, 4f

block 6: 63, 66, 6b, 6f

block 8: 83, 86, 8b, 8f

block A: A3, A6, AB, AF

block C: C3, C6, CB, CF

block E: E3, E6, EB, EF

 

See, this is not the same as a U1MB in 576k mode (my XRAM has 8 blocks x 4 banks, whereas U1MB has 4 blocks x 8 banks: only blocks 26AE with 8 banks each). But with my XRAM config. all DOS 2.x types that are limited to a max. of four banks per block (e.g. DOS 2.5, Turbo-DOS, Bibo-DOS, Super-DOS, XDOS, etc.) work fine, while they crash on U1MB in 576k and 1MB mode. (Tested this, when I had two computers with U1MB: Spartados and compatibles worked fine in 576k and 1MB mode, MyDOS worked fine when in 576k or 1MB mode, most DOS 2.x versions however crashed or hanged the system when in 576k or 1MB mode.)

Edited by CharlieChaplin
  • Like 1
Link to comment
Share on other sites

Ultimate 1 Meg and some other modern expansions means there's plenty more people's machines satisfying the top requirements.

Yeah, But I figure that, say, 10-15 years ago (or so), the 256 KB expansions were the norm, and probably lots of those people don't want to mess with soldering, so they keep the 256 KB expansion, as there's probably not a big reason to upgrade to 1 MB anyway (though, apparently, RAM upgrades are very popular)...

 

Also, since it's flatshading, I really don't think that levels will consume that much RAM, but I know that already right now, with all tables and unrolled code, it won't fit into 128 KB (not with the unrolled rendering code, that is), so realistically, I need 256 KB + content.

 

Also, imagine 1,024 KB spent on triangle list - that's a lot of content, considering the ultra-low polycount of objects :)

Now, if there were to be some 2D bitmaps (say, for story/mission screens), then filling up 1 MB is easy, but I'm not a huge fan of wasting the RAM...

 

Still, you'd probably get a much bigger audience limiting Ram requirements to 320K.

I think it should be possible to do a build that would run on stock 130 XE:

- it won't have unrolled fast rendering code, tables will also be largely reduced, so framerate and 3D precision will definitely suffer

- it'll have the least amount of content possible (like, 1 level - so more like a demo than game)

- but it would run on stock machine

- I have recently vastly upgraded my jaguar's 3D engine in terms of compile-time configurability - via 4 flags I have a total of over 32 possible variations (with varying amounts of unrolling, software, hardware codepaths, and combinations thereof), so I would do the same for 6502. I already can, on 6502, via flags, choose between heavily unrolled code or generic loop. Shouldn't be too much work to have a separate build for stock 130 XE, I think....

 

But highly likely, the 320KB will be a reasonable [content-wise] minimum.

But really, with large flashcarts available there's not really reason to need huge amounts of Ram. Entirely possible to get the same or better result using a 1 Meg cart on a 128K Ram system as using a peripheral loaded program on 1 Meg Ram.

Can you elaborate a bit ? I'm not really familiar with the cart solutions on A800 (though I bought some kind of blue multicart with my U1 MB, it's all still in the box though).

 

Do you perhaps mean that I could just swap the banks into main ram via PORTB from the multicart like I do with extended RAM ?

Link to comment
Share on other sites

  • Is there a route which will work 100% on all extensions - e.g. both 6502&Antic reading the mapped bank ?

In my opinion yes, if you go that way. All A8's with port-B XRAM ($D301) do support CPU& Antic reading the same bank, so it will work 100% on all Ataris with XRAM. (As long as you have the correct banks / the correct setup/config for your type of XRAM.) The only thing I am not sure, is what will happen on Ataris where the base 64k RAM is replaced with XRAM, since I never owned such an Atari. Most XRAM detection programs do falsely detect part of the base RAM as XRAM there (e.g. if you replace 64k base RAM with 256k RAM, you end up with 64k base RAM and 192k XRAM, but most XRAM detection programs see something else, e.g. 48k base RAM and 208k XRAM or something like that; as said before I never owned such XRAM). So it is absolutely required to make the available XRAM configurable !

 

Unfortunately, that also means significant rendering performance penalty for about ~50% of the users that do support separate CPU/Antic access and that's not fair either...

 

Hypothetically, once all engine and game components are up&running, I will know how much RAM I can spend on such rasterizer, and could do few levels of unrolling, but I don't like the idea....

 

 

  • How many % of users will be affected if I choose to go the other route ?

I cannot tell in numbers or percentage, but afaik all RAM enhancements that use Rambo-style (8ACE) banks do not have sep. Antic access (it is not possible there!) and therefore the program will not work. Even some (most?) Compyshop compatible RAM-enhancements do not have sep. Antic access out-of-the-box available it seems. When I only had 256k XRAM in my 800XL, it was Compyshop-compatible, used the banks 26AE (=Compyshop type!) and still none of the programs that required sep. Antic access worked. (Maybe I would have had to install an extra cable or add the Gate Array chip or whatever, I do not know.) I would *guess* that more than 50% of the Atarians using real Ataris will be unable to run a program using sep. Antic access... but it is only a guess. Waiting for Mathy to get angry at me, errm, to tell you more here... ;-)

Even if it was only around 30-40%, then that'd be unacceptable. I'm sure it'd enrage lots of people...

 

So, really, the slower shorter reference rasterizer actually has to be a fallback option, probably best selectable from the start-up menu (alongside the RAM size).

 

Better if it runs slow, then not at all...

 

 

 

 

I do own two 800XL with 576k SRAM. So a program requiring 1MB will not work ! None of my Ataris do have VBXE, U1MB or 65816, so that is something I cannot test. The two upgraded Ataris do have the 576k always present - so all programs requiring either Compyshop (26AE) or Rambo (8ACE) or any of the available 32 banks (8 blocks with four 16k banks each) will work on them. But programs requiring sep. Antic access do not work on these upgraded Ataris. I would be willing to test your program, but can never say, it works on Compyshop or it works on Rambo, since I have both standards available at the same time. My "bank account":

 

block 0: 03, 06, 0b, 0f

block 2: 23, 26, 2b, 2f

block 4: 43, 46, 4b, 4f

block 6: 63, 66, 6b, 6f

block 8: 83, 86, 8b, 8f

block A: A3, A6, AB, AF

block C: C3, C6, CB, CF

block E: E3, E6, EB, EF

 

See, this is not the same as a U1MB in 576k mode (my XRAM has 8 blocks x 4 banks, whereas U1MB has 4 blocks x 8 banks: only blocks 26AE with 8 banks each). But with my XRAM config. all DOS 2.x types that are limited to a max. of four banks per block (e.g. DOS 2.5, Turbo-DOS, Bibo-DOS, Super-DOS, XDOS, etc.) work fine, while they crash on U1MB in 576k and 1MB mode. (Tested this, when I had two computers with U1MB: Spartados and compatibles worked fine in 576k and 1MB mode, MyDOS worked fine when in 576k or 1MB mode, most DOS 2.x versions however crashed or hanged the system when in 576k or 1MB mode.)

 

Can you please explain the 26AE thing and why does it matter from programmer's standpoint if the block has 4 or 8 banks ? I mean, via PORTB, you do not select the block, only index of the bank, correct ? It's the job of the HW memory controller to remap the bank into physical block after all, right ?

Link to comment
Share on other sites

The most common flashcart example is the Atarimax one - 128K and 1 Meg (bytes not bits).

 

Both allow banking 8K in at a time or disabling completely to allow access to the 8K Ram if it's present underneath.

Common use might be either run code directly from Rom or move from Rom into Ram.

The disadvantages:

- since the Rom lives in just an 8K section, your code if executing from there has to live there and you have multiple instances of program sections that live in the one place and have to take care of bank selection for subroutines etc carefully. Though this problem exists as well for extended Ram though it has 16K blocks in most cases.

- you can't do arbitrary writes to flash. They have to be performed in such large blocks that generally you'd only use it for savegames or applying patches to the game.

  • Like 1
Link to comment
Share on other sites

Hello VladR

 

If you want to support big memory expansions, using a small routine to test which bits are used for banking shouldn't be a problem. The same is true for a routine that detects if separate ANTIC and CPU access is possible.

 

- sarcasme mode ON -

 

But please don't write big programs. Some people only have a 1010. Loading software > 48 KB will take days. And then a loading error appears and you have to start all over again. What if you load the cassettes in the wrong order? Because that stack of cassettes fall over and you didn't number them correctly. Or they became unreadable because your persian cat zapped them with some static electricity?

 

- sarcasme mode OFF -

 

Sincerely

 

Mathy

 

  • Like 2
Link to comment
Share on other sites

imho separate antic access is an Atari design, and there should be no reason not to support it... when it wasn't supported in the Peterson upgrades we all added the fix later... just like compy and almost everything else did... it's not hard to fix or reconfigure a memory upgrade.... and frankly since it was by design for the Atari line to allow sep Antic access, any memory upgrade that does not support it shouldn't be considered an overriding factor not to support it. I am certain a fix could or would come from someone truely clever.... as has always been the case..

  • Like 1
Link to comment
Share on other sites

Hello Rybags

 

My XEGS has 64kB plus 1024KB, separate ANTIC and CPU access and full software controle over BASIC, Selftest, OS RAM/ROM and Missile Command. There is NO reason at all for not supporting separate ANTIC and CPU access.

 

Sincerely

 

Mathy

Link to comment
Share on other sites

A pretty half-arsed implementation, though. Without separate banking registers for the CPU and ANTIC, if you put your frame buffer in extended RAM (highly desirable), the CPU is tied to accessing that bank or main memory unless you want your display messed up. Doubtless handy in some game and demo scenarios but pretty much useless at the OS level.

Link to comment
Share on other sites

The most common flashcart example is the Atarimax one - 128K and 1 Meg (bytes not bits).

1 MB cart sure sounds great to have access to from just a bare 64K machine !

 

Thus, it's entirely possible to have a build that would require only 64 KB of RAM (although with obvious performance implications), with the rest banked from the cart.

Also, since full game would be on cart, I would not have to deal with various OS versions and figuring out if there's a single piece of generic code that can fill the extended RAM at start-up with all data.

 

 

Both allow banking 8K in at a time or disabling completely to allow access to the 8K Ram if it's present underneath.

Can you do the same with all of the extended RAM's solutions ? To be more specific:

1. Start of the game frame (long: lasts 4+ vblanks)

2. Banking disabled: Running RAM code from the $4000-$7FFF

3. Banking enabled: Running ROM code from the $4000-$7FFF

4. Banking disabled: Running RAM code from the $4000-$7FFF

5. End of the game frame

 

In other words, is the original RAM window's contents always preserved ? From reading the AtariMania FAQ on this (linked earlier in this thread), it looks like not all extensions preserve the RAM window ?

 

 

since the Rom lives in just an 8K section, your code if executing from there has to live there and you have multiple instances of program sections that live in the one place and have to take care of bank selection for subroutines etc carefully.

Yeah, that inconvenience is to be expected. But, I'm doing the initial 6502 prototyping from VisualStudio and C++ on PC, and already have various substages of the 3D pipeline at any time (via bool flag) replaceable by C or ASM code (kinda like a LEGO).

So, I imagine I'm going to do the same with bank switching and make sure it works high-level first (while implementing as much Atari code as possible - e.g. PORTB), then Altirra, then HW.

 

 

Though this problem exists as well for extended Ram though it has 16K blocks in most cases.

Wait, I thought ALL RAM extensions had 16 KB blocks, because that's the standard forced by 130XE ? Charlie mentioned that there's differences in BankCount per Block (hence some banks are invisible under certain circumstances under DOS (or something)).

 

I don't think a bigger bank size is possible to support. The next bigger bank from 16 KB is 32 KB, which would leave 62 KB (RAM) - 32 KB (bank) - 15 KB (DoubleBuffering) = 15 KB for all non-banked tables and code. Very undesirable situation from performance standpoint - basically almost no tables (or very short ones), and just calculate everything...

 

 

 

- you can't do arbitrary writes to flash. They have to be performed in such large blocks that generally you'd only use it for savegames or applying patches to the game.

Good point. I didn't think of save games at all yet. Besides, for Atari it's normal to have permadeath and start from scratch. But there's plenty schemes for that - e.g. hexadecimal codes for saves or code words to jump to a level etc.

Link to comment
Share on other sites

If you want to support big memory expansions, using a small routine to test which bits are used for banking shouldn't be a problem. The same is true for a routine that detects if separate ANTIC and CPU access is possible.

I'm pretty sure I'm not going to go the route of autodetect, because:

- the Extended memory landscape is incredibly fragmented, not even just one order of magnitude more than I thought initially, but way more

- the odds of certain HW implementation to not behave in a standard way are very high, and it remains unknown how big the impact would be as there are no official numbers as to which extension sold how many units

 

A simple user-based dialog with 2 choices at the start up of the game will take care of that. In worst case, if user has no idea, and happens to choose wrong, you just have to reset and try the other choice. That could be even autosaved as a setting.

  • Like 2
Link to comment
Share on other sites

Hello VladR

 

I'm pretty sure I'm not going to go the route of autodetect, because:

- the Extended memory landscape is incredibly fragmented, not even just one order of magnitude more than I thought initially, but way more

- the odds of certain HW implementation to not behave in a standard way are very high, and it remains unknown how big the impact would be as there are no official numbers as to which extension sold how many units

 

A simple user-based dialog with 2 choices at the start up of the game will take care of that. In worst case, if user has no idea, and happens to choose wrong, you just have to reset and try the other choice. That could be even autosaved as a setting.

 

 

So you are saying that our computers can not determine which bits are used, since there are a zillion options, but the user can select between two of those.

 

That sounds reasonable.

 

Sincerely

 

Mathy

Link to comment
Share on other sites

 

So you are saying that our computers can not determine which bits are used, since there are a zillion options, but the user can select between two of those.

 

Mathy

I have read enough threads on memory extensions to not trust the auto detection 100%.

 

There's going to be few players with configurations where it fails. If you get a pop up upon start up, you are gonna try again if it fails.

 

With auto detect you are screwed.

 

Presumably, early in the public testing phase, we will know the exact behavior of the test routine(glitch,etc.) and player will be instructed accordingly.

 

A very quick non crashing test scenario could be something like merging two bitmaps from 2 banks - if you got combined image, it works.

Link to comment
Share on other sites

  • 11 months later...

It's been 365 days, but I have a question regarding this so best to keep it at same thread:

 

For one specific demo that I'm working on now, I'd like it to run on an official stock 130XE (so I will only need 128 KB, not full megabyte). However, at run-time, I need to use FrameBuffer both in Main Ram and Extended RAM. So, Antic definitely needs to be able to access the Ext.RAM, because whole extended 64 KB will be precomputed at level load-time, and about 48 KB of main RAM will be used (for tables, code, etc.).

 

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)

 

 

Link to comment
Share on other sites

I think the rule regarding Antic is that it cannot see the extended ram by itself, like it can on the 130XE. It sees whatever bank is swapped in the for CPU to use. So from your chart, only modes 1 and 4 would be supported.

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 ?

 

AFAIK Alfred is right. I was just thinking about this the other day, how swapping between mode 2 and 3 every frame makes an easy double buffering with the same routine to do the drawing both times.

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

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

  • Recently Browsing   0 members

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