4MB banked memory

[Panther]

I've seen discussions about having 4MB XE style banked memory extensions, but are there any of these that have actually been implemented?  Or any beyond the typical 64 extended memory banks?  If so, I would like to know exactly how these function.  I know the Axlon cards for the 800 went up to 4MB and the way those work are simple enough using $cfff in the reserved block for bank selection, but to have extended memory access via PORTB that goes beyond 64 banks you need to make use of bits 0 and 4 which are the OS ROM enable and base/extended switch.  Now, I can see simply having extended memory enabled all the time, thus allowing use of bit 4 to select the bank, then you simply would never actually utilize the block of base memory and technically reducing your actual total memory by 16K.  Has anyone done this though?  I would think this would mess up a number of games and applications.  Then there's the OS ROM enable/disable, which is certainly needed for a lot of programs, including SDX.

 

[Mathy]

Hello Panther

 

I've heard that the Newell 4MB upgrade uses all eight bits of $D301 to select a bank.  And that it's in extended memory all the time.

 

Sincerely

 

Mathy

 

PS but 1MB with full controle over BASIC, RAM/ROM, Selftest and Missile Command (on the XEGS) AND separate ANTIC and CPU access is possible.  For everything above 1MB I'd go to a second address above $D301.

 

Edited March 12, 2022 by Mathy
typo

[Panther]

12 hours ago, Mathy said:

I've heard that the Newell 4MB upgrade uses all eight bits of $D301 to select a bank.  And that it's in extended memory all the time.

I've heard this too, but I'm yet to find any specific documentation on this.  I'm not saying it doesn't exist, but it's seeming more myth than real.  If it does exist, I wonder if they included a physical switch to enable/disable it.

 

[flashjazzcat]

Antonia implements 4MB as an Axlon extension, which I imagine is the only way to cater for an 8-bit bank number (this being impossible with PORTB).

[1050]

I've got one. It was sold by B&C back in 95 and there was barely enough instructions to work out the concept. I seem to remember the 4 meg capable one sold for more money and that money amounted to one additional piece of paper that was highly confusing, but I did work it out. The first hurdle was to buy (8) 4 meg x 1 bit memory chips and replace the (8) 1 meg x 1 bit chips that I also had to purchase for flying the 1 Meg. The instructions for the one meg were so lousy that it didn't work at first and then I thought to suspect a typo and once I corrected for that, it did work. Eventually after learning quite a bit about programing, I just had to try it as a 4 meg, but there was no software capable of using it other than my "creative" DOS patches and such a royal PIA to do the simple things I had gotten used to doing with the 1 meg. You had to shove a copy of the OS ROM in the RAM under ROM first thing at boot up so that bit 0 of port b use didn't matter anymore. But that meant that ANY use of that RAM under ROM would crash it. Bit 7 was the self-test, somehow it was completely disabled and I don't even remember exactly how. So no self-test anymore. Not sure if I ever investigated how well it worked with BASIC at all, I had it set up for less than a week at most. It became the monster that ate my beloved Atari, and I missed it very much, I could do next to nothing but investigate it until I could not think of anything else I should try to look at. I absolutely couldn't wait to kill that beast and have my 1 meg back. Just so many things you can't do that you are used to. It was the standard 1 Meg Newell with a hard to follow rambling outline of making it into a 4 Meg ramdisk. This 1 meg Newell package did come with a modified MyDOS disk that worked adequately well. But there was no software for the 4 meg and not even a mention of what one is supposed to do with such a hampered machine. It was unusable for me, no BBS, no printing and both those were what I was doing with my system then. My one meg did use a switch to be able to use BASIC, that switch isn't apparent in this schematic so he must have changed things around since I installed the one Bruce at B&C sold me back in 95. I don't know if those papers are viable or where they might be.

 

The above is better specific documentation than I had, no telling where that single sheet of paper is or if it still exists here. My roof leaks, lots is ruined. I also built a dual PIA machine and had some luck with that approach. It involves shunting the negative enable signal from the original PIA to the 2nd PIA if the address is 0xD304 or higher. Address line 2 then works a 74LS157/158 select line to move the enable signal between the two PIAs alternately. The entire region of 0xD3xx is then a repeating pattern of both PIAs instead of the only one as per normally seen there. You won't need a switch, software talking to 0xD305 is working the 2nd port b automagically. All this needs special software and nothing is compatible, end of the day, it surly is interesting but, so highly ambiguous to the point that I don't know why I went there and tried it. I suppose it's a mountain that just needs climbing.

 

Looking for perhaps some better information I came across this which you might find interesting.

http://atari.a8maestro.com/info/8ball/ballhc.htm

 

I hope that one works, I swore I tried it before and fell down one of his rabbit holes. Of interest is the 800XL Newel 1 meg instruction sheet which is much more detailed than the one I had to go by. But it came with a schematic as well so here are two I do have and with the above maybe it can finally make some sense.

