Memory Banking Question

[reifsnyderb]

Hello,

 

I am working on the 600XLM memory control CPLD's and have a question regarding memory banking.

 

Thus far, simulations show that memory banking should work fine with the following 3 jumper settings on the 600XLM:

1.  64k only, no banking.

2.  192k, 130XE compatible + bit 6.

3.  576k, with Antic banking (compy shop)

 

To use 576k or 1024k (option 4) of memory I've got a latching system working whereby when PORTB bit 4 is set (to zero to bank the memory) there are 2 JK Flip-Flops that hold the state of bits 1 and 7 of PORTB.  So you never lose the capability of enabling/disabling BASIC or using the self-test.  Just turn off the banking and full PORTB capability is available.  (No missile command, sorry, thats XEGS.     )

 

However, with 1024k banking everything will work fine but there are 4 banks that share the main memory.  This is not unheard of as there were banked memory upgrades in the past that had this issue.  (http://www.atarimania.com/faq-atari-400-800-xl-xe-what-types-of-memory-upgrades-are-there-for-the-atari_68.html)  Obviously, if the wrong bank is selected, memory corruption will occur.  With the current design, as long as bits 1,5,6,7 are never all set to zero there isn't a problem.  But if all of those bits (1,5,6,7) were to be set to zero at once then a bank in the lower 64k would be selected.  (Bits 1,2,3,5,6,7 are used for banking with 1024k.  Bits 2 and 3 map to memory addresses using bit 14 and 15 on the memory chip, respectively.)  Is there some "standard" that was followed to prevent overlapping memory regions from being selected under these circumstances?

 

Thanks!

 

Brian

 

 

The 600XLM is documented here:  

 

 

 

[Rybags]

Unsure what the "standard" was - generally it was set by whoever made the first upgrade of that size (though you have the Rambo/Compy differences)

 

It can actually be handy to replicate main Ram into the $4000 window since the Ram under OS has that 2K IO region that otherwise could never be accessed.

Though that said, access only becomes available to those upgrades that support it.

[Mathy]

Hello Brian

 

If you have a latching system anyway, why not latch bit 0 too?

 

Are you sure that you have 64k + (128, 512 or 1024k)?  Or do you have (128, 512 or 1024k) only?

 

Sincerely

 

Mathy

 

[reifsnyderb]

1 hour ago, Mathy said:

Hello Brian

 

If you have a latching system anyway, why not latch bit 0 too?

 

Are you sure that you have 64k + (128, 512 or 1024k)?  Or do you have (128, 512 or 1024k) only?

 

Sincerely

 

Mathy

 

I only latched the PORTB bits 1 and 7 and left PORTB bit 0 unlatched so the OS ROM can be switched on or off to access the underlying memory.  It would be possible for me to use PORTB bit 0 and leave PORTB bit 5 for 1024k ANTIC banking. 

In 192k and 576k mode, banking is controlled by PORTB bits 4 and 5.  In 1024k mode ANTIC banking is disabled as bit 5 is used as a bank address line.

I was thinking having the OS ROM still switchable while using banked memory was more important than ANTIC banking.

 

I am sure of the memory.  The SRAM chip is 1024k total.  The addressing works out as follows:

 

The 64k setting is 64k as address bits 14 and 15 from the address bus map directly to the SRAM address lines 14 and 15.  Bits 16 through 19 on the SRAM are held low.

 

The 192k is 64k base RAM + 64k with bits 2 and 3 of PORTB.  Add another 64k by using bit 6 of PORTB for a total of 192k.  

  The bank address bits map as follows:

      PORTB bits 4 and/or 5 set low enables banking and sets SRAM address line 16 high (the logic checks on the /HALT status for ANTIC banking)

      PORTB bits 2 and 3 map to SRAM address lines 14 and 15 when banking is enabled.

      PORTB bit 6 maps to SRAM address line 17.

 

For 576k the bank address bits map as follows:

     PORTB bits 4 and/or 5 set low enables banking and sets SRAM address line 16 high (the logic checks on the /HALT status for ANTIC banking)

     PORTB bits 2 and 3 map to SRAM address lines 14 and 15 when banking is enabled.

     PORTB bit 6 maps to SRAM address line 17.

     PORTB bit 1 maps to SRAM address line 18.

     PORTB bit 7 maps to SRAM address line 19.

     With SRAM address line 16 always high, there is a considerable amount of wasted space but it's not required for 576k.

     PORTB bits 1 and 7 are latched when banking is enabled.

 

For 1024k the bank address bits map as follows:

    PORTB bit 4 set low enables banking.  (PORTB bit 5 is now used as an address.)

    PORTB bits 2 and 3 map to SRAM address lines 14 and 15 when banking is enabled.

    PORTB bit 1 maps to SRAM address line 16.

    PORTB bit 5 maps to SRAM address line 17.

    PORTB bit 6 maps to SRAM address line 18.

    PORTB bit 7 maps to SRAM address line 19.

    PORTB bits 1 and 7 are latched when banking is enabled.

 

(I just verified that in simulation using the Digital program by H. Neemann.)

 

So, with 1024k mode, if PORTB bit 4 is set low and all other PORTB bits are low, the bank will start at 0x0.  In this case, PORTB bits Bits 2 and 3 will select a bank in the first 64k.  This, of course, could result in memory corruption unless the application using the banked memory is aware of this problem.

 

If ANTIC banking is more important than toggling the OS chip, it wouldn't be hard to change the CPLD such that PORTB bit 0 selects a bank and PORTB bit 5 still controls ANTIC banking.  Another J-K flip flop could be added to latch PORTB bit 0 when banking is enabled.

 

Best Regards,

 

Brian

 

 

Edited January 18, 2022 by reifsnyderb

[Mathy]

Hello Brian

 

So the computer as is will have 1024kB max, instead of 1088kB if I understand correctly.  That's just like most 256kB 800XL upgrades.  Why not just add 64kB for main memory and use all of the 1024kB SRAM for the expansion?  That would make things a bit easier.

 

46 minutes ago, reifsnyderb said:

If ANTIC banking is more important than toggling the OS chip, it wouldn't be hard to change the CPLD such that PORTB bit 0 selects a bank and PORTB bit 5 still controls ANTIC banking.  Another J-K flip flop could be added to latch PORTB bit 0 when banking is enabled.

 

If you latch bit 0, it'll still be possible to toggle the OS chip, you just can't toggle it when the memory extension is accessed.

 

Sincerely

 

Mathy

 

[_The Doctor__]

I like the idea of full antic banking... would be interesting to see what would come of it.

Edited January 18, 2022 by _The Doctor__

[reifsnyderb]

50 minutes ago, Mathy said:

Hello Brian

 

So the computer as is will have 1024kB max, instead of 1088kB if I understand correctly.  That's just like most 256kB 800XL upgrades.  Why not just add 64kB for main memory and use all of the 1024kB SRAM for the expansion?  That would make things a bit easier.

 

 

If you latch bit 0, it'll still be possible to toggle the OS chip, you just can't toggle it when the memory extension is accessed.

 

Sincerely

 

Mathy

 

 

Yes, the total memory is 1024kb.  The chip used is a 1024kb chip which costs over $8.00.  Adding another 64kb would add yet another chip to the board and I am trying to keep the parts cost from climbing.  Going through Mouser, I estimate there is already at least $125 for the components and other parts on these boards.  (Once everything settles out I'll come up with another estimate on the cost of the components.)

 

The OS chip could still be toggled, yes.  It would also be possible to reach the RAM under the OS and in the hardware registers via a bank...with the current configuration.  Having ANTIC banking still available may be an interesting option but I don't know how much ANTIC banking is used.

 

I just checked prices and adding a 64k SRAM chip would add around $3 in cost to the board.  However, given the current microchip supply problems, chip availability is an issue.  Using 64k of a bigger chip would be an option....at more cost.

 

Are there many applications that support 1088kb?  Would it take adding another chip (64k base memory) to ensure compatibility?  Would the 576k be compatible but the 1024 not be compatible with most applications that use the extra memory?   (Don't get me wrong, I want a compatible solution.)

 

Edit:  Added other questions.

 

 

 

 

 

 

 

 

Edited January 18, 2022 by reifsnyderb

[_The Doctor__]

 some demos and this

https://a8.fandal.cz/search.php?search=1024+kB&butt_details_x=x

and this...

also some digitized music and

for the future maybe some GOS systems etc might use it...

other such things as well

 

[reifsnyderb]

I couldn't find a way to eliminate the overlap problem and there really isn't space on the board for an extra chip...if it were available.  Antic banking will now work in all banked modes, though.

 

So, 64k, 192k, and 576k won't have any overlap issues.

1024k will have overlapping banks in the first 64k....so don't use them unless you want access to RAM underneath the ROM or device registers.

 

1024k banking is now as follows:

 

For 1024k the bank address bits map as follows:

    PORTB bit 4 set low enables CPU banking and PORTB bit 5 set low enables ANTIC banking.

    PORTB bits 2 and 3 map to SRAM address lines 14 and 15 when banking is enabled.

    PORTB bit 0 maps to SRAM address line 16.

    PORTB bit 1 maps to SRAM address line 17.

    PORTB bit 6 maps to SRAM address line 18.

    PORTB bit 7 maps to SRAM address line 19.

    PORTB bits 0, 1, and 7 are latched when banking is enabled.

 

 

Edited January 19, 2022 by reifsnyderb

[Rybags]

Something to note if you're emulating banking by shadowing PORTB.

 

Your device needs to be aware of the data direction mode and states of each bit.  ie, if the DDR is enabled in PBCTL then reads/writes to PORTB should act as such.

If a particular PORTB bit is set as input, then I'm fairly sure writing to it has no effect on the banking state that it controls.

[reifsnyderb]

7 hours ago, Rybags said:

Something to note if you're emulating banking by shadowing PORTB.

 

Your device needs to be aware of the data direction mode and states of each bit.  ie, if the DDR is enabled in PBCTL then reads/writes to PORTB should act as such.

If a particular PORTB bit is set as input, then I'm fairly sure writing to it has no effect on the banking state that it controls.

That's a good thing to keep in mind for a parallel port card or some other banking system.  This is for a completely re-made 600XL board.  I've attached a picture showing the board running MULE.  Presently, the board is still set to use 64k only. 
The board has a 1024k SRAM chip on it controlled by a CPLD that has 8 data lines coming to it from the PIA chip, PORTB.

 

Edited January 19, 2022 by reifsnyderb

[drac030]

The overlap is not a big problem, most RAM testing procedures are aware that some extensions have this "feature" (e.g. 256k already mentioned), for example:

 

http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM

 

The overlapping banks are skipped (so that a program trying to use the extended banks will not accidentally pull out the carpet from under its feet, so to speak). The procedure should still be put outside the area which can be possibly swapped out. In general, this is a nuisance rather than a useful feature IMHO.

 

Also, using PORTB bit 0 to swap banks is certain to cause incompatibilities, because programs expect the ability to swap the OS ROM in/out regardless of the state of the remaining PORTB bits, and, conversely, that doing that does not switch the extension bank which has already possibly been selected and swapped in. That is why the extensions to 2 MB are not in use, although they were designed in the past.

 

 

[reifsnyderb]

16 minutes ago, drac030 said:

The overlap is not a big problem, most RAM testing procedures are aware that some extensions have this "feature" (e.g. 256k already mentioned), for example:

 

http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM

 

The overlapping banks are skipped (so that a program trying to use the extended banks will not accidentally pull out the carpet from under its feet, so to speak). The procedure should still be put outside the area which can be possibly swapped out. In general, this is a nuisance rather than a useful feature IMHO.

 

Also, using PORTB bit 0 to swap banks is certain to cause incompatibilities, because programs expect the ability to swap the OS ROM in/out regardless of the state of the remaining PORTB bits, and, conversely, that doing that does not switch the extension bank which has already possibly been selected and swapped in. That is why the extensions to 2 MB are not in use, although they were designed in the past.

 

 

If leaving bit 0 function normally is the better solution, I'll go back to using bit 5 to reach 1024k.

Edited January 19, 2022 by reifsnyderb

[reifsnyderb]

1 hour ago, drac030 said:

The overlap is not a big problem, most RAM testing procedures are aware that some extensions have this "feature" (e.g. 256k already mentioned), for example:

 

http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM

 

The overlapping banks are skipped (so that a program trying to use the extended banks will not accidentally pull out the carpet from under its feet, so to speak). The procedure should still be put outside the area which can be possibly swapped out. In general, this is a nuisance rather than a useful feature IMHO.

 

Also, using PORTB bit 0 to swap banks is certain to cause incompatibilities, because programs expect the ability to swap the OS ROM in/out regardless of the state of the remaining PORTB bits, and, conversely, that doing that does not switch the extension bank which has already possibly been selected and swapped in. That is why the extensions to 2 MB are not in use, although they were designed in the past.

 

 

Changed back.  Thank you for pointing this out.

 

I changed 1024k mode back to...

 

For 1024k the bank address bits map as follows:

    PORTB bit 4 set low enables banking.  (PORTB bit 5 is now used as an address.)

    PORTB bits 2 and 3 map to SRAM address lines 14 and 15 when banking is enabled.

    PORTB bit 1 maps to SRAM address line 16.

    PORTB bit 5 maps to SRAM address line 17.

    PORTB bit 6 maps to SRAM address line 18.

    PORTB bit 7 maps to SRAM address line 19.

    PORTB bits 1 and 7 are latched when banking is enabled.

 

 

[+DjayBee]

You can find all PORTB settings for standard RAM extensions in phaeron's Altirra Hardware Reference Manual starting from page 32.

[drac030]

4 minutes ago, DjayBee said:

You can find all PORTB settings for standard RAM extensions in phaeron's Altirra Hardware Reference Manual starting from page 32.

There is an error there, though: the table on page 33 lists the 192k extension as RAMBO, without separate ANTIC access. Maybe such extensions exist too, but the whole point of using bit 6 in 192k for banking is to keep bit's 5 function of controlling separate ANTIC access. So it is not RAMBO-type.

[+DjayBee]

2 minutes ago, drac030 said:

There is an error there, though: the table on page 33 lists the 192k extension as RAMBO, without separate ANTIC access. Maybe such extensions exist too, but the whole point of using bit 6 in 192k for banking is to keep bit's 5 function of controlling separate ANTIC access. So it is not RAMBO-type.

Paging @phaeron

[+Nezgar]

7 hours ago, DjayBee said:

You can find all PORTB settings for standard RAM extensions in phaeron's Altirra Hardware Reference Manual starting from page 32.

This is a good suggestion, and I just checked it as well.. but the "expansion list" on page 33 (of the Jan 2022 edition) there is a reference of a 1088K upgrade (64K + 1024KB) but no reference example for 1024KB... which 4 banks should mirror the base 64K, or IMHO be blocked from use?

 

I think there was maybe one Petersen type 1024K upgrade for the 800XL, vs 1088K in an XE, since "usually" the base 64K in the first row is untouched... If anything, it should match the behaviour of that upgrade... IIRC Petersen type upgrades would block access banks that would otherwise mirror main RAM.. I'd have to read up on them again.

 

I'm not optimistic about the number of ramdisk programs that would correctly identify that 4 banks are mirroring base RAM....

 

In regards to 192K mode - it could be simplified to be a 320K "COMPY SHOP" type mode that uses bits 2,3,6,7, preserving ANTIC banking on bit 5. Programs that don't support bit 7 for banking will only detect 128KB of extended RAM (192KB total) Ie SpartaDOS 3.2 RD.COM), but those that do will detect all 256K of extended RAM (320KB total)