Author Topic: Banking Schemes  (Read 100 times)

0 Members and 1 Guest are viewing this topic.

Offline zhulien

  • 464 Plus
  • *****
  • Posts: 434
  • Country: au
    • 8bitology
  • Liked: 195
  • Likes Given: 121
Banking Schemes
« on: 06:15, 03 December 19 »
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...