Rick Detlefsen's site is a bit confusing. I always have a hard time of it over there, but he's got some good stuff just the same. For a further dive, click on the link titled ars-technica near the bottom of the 800XL 1 meg newell instruction page. You'll see his inputs by his initials RLD.

Newell used to have a site that offered just the schematics of all his memory upgrades which is how I came by these. But it no longer exists.

Edited March 13, 2022 by 1050
typo

[xxl]

An interesting concept of building a memory expansion using address lines in addition to data lines allows to use 64 MB (sic!) of banked memory and is 100% compatible with PORTB and PIA repeated registers... by the way, a similar concept was used in Atarimax (address lines) and RAM-CARD

 

 

---

Moreover, such an extension can work in CompyShop and Rambo modes

Edited March 13, 2022 by xxl

[ivop]

I really wished somebody created a memory expansion that banks the lower 32kB.  Would be very helpful for a multitasking OS.

[ClausB]

50 minutes ago, ivop said:

I really wished somebody created a memory expansion that banks the lower 32kB.  Would be very helpful for a multitasking OS.

Somebody did:

https://atariage.com/forums/applications/core/interface/file/attachment.php?id=362652

[ivop]

9 minutes ago, ClausB said:

Somebody did:

https://atariage.com/forums/applications/core/interface/file/attachment.php?id=362652 6.18 MB · 931 downloads

Completely forgot that your upgrade used a different memory window. Very cool!

 

What is this Atari's memory-control register you speak of in the BANK SELECTION section? Do you mean PORTB, or is it located somewhere else?

 

It would be really nice if the upcoming external U1MB supports this banking scheme!

 

[ClausB]

Yes, PORTB, bits 4,5,6. Banks 0-5 are extended RAM and bank 6 is a mirror of the upper 32K.

Edited March 13, 2022 by ClausB

[ivop]

I hope @candle is reading along and adds ClausB Banking, and Axlon (up to 4MB), and the usual PORTB variants for up to 1MB

 

@flashjazzcat could really make good use of the ClausB Banking scheme for his graphical multi-tasking OS

[flashjazzcat]

2 minutes ago, ivop said:

@flashjazzcat could really make good use of the ClausB Banking scheme for his graphical multi-tasking OS

If every machine with 128K of RAM out in the field had a 32KB banking window which encompassed the stack and page zero since the early 1980s, then yes, but since I already designed a high-performance microkernel back in 2013 or so which works perfectly well with an un-banked stack and zero page, I doubt I would go out of my way to exploit such a thing at this point in order to save a couple of thousand machine cycles per frame. Stack segmentation and other tricks resulted in the standard Atari architecture presenting no insurmountable issues.

 

[ivop]

3 minutes ago, flashjazzcat said:

If every machine with 128K of RAM out in the field had a 32KB banking window which encompassed the stack and page zero since the early 1980s, then yes, but since I already designed a high-performance microkernel back in 2013 or so which works perfectly well with an un-banked stack and zero page, I doubt I would go out of my way to exploit such a thing at this point in order to save a couple of thousand machine cycles per frame. Stack segmentation and other tricks resulted in the standard Atari architecture presenting no insurmountable issues.

Yes, I understand that. I was actually thinking about a combination of both. Small tasks run in one bank with your re-locator and stack segmentation. Large tasks get their own 32kB bank with a full stack and most of page zero, and no need for relocation. Everything should behave nicely of course, because we don't have memory protection.

 

But even if you were not to utilize the ClausB (or ClausB+ with more banks) banking scheme, I still think it would be a useful addition to the new external U1MB (U4MB? )

 

[flashjazzcat]

It might create more problems than it's worth in the GOS, since I don't really need kernel and driver code in low RAM vanishing every time there's a context switch. To deal with that, I'd have to duplicate the code in low memory in every bank otherwise the OS would crash at the next VBL. And with that, we have a complete redesign of the entire OS memory map for the sake of a facility which exists on a handful of machines.

 

Of course these things always look like a magical solution to everything until you actually start to think seriously about how stuff would be implemented in the real world. Not that I object at all the idea of of such a banking scheme being available, although I told Candle that a much more useful feature (for the next U1MB) would be two interchangeable base 64K banks, since that will allow the firmware and loader to access all the base RAM without disturbing the running application and without having to cache said application.

 

[ClausB]

A multitasking OS for 32K banks would keep its code and drivers in upper memory. Apps, their data, their displays, and some OS data would stay in lower RAM.

 

[flashjazzcat]

Got it all worked out, I see. The GOS has the microkernel under the OS ROM, 8K of (bank-switched) ROM below that (contains window manager, and other large processes when need direct access to all the RAM on the system), and another 8K of RAM at $8000 for the display. There are also sections of drivers which need to be outside of the 16K banking window, and they live in low RAM, along with more kernel code, and obviously the stack and page zero. Lots of dynamically loaded drivers will have to load sections into extended memory, since you won't fit much into 14K when even all the resident system fonts consume several kilobytes, plus icons and other resources.

Edited March 13, 2022 by flashjazzcat

[ClausB]

25 minutes ago, flashjazzcat said:

