Re: [M100] REXCPM playing and observations
Good news is it's going to rain for a few days here, so I can spend time inside & improve M100 CP/M by: - increase Directory size from 256 entries to 512. - make Import/Export "user" friendly. ie for user area to remain constant before & after. Thought I'd let CP/Mers know this so they can delay any mega-installs until I complete the above. Philip On 7/11/2020 3:36 am, Bert Put wrote: Hi Philip, On 10/29/20 3:53 PM, Philip Avery wrote: Hi Jim Fear not, we can increase the size of the Directory making full use of 4MB. This will require BIOS changes & an OS update. That means... at present you'll have to re-import all your user files. I'll vote for an expanded directory as well please, thank you! Cheers,Bert
Re: [M100] REXCPM playing and observations
Hi Philip, On 10/29/20 3:53 PM, Philip Avery wrote: > Hi Jim > > Fear not, we can increase the size of the Directory making full use of > 4MB. This will require BIOS changes & an OS update. That means... at > present you'll have to re-import all your user files. I'll vote for an expanded directory as well please, thank you! Cheers,Bert
Re: [M100] REXCPM playing and observations
> -Original Message- > Hi Jim > > Fear not, we can increase the size of the Directory making full use of > 4MB. This will require BIOS changes & an OS update. That means... at > present you'll have to re-import all your user files. Can you reply So it goes - that's the price we pay for being on the bleeding edge. :) > please with what D.COM states for directory status/usage, I don't need > each file size. Certainly - and now that I understand how it allocates multiple directory entries for large files, I understand why D.COM reports different counts for the number of files and number of entries. User 0 - 39 files 55 entries. User 1 - 17 files 32 entries. User 2 - 52 files 56 entries. User 3 - 54 files 71 entries. User 4 - 24 files 42 entries. Wouldn't you know it, that totals to 256 entries. :) Back-of-the-napkin math indicates that's optimal for an average file size of about 13.7kb (or large files of (X*16)+13.7kb) in a 3.5mb filesystem, and it feels to me like the average file size for an old system would be quite a bit lower than that (probably only a few kb). I've chewed those 256 entries up in about 2mb worth of files, so that's roughly 8kb apiece. I have no idea what the conventional wisdom is for how many directory entries to allocate for a given size of disk in CP/M 2.2 so I'll keep quiet now :) > With NADSBox I had 'checksum error' at various stages when loading large > files (>32KB). I presumed my NADSBox was faulty. Is your error > consistently at the 64KB size? Yes, and in fact I don't get an error message from IMPORT.COM at all, it seems to terminate normally (except that the transferred file is only 64kb in size). It also produces a number of progress-indicator dots proportional with a 64kb file (ie. if I copy the same large file from mComm running on my phone, I get a proportionally larger number of progress dots - twice as many if the file is 128kb, etc). I'm not sure how the TPDD protocol handles large files, whether it is able to tell IMPORT.COM the correct size and the NADSbox is just telling it 64kb so it stops at 64kb, or if IMPORT.COM has no idea how big the file is and just reads until the TPDD device says it's done, or what... > Returning to User 0 after execution: This doesn't seem right to me, I'll > look into this Looking at the CP/M 2.2 manual, it says (top of page 1-3) that a user's program can overlay memory areas used by the CCP and/or BDOS and that by branching to the bootstrap loader at the end of execution it causes the complete CP/M monitor to be reloaded from disk. Further on (page 1-12) it says about the USER command, "The active user number is maintained until changed by a subsequent USER command, or until a cold start when user 0 is again assumed." I have noticed since reading this that the few commands which do preserve the active user number exit immediately to the A> prompt, whereas most other commands which put me back in user 0 have a bit of a delay when exiting before the A> prompt appears - the exact same amount of time it takes to reload CP/M if you hit Ctrl-C at the A> prompt and watch for a new A> prompt to appear. Since there's no disk activity indicator, it hadn't hit me before that this little delay (and subsequently ending up back in user 0) was the system reloading. It sounds like the difference is that some programs (like the variants of D.COM, SWEEP, STAT) don't need to reload the system after execution, and I find myself still in the same user area, whereas PIP, DDT, MBASIC, IMPORT, EXPORT, and almost everything else I've loaded into my machine does perform this reload at termination. > Steve: Drive B: proposal. Initially I'm reluctant as it chews up part of > our 64KB RAM with an extra Drive tables - there's quite a bit of > overhead for that. However it maybe the way to go, I'll have a good > think on that. But... a souped-up IMPORT with wildcards/sub directory > ability would solve this issue I believe. Yes Please :) jim
Re: [M100] REXCPM playing and observations
> -Original Message- > thinking out loud here, > > Sure, the directory structure for a single large disk could get fixed to > address the issue. > I wonder though if we might want something else. > > What if we had a smallish (360kB) drive B, intended for file sharing? This might be a useful thing - hopefully it would be in addition to increasing the number of directory entries because right now there's only enough to accommodate an average file size of 13.7kb (or 29.7kb, or 45.7kb) on the 4mb REXCPM image. I suppose the option of having a B: drive would be something that would have to be baked into the starting image - you wouldn't be able to choose to allocate some space on the fly for a B: drive, right? jim
Re: [M100] REXCPM playing and observations
Hi Jim Fear not, we can increase the size of the Directory making full use of 4MB. This will require BIOS changes & an OS update. That means... at present you'll have to re-import all your user files. Can you reply please with what D.COM states for directory status/usage, I don't need each file size. NADSBox error: Interesting, I had similar trouble when using my NADSBox when developing. Plus I had a similar error with cheap USB-Serial converter as stated in the wiki. This took about a month to overcome... With NADSBox I had 'checksum error' at various stages when loading large files (>32KB). I presumed my NADSBox was faulty. Is your error consistently at the 64KB size? Returning to User 0 after execution: This doesn't seem right to me, I'll look into this Steve: Drive B: proposal. Initially I'm reluctant as it chews up part of our 64KB RAM with an extra Drive tables - there's quite a bit of overhead for that. However it maybe the way to go, I'll have a good think on that. But... a souped-up IMPORT with wildcards/sub directory ability would solve this issue I believe. Philip On 29/10/2020 10:44 pm, Jim Anderson wrote: So I recently wanted to try printing from WordStar 3.3 and discovered that worked quite nicely. I also discovered that WordStar 4.0 has support for the early HP LaserJets (and, therefore, possibly my HP 4000N may understand it), and also the spell check may be better integrated and/or at least configurable for VT100 unlike the version of SPELSTAR that is on classiccmp.org (and reliably check spelling, although I have figured that problem out - more below). Naturally I went on to try putting WordStar 4.0 in USER 4 on my REXCPM since I still had more than half the disk space available :) I ran into a few issues which I thought I'd mention here for the benefit of others, and resolved some of them (but not others). First, a hardware thing: in order to run RXCUTL.BA (the utility for backing up and restoring the REX and CP/M parts of the REXCPM memory), you need to unload the REX hook (Ctrl-X from the M100 menu screen) and then power-cycle the M100 to reset the REX module's state. Well, I was trying to run a backup tonight and kept getting the error (I forget the exact message) you get if you forget the power-cycle step (which I had definitely not forgotten - multiple times). Turns out, while I've got my DMP-105 hooked up to the parallel port and powered on, when I turn the M100 off there's power being fed back into the M100 from the printer through the parallel port and this keeps the REX from resetting. I only figured this out because it *also* causes the 'low battery' LED on the M100 to illuminate when the power is switched off. Weird, and probably nothing can be done about this - I haven't even checked with another parallel printer to see if this is unique to the DMP-105 or not. I just thought I'd mention it in case anybody else runs into such a thing. So, WordStar 4.0 - I discovered in the process of copying this over that IMPORT.COM was only copying the first 64kb of any large files over 64kb in size. Further testing shows that this only happens when using IMPORT.COM with my NADSbox - if I use mComm on my phone it imports the full file (the largest was 163kb). I don't know if this is a limitation of the NADSbox or just some weird interaction between it and IMPORT.COM - of course, there isn't really any other way to test pulling a large file over 64kb from the NADSbox that I'm aware of... This got me worried about backup integrity because I'd been making backups using RXCUTL.BA to my NADSbox and those files are enormous (545kb for the REX backup and 3457kb for the CP/M backup). What if it doesn't write good data for large files? I know I did a full backup and restore as a test in the first few days after I got my REXCPM but I don't remember if that restore was done using mComm, LaddieAlpha, or the NADSbox. I tested tonight making backups to mComm and to the NADSbox (this is why I was whining about the speed again earlier tonight :) ) and diffed the resulting files - they are identical. Whew, my backups are good. I'll test later what happens if I restore one of these backups from the NADSbox and try to remember to post my results - it will be interesting to see if it only supplies the first 64kb or if it goes the distance. Last point - what led me to this whole backup/restore thing is that while I was copying over WordStar 4.0 into a new user area I've run into a CP/M limit and put too many files into A: for the directory structure to handle. Sorry, I should have counted them to see how many there were, but I'm sure it's a documented figure. It may be that 4mb is overkill for REXCPM unless you're planning to store mostly very large files (or unless there's a fix for the directory structure limits?), like maybe using WordStar to write a big novel or something, or writing very large programs. I forgot to
Re: [M100] REXCPM playing and observations
Jim, thinking out loud here, Sure, the directory structure for a single large disk could get fixed to address the issue. I wonder though if we might want something else. What if we had a smallish (360kB) drive B, intended for file sharing? Use case: Someone imports and configures all of Wordstar. Great! Now, copy those files to B: (360kB). Use RXCUTL to make a backup of the disk, and then post or email the disk image. This would be an improvement over posting the files in a zip. ..Steve On Thu, Oct 29, 2020 at 5:45 AM Jim Anderson wrote: > So I recently wanted to try printing from WordStar 3.3 and discovered that > worked quite nicely. I also discovered that WordStar 4.0 has support for > the early HP LaserJets (and, therefore, possibly my HP 4000N may understand > it), and also the spell check may be better integrated and/or at least > configurable for VT100 unlike the version of SPELSTAR that is on > classiccmp.org (and reliably check spelling, although I have figured that > problem out - more below). Naturally I went on to try putting WordStar 4.0 > in USER 4 on my REXCPM since I still had more than half the disk space > available :) > > I ran into a few issues which I thought I'd mention here for the benefit > of others, and resolved some of them (but not others). > > First, a hardware thing: in order to run RXCUTL.BA (the utility for > backing up and restoring the REX and CP/M parts of the REXCPM memory), you > need to unload the REX hook (Ctrl-X from the M100 menu screen) and then > power-cycle the M100 to reset the REX module's state. Well, I was trying > to run a backup tonight and kept getting the error (I forget the exact > message) you get if you forget the power-cycle step (which I had definitely > not forgotten - multiple times). Turns out, while I've got my DMP-105 > hooked up to the parallel port and powered on, when I turn the M100 off > there's power being fed back into the M100 from the printer through the > parallel port and this keeps the REX from resetting. I only figured this > out because it *also* causes the 'low battery' LED on the M100 to > illuminate when the power is switched off. Weird, and probably nothing can > be done about this - I haven't even checked with another parallel printer > to see if this is unique to the DMP-105 or not. I just thought I'd mention > it in case anybody else runs into such a thing. > > So, WordStar 4.0 - I discovered in the process of copying this over that > IMPORT.COM was only copying the first 64kb of any large files over 64kb > in size. Further testing shows that this only happens when using > IMPORT.COM with my NADSbox - if I use mComm on my phone it imports the > full file (the largest was 163kb). I don't know if this is a limitation of > the NADSbox or just some weird interaction between it and IMPORT.COM - of > course, there isn't really any other way to test pulling a large file over > 64kb from the NADSbox that I'm aware of... > > This got me worried about backup integrity because I'd been making backups > using RXCUTL.BA to my NADSbox and those files are enormous (545kb for the > REX backup and 3457kb for the CP/M backup). What if it doesn't write good > data for large files? I know I did a full backup and restore as a test in > the first few days after I got my REXCPM but I don't remember if that > restore was done using mComm, LaddieAlpha, or the NADSbox. I tested > tonight making backups to mComm and to the NADSbox (this is why I was > whining about the speed again earlier tonight :) ) and diffed the resulting > files - they are identical. Whew, my backups are good. I'll test later > what happens if I restore one of these backups from the NADSbox and try to > remember to post my results - it will be interesting to see if it only > supplies the first 64kb or if it goes the distance. > > Last point - what led me to this whole backup/restore thing is that while > I was copying over WordStar 4.0 into a new user area I've run into a CP/M > limit and put too many files into A: for the directory structure to > handle. Sorry, I should have counted them to see how many there were, but > I'm sure it's a documented figure. It may be that 4mb is overkill for > REXCPM unless you're planning to store mostly very large files (or unless > there's a fix for the directory structure limits?), like maybe using > WordStar to write a big novel or something, or writing very large > programs. I forgot to count the number of files I had in all user areas at > the time (I've since made a backup and deleted a bunch of cruft) but I did > note that there was still 1430kb free. > > Okay, the above statements about large files etc. may not be so valid - > doing a little late-night googling right now, I'm finding some info which > indicates that the file system allocates a directory entry for every 16kb > of a file (as a workaround for the fact that each directory entry can only > keep track of 16 1kb blocks)... this means that even if
