Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!mmdf
From: andersen!tsarver@uunet.uu.net (Tom Sarver)
Newsgroups: comp.sys.amiga.misc
Subject: Non-contiguous memory
Message-ID: <50186@nigel.ee.udel.edu>
Date: 9 Apr 91 18:24:24 GMT
Sender: mmdf@ee.udel.edu
Lines: 38

This is to all the hardware/low-level system software folks:
I've got a non-contiguous fast memory space.
Hardware:
   StarBoard II, 2M (with StarDrive controller)
   Imtronics (originally Ronin) Hurricane 1000 w/ 2M memory board
   A1000
Situation:
   SB II auto-config's to 2000000 to 3FFFFFFF (or however many digits)
   Imtronics configs to 6000000 to 7FFFFFF (etc.)
   I set up RAD: to the SB II memory (all but about 150K).
   RAM: initially grabs space in the SB II area as well.

Problem:
   The RAM: device bombs when I put any significant amount of data in it.

Workaround:
   Don't use the RAM: device.

Potential problem:
   If any old program asks for a block of memory, X, will it receive a
   block which lies on the 3FFFFFFF boundary?  That is, with, say, 25
   bytes in real memory and X-25 bytes in nowhere memory?

The reason I'm bringing this up now is that I just got a hard drive, and I
don't want to use a 2M RAD: as a system disk anymore.  Is there a problem
with the non-contiguous memory from the system software point of view?
Or is this a problem with the RAM: device?  How does this affect programs
which need contiguous memory (eg, BASIC)?

The only way to make the memory contiguous is to 1) change the auto-config
on the SB II or 2) change a PROM on the Hurricane board.  I don't know how
to change the SB II board, and I can't get the PROM from Imtronics.

--Tom
-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%--%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%
% Tom Sarver: tsarver@andersen.com | "Only Amiga makes it possible!"    //\   %
% "A real computer has a linear address space. NO 386's!!"          \\ //--\  %
-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%--%-%-%-%-%-%-%-%-%-%-%-%-%-%-%-%\X/%-%-\-%