Hi Jim,
See my responses in-line. cheers Steve

On Sun, Jan 17, 2021 at 3:48 PM Jim Manley <[email protected]> wrote:

> Thanks Steve!
>
> I was able to download the REXCPM v2 ZIP file once you had updated the
> link to the current version.
>
> Is there somewhere that lists what's in the Option ROM image files at the 
> Validated
> OPTROM Images for M100/T102
> <http://bitchin100.com/wiki/images/6/63/M100_OPTION_ROMS.zip> link?  I
> can guess a few of them by name, but most are effectively in hieroglyphics
> to me.
>

Most of them are listed at Club100, but I don't have such a list.



>
> Also are there other images elsewhere that can be readily loaded into
> REXes?  AIUI, you can create an image from any 32 KB segment, so any
> 8080-compatible code and data files loaded into a segment can be archived
> that way.  Obviously, they would have to either be text/command-line based
> or M100-specific for addressable interactive text displays, graphics, etc.
>

Generally, making a option ROM work is a broad topic. Since option roms
occupy the same address space as the main rom, you need to either (1)
completely take over operation of the M100 or (2)  you need to leverage the
existing main ROM for interrupts, and other routines.

Everything I have seen LEVERAGES the existing main rom.  This means you
need to "trampoline" between the option rom software and the main rom
software.

Also, remember that in a typical M100 option roms are read only. It is only
REXCPM that is read/write.

I suggest reading "Secrets of the ROM Revealed".

It is possible to make your own program to run in Optrom space.  that is
what REX Manager is.

It is also possible to transform a basic program to run out of optrom space.

Lots of possibilities.

there is a FORTH option ROM too.




>
> So, 512 KB of the REXCPM is reserved for the sixteen 32 KB "Option SRAM"
> segments, leaving 1.5 MB of the 2 MB REXCPM unit available.  That 1.5 MB is
> only accessible by CP/M AIUI, though (and did I see that BASIC can access
> up to two of the 32 KB segments?).
>

In REXCPM, in fact you can switch any 32k segment into the Option ROM
space, and you can switch any 16k segment into either 8000-BFFF or
C000-FFFF spaces.

512k is reserved for "traditional REX use" - option ROMs and RAM backups.

1.5MB is reserved for CPM disk A.

M100 should leave the CP/M disk alone, but it is not protected.  So from
M100 BASIC you could alter the CP/M disk.

M100 files are not storable on the CP/M disk.

Think of it like 2 separate machines in one box.  The M100 box and a CP/M
8085 box.


>
> Is that 1.5 MB available for CP/M files that are larger than 32 KB as well
> as for direct execution of CP/M-based application code that requires more
> than 32 KB?  I don't recall if there have ever been any legacy CP/M
> executables larger than 32 KB, but I could eventually build some.  I do
> recall some applications built using modules that could be called and were
> then dumped from RAM when no longer needed.
>

It is a true A: drive for CP/M, and very fast.

>
> Can there be data files larger than 32 KB, or even some significant
> fraction of the 1.5 MBs?  I'm asking out of curiosity rather than having a
> foreseeable need to do anything like that.
>

Yes.


> Does REXCPM do some voodoo behind the scenes to switch segments without
> the code knowing any better?  Obviously, plain-vanilla 8080 CP/M code
> couldn't access anything beyond a 64 KB address space, but is it possible
> to write code that does extend beyond, or is that something we'd have to
> manage ourselves via segment-switching?
>


CP/M uses a fixed memory allocation out of the 2MB SRAM.  the disk is the
only thing that is "switched" when CP/M is running.

It is very possible to program REXCPM to bank-switch the active memory, but
nothing like that is implemented.

That is how the M100 and CP/M machines co-exist.
Block0 = power up RAM 8000-FFFF
Block1 = default option ROM 0000-7FFF= REXCPM rom
Block 2 = lower RAM for CP/M 0000-7FFF
block 3 = upper RAM for CP/M 8000-FFFF

so you can see that bank switching is used to enable CP/M.

At some point I will write  a technical document for REXCPM.  Just, not
really something of a quality I could post at this time.

Philip Avery authored the changes to "stock CP/M 2.2" to support the M100
implementation.

>
> I think I need to dig into the CP/M docs from long ago in that galaxy far,
> far away!  My MSCS compiler course prof was Dan Davis, best friend of Gary
> Kildall when they both co-founded the CS Department at the Naval
> Postgraduate School in Monterey.  Dan had followed Gary to Digital Research
> a year, or so, after it was founded, to build the PL/I compiler.  He
> returned to NPS a few years later after Microsoft had decimated DR's market.
>
> Thanks and All the Best,
> Jim
>
>
>

Reply via email to