RomWBW and use of CPM2RSX under CPM3

[rwd...@gmail.com]

There is a utility called cpm2.com (which is actually an rsx known as CPM2RSX).  It runs under CP/M 3 to provide a compatibility layer for cp/m 22 bios calls, e.g. to get Andy Johnson Laird's find utility to work.

When I run cpm2.com under cpm3 of romwbw I get an error:

K>cpm2
K:CPM2     COM
*** Privileged Instruction @3838 [76696F75738300436C6F736581008A83]

Does anyone know why this might happen, and from an architectural standpoint should it be feasible to run cpm2 in this way under romwbw?

Richard

[Wayne Warthen]

Hi Richard,

The message you have received occurs when the Z280 CPU encounters an instruction that is either unknown or not allowed in "user" programs.  The message indicates that the offending opcode is at address 0x3838 and shows the 16 bytes starting at that address.  In this case the instruction is 0x76 which is a HALT instruction.

A HALT is not normally appropriate in a program unless it is dealing with hardware interrupts which it should not be.  So, the question becomes how did the program flow get to a HALT?  Do you have the source code I could look at?

There is no reason that CPM2 should not be entirely compatible with RomWBW.  RomWBW utilizes a completely vanilla CP/M 3 implementation.  All it does is implement a CBIOS that forwards calls to RomWBW's HBIOS.

Thanks,

Wayne

[Douglas Miller]

Also note that 0x3838 is an unlikely address for an RSX, plus the "opcodes" at that address are actually a (sub)string "vious\0". Looks to me like something crashed and ran off into random memory.

[rwd...@gmail.com]

There is some source at https://mark-ogden.uk/mirrors/www.cirsovius.de/CPM/Projekte/Assembler/RSX/CPM2/CPM2RSX-MAC.txt

I can't guarantee that this exactly matches the cpm2.com that I was using.  I have not had the chance to build and experiment yet.

 

I also noticed that this was a documented feature on Morrow CPM3 systems.

It seems that the RSX is given a com header so that when invoked it loads the rsx. Morrow provided cpm3.com to turn it off.

Richard

[Wayne Warthen]

On Friday, February 25, 2022 at 2:29:30 PM UTC-8 rwd...@gmail.com wrote:

There is some source at https://mark-ogden.uk/mirrors/www.cirsovius.de/CPM/Projekte/Assembler/RSX/CPM2/CPM2RSX-MAC.txt

I can't guarantee that this exactly matches the cpm2.com that I was using.  I have not had the chance to build and experiment yet.

 

I also noticed that this was a documented feature on Morrow CPM3 systems.

It seems that the RSX is given a com header so that when invoked it loads the rsx. Morrow provided cpm3.com to turn it off.

OK, well it is not obvious what the problem is.  The address where execution is interrupted is not an address that the RSX would naturally occupy.  The RSX is doing all kinds of bank switching, so a lot could go wrong.  Any chance the binary you are using is Morrow specific?

Thanks,

Wayne 

[Douglas Miller]

Could the RSX be crossing the common memory boundary? and so it partially disappears after bank switching?

[Wayne Warthen]

On Friday, February 25, 2022 at 3:30:42 PM UTC-8 Douglas Miller wrote:

Could the RSX be crossing the common memory boundary? and so it partially disappears after bank switching?

Hi Doug,

Sorry, I missed your previous response and I see that I mostly repeated what you said.  Anyway, I would not expect the RSX to wind up crossing the common boundary.  The TPA for RomWBW running CP/M 3 is 60K and the boundary is at 32K.  Assuming it is loaded high (I think it is), I don't see how it could be big enough to cross the common boundary.

Thanks,

Wayne

[Richard Deane]

I don't know the derivation of my cpm2.com. I found Morrow doc but didn't look at the software.

I am prepping  my non RomWBW Z80-MBC2 system (it's a slow Z80 :) ) so that I can ensure I have a proper working software set under cpm/3, before I experiment with building the rsx from the link I gave.

Richard

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/V4UORGpFW5k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/aff5b689-6187-4dc5-9502-808803b0fd1fn%40googlegroups.com.

[Douglas Miller]

Note that the Z80 won't trap illegal instructions, so even if it still crashes you won't have the same (graceful) result.

[Wayne Warthen]

On Saturday, February 26, 2022 at 10:18:54 AM UTC-8 rwd...@gmail.com wrote:

I don't know the derivation of my cpm2.com. I found Morrow doc but didn't look at the software.

I am prepping  my non RomWBW Z80-MBC2 system (it's a slow Z80 :) ) so that I can ensure I have a proper working software set under cpm/3, before I experiment with building the rsx from the link I gave.

Sounds good Richard.  It would be nice to know if the application actually works before I start chasing my tail...  🙂

Thanks,

Wayne 

[rwd...@gmail.com]

Some progress:

The fog164.arc contains a version of cpm2.com and other useful bits. Can be downloaded from here -  http://www.znode51.de/fog/filelist.htm

If I run BIOSFIX.COM then CPM2.COM under CPM3 of my Z80-MBC2 system (non ROMWBW)  then it works and I can run find.com (example from Andy Johnson Laird  Programmers CP/M Handbook) e.g with command find *:**

I have renamed the file to find-ajl.cpm and attached it to this message, just rename back to .com before use. Should work fine under zsystem and cpm22 if you want to get familiar with it. It is nice on a fast system, a bit tedious on a slow one.

If I run this under ROMWBW, with biosfix.com and cpm2.com first, then it will fail with some disk io errors.

Also in fog164.arc is bios2rsx which seems similar to cpm2.com; I shall try that to see if it works.

Keeps the brain active.

Richard

[Douglas Miller]

Some things to consider: Using an RSX designed for Morrow systems may not be the best way to workaround a deficiency in a program that was not written to run under CP/M 3. There have been improved versions of FIND.COM out there, and I'm trying to track one down now. I helped on changes to FIND.COM to make it work "correctly" under CP/M 3 - by using the facilities designed for CP/M 3 to access the BIOS. Directly accessing the CP/M 3 BIOS has been problematic in the past, and DRI never recommended that.

[Richard Deane]

The fog164 version of cpm2 rsx seems to be generic judging by the comments in cpm2.doc -and it works in z80-mbc2 under cpm3.

My mention of Morrow was because they shipped one, documented it, and were a reputable supplier.

A better version of find would be welcome if it has a single screen summary of numbers of files across all disks and user numbers (though need to expand console more than 80*24, but that's fine.

I also use sfile32 a lot which is clean under cpm3 and cpm22.

Richard

On Sun, 27 Feb 2022 at 17:45, Douglas Miller <durga...@gmail.com> wrote:

Some things to consider: Using an RSX designed for Morrow systems may not be the best way to workaround a deficiency in a program that was not written to run under CP/M 3. There have been improved versions of FIND.COM out there, and I'm trying to track one down now. I helped on changes to FIND.COM to make it work "correctly" under CP/M 3 - by using the facilities designed for CP/M 3 to access the BIOS. Directly accessing the CP/M 3 BIOS has been problematic in the past, and DRI never recommended that.

--

You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/V4UORGpFW5k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/586d4412-179e-4744-9e43-a6b88a84adabn%40googlegroups.com.

[Douglas Miller]

This is the find command I was thinking of: https://github.com/jayacotton/find. It is not Andy Laird's FIND. I'll look into fixing Andy's FIND for CP/M 3.

[Wayne Warthen]

First of all, thanks to everyone that has jumped in to help with this.  Really appreciate it.  My primary (actually only) concern is if RomWBW's implementation of CP/M 3 has a bug or is deficient in some way.  These RSXs push the boundaries of what is supposed to be done under CP/M 3.  But with that said, I hate the idea of latent issues within my code.  🙂

I am not sure what platform you are using Richard, but I am currently testing on a Z180-based MK4.  It is a good platform for me because it is one of the oldest and most stable platforms I have.  Anyway, I am finding that I can run CPM2, followed by FIND-AJL and, in general, it works.  As you will see below, running it with some specified drive letters seems to work fine.  However, when I run it with "*" for the drive letter, I get a directory read error.  It is not exemplified below, but further testing seems to indicate that running it against the RomWBW ROM or RAM drive letters is problematic.  Note that I am not using BIOSFIX.  I have tried with and without it and it seems to make no difference for me.

I would be interested to know if you can run it successfully on your RomWBW system by specifying just hard disk drive letters.  I am also interested in anything that Doug finds if/when he looks at what the FIND-AJL code is doing.  In the meantime, I will review my RAM/ROM disk code as invoked by CP/M 3 and see if anything looks amiss.

Thanks,

Wayne

CP/M V3.0 Loader
Copyright (C) 1998, Caldera Inc.

 BNKBIOS3 SPR  F600  0800
 BNKBIOS3 SPR  4500  3B00
 RESBDOS3 SPR  F000  0600
 BNKBDOS3 SPR  1700  2E00

 60K TPA

CP/M v3.0 [BANKED] for HBIOS v3.1.1-pre.155

RAM Disk Initialized

A>cpm2

[CPM2 RSX active]
A>find-ajl afg:*.*

FIND Version 1.0 02/11/83 (Library 1.0)
Searching disk : A
Searching disk : F
Searching disk : G
                Numbers show files in each User Number.
                          --- User Numbers ---                     Dir. Entries
      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Used Free
A:   51       4   2  23                                               185  839
F:   42       4   2  24                                               156  868
G:   68       4   2  24                                               190  834
[CPM2 RSX active]
A>find-ajl *:*.*

FIND Version 1.0 02/11/83 (Library 1.0)
Searching disk : A
Searching disk : B
Error during Reading Directory on disk &:.
[CPM2 RSX active]
A>

[Richard Deane]

Wayne, I am running on zzrcc with the fog 164 version of cpm2.com. With the unknown cpm2.com I had also had it fail on sc126, but not tried that since

Testing your scenario of find-ajl ijkl:*.* on zzrcc worked for me, so it does indicate the bug relates to the wildcard drive search. in a way that is good news - the bug is more contained and narrower in scope.

Interesting corruption when running assign command after cpm2.com rsx loaded

K>find-ajl ijkl:*.*
I:FIND-AJL COM

FIND Version 1.0 02/11/83 (Library 1.0)

Searching disk : I
Searching disk : J
Searching disk : K
Searching disk : L

                Numbers show files in each User Number.
                          --- User Numbers ---                     Dir. Entries
      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Used Free

I:   82   4  14  20  42   8  15   5                                   258  766
J:  151  32  19  34  30  27  33  52   4      32                       520  504
K:   27                                                                44  980
L:  -- None --                                                          0 1024
[CPM2 RSX active]
K>assign
A:ASSIGN   COM

   A:=PPPSD117:116
   B:=PPPSD120:105
   C:=PPPSD9:106
   D:=PPPSD83:105
   E:=PPPSD101:242
   F:=PPPSD111:116
   G:=PPPSD118:229
   H:=PPPSD117:115
   I:=PPPSD115:244
   J:=PPPSD105:230
   K:=PPPSD13:9
   L:=PPPSD118:97
   M:=PPPSD117:109
   N:=PPPSD44:120
   O:=PPPSD42:51
   P:=PPPSD13:9

[CPM2 RSX active]
K>

I rebooted and ran cpm/3  again without BIOSFIX being run, and I noted that the ASSIGN output is wrong immediately after running cpm2.com, don't even need to run find-ajl to see that corruption.

Regards

Richard

--

You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/V4UORGpFW5k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/f514110e-59cf-4a82-b469-bfcda643f4can%40googlegroups.com.

[Wayne Warthen]

On Sun, Feb 27, 2022 at 1:15 PM Richard Deane <rwd...@gmail.com> wrote:

Wayne, I am running on zzrcc with the fog 164 version of cpm2.com. With the unknown cpm2.com I had also had it fail on sc126, but not tried that since

Testing your scenario of find-ajl ijkl:*.* on zzrcc worked for me, so it does indicate the bug relates to the wildcard drive search. in a way that is good news - the bug is more contained and narrower in scope.

I am happy to hear that the ZZRCC is behaving consistently.  This is indeed a little better -- gives me a better focus.

 

Interesting corruption when running assign command after cpm2.com rsx loaded

Darn you!  🙂 I had hoped to have that fixed before you even saw it.  I had also observed this and the problem in my code is obvious (to me).  I did something really stupid that ignored the possiblity of an RSX being loaded.  The fix is working and will be checked in soon.

This problem is purely an RSX incompatibility I introduced in the ASSIGN command.  It does not have anything to do with the CPM2 problem.

Thanks,

Wayne

[Wayne Warthen]

On Sunday, February 27, 2022 at 4:24:49 PM UTC-8 Wayne Warthen wrote:

On Sun, Feb 27, 2022 at 1:15 PM Richard Deane <rwd...@gmail.com> wrote:

Wayne, I am running on zzrcc with the fog 164 version of cpm2.com. With the unknown cpm2.com I had also had it fail on sc126, but not tried that since

Testing your scenario of find-ajl ijkl:*.* on zzrcc worked for me, so it does indicate the bug relates to the wildcard drive search. in a way that is good news - the bug is more contained and narrower in scope.

I am happy to hear that the ZZRCC is behaving consistently.  This is indeed a little better -- gives me a better focus.

I have tried pretty hard to get the CPM2 RSX to misbehave with any other tools and it does not seem to.  Additionally, under FIND-AJL, it only misbehaves with the ROM or RAM disks of RomWBW.  So, I am now a little unsure of whether there is a RomWBW issue.  It clearly doesn't like something about the RAM/ROM disks, but that could be a lot of stuff.  Does Z80-MBC2 have anything like a RAM/ROM disk?  Where do I find a copy of the source for FIND-AJL?

Interesting corruption when running assign command after cpm2.com rsx loaded

Darn you!  🙂 I had hoped to have that fixed before you even saw it.  I had also observed this and the problem in my code is obvious (to me).  I did something really stupid that ignored the possibility of an RSX being loaded.  The fix is working and will be checked in soon.

This problem is purely an RSX incompatibility I introduced in the ASSIGN command.  It does not have anything to do with the CPM2 problem.

I have not yet checked in my ASSIGN command work-in-progress because there are still a couple of places that I am worried about the way I handled CP/M 3.  For now, just make sure to do any ASSIGN work prior to loading an RSX.  Note that the CPM2 RSX is not overriding the CP/M version number returned via the CP/M API.  Any tool that does so will cause ASSIGN to go crazy.  ASSIGN must see the real version number.

Thanks,

Wayne

[Douglas Miller]

This may be an interesting data point, or else a distraction, but I took the FIND source code that I found and converted it to build with zcc (as I don't have a setup for BDS-C) and it does not work correctly under Heath CP/M 2.2 or MMS CP/M 3 on (simulated) Heathkit hardware. It does not crash, but just never finds any files. There are several possible explanations, though, like the source code I have is bad or I messed up something converting to zcc.

One thing I have noticed thus far is that it seems to be reading raw sectors in order to search the directory - in other words, it does not use the BDOS functions. Perhaps this is a clue as to some other problems being seen. Anything "unexpected" about the DPB might throw off the code in FIND - I'm not saying the DPBs are wrong, just that they might be exceeding certain limits that FIND does not handle.

[Wayne Warthen]

On Sun, Feb 27, 2022 at 7:23 PM Douglas Miller <durga...@gmail.com> wrote:

This may be an interesting data point, or else a distraction, but I took the FIND source code that I found and converted it to build with zcc (as I don't have a setup for BDS-C) and it does not work correctly under Heath CP/M 2.2 or MMS CP/M 3 on (simulated) Heathkit hardware. It does not crash, but just never finds any files. There are several possible explanations, though, like the source code I have is bad or I messed up something converting to zcc.

One thing I have noticed thus far is that it seems to be reading raw sectors in order to search the directory - in other words, it does not use the BDOS functions. Perhaps this is a clue as to some other problems being seen. Anything "unexpected" about the DPB might throw off the code in FIND - I'm not saying the DPBs are wrong, just that they might be exceeding certain limits that FIND does not handle.

Thanks Doug.  Indeed, something like this seems like a possible explanation.  One thing that is a little unusual about the RomWBW ROM/RAM disks is that they have no system tracks.

I believe that further investigation should center on understanding what FIND-AJL is doing.

Richard, are you building the code or just running a pre-compiled copy you found?  I'm in the same situation as Doug in that I don't have a BDS C build environment ready to go.

Thanks,

Wayne

[Douglas Miller]

Again, this may be a detour from the original problem but... I see a confusing trend in the source code that I have (http://www.cpm.z80.de/download/cpm-hndbk-src.zip), for example:

struct _dpb
{
unsigned dpb_sptrk; /* sectors per track */
short dpb_bshift; /* block shift */
short dpb_bmask; /* block mask */
short dpb_emask; /* extent mask */
unsigned dpb_maxabn; /* maximum allocation block number */
unsigned dpb_maxden; /* maximum directory entry number */
short dpb_rab0; /* allocation blocks reserved for */
short dpb_rab1; /* directory blocks */
unsigned dpb_diskca; /* disk changed workarea */
unsigned dpb_trkoff; /* track offset */

};

The problem is that many of these fields should be single-byte (8-bit), and as far as I can tell (at least in zcc) "short" is a 2-byte (16-bit) data type. That's the way I always remember "short" being defined, unless memory fails me. I see this use of "short" all over the code, for CP/M structure elements that should be using "char".

So, I'm starting to doubt my source code as being correct, or else there are bigger issues with Andy's FIND program than we know.

[Douglas Miller]

Cancel that, I found "#define short char" in "library.h", so those fields should be getting "fixed". It still annoys me, and has probably tripped me up when I was converting to zcc - so need to go back and be careful about where I used "short" thinking it was 16-bit. I'm not sure what I think about this redefining of "short".

[Richard Deane]

The source is find.c and library.c in  attached cpm-hndbk-src.

the other attached file (lbr)  is a bdsc version, ready to go, extract with nulu. Might even have find and library in it.

Hope this helps

Richard

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/CADQpb5OUOQcomKLJ3vG5yTxFBRQmXBxvS8zC4tZ%2BOvnKjFSe5w%40mail.gmail.com.

[Douglas Miller]

That's the same source code package I am looking at.

On Monday, February 28, 2022 at 9:11:31 AM UTC-6 rwd...@gmail.com wrote:

The source is find.c and library.c in  attached cpm-hndbk-src.

...

[Wayne Warthen]

On Monday, February 28, 2022 at 4:57:00 AM UTC-8 Douglas Miller wrote:

Cancel that, I found "#define short char" in "library.h", so those fields should be getting "fixed". It still annoys me, and has probably tripped me up when I was converting to zcc - so need to go back and be careful about where I used "short" thinking it was 16-bit. I'm not sure what I think about this redefining of "short".

That is indeed very unusual.  I agree that it is not a good idea to redefine keywords!  Additionally, the #define seems wrong.  Seems like it should be "#define short unsigned char".

Thanks,

Wayne 

[Wayne Warthen]

On Sunday, February 27, 2022 at 7:00:06 PM UTC-8 Wayne Warthen wrote:

Interesting corruption when running assign command after cpm2.com rsx loaded

This problem is purely an RSX incompatibility I introduced in the ASSIGN command.  It does not have anything to do with the CPM2 problem.

 

OK, the updated ASSIGN command is now checked in to the dev branch.  This does nothing to resolve the core issue of getting FIND-AJL running using the CPM2 RSX, but it is a step in the right direction.

Thanks,

Wayne

[Douglas Miller]

I just realized what I believe is another fatal flaw in this FIND.COM on CP/M 3. Since it is directly calling the BIOS to access the directory, and has no knowledge of CP/M 3, it has no idea what physical sector size the disk uses in the BIOS. Everything will be off, including the possibility that the BIOS read operation will overflow the application buffer.

[Wayne Warthen]

On Monday, February 28, 2022 at 2:16:22 PM UTC-8 Douglas Miller wrote:

I just realized what I believe is another fatal flaw in this FIND.COM on CP/M 3. Since it is directly calling the BIOS to access the directory, and has no knowledge of CP/M 3, it has no idea what physical sector size the disk uses in the BIOS. Everything will be off, including the possibility that the BIOS read operation will overflow the application buffer.

In theory, the CPM2 RSX should take care of that, right?

Thanks,

Wayne 

[Douglas Miller]

True, from the disassembly we have it appears that CPM2 RSX is doing the deblocking. It is also doing some sort of mirroring of the ALV, which I don't fully grok yet. It certainly has some complexities worthy of more investigation.

My effort to make FIND.COM to be CP/M-3-aware has hit the point where I'm no longer interested in trying to make it's BIOS calls work. If I continue, I will rewrite it to "do the right thing" and use BDOS calls to search the directory. The only BIOS call would be for an error-controlled SELDSK so that a "probe" of a non-existent drive will not be fatal.

[Wayne Warthen]

I spent some time adding some diagnostic code to FIND-AJL.  I observed the following:

1. The sector skew mechanism is not working.  I think this is related to something going on in the CPM2 RSX, but hard to prove.  I removed the skew functionality in FIND-AJL and got around this issue.  For RomWBW, no sector translation is needed.
2. The main problem...  When running against a large disk, CPM2 appears to be deblocking as needed on BIOS calls.  However, for RAM/ROM disk I/O, it is simply forwarding the disk I/O request along to the CP/M 3 BIOS.  The CP/M 3 BIOS reads a physical sector (as designed) directly into the FIND-AJL buffer and immediately overflows the buffer (buffer is 128 bytes, physical sector is 512 bytes).  Devastating corruption ensues.

I have no idea why the CPM2 RSX is not deblocking for the RAM/ROM disks.  RomWBW has nothing to do with this.  I have confirmed that the disk I/O calls sent to RomWBW are specifically requesting the full sector of data be loaded right into the FIND-AJL buffer that is too small.  RomWBW and my CP/M 3 BIOS could not invent a call that includes a pointer that points exactly at the FIND-AJL buffer -- only the CPM2 RSX should know that.  For some reason, the CPM2 RSX is not properly trapping the disk I/O calls in the case of the RAM/ROM disks.

I am 90% certain that there is some deficiency in the CPM2 RSX that is causing the FIND-AJL issues.  Richard, do you have source for the CPM2 RSX?  I see "bios2rsx.asm" in the FOG164 archive, but it is not clear to me that it is the source used for CPM2.

Oh, one more oddity.  The documentation for the CPM2 RSX explicitly says it will return the CP/M 2.2 version number when queried via BDOS.  According to my ASSIGN application, that is not happening.  My ASSIGN application is still seeing the CP/M 3 version number when queried after CPM2 RSX is loaded.

Thanks,

Wayne

[Wayne Warthen]

Since I was already 90% invested, I went ahead and tried the BIOS2RSX from the FOG164 archive.  It worked perfectly across all drives (RAM/ROM/floppy/hard).  See below.

I am going to declare the CPM2 RSX to be deficient and suggest that BIOS2RSX be used instead.  I think RomWBW is sufficiently vindicated.  

If you want to build BIOS2RSX, you need to be sure to update the equate at the top which determines the maximum physical sector size to allow.  It is 256 in the source provided and needs to be 512.  I am attaching a copy of the RSX file here with the adjustment included  I found it easiest to attach it to the FIND command by using GENCOM like this:

GENCOM FIND BIOS2RSX

Once this is done, you can just enter FIND and the RSX loads/unloads automatically.  Kind of slick.

Oh, and one last thing.  I think there is still something amiss with the FIND-AJL program.  Notice below how it indicates that the B drive has no files, yet it indicates there are 2 directory entries used.  In fact, there is one file on B.  This misbehavior happens when FIND is run under CP/M 2.2 as well, so this anomaly is not related to CP/M 3 or the RSX.  I have had quite enough fun with FIND-AJL, so I shall leave the resolution of this anomaly to someone else!

Case closed.

Thanks,

Wayne

M>find *:*.*

BIOS ver 2.21 ACTIVE

FIND Version 1.0 02/11/83 (Library 1.0)
Searching disk : A
Searching disk : B

Searching disk : C
Searching disk : D
Searching disk : E

Searching disk : F
Searching disk : G

Searching disk : H

Searching disk : I
Searching disk : J
Searching disk : K
Searching disk : L

Searching disk : M

                Numbers show files in each User Number.
                          --- User Numbers ---                     Dir. Entries
      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  Used Free

A:   53       4   2  23                                               186  838
B:  -- None --                                                          2  254
C:   35                                                                50  206
D:   48                                                                51  205
E:   48                                                                51   77

F:   42       4   2  24                                               156  868

G:   70       4   2  24                                               192  832
H:  145       4   2  24                                           6   289  735
I:   36  18       2  24                                               135  889
J:   68  18       2  24                                               183  841
K:   88           2                                                   149  875
L:   32           2  23                                               131  893
M:   38                                                                55  969
M>

[Richard Deane]

THANK YOU SO MUCH. Really appreciate it, and glad to know it is not a RomWBW bug!

Richard. 

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/3c42346a-0ac1-40b4-b032-130318442875n%40googlegroups.com.