4MB banked memory

[flashjazzcat]

9 minutes ago, ivop said:

Why limit that to only two banks? With 1MB 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.

RAM is far from unlimited. The same 2MB SRAM needs to supply the following:

• 64KB base RAM
• 1MB cartridge emulation
• 1MB extended memory
• 2KB (?) of PBI RAM
• 72K (at least) for the loader's FAT file list and various buffers
• BIOS RAM (1-2K)

Obviously, there will have to be some trade-offs here (a limit to the size of emulated carts when there's 1MB of extended memory, etc, although the dual 64K base banks need to be independent of the extended memory scheme and cartridge emulation, unless we want a system in which the loader can only be used when no cartridge is mounted, or when there's only 256K of extended memory), and here I am asking for a second 64KB of base RAM. On top of this, there is the matter of the CPLD on the external U1MB already being fairly close to being full, so unless we want to dramatically increase the cost of the device (by doubling the SRAM and enlarging the CPLD), there is a limit to what can be done. It should become apparent why supporting fanciful banking schemes which may or may not find support from software at some point in the next 36 years is something which needs careful consideration.

Edited March 15, 2022 by flashjazzcat

[ivop]

26 minutes ago, flashjazzcat said:

although the dual 64K base banks need to be independent of the extended memory scheme and cartridge emulation, unless

Here's why I misunderstood. I thought you meant it as an extended memory banking scheme, but independent is the key word here

 

26 minutes ago, flashjazzcat said:

It should become apparent why supporting fanciful banking schemes which may or may not find support from software at some point in the next 36 years is something which needs careful consideration.

Fanciful banking schemes (for extended memory) would not require more memory (unlike your independent 64kB base RAM ), but only a few extra lines of VHDL/Verilog to switch address lines to the right memory if the banking scheme selection registers says so. It's more or less similar to adding a new cartridge banking scheme. I know FPGA cells are limited, so I understand if some obscure stuff is not supported, but if there's room, it opens up a lot of new possibilities. It not being available on stock and expanded computers before, doesn't really matter IMHO. U1MB Firmware doesn't run on a computer without U1MB either, which includes most of my machines

 

Anyway, if Candle did not add your requested extra 64kB bank in five years, I have little hope he will add exotic banking schemes.

 

Edited March 15, 2022 by ivop

[flashjazzcat]

5 minutes ago, ivop said:

Here's why I misunderstood. I thought you meant it as an extended memory banking scheme, but independent is the key word here

Exactly. If we end up making it so that the loader can work like the firmware setup menu in that it doesn't disturb the running application, the memory used needs to be totally independent of the extended RAM and cartridge emulation, otherwise one or the other will get messed up every time the loader is called. I had various ideas about implementing this on U1MB/SIDE2 in the past, using extended memory, but the fact there's no secondary (private) RAM banking register and three banks of the user's extended memory would be clobbered every time the loader was launched made it more trouble than it was worth (other things like a write-only SDX banking register added to this list of reasons not to bother, too).

9 minutes ago, ivop said:

Fanciful banking schemes (for extended memory) would not require more memory (unlike your independent 64kB base RAM ), but only a few extra lines of VHDL/Verilog to switch address lines to the right memory if the banking scheme selection registers says so.

A reasonable point, but Candle is best positioned to elaborate on feasibility. I know that when adding features to Incognito, squeezing in those 'extra few lines' of code proved challenging, and certain cartridge banking schemes on SIDE3 - although not that complex in terms of logic - consumed a preposterous amount of chip resources.

11 minutes ago, ivop said:

It not being available on stock and expanded computers before, doesn't really matter IMHO. U1MB Firmware doesn't run on a computer without U1MB either, which includes most of my machines

I referenced the matter of firmware exploiting unique hardware features as a matter of course earlier; this is obviously a given. One of the things I was responding to earlier, though, was the suggestion that my GOS could leverage 32KB banking, and my GOS is not firmware, but an application designed to run on a generic banked cartridge, and on a minimal configuration of 128K (as per a stock 130XE).

14 minutes ago, ivop said:

Anyway, if Candle did not add your requested extra 64kB bank in five years, I have little hope he will add exotic banking schemes.

The difference is that dual base memory banks are - in my view - highly desirable for improvements in the functionality and usability of the device firmware. Generic 32K banking is not, so the two should not be considered in the same breath.