From 16KB to 4,256KB under 1-min: Pushing the 800 limits... and beyond!

[Faicuai]

 

... Multi-vendor, plug-and-play Memory expansions?  80-columns Video Cards? $4000-$7FFF Banking? $C000-$CFFF Banking?

 

Well, it turns out that all these things already existed well before PortB-banking (!)... Since I jumped straight from the 400 to the 800XL, I always wondered how far the 800 (that I could never have) could really go... until now!

 

Thanks to (reifsnyderb) and his neatly designed RamRom-2022 (personality card) and Mega-4 (ram-card) sleek combo, the wait is finally over! By directly leveraging on the 800 architectural strengths, we can ALL now enjoy pure 800-goodness, without being at the mercy of eBay:

 

1. Instant, plug-and-play, no-soldering installation:
   • just open the expansion bay compartment, pull out all existing cards, and plug in Personality, Jumper and RAM cards in slots 0,1 and 2, respectively, and VOILA !!
   • Special-purpose Slot-3 is finally FREE, for use with Bit3 FullView 80-col card (for instance), even with RAM fully expanded! YAYYYYYYY !!
2. On Slot-0:
   • up to 64KB of manually-banked ROM-space (flash-chip has 128KB capacity)
   • four (4) possible OS flash "slots" (16KB each, $C000-$FFFF) PLUS complete set of on-board sockets for legacy OS rom chips, too!!
   • $C000-$CFFF address space can be RAM-enabled (52KB), ROM-enabled (from same space in ROM-slot, like OS/N Omnimon) or disabled!
   • Total of 128 KB of MOSAIC RAM, banked through $C000-$CFFF can be enabled or disabled (even if disabled, above setting can leave one (1) 4KB RAM-bank usable if set above!)
   • (32) Mosaic-banking addresses enabled from $FFC0 to $FFDF
