>Just a thought, but would there be any way to patch the OS so it saw some
>of the card as heap memory?
Well, here is the point.
The Newton OS already uses virtual memory extensively.
The Linear stores have a fast, reliable, virtual access.
Just by playing with the MMU, you can declare part of the Linear
Flash as RAM or Read-Only RAM Like.
I thought first that the Newton worked this way, and therefore an ATA
drive would be irrealistic since ATA are accessed like a disk. (using
third party mechanism would mean using only a part of the available
cards, which is basically a bad idea).
But today, I have access to the MMU. Basically, package objects are
at 60xxxxxx. But all pages there map to the RAM (04 physical). This
is normal since pacakges are compressed, and therefore they are
decompressed, not mapped directly. This is a kind of virtual memory
like the one into MacOS for DataFork-CFM softwares, except that the
Newton uses compression.
It is also the case for VBOs.
Technically, the PCMCIA cards are at 3xxxxxxx & 4xxxxxxx physical.
What is strange/unfortunate, is that the Newton feels the need to map
the card's memory at two places:
as is at 9xxxxxxx & Axxxxxxx and just the flash memory at
70000000-73FFFFFF / 74000000-77FFFFFF and just for the available
memory (in my newt, there is just 6 megs for each cards, at 70 & 74).
This may mean that it relies heavily on having the card as is.
It is possible technically to extend the Newton RAM with storage. I
have not investigated this point already. In fact, the Newton decides
how to allocate the memory depending on the available amount. This
seems more complex than an ATA driver (in my own point of view).
ATA accesses work with registers and a buffer located into the card.
You can read up to 256 sectors at a time. Then, you access the buffer
to move this information.
I have just checked TATASimple::IdentifyDrive(TATADriveInfo*,
uchar*), and it seems properly implemented. (The code is at 00026548
physical & logical, and it calls TATASimple::DoATARegCommand after
managing the parameters properly.
The problem is the declaration of previous Newton engineers, and the
fact that Sharp tried to implement this driver, without success.
In the worst case, the PCMCIA hardware interface seems to be reliable
enough to do accesses. As I said, the minimum possible is archiving
and specific uses with a specific application interface, which could
be implemented into an MP3 player or a sound recorder. (anyway, there
is no available mp3 player yet).
At best, we could hope to have a fully driver with tools to access
foreign FS. I have thought for example that considering the NewtonOS,
the disks, whatever their size may be (and if this part is written,
Click and real drives could be used, too) should be divided into
*several* newton stores, each to be mounted at will and with
reasonable size. There are very probably size limits for stores. For
example, the physical limit of linear cards is 64 megs (at least,
with the CL-PS7030, and probably with the standard itself), but the
Newton OS 2.0 only accepts 4 megs stores, and 2.1 32 megs (that's
what I have read).
Regards,
Paul
-- P&M Consulting Newton Program http://www.pnm-consulting.com/newton/ *************************************** NewtonTalk brought to you by:EVOTE.COM -- the ESPN of politics on the Internet! All the players, all the news, and the hottest analysis and features (plus 'toons!) anywhere.... visit http://www.evote.com today!
*************************************** Need Subscribe/Unsubscribe info?
Visit the NewtonTalk section at http://www.planetnewton.com
This archive was generated by hypermail 2b29 : Thu Jun 01 2000 - 00:00:08 CDT