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 <[email protected]> wrote: > 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 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 <[email protected]> wrote: > >> 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 2/03/2021 7:33 am, Stephen Adolph wrote: >> >>> 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 allocated >>> to form a disk. There will be an upper limit of 16 blocks in the disk, for >>> a total of 512kB. There will be support for up to 31 directories (nested) >>> and thinking 256 files total. Organization will be based on 128 byte >>> sectors. >>> >>> Anyhow that is the plan. Not sure when I will get it done but I'm on >>> the way now. Looking forward to seeing this through to fruition. >>> >>> Steve >>> >> >> >