3. On Slot-2:
   • In Address Space $0000-$3FFF: first dedicated 16 KB of base-RAM
   • In Address Space $4000-$7FFF: 4,096 KB of AXLON-banked RAM (maxed out to Axlon's full 256 banks potential !!!) through $CFFF banking-address
   • In address-space $8000-$BFFF: last dedicated 16 KB of base-RAM
   • Total of 4,128 KB of RAM all available from Slot-2 (!)
4. Total of 4,256 KB of system RAM, across Slot-0 and Slot-2 (!)
5. Both MOSAIC and AXLON banking models are fully independent and can simultaneously remain active, if set so on Slot-0, and right under our direct control.
6. It seems that the 800's dual-floating bus also remains untouched, which means Wargames should be able to run with the proper settings on Slot-0 card.

 

Besides my 800-Incognito daily driver, I also have this rescued-by-miracle CTIA 800 (040-0077), that will never be subject to internal, non-reversible mods either. If you happen to be on this fence, YOU CANNOT miss this wonderful upgrade. Just LOOK: 

 

  

 

Right after 1-min of work, even the Bit-3 can also be installed:

 

  

 

And now the basic tests confirming bank-sizing and integrity:

 

 

 

And of course, a little "freak" test, opening a large 2MB text-file for viewing under SDX 4.49g integrated "XLESS" text-formatter, fully supporting AXLON-banking, as it can be seen (80col via XEP-80 for SDX-compatibility):

 

 

 

And NOTICE that SDX is INCORRECTLY reporting system-memory size, as there ARE. in fact, 256 memory banks independent of base memory (!).

 

If you are STILL reading here, you better go and grab your RamRom-2022 and Mega-4 cards while they are still available. Coupled with SIDE-2, will transform your bone-stock 800 into a little plug-and-play monster... but more on this later!

 

Enjoy!!!

 

 

Edited June 5, 2023 by Faicuai
(accuracy, completeness)

[drac030]

17 hours ago, Faicuai said:

And of course, a little "freak" test, opening a large 2MB text-file for viewing under SDX 4.49g integrated "XLESS" text-formatter, fully supporting AXLON-banking

It is not so XLESS supporting Axlon banking as SDX supporting Axlon banking: XLESS itself does not contain any code referring to any specific RAM expansion. The same is true for other utilities, e.g. resident drivers, COPY, etc. You should notice that if you e.g. copy your 2 MB file from disk to disk, COPY will do it in one read/write cycle. It is so because it uses the extension banks as copying buffer.

 

17 hours ago, Faicuai said:

And NOTICE that SDX is INCORRECTLY reporting system-memory size, as there ARE. in fact, 256 memory banks independent of base memory (!).

Yes, it is a limitation of SDX memory handler: every extension bank gets own ID, aka "memory index", and that index is an 8-bit number. Therefore there can be 256 indexes in total, which seems sufficient; however, by ICD design, there are two special indexes: $00 (home/default bank) and $02 (system bank), and two others are reserved ($01 and $03). This means that the maximum number of actual extension banks SDX can "see" is 252 (or 253 if you count the home bank as one of them).

 

On the screen shots you can see which of the banks is seen as the topmost one, it is the bank with the memory index $FC (on the Axlon, this is identical with the selection value you write to the $CFFF register). Therefore banks $FD, $FE and $FF are free and unused by the system.

 

The index $03 is currently used to access the 65C816 linear memory, of course only in the presence of the appropriate memory manager loaded.

 

[+CharlieChaplin]

From 16k (600XL) or 64k (other XL/XE) to over 4MB in a few seconds:

 

https://miscretro.com/product/subcart/

 

Just plug in that cart into your XL/XE and also plug in the PBI or ECI cable and you are done.

Comes with 1MB port-B compatible XRAM or 4MB Axlon compatible XRAM.

 

Also comes with various OS, stereo-Pokey and Covox emulation and much much more...

 

[Faicuai]

44 minutes ago, CharlieChaplin said:

From 16k (600XL) or 64k (other XL/XE) to over 4MB in a few seconds:

 

https://miscretro.com/product/subcart/

 

Just plug in that cart into your XL/XE and also plug in the PBI or ECI cable and you are done.

Comes with 1MB port-B compatible XRAM or 4MB Axlon compatible XRAM.

 

Also comes with various OS, stereo-Pokey and Covox emulation and much much more...

 

My 800XL does not support Mosaic64 banking, CANNOT run AXLON if $C000-$CFFF is RAM-enabled while running 16K soft-rom, does not have on-board expansion slots, cannot sync the L-cart on RAS or Phi-2 (at will, plug-and-play), does not run my right-port carts, and (more importantly) cannot hold and power-up my legacy Bit3/fullview card nicely tucked inside. 

 

And funny enough, no need (at all) of PBI on the 800 to achieve the above. 😉

 

Nevertheless, very nice and convenient cart!! ... Will not be surprised to see AVG-cart evolving further on that direction, which would be wonderful (I have and occasionally use AVG on both platforms, especially for its SIO-emulation and support of CAS/ATX).

 

Anyways, thanks, but no, thanks! 

Edited June 5, 2023 by Faicuai
Accuracy...

[Faicuai]

2 hours ago, drac030 said:

It is not so XLESS supporting Axlon banking as SDX supporting Axlon banking: XLESS itself does not contain any code referring to any specific RAM expansion.

Of course, I am perfectly aware of the HW-abstraction of SDX's memory manager. In fact, SDX is THE ultimate reason (and masterpiece) for me to go ahead with this sweet upgrade.

 

Just imagine what could be done with combining AXLON and Mosaic RAM with SDX (e.g. virtual RAM-images, PBI-like soft-loading or boot-strapping HW drivers on $C000-$CFFF, for XEP, Numeric Keypad, Networking, you name it!) And ALL of it battery-backed if we wish so! 

 

2 hours ago, drac030 said:

 

(...) however, by ICD design, there are two special indexes: $00 (home/default bank) and $02 (system bank), and two others are reserved ($01 and $03). This means that the maximum number of actual extension banks SDX can "see" is 252 (or 253 if you count the home bank as one of them).

 

That makes sense, but I would then choose different wording for presenting RAM totals. Notice that it says "252 Ext. Banks TOTAL"... maybe "usable" or "user-available" would suffice, and then one line before listing those reserved, etc.

 

Nitpicking, of course, but just for accuracy and semantics.

Edited June 5, 2023 by Faicuai
Clean-up...

[drac030]

On 6/6/2023 at 12:52 AM, Faicuai said:

Of course, I am perfectly aware of the HW-abstraction of SDX's memory manager. In fact, SDX is THE ultimate reason (and masterpiece) for me to go ahead with this sweet upgrade.

Note that the fact, that the SDX memory manager is hardware abstracted, could in theory also make possible to expand the extended bank range by swapping 16k blocks between an actual RAM bank and the swap partition on a HDD. The only bad thing would be that the swapped in bank should always be considered updated ("dirty"), because there is no method of checking if the 6502 was writing something to the memory or only reading it

[Faicuai]

22 hours ago, drac030 said:

Note that the fact, that the SDX memory manager is hardware abstracted, could in theory also make possible to expand the extended bank range by swapping 16k blocks between an actual RAM bank and the swap partition on a HDD. The only bad thing would be that the swapped in bank should always be considered updated ("dirty"), because there is no method of checking if the 6502 was writing something to the memory or only reading it

That would be great news for plain/stock XE-owners, who with just a SIDE-2 cart, could circumvent expanding built-in extended RAM.

 

And on this note, I wonder in which ways SDX could take advantage of those Mosaic-128KB of RAM, in the $C000-$CFFF region (except $CFFF address).

 

I know SDX rom-disk (and even files) are tuned for 8KB boundaries, but would it possible to move MOST of SDX to $C000-$CFFF (banking in 4KB boundaries) and return those 8KB in $A000-$BFFF to the user-session?

 

If not possible, what about loading key drivers and E: buffer, up there (especially with a truly 52K-friendly OS like Avery's?)

 

Is there something not too involved that could easily allow SDX to take advantage of all that RAM?

Edited June 8, 2023 by Faicuai

[kenp]

Oh My Lord.  but this does look like another reason to try and leave Sparta DOS behind. 

[Faicuai]

1 hour ago, kenp said:

Oh My Lord.  but this does look like another reason to try and leave Sparta DOS behind. 

You are absolutely free to do so (plenty of options out there, from AtariDOS to no-name DOS'es, you name it!)

 

Bon voyage!

[reifsnyderb]

1 hour ago, Faicuai said:

And on this note, I wonder in which ways SDX could take advantage of those Mosaic-128KB of RAM, in the $C000-$CFFF region (except $CFFF address).

Realistically, and for full compatibility, the range of $CFC0-$CFFF needs to be considered for the banking register.  http://www.atarimania.com/faq-atari-400-800-xl-xe-what-types-of-memory-upgrades-are-there-for-the-atari_68.html 

All of those addresses were mirrored as it saved chips on early Axlon compatible boards.  Even the 1056 board mirrors the range of $CFC0-$CFFF as that was the original specification, it saved chips, and it saved space on the board.  The Mega 4 board is different in that no expense was spared and extra chips were added.

[Faicuai]

31 minutes ago, reifsnyderb said:

Realistically, and for full compatibility, the range of $CFC0-$CFFF needs to be considered for the banking register. 

Certainly a legitimate point, but if we go down that path and want to truly remain loyal to AXLON's original specs, we would also have to consider $0FC0-$0FFF shadowing, which not only has been dropped, but it is almost an "aberration" in terms of today's handling of LOMEM area, where every single byte is a precious asset, literally. 

 

Next is the also legitimate question of how widespread / sold where these upgrades back then... even Magna, for instance (already giving 1 MB on the 800, back then). Also, which titles were specifically made to rely on LOMEM banking, or even $FFC0-$FFFE extra-addresses. That is probably even more important.

 

Do we want to bring (and sell) replicas of those upgrades, or do we want to fully leverage today's density, simplify operation, and support adoption of TODAY's SW on which thousands of men-hours have been already invested (!?)

 

In my humble opinion, the Mega-4 tradeoff is the way to go (in the drop-in, easy-and-massive, upgrades department)

[reifsnyderb]

24 minutes ago, Faicuai said:

Certainly a legitimate point, but if we go down that path and want to truly remain loyal to AXLON's original specs, we would also have to consider $0FC0-$0FFF shadowing, which not only has been dropped, but it is almost an "aberration" in terms of today's handling of LOMEM area, where every single byte is a precious asset, literally. 

 

Next is the also legitimate question of how widespread / sold where these upgrades back then... even Magna, for instance (already giving 1 MB on the 800, back then). Also, which titles were specifically made to rely on LOMEM banking, or even $FFC0-$FFFE extra-addresses. That is probably even more important.

 

Do we want to bring (and sell) replicas of those upgrades, or do we want to fully leverage today's density, simplify operation, and support adoption of TODAY's SW on which thousands of men-hours have been already invested (!?)

 

In my humble opinion, the Mega-4 tradeoff is the way to go (in the drop-in, easy-and-massive, upgrades department)

I was thinking about this some more and completely understand and appreciate your argument.  Practically speaking, and as a software developer, I don't see an issue with losing those 64 bytes per Mosaic compatible bank.  Here are my thoughts...

 

1.  One issue is that by limiting the register to $CFFF there will be a lack of compatibility with older Axlon compatible boards.  Breaking compatibility with those boards has to be weighed against the tradeoff of saving 64 bytes per Mosaic compatible bank.

2.  Most of the time, with software, you are wasting space anyhow.  A function isn't exactly x bytes.  If there is some extra space, but not enough space for anything else, it is wasted.  This is true in the Atari OS where some vectors have to be located at a specific location.  The same goes for data storage.  Disk drives are notorious for this.  On the Atari, that 126 byte file will take up two 128 bytes sectors.  So, losing 64 bytes, per bank, to gain slightly under 4k per bank is, in my mind, a reasonable tradeoff to use the extra memory.

3.  A theoretical option option could exist to do both.  That is, develop software to handle only losing $CFFF or 64 bytes from each bank.  This would be miserable to develop for and wouldn't be practical.

 

I wouldn't worry about the shadowing from $0FC0-$0FFF.

 

Best Regards,

 

Brian

 

[Faicuai]

(deleted)

Edited June 8, 2023 by Faicuai

[kenp]

2 hours ago, Faicuai said:

You are absolutely free to do so (plenty of options out there, from AtariDOS to no-name DOS'es, you name it!)

 

Bon voyage!

Almost free.  Too many old disks in 368K Sparta DOS format that need moving to a more open format.  Watching for a DOS that understands SD format and handles the N: device for the FujiNET (which SD doesn't seem to be up to.)

[Faicuai]

42 minutes ago, kenp said:

Almost free.  Too many old disks in 368K Sparta DOS format that need moving to a more open format.  Watching for a DOS that understands SD format and handles the N: device for the FujiNET (which SD doesn't seem to be up to.)

I read three times and... after having used / known almost every DOS under the sun (and Fisher-Price versions of them), I will definitely / absolutely stay with SDX, no questions asked.

 

Now, you may want to check this FujiNet video, it seems to covers both if your pain-points:

 

 

Also, don't see any major problem with transferring your old SDX disks to PC (infinite storage) and running them through PCLink packet-transfers (on SDX), at divisors 0/1, yielding an effective SIO transfer rate that will eclipse everything I have tested on such interface...

 

Good luck!

 

 

 

Edited June 8, 2023 by Faicuai

[drac030]

On 6/8/2023 at 3:53 PM, Faicuai said:

That would be great news for plain/stock XE-owners, who with just a SIDE-2 cart, could circumvent expanding built-in extended RAM.

That would be slow. Heck, I think it would be slow even on Rapidus, and even when the swapping device would not be a HDD, but the extra RAM. But it would be a fancy feature, undoubtedly.

 

On 6/8/2023 at 3:53 PM, Faicuai said:

I know SDX rom-disk (and even files) are tuned for 8KB boundaries, but would it possible to move MOST of SDX to $C000-$CFFF (banking in 4KB boundaries) and return those 8KB in $A000-$BFFF to the user-session?

After thinking about it for a while, I guess that it would be rather difficult. Theoretically it is of course possible, but realistically... It is like porting SDX to completely new hardware: the internals of the cart would have to be completely rearranged to fit in 4k blocks. In any case, probably noone in Europe has such a machine, so we would not be able to test the port, if any were ever made.

 

On 6/8/2023 at 3:53 PM, Faicuai said:

If not possible, what about loading key drivers and E: buffer, up there (especially with a truly 52K-friendly OS like Avery's?)

One could think of some uses, probably, yes. But - have you already used up all the 4 MB of the Axlon extension?

 

On 6/8/2023 at 7:17 PM, reifsnyderb said:

One issue is that by limiting the register to $CFFF there will be a lack of compatibility with older Axlon compatible boards.  Breaking compatibility with those boards has to be weighed against the tradeoff of saving 64 bytes per Mosaic compatible bank.

Is this a real issue? The offcial banking register is $CFFF, so if any software exists, which use the shadows, it could probably be fixed.

 

The worse thing is that the Axlon banking register is write-only. So it is either so that we leave the use of the expansion to the system only (unrealistic), or, when a program changes the active bank out of the system control, we have a problem: no previous configuration can be restored, because, in the first place, it cannot be read from the hardware.

Edited June 9, 2023 by drac030

[reifsnyderb]

 

 

4 minutes ago, drac030 said:

Is this a real issue? The offcial banking register is $CFFF, so if any software exists, which use the shadows, it could probably be fixed.

I don't know if there was any software released that used anything other than $CFFF (i.e.  $CFC0) for Axlon banking.  I only brought it up because the original Axlon specification had the range of $CFC0-$CFFF.  Realistically, it may never have been an issue.

 

4 minutes ago, drac030 said:

 

The worse thing is that the Axlon banking register is write-only. So it is either so that we leave the use of the expansion to the system only (unrealistic), or, when a program changes the active bank out of the system control, we have a problem: no previous configuration can be restored, because, in the first place, it cannot be read from the hardware.

I agree.  The write-only nature is a big problem.  Going forward, a possible solution would be to handle this like $D1FF is handled for the PBI and that is to shadow it somewhere in RAM.  So, you would have to write to the shadow before writing to the register.  Of course, since this was probably never done in the past there is no "standard" of sorts, nor any software that is expecting a shadow register.

 

 

Best Regards,

 

Brian

[drac030]

10 minutes ago, reifsnyderb said:

there is no "standard" of sorts, nor any software that is expecting a shadow register

Which also means that it would not hurt anyone if that register, in new implementations, was read/write.

[reifsnyderb]

5 minutes ago, drac030 said:

Which also means that it would not hurt anyone if that register, in new implementations, was read/write.

Agreed.  This is the way I'd handle this, in new implementations.

[kenp]

On 6/8/2023 at 12:02 PM, Faicuai said:

I read three times and... after having used / known almost every DOS under the sun (and Fisher-Price versions of them), I will definitely / absolutely stay with SDX, no questions asked.

 

Now, you may want to check this FujiNet video, it seems to covers both if your pain-points:

 

 

Also, don't see any major problem with transferring your old SDX disks to PC (infinite storage) and running them through PCLink packet-transfers (on SDX), at divisors 0/1, yielding an effective SIO transfer rate that will eclipse everything I have tested on such interface...

 

Good luck!

 

 

 

Wait, there's still a disconnect, I think.  I'm not using SpartaDOS X, which is, I think, the version that needs a cartridge to hold part of its functions.  I'm only using an older version of SpartaDOS, something in the 3.x region, because I haven't got a cartidge to load things into.  Now, I have a 130XE modded up to 320K of memory.  If SpartaDOS X can be loaded so that it uses some of the paged memory instead of a cartridge, then I might be getting further along.  (this place is just too damn rich with information and I'll never sort it out on my own.  🙂 )  Or maybe I should just buy a cartridge for the SpartaDOS X. 

 

I'm not overly concerned about the rate of transfers so much as the correctness of transfers, making sure all the bytes are transferred correctly.

 

(btw, I am going to byte the bullet and bring a Windows machine into play for an Altirra installation.  I have a couple of machines that I bought ready to go with Windows 10 installed but set the HDDs aside and ran Linux on them instead.  Just needed a couple of machines quickly and didn't have time to sort out parts and put thing together.  I have to admit a real antipathy towards Microsoft.  Maybe no longer deserved but hard to cast aside.  Anyway, I didn't cast aside the HDDs with the Windows on them so one has been reinstalled and brought up to its latest and apparently last update to become an Altirra base. ( At least until we see an Altirra written in Rust for the Linux world. 🙂 (don't worry. really just kidding.  Too many desktop environments in the Linux world for such a thing.) )

[reifsnyderb]

5 minutes ago, kenp said:

 ( At least until we see an Altirra written in Rust for the Linux world. 🙂 (don't worry. really just kidding.  Too many desktop environments in the Linux world for such a thing.) )

Altirra runs on Linux via wine.

[kenp]

1 hour ago, reifsnyderb said:

Altirra runs on Linux via wine.

I'd try that, eventually, but would like to have a plain installation working on a Windows machine first as a reference. 

 

Whether native on a Windows machine or on Linux via Wine I'm sure it's going to be a heavy lift for me as it's been literally decades since I left Microsoft and Windows behind so I think it would be better to take it one layer at a time. 

[+slx]

On 6/5/2023 at 4:47 AM, Faicuai said:

Thanks to (reifsnyderb) and his neatly designed RamRom-2022 (personality card) and Mega-4 (ram-card) sleek combo, the wait is finally over! By directly leveraging on the 800 architectural strengths, we can ALL now enjoy pure 800-goodness, without being at the mercy of eBay:

Where are these cards available? Not sure if I really need them as I have enough Incognitos for my 800s but should a Bit3 come my way (or should someone develop a Bit3 replacement)...

[reifsnyderb]

3 hours ago, slx said:

Where are these cards available? Not sure if I really need them as I have enough Incognitos for my 800s but should a Bit3 come my way (or should someone develop a Bit3 replacement)...

Hello,

 

I have them on ebay, Tindie, and my website.  Links and info is in my signature block.

 

Best Regards,

 

Brian

 

Edited June 10, 2023 by reifsnyderb