Banking Schemes

[zhulien]

Hi Everyone,


In writing drivers for CPC banking and AMSDOS, I have some banking schemes in mind.


What are your preferences and why?



BANKING SCHEME   

A - Totally Flexible?   

If totally flexible then we can allocate RAM anywhere in the memory map of any size, but our code is never assumed to sit in a constant space - so coding is harder for our own software.
RAM allocations can be between a byte and almost 16KB.
I have coded this already but it makes coding software harder as always everything are far addresses that are byte aligned.

B - Flexible sizes but always between #4000 and #8000 for RAM, but ROM can be at #C000 to #FFFF   

If like this, then we always know where RAM is so our ROMs can use RAM, our software can use RAM and we have total control of where we put things that are not within extra RAM.
RAM allocations can be between a byte and almost 16KB.
A variant of A but we can make some shortcuts.

C - Fixed sizes but always between #4000 and #8000 for RAM, but ROM can be at #C000 to #FFFF   

If like this, the same pros as option B, but more RAM wastage.  Easer for multi-tasking though.
RAM allocations are always 16KB.
Current MCP Proof Of Concept does this.

D - All tasks run in alternative 64KB, so we can get likely around 61KB TPA for each task etc.  More complicated to code the OS, but we can code massive applications in a single chunk.  But sometimes a single chunk application is not as useful as a component (16KB per component) based one.   
RAM allocations are always around 61KB but very hard to use more RAM beyond something like a RAMDisc.
I believe Symbos does something like this, so does CP/M Plus.

E - Other, please describe...

[zhulien]

Typically people use a byte for a bank, and a 16bit address for direct memory access within a bank, basically a 24bit far address which is annoying to deal with.
What is your thoughts on the following two schemes which use 16bit far addresses?  Such schemes mean that functions called across banks would need to be byte aligned and any data can be read using IX or IY directly, or of course, translating the 16bit address into a 24 bit one.

Perhaps someone can even make a new 16mb RAM expansion with such a mode as OPTION 1 built in?  (of course the RAM expansion should be optionally switchable to DkTronics mode).  Such an expansion could use a microcontroller with inbuilt 16mb RAM and itself handle maintenance of the RAT?





x = which 64kb bank
y = byte aligned block

OPTION 1:

address:   xxxxxxxxyyyyyyyy
capacity:   x = 256 x 64kb = 16mb (note: 1kb wasted per 64kb) so effective almost 16mb
alignment:   y = 64 x 256byte blocks per 16kb (1st block is header)

stats:     

64kb has 256 blocks
256kb has 1024 blocks
512kb has 2048 blocks
16mb has 65536 blocks

pros:     

address fits within 16 bits
likely fast to translate due to 256 byte alignment
perfect fit for use with IX and IY registers
minimal wastage for ram allocation table (RAT)

cons:     

perhaps not enough blocks for certain types of applications

RAT per 16kb:
         1         2         3         4         5         6
0000000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------------------

OPTION 2:

address:   xxxxxxyyyyyyyyyy
capacity:   x = 64 x 64kb = 4mb (note: 1kb wasted per 64kb) so effective almost 4mb
alignment:   y = 256 x 64byte blocks per 16kb (1st block is header)

stats:     

64kb has 1024 blocks
256kb has 4096 blocks
512kb has 8192 blocks
4mb has 65536 blocks

pros:     

address fits within 16 bits
still works with IX and IY registers
lots of blocks for certain types of applications

cons:     

slower to translate due to 64 byte alignment
ram allocation table (RAT) is larger

RAT per 16kb:
         1         2         3         4         5         6
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------------------

[zhulien]

To make MCP more useful, not only from assembly language I have decided the following will be likely.


- All memory handling will be done from ROM only so that I know that the memory handling functions won't be paged out themselves
- Memory handling will support drivers (proven at a high level in the other MCP thread), drivers can be either passive like libraries which don't do anything unless called, alternatively they can be multitasking in the background (as proven by the MCP POC)
- Memory handling will support buffers, a driver will be able to specify itself how many buffers it needs so they can be allocated at driver load time.  A buffer can be a static bit of RAM for driver usage, or it can be a FIFO (circular) buffer.  Since these buffers need to be able to be read/written to from BASIC RSXs, another benefit of having the memory drivers in ROM only.
- Memory handling will support general usage memory allocations from BASIC with a form of MALLOC and FREE.  I am still working on the memory model, I have one workable idea with a limitation of 16128 bytes being the maximum allocation size - not bad... but will it be sufficient for all application types?  You can fit compressed screens in there, sprites, music data I guess...  but this model supports up to 16mb CPC RAM (if someone were to make a memory expansion).

[rpalmer]

Zhulien,
I have already design a CPC memory expansion which can handle up to 64MB.
See attached zip file for more info.
The MMU has been built as well as a 4MB expansion board.
The MMU can handle 512K up to 6MB where I have also designed expansions with 4MB, 8MB, 16MB and 64MB
rpalmer

[zhulien]

That's cool, but that does mean the memory addresses are effectively 26 bits long (you have gained an additional 10 bits). 


Actually I am looking at how to pack a 24 bit address (16mb ceiling) into 16 bits - which it does but within a 256 byte alignment.  What that would allow, easy pushing and popping of such an address off the stack, if the allocated memory was for large bits of data (e.g. graphic screens?) then there isn't much wastage.  To access the data within the 256 byte boundaries requires a translation from the packed address to an unpacked on after the correct bank is selected or alternatively, use of the index registers to access the additional bytes between each 256 byte aligned block. 


My original Malloc and Free routines are really good for what they do, they allow for full 24bit direct addressing and allocation / free of any sized memory without byte alignment and they are kept in a kind of linked list.  It is however not really a speed optimal solution for a CPC.  So, I have chosen to look at a RAT (RAM Allocation Table) solution where within a 16kb block of which is 256byte aligned, the first 256byte page of it is actually the RAT.  I can track where allocations start and how big an allocation is without much logic meaning extremely fast allocations / deallocations.


eg:


FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFF  (63 free 256byte blocks)
DEEFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF FFF (after a driver is loaded)


The D meaning that block is where the the driver was allocated and started, only needs a packed pointer to there.  EE meaning the driver had allocated 2 extention 256 byte blocks.  Freeing D would mean freeing all subsequent E's also (just change the 3 bytes to F for re-use).


The reason I wanted to avoid 24bit addressing for most operations, API calls etc, is it is a pain to have to deal with.  For example, to make an API to block copy, I need 2 sets of 24 bit addresses in registers, or setup a control block in memory.  Packing them to 16bits makes most things feel natural but being able to deal with heaps of memory.


What is the purpose of your MMU?  To handling the latching?  With regard to DkTronics compatability, all are useful configurations, Configuration 3 is usually avoidable especially if memory routines are mostly in ROM, or in RAM above &8000.  I chose ROM to allow for greatest flexiblity with BASIC programs.

[rpalmer]

Zhulien,
Yes, that means the address for referencing memory is 26 bits.
The MMU is the base board for which user can then install what ever required amount of memory they see fit to use. It primarily latches either the configuration 0 for upper 5 bits of the bank select and latches the usual bank select for the lower 5 bits.


rpalmer

[zhulien]

Have you made a board yet?  What is the likely price range for a 16mb, 32mb, or 64mb board?