[En-Nut-Discussion] Nut/OS Memory Considerations

Alastair Jeremy ajeremy at dotaussie.com.au
Sun Nov 3 23:15:32 CET 2002

Hi Harald,

My comments on the bank switching (I think these were in fact similar or the
same as ones made before by Louis)....

In the implementation of bank switching in the OS:

Have the ability to specify the start and end of the "Unswitched RAM".
Have the ability to specify the start and end of the "Bank Switched RAM".
Have the ability to move the bank select register to be any location in

Also (maybe?) have the ability to specify a second range of SRAM that is
able to be used by the heap. This would mean that you could fill up an area
between 0xC000 to 0xFEFF that is unused by memory mapped IO with RAM, and
have the O/S support putting the heap into it. I haven't looked deep into
the heap allocation process, but I assume that since it is a linked list of
free areas, this should mean that the areas do not actually HAVE to be
continuous, and thus you could have a second area after the bank switched

Assuming everything worked off these sort of pointers, then you would
obviously be able to implement your suggested memory map, but also others,

Also, for your bank switching numbers, and things such as a default of
'0'... you might find that when it comes around to actually implementing the
bank switching that the default of 0 might make it a little more difficult
to implement. You (I assume) will only be using a single SRAM chip, in which
case you might find that a default of '2' ends up easier to implement in
hardware (leaving "Bank0" and "Bank1" to be the "Unswitched RAM").

You may want to be able to move the bank select register around, because
since in any wait-state cycle setup the topmost area of memory is the most
likely to end up with wait states (assuming use of fast SRAM). So it would
be 'nice' to be able to move things that don't need wait states out of
there. (Yes, I agree you will not be switching very often) You might also
want to think about read-back capability for the "current SRAM bank" in your
hardware implementation, too.



-----Original Message-----
From: en-nut-discussion-admin at egnite.de
[mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp
Sent: Monday, 4 November 2002 7:09 AM
To: en-nut-discussion at egnite.de
Subject: [En-Nut-Discussion] Nut/OS Memory Considerations

A new document will be available in a few minutes at

It's incomplete and contains a lot of well known
blah blah, but also a small part about bank switched

Comments are most welcome.


En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de

More information about the En-Nut-Discussion mailing list