52K Memory on an XL/XE?

[+Larry]

Is this possible?  I used to use 52K for some BASIC programs (IIRC), but I'm pretty sure that was with an 800 using special hardware.  It was in the 1980's, so I've forgotten the details.  Possible with an 800 10K OS in an XL/XE? 

[baktra]

24 minutes ago, Larry said:

Is this possible?  I used to use 52K for some BASIC programs IIRC), but I'm pretty sure that was with an 800 using special hardware.  It was in the 1980's, so I've forgotten the details.  Possible with an 800 10K OS in an XL/XE? 

It is. There was a software called "OS translator disk" to run older software on XL/XE . It disconnects OS ROM and copies Atari 800 OS to RAM. The memory area from 48K-52K is free and unused by the older OS. So one can set RAMTOP and other memory size indicators to use those extra 4 KB. No hardware would be needed. 

Edited January 2, 2021 by baktra

[TGB1718]

1 hour ago, Larry said:

Is this possible?  I used to use 52K for some BASIC programs IIRC), but I'm pretty sure that was with an 800 using special hardware

Yes it was, I did it myself, see this link

 

 

[Rybags]

If you just wanted the 1K + hundred bytes or so around $CC00-$CFFF you could copy the OS to RAM and overwrite the second character set.

 

[+CharlieChaplin]

Ultra-Translator does this (and others too).

If you are using e.g. Howfen Tape2Disk on a 64k XL/XE you get approx. 360 free blocks for copying, use a Translator first and you then get 392 free blocks for copying...

 

[+Nezgar]

6 hours ago, Rybags said:

If you just wanted the 1K + hundred bytes or so around $CC00-$CFFF you could copy the OS to RAM and overwrite the second character set.

 

The BOSS-XL and Omniview XE OS's have built in functions to copy the OS to RAM and give 52K RAM to the system. I noticed the happy utilities recognized 52K, and could copy 1 additional track before disk swap in happy backup.

 

https://atariage.com/forums/topic/288214-52k-atari-800-did-anyone-else-do-this/?do=findComment&comment=4221257

 

Of course if BASIC is enabled, it will result in non-contiguous RAM, with the main contiguous RAM under the 40K mark as usual, and the extra 4K above the 48K mark.

[ivop]

12 minutes ago, Nezgar said:

Of course if BASIC is enabled, it will result in non-contiguous RAM, with the main contiguous RAM under the 40K mark as usual, and the extra 4K above the 48K mark.

I suppose not if you do what  baktra said:

7 hours ago, baktra said:

So one can set RAMTOP and other memory size indicators to use those extra 4 KB.

The display list and screen memory should end up at $CC00 instead of $BC00, and ?FRE(0) shows the extra 4096 bytes.

[+Nezgar]

37 minutes ago, ivop said:

The display list and screen memory should end up at $CC00 instead of $BC00, and ?FRE(0) shows the extra 4096 bytes.

If you do that, FRE(0) will actually show 12288 extra bytes - "usuable RAM" will overlap the 8K BASIC ROM space - so a large enough program may corrupted if it grows past the 40K mark in the memory map - and OS graphics modes that need more than 4K will also fail as the display list and start of screen memory will descend into the ROM area as well.

[ivop]

4 minutes ago, Nezgar said:

If you do that, FRE(0) will actually show 12288 extra bytes - "usuable RAM" will overlap the 8K BASIC ROM space - so a large enough program may corrupted if it grows past the 40K mark in the memory map - and OS graphics modes that need more than 4K will also fail as the display list and start of screen memory will descend into the ROM area as well.

I see. I forgot about the ROM portion   So in theory, up to graphics 7, the screen memory could live above the BASIC ROM, and then you have 1-4kB extra space below the BASIC ROM? Set RAMTOP above the ROM, call graphics 7, then set RAMTOP back to below the ROM. Could that work?

[Faicuai]

9 hours ago, Larry said:

Is this possible?  I used to use 52K for some BASIC programs (IIRC), but I'm pretty sure that was with an 800 using special hardware.  It was in the 1980's, so I've forgotten the details.  Possible with an 800 10K OS in an XL/XE? 

I don't think it is possible to do it like it is done on the 800/Incognito (in Colleen-52K) or with 800 / RAMROD (on Slot-0) with $C000-$CFFF populated with ram and dip-switched accordingly (it can be done on the XL, however, for work that is not sensitive to volatility on that region).

 

The reason is because on the XL/XE address-space, you will need to bank-out ROM and bring $C000-$FFFF 16KB ram in, while ensuring you are running a OS-load  that will NEVER need $C000-$CFFF, and also make sure the XL/XE  MMU NEVER, EVER banks-out the 16KB RAM and brings back the original 16KB rom-space, especially during resets / restarts or other operations.

 

I currently use the 800/Incognito on Colleen 52K mode (and my test-bed 800 / Ramrod), frequently, with SDX 4.49... With my custom-builds of Avery's XEP80 ultra-speed drivers (and an embedded, tiny memory manager), I load such XEP drivers on $C600-$CCXX, instruct the OS to move the std. screen buffer to the last 960 bytes (which I never use with XEP-driver, thus avoiding disruption of AXLON banking control), and end up with a nice, contiguous block of base-RAM, without such address-space or OS-load ever banking out, and all with a 80-columns display. The same scheme is also usable without XEP drivers themselves, as it will equally deliver an additional 1KB free on $9C40-$9FFF space, which Basic, Assembler Editor and many others will enjoy from.

 

My 0.02c

 

 

 

 

[+Nezgar]

1 hour ago, ivop said:

I forgot about the ROM portion   So in theory, up to graphics 7, the screen memory could live above the BASIC ROM, and then you have 1-4kB extra space below the BASIC ROM? Set RAMTOP above the ROM, call graphics 7, then set RAMTOP back to below the ROM. Could that work?

I was playing around with a program from a Creative Computing review of the Mosaic 64KB upgrade for the 800 - which adds 4K of RAM to make a similar 52K, but that has 4x4KB banks too.

 

http://www.atarimuseum.com/computers/8BITS/3rdparty/ExpansionBoards/Memory/Mosiac/Mosaic64k-creative_atari.htm

 

This program creates a graphics 5+16 screen - I think graphics 6+16 or 7+16 might use more than 4K when display list is added. But it creates this screen in all 4 banks, and then page flips the 4 banks, each of which also contain the display list data below the screen memory... I vaguely recall GR.7 command in basic at least would result in a corrupt display with RAMTOP set at 52K...

[+David_P]

You could build a DL in main memory and store the graphics in the high 4K and flip the banks without worrying about the DL.  Mind you, you're getting outside the realm of BASIC for that.