Separate Antic/CPU access...?!?

[+CharlieChaplin]

Hello folks,

 

I would like to know how many of you actually have sep. Antic/CPU access to the RAM / XRAM...

 

- standard means: e.g. a 130XE with 128k RAM, it is the standard there (or any XL/XE upgraded to 128k RAM in the same way as and/or fully compatible to the 130XE)...

 

- via hardware/software means: via a hardware/software switch (or hardware/software I may not know), so even 128k / 192k / 256k / 320k / 512k / 576k / 1024k / 1088k RAM enhancements become fully 130XE compatible and provide sep. Antic/CPU access...

 

- not possible: the RAM enhancement (e.g. Rambo/AM/TOMS/...) uses the bits for other XRAM blocks, so sep. Antic/CPU access is not possible there...

 

- not yet: sep. Antic/CPU access is possible, but not built-in (e.g. Megaram 1,2,3 enhancements with 256k XRAM), so one has to do it himself...

 

- don`t know: I never tested this, I never cared about this, I have no knowledge about this, etc.

 

Let me know, if you have some suggestions for more choices. Me, I have 512k XRAM (576k total memory) by mega-hz and I could add switches do downgrade to 256k Compyshop mode and thus make sep. Antic/CPU access available, but I did not (and do not) want to add any switches to the enhancement, so sep. Antic/CPU access is not available for me yet (= option: NO, not yet). In the end I would like to see, how many of you choose "no" and how many choose "yes". My guess in the wild is that we have more no`s than yes`s, but lets wait and see...

 

-Andreas Koch.

 

P.S.: You are allowed to select multiple answers...

[jaybird3rd]

My 130XE machines support it, of course. Also, I have a 128K XEGS which is fully 130XE-compatible thanks to the Innovative Concepts upgrade (which I posted in another thread), and this supports it also.

[Rybags]

130XE standard, so you know the drill there.

 

800XL base 64K + 512K on VBXE, so MEMAC banking there with seperate CPU/Antic access.

[+bf2k+]

I have so many... 800s, 1200xls, 800xls, 600xls, 130xes & 65xes and an XEGS. I guess almost all those answers apply to me.

[flashjazzcat]

Just one unmodded 130XE. Separate ANTIC and CPU access was such a useful feature but I never used it for apps (I know demos often used it) because so many parts of DOS used the extended banks. Plus which, it was only possible with selected memory set-ups. Having the display RAM in extended memory was a great idea: only with VBXE can we put this kind of idea to practical use.

 

RAM upgrades would have benefitted from more bits in the bank selection register so that a bank could be assigned and left intact with ANTIC permanently pointing to it. Real shame that never happened.

Edited January 4, 2010 by flashjazzcat

[HiassofT]

Having the display RAM in extended memory was a great idea: only with VBXE can we put this kind of idea to practical use.

 

RAM upgrades would have benefitted from more bits in the bank selection register so that a bank could be assigned and left intact with ANTIC permanently pointing to it. Real shame that never happened.

IMO the way Atari implemented separate CPU/ANTIC access makes it pretty useless. If you put screen data into extended memory you can't really access the rest of the extended memory (only during vblank, otherwise the screen will flicker).

 

A better solution, for example, would have been to add 2 bank-bits for ANTIC bank selection (instead of the combined CPU/ANTIC bank bits). So one would have 3 bits for CPU and 3 for ANTIC (one controlling standard/extended memory access, the other 2 bits for banks). While ANTIC accesses, lets say, bank 1, the CPU could still access banks 2-4 without interfering with the displayed screen.

 

BTW: I have a stock 130XE, two 800XLs with (different) 1MB upgrades and a 600XL with a 512k upgrade (plus several stock 800XLs and a 65XE). All upgrades support separate ANTIC access but usually they are configured to the largest mode without separate ANTIC access. I only flip the switches if I have to do some (soft- or hardware) testing.

 

so long,

 

Hias

[MEtalGuy66]

It's not useless.. You use base ram for screen memory, and write your CPU code to run from 16k banks.. Leave ANTIC alwayse pointed to BASE RAM. Then put a service routine somewhere above $7FFF that brings the CPU into main ram, does whatever manipulation you need to screen data, and then returns the CPU to whatever extended bank was selected..

 

This allows you to have almost 30k just for screen data if you want it, as many 16k banks as you need for your CPU code.. And you don't have to run anything in the VBI interval..

 

Separate Antic/CPU access is one of the kewlest things atari EVER did.. and to delete this feature in favor of a single aditional bit of extended ram adressing is completely ASSANINE.. Take the useless self-test bit instead.. Or better yet, just build a small circuit to decode an entire additional 8-bit register in the PIA shadowed adress space.. Then you can go up to 16megs without changing ANY of the stock 130xe PORTB bit assignments..Your machine will remain 100% 130XE compatable, and have the ability to use 1024 16k banks for software that "knows" about the extra register..

Edited January 4, 2010 by MEtalGuy66

[flashjazzcat]

It's not useless.. You use base ram for screen memory, and write your CPU code to run from 16k banks.. Leave ANTIC alwayse pointed to BASE RAM. Then put a service routine somewhere above $7FFF that brings the CPU into main ram, does whatever manipulation you need to screen data, and then returns the CPU to whatever extended bank was selected..

I would have preferred the screen RAM in an extended bank, just to keep it out of the way of the executable in main memory. Obviously code in main RAM would have to be fairly carefully organised, but this kind of arrangement would have been a godsend for applications using hi-res graphics, which otherwise wipes out 8K in conventional memory.

[MEtalGuy66]

Well, like it or not, this is how it was implemented by ATARI.. and it's not hard to write your "executable" in "banked" code.. People do it all the time for cartridges..

 

Yes, it is possible to modify the hardware to add some additional control for separate antic/cpu access.. but this will never be a "standard" because theres thousands of machines out there that came stock with the existing standard.. so why not learn to make effective use of the standard rather than try to change it, and have your software dependant on some hack..

[sloopy]

altho the current setup is useful, i would like the idea of being able to set antic access to its own bank and still have cpu access other banks with no negative effects... but i have to agree with metalguy66, removing the seperate antic access for an additional 16K bank is stupid, especially considering how easy it is to use the basic bit, and using a cart for basic... or get rid of basic and run assembler of some type...

 

sloopy.

[MEtalGuy66]

altho the current setup is useful, i would like the idea of being able to set antic access to its own bank and still have cpu access other banks with no negative effects... but i have to agree with metalguy66, removing the seperate antic access for an additional 16K bank is stupid, especially considering how easy it is to use the basic bit, and using a cart for basic... or get rid of basic and run assembler of some type...

 

sloopy.

 

Each additional bit does not add one additional 16k banks.. it doubles the number of 16k banks..

But if you ask me, 576k is an ASSLOAD for an 8-bit atari.. if you cant write your code in 576k, something is wrong.. So you use bits 1,2,3,6, and 7 for bank select.. and leave bits 0,4, and 5 the way ATARI intended.. You get 512k of extended ram, separate antic/CPU access (the way atari intended) and you loose internal BASIC and SELF-TEST..

[HiassofT]

It's not useless.. You use base ram for screen memory, and write your CPU code to run from 16k banks.. Leave ANTIC alwayse pointed to BASE RAM. Then put a service routine somewhere above $7FFF that brings the CPU into main ram, does whatever manipulation you need to screen data, and then returns the CPU to whatever extended bank was selected..

 

This allows you to have almost 30k just for screen data if you want it, as many 16k banks as you need for your CPU code.. And you don't have to run anything in the VBI interval..

Yes, this would be a possibility, but it's still quite tough and/or slow to use. If you have your screen memory outside $4000-$7FFF you can keep code and data both in standard and extended memory and don't need to toggle the CPU access bits when you want to copy data from extended memory to screen memory. And you can also put code into extended RAM (for example large unrolled loops) that directly write into screen memory.

 

so long,

 

Hias

[MEtalGuy66]

It's not useless.. You use base ram for screen memory, and write your CPU code to run from 16k banks.. Leave ANTIC alwayse pointed to BASE RAM. Then put a service routine somewhere above $7FFF that brings the CPU into main ram, does whatever manipulation you need to screen data, and then returns the CPU to whatever extended bank was selected..

 

This allows you to have almost 30k just for screen data if you want it, as many 16k banks as you need for your CPU code.. And you don't have to run anything in the VBI interval..

Yes, this would be a possibility, but it's still quite tough and/or slow to use. If you have your screen memory outside $4000-$7FFF you can keep code and data both in standard and extended memory and don't need to toggle the CPU access bits when you want to copy data from extended memory to screen memory. And you can also put code into extended RAM (for example large unrolled loops) that directly write into screen memory.

 

so long,

 

Hias

 

But then you gain nothing from the standpoint of separate antic/cpu access.. The main advantage here is MORE screen memory for ANTIC.. For instance, you could employ a 640x400 "superbitmap" in BASE RAM and use full vertical/horizontal scrolling via simple display list manipulation.. This would hog up just about all available RAM in the base memory map.. But you could still write a really extensive application using banked code in extended RAM, and a small custom-tailored/optimized screen-manipulation routine stuck somewhere in BASE ram.. And no it's not "slow" if you code it right..

[HiassofT]

But then you gain nothing from the standpoint of separate antic/cpu access..

This is correct. As I already wrote the separate Antic access is pretty useless IMO.

 

The main advantage here is MORE screen memory for ANTIC.. For instance, you could employ a 640x400 "superbitmap" in BASE RAM and use full vertical/horizontal scrolling via simple display list manipulation.. This would hog up just about all available RAM in the base memory map..

Then think a step further. 640x400 might be nice, but for some other applications you might want to have a larger "screen". Some 20 years ago I wrote a simple graphics program that used my 256k RAM extension as a screen (so that I could create graphics to be printed on my 24pin Epson printer at 180 or 360 dpi). The main application was written in assembler and TurboBasic and IIRC some assembler code blitted data from extended RAM to screen memory (also in main memory). So I had all main memory (except 8k of screen RAM) free for code plus 256k of data space.

 

The time needed to transfer 8k of RAM was OK for this kind of application, since scrolling didn't happen that often.

 

For other programs, like for example games, fast(er) screen updates are really a must. And in these cases it's a good choice to keep screen memory in another location than program/data memory. Just compare the length of code and cycles needed for copying 256 bytes of data from extended RAM to a) $8000 or b) $4000 in main memory. You'll also need an additional buffer in main memory for case b) if you want to avoid setting portb 2 times for each byte you want to transfer...

 

Some time ago I also thought that the separate Antic access was a nice feature, but after looking closer and trying to make use of it I realized it was really a PITA to use.

 

so long,

 

Hias

[andym00]

But then you gain nothing from the standpoint of separate antic/cpu access.. The main advantage here is MORE screen memory for ANTIC.. For instance, you could employ a 640x400 "superbitmap" in BASE RAM and use full vertical/horizontal scrolling via simple display list manipulation.. This would hog up just about all available RAM in the base memory map.. But you could still write a really extensive application using banked code in extended RAM, and a small custom-tailored/optimized screen-manipulation routine stuck somewhere in BASE ram.. And no it's not "slow" if you code it right..

 

Or actually use 256 byte wide screens in a useful fasion without having to interleave your code into the remaining 64/128/192 bytes per scanline left over

 

edit: Oh, and the vote answer is both yes and no.. 130XE + a stock 800XL

Edited January 4, 2010 by andym00

[Mathy]

Hello Ken

 

So you use bits 1,2,3,6, and 7 for bank select.. and leave bits 0,4, and 5 the way ATARI intended.. You get 512k of extended ram, separate antic/CPU access (the way atari intended) and you loose internal BASIC and SELF-TEST..

 

No. You use bits 0,1,2,3,6 and 7 to switch banks, leave 4 and 5 as Atari intended them to be used and you DO NOT loose control over BASIC, SelfTest, OS RAM/ROM and on the XEGS Missile Command. :D

 

greetings

 

Mathy

[MEtalGuy66]

Hello Ken

 

So you use bits 1,2,3,6, and 7 for bank select.. and leave bits 0,4, and 5 the way ATARI intended.. You get 512k of extended ram, separate antic/CPU access (the way atari intended) and you loose internal BASIC and SELF-TEST..

 

No. You use bits 0,1,2,3,6 and 7 to switch banks, leave 4 and 5 as Atari intended them to be used and you DO NOT loose control over BASIC, SelfTest, OS RAM/ROM and on the XEGS Missile Command. :D

 

greetings

 

Mathy

 

With about half the logic involved in your upgrade, Mathy, I can add 16 megs of 16k banks, not touch a single PIA bit, and retain 100% 130xe compatability. And not have any PHI2 problems, or have to deal with any latch conditions..

[MEtalGuy66]

Edit: That is not to say that what Mathy has done with the XEGS isn't cool.. I just meant to say that I personally would not choose that upgrade path for a 130XE..

Edited January 5, 2010 by MEtalGuy66

[atariksi]

I haven't voted yet as I just took apart my special 800XL that I hardly ever use. It has this board with Rambo XL written on it and some separate plug in board for the ROM socket that states "Fast Chip". Which catagory does this fall into?

 

Oh, there's a switch in the back that seems to control the BASIC cartridge. I didn't do this expansion-- someone did it for me-- but looks clean with not much wires running around.

[MEtalGuy66]

I haven't voted yet as I just took apart my special 800XL that I hardly ever use. It has this board with Rambo XL written on it and some separate plug in board for the ROM socket that states "Fast Chip". Which catagory does this fall into?

 

Oh, there's a switch in the back that seems to control the BASIC cartridge. I didn't do this expansion-- someone did it for me-- but looks clean with not much wires running around.

 

The RAMBO XL does not support separate ANTIC/CPU access.. It doesnt have the logic on board to do it, no matter what switches have been installed..

so the answer for that machine would be "no"..

[Rybags]

Fast Chip = probably almost certainly the OS with Newell improved Floating-point ROM.

[+rdemming]

Each additional bit does not add one additional 16k banks.. it doubles the number of 16k banks..

But if you ask me, 576k is an ASSLOAD for an 8-bit atari.. if you cant write your code in 576k, something is wrong.. So you use bits 1,2,3,6, and 7 for bank select.. and leave bits 0,4, and 5 the way ATARI intended.. You get 512k of extended ram, separate antic/CPU access (the way atari intended) and you loose internal BASIC and SELF-TEST..

 

You can use the self-test bit for bank-switching without loosing the self-test. You only need a little extra logic. When CPU access or ANTIC access is on, you use the self-test bit to select the bank. When CPU and ANTIC access are both off, you use the self-test bit to enable the self-test rom as normal. In self-test mode you don't need the extra memory banks anyway.

 

Robert

[MEtalGuy66]

The stock ATARI self-test is pretty useless.. One of the most useful applications I could think of for it would be to replace the code with a REAL memory tester program that could test ALL of your RAM.. in which case, you would need access to the extended banks with it enabled.. But why bother.. Its easy to load XRAM or some other memory checking app from disk.. Just eliminate the useless self-test..

[atariksi]

Fast Chip = probably almost certainly the OS with Newell improved Floating-point ROM.

 

If I turn off the BASIC with the switch and then power up the machine with OPTION held down, I get BASIC. So it looks like there's new OS in that board. Perhaps, there's some documentation floating around for that somewhere?

[atariksi]

The stock ATARI self-test is pretty useless.. One of the most useful applications I could think of for it would be to replace the code with a REAL memory tester program that could test ALL of your RAM.. in which case, you would need access to the extended banks with it enabled.. But why bother.. Its easy to load XRAM or some other memory checking app from disk.. Just eliminate the useless self-test..

 

The machine that I posted picture of above does check extra memory in the self-test with extra green rectangles (not squares). I guess it's still useless if the memory test itself uses RAM in order to run. Perhaps, they can write a routine that uses ROM and registers only.