u572112244ea@ucdavis.UUCP (Mark Nagel) (11/28/85)
I have heard over and over that it is impossible to bank extra RAM in the CoCo without dragging the entire operating system with you when you select a new bank. Although it might be slower memory, would it be possible to use some of the I/O memory as an address selector which would then read the data from the extra memory (it would have to add 64K to the address value) and then return the contents of that address through the same I/O address? I don't know too much about hardware, but is this even possible? If so, could OS9 use this extra memory? - Mark Nagel
jimomura@lsuc.UUCP (Jim Omura) (11/29/85)
Mark, there's been a lot written on this topic. See if you can get
back issues of the Rainbow or Hot CoCo. In brief, you can expand pretty
far. The new Tandy CoCo has a new PIA which may help. The problem with
software stems from the fact that the CoCo banks in 32K pages. If you
address only 64K (the limit of most 8 bit processors), and you have to
have the top addresses reserved for IO, then that limits your OS design
options. You'd have to put your OS in the top page completely to have it
all there and bank the bottom half, but with a bit of the top page used
for parameter passing.
The Colorburst is the only unit I know that expands the Color Computer
properly for position independant systems (like OS-9 and Unix). It has a
6829 MMU which can bank 2K or 4K pages. It can be bought with 64K RAM
for about $500.00 or with up to 1 Meg. of RAM. I think it comes with RAM
disk software too. sp
]
so it's immediately useable.
Cheers! -- Jim O.
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
Compuserve: 72205,541
MTS at WU: GKL6emjej@uokvax.UUCP (12/03/85)
/* ---------- "CoCo Memory Expansion" ---------- */ I have heard over and over that it is impossible to bank extra RAM in the CoCo without dragging the entire operating system with you when you select a new bank....[Proposal to access/select additional memory via memory-mapped I/O, if possible] If [it is possible], could OS9 use this extra memory? - Mark Nagel /* End of text from net.micro.trs-80 */ It would be hard to use such memory for anything but device drivers, unless you're talking something that does real live memory mapping of the kind that Level Two wants. I don't know enough to say whether it's hardwarily pos- sible, although something like that is how Level Two systems (and SS-50C bus boxes) work, I think--one uses memory-mapped I/O to control the memory mapping hardware. The problem would be how to support the "link" operation (handing a process a pointer to a specified module) in the face of that kind of memory. If you let some modules live in the stock memory and some here, it could be nasty. (If there are, as I strongly suspect, other pitfalls as well, I invite corrections and addenda!) That is *NOT* to say it's not worth doing--it would be wonderful to be able to move graphics pages out of the memory one uses for modules, or to do real live caching to minimize the effect of the cretinous CoCo disk controller on CoCo performance. (That's what's *really* depres- sing about Tandy's slowness in coming out with a 6809 box not hamstrung by a design that was probably OK for a single-user game machine running Microshaft BASIC--if you've seen a SSB or Gimix box running OS-9, or if you're among the VERY lucky, a Fujitsu FM-11, you know it could utterly blow away far more expensive machines.) James Jones