Got it all worked out, I see.

No, just some initial thoughts. And it wouldn't be as ambitious as your GOS. Maybe just some parallel BASIC programs with a shared DOS in upper RAM. Probably not very useful really.

[flashjazzcat]

No problem. It was suggested I make the existing operating system work with both banking methods, so I was really responding with that suggestion in mind. A task switcher for legacy applications could certainly benefit from being able to switch 32K (or even 48K for that matter), and this is what I had in mind for the ExtU1MB in order to jump in and out of the loader without clobbering the running application. As for the GOS: I gave up on making something which would run in 48K, but what's been produced (though half finished) will multitask several processes quite happily on a stock 130XE, so the user only needs a bank-switched cartridge. Firmware is a different matter, of course: one can then exploit whatever unique features the host hardware has to hand with the absolute knowledge said hardware will be present.

[ivop]

As I said, it might not be for you and your GOS, but IMHO it still would be a nice addition to the next U1MB incarnation to have the possibility to switch 32kB, or even 48Kb as you say. The address lines are there, so it could work. It opens up a lot of possibilities. Even 64kB would be possible if both banks are initialized through code in ROM. I mean, it currently supports banking schemes that are also only used by a handful of programs, so why not add this? ClausB's Quarter Meg has existed for over 36 years but was never fully explored. Banking ZP and the stack. That's cool IMHO. The C128 can do that

 

 

[flashjazzcat]

6 hours ago, ivop said:

ClausB's Quarter Meg has existed for over 36 years but was never fully explored.

Here's to the next 36 years.

[Panther]

On 3/13/2022 at 7:04 AM, 1050 said:

I've got one. It was sold by B&C back in 95 and there was barely enough instructions to work out the concept. I seem to remember the 4 meg capable one sold for more money and that money amounted to one additional piece of paper that was highly confusing, but I did work it out. The first hurdle was to buy (8) 4 meg x 1 bit memory chips and replace the (8) 1 meg x 1 bit chips that I also had to purchase for flying the 1 Meg. The instructions for the one meg were so lousy that it didn't work at first and then I thought to suspect a typo and once I corrected for that, it did work. Eventually after learning quite a bit about programing, I just had to try it as a 4 meg, but there was no software capable of using it other than my "creative" DOS patches and such a royal PIA to do the simple things I had gotten used to doing with the 1 meg. You had to shove a copy of the OS ROM in the RAM under ROM first thing at boot up so that bit 0 of port b use didn't matter anymore. But that meant that ANY use of that RAM under ROM would crash it. Bit 7 was the self-test, somehow it was completely disabled and I don't even remember exactly how. So no self-test anymore. Not sure if I ever investigated how well it worked with BASIC at all, I had it set up for less than a week at most. It became the monster that ate my beloved Atari, and I missed it very much, I could do next to nothing but investigate it until I could not think of anything else I should try to look at. I absolutely couldn't wait to kill that beast and have my 1 meg back. Just so many things you can't do that you are used to.

Thank you for the explanation on the 4MB PORTB expanded memory.  It makes much more sense now understanding that it didn't really work, not with any normal software anyway.

[Panther]

On 3/13/2022 at 11:36 AM, flashjazzcat said:

I told Candle that a much more useful feature (for the next U1MB) would be two interchangeable base 64K banks, since that will allow the firmware and loader to access all the base RAM without disturbing the running application and without having to cache said application.

That would be an excellent solution.  Okay, I'm not buying any more U1MB or Incognito cards until this feature has been added to them!  =B>

[Alfred]

On 3/13/2022 at 1:43 PM, ClausB said:

Somebody did:

https://atariage.com/forums/applications/core/interface/file/attachment.php?id=362652 6.18 MB · 946 downloads

Haha, the first upgrade I ever did. Still have the Byte issue it was in. Puff was horrified when he saw it because I used 18ga doorbell wire. Worked great and trying to code the ramdisk driver was one of my early introductions to Atari assembler.

[flashjazzcat]

11 hours ago, Panther said:

Okay, I'm not buying any more U1MB or Incognito cards until this feature has been added to them!

I've been wanting to get this facility implemented for the past five years or so, but even if I had unlimited PBI RAM and ROM, I'm not overly keen on converting the loader (which is now a 64K blob of code and data in a bank switched cart) into something which runs in 32x2KB ROM banks and accesses RAM through a tiny window. So simply switching between two discreet base memory areas would be a whole lot easier.

[ivop]

On 3/13/2022 at 7:36 PM, flashjazzcat said:

Not that I object at all the idea of of such a banking scheme being available, although I told Candle that a much more useful feature (for the next U1MB) would be two interchangeable base 64K banks, since that will allow the firmware and loader to access all the base RAM without disturbing the running application and without having to cache said application.

Why limit that to only two banks? With 1MB of RAM, there are sixteen available. All banks have to be initialized through ROM code of course. If Candle implements switching of the full 64kB base RAM as you would like him to, I see no reason to stick to only two banks instead of sixteen.

Edited March 15, 2022 by ivop