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 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 you load it up with large files you're going
to run out of directory space as a 160kb file would consume ten directory
entries. It also seems that the directory can be different sizes on different
systems and disk formats... so:
I guess this is a question for Philip Avery - how big is the directory
structure in the 2mb and 4mb REXCPM images? Can it be made bigger in the 4mb
image? If so, is this something one could do oneself (not being an expert on
filesystems, but being adventurous and willing to play with a hex editor), or
best left to the professionals? :)
jim
