Maybe not, but I think that being able to edit text using M100 is possibly
more convenient than using an editor in CP/M.
In any case, the REX disk and the CP/M disk can be separate.
On Tuesday, March 2, 2021, Philip Avery wrote:
> Hmm, not sure I follow. I don't see value in transferring from
Hmm, not sure I follow. I don't see value in transferring from CP/M disk
to M100 disk. But I do see value in having a REXCPM machine able to do
CP/M *and* do your internal disk in M100 mode.
Philip
On 2/03/2021 11:55 am, Stephen Adolph wrote:
Hi Philip,
So, my goal here is a common function
Hi Philip,
So, my goal here is a common function for both flash and ram versions.
Maybe as a adjunct we could add transfer to and from the cpm disk.
..steve
On Monday, March 1, 2021, Philip Avery wrote:
> This sounds interesting Steve. I'm sure I could put enough smarts into
> M100 CP/M so that
This sounds interesting Steve. I'm sure I could put enough smarts into
M100 CP/M so that it could co-exist with a M100 "disk drive".
Particularly if your disk is at the end of CP/M disk, ie the upper REX
blocks. I could set the end-point of CP/M disk to be below M100 Disk.
Philip
On
Very cool Steve/
Mar 1, 2021 11:33:54 AM Stephen Adolph :
> Quick note just to say that I have got a plan now, and have started coding,
> for how to implement an internal "disk drive" using both REX# and REXCPM.
> This is the last major hurdle that I have wanted to overcome for a long time.
>
Quick note just to say that I have got a plan now, and have started coding,
for how to implement an internal "disk drive" using both REX# and REXCPM.
This is the last major hurdle that I have wanted to overcome for a long
time.
Basically, the user can identify some of the 32k blocks to be
