> -----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
