Tandy T100 info

[Allison]

>
>Subject: Re: Tandy T100 info
>   From: John Hogerhuis <jhoger at gmail.com>
>   Date: Mon, 16 May 2005 14:25:13 -0700
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 5/16/05, Allison <ajp166 at bellatlantic.net> wrote:
>> 
>> Ok, the usual MMU only fairly fine grained.  Does any apps make use of
>> that kind of MMU and space?
>> 
>
>Not yet, this is a new thing, and there's no software to take
>advantage of the full potential yet.

Not surprized as even in the S100 Z80 world where MMU and banking has 
been around for a long time it was rarely used for anything but 
pseudodisk space.

I've gone as far as do a memory allocation recovery systems for 
to get an approach to a virtual OS.  Not all the way but close.
In that case the MMU is being used for a scatter/gather 
execution space allocator.

>> >Each block in the map can be marked read-only so that if you are
>> >emulating ROM with RAM or flash you get a perfect emulation, i.e. any
>> >writes against ROM don't get applied.
>> 
>> Handy!
>> 
>
>Handy and required... some vintage ROMs do some funny stuff writing
>against ROM for efficiency believe that it won't have any effect. But
>writing against RAM has an effect, and against flash can lock up the
>flash since it can trigger its state machine.

;)  thats a bad thing!  I know. :-P

>> Now I understand what it is and the basic logic inside.  Like many MMU
>> based 8bitters the addition of large ram is usually to emulate disk.
>> I'm curious to see if any actually do swaping or overlay so the app
>> can access a larger space or larger data.  The reason for that is
>> most cases that is rare or not even done.
>> 
>
>Well the M100 uses a RAM based file system. Our MMU is a new thing, so
>any use made of it beyond emulating multiple M100 fast-switch maps
>will be by new software. In particular I'm planning a management

Not surprized for reasons stated.

>program that can set up maps and burn new ROMs to flash or set them up
>in RAM. But the spec will be freely available so user programs can get
>direct access to extended RAM. All you need to do is CLEAR enough
>space to get a 1K window  and a BASIC program can start PEEKing and
>POKEing extended RAM without too much trouble. That's why we have such
>a fine-grain MMU block size.

I'm still getting used to the M100s applications and space usage.
It's a bit foreign to a CP/M, OS/8, RT-11, VMS user like myself.
I'e sone real time stuff and systems stuff for myself that used 
mapped ram and rom to get around the latency of disks (even IDE).

I'll have to look more at all this.  However, step one is to
get the M100 I have up to 32k ram.  Then I'll look at how secondary 
rom socket space is used. I'd like a configuration that also has 
ram at 0000h and maybe a OS in it.  I've considered getting some 
larger F-Rams too.  All in time.


Allison