On Thu, 17 Oct 2024, Steve Lewis via cctalk wrote:
Well, none of the bubble cartridges has a FORMAT.COM. There is MODE.COM,
CHKDSK.COM, EDLIN.COM, and then SYS.COM .
And trying to run FORMAT.COM from another DOS 3.30 on the PC-5000, it
actually does try to run, but then says "Incorrect DOS version"
Try te VER command, to confirm whether what is running is 2.00
Back in 1982?, when PC-DOS 1.10/1.25 came out, with different disk format,
there were problems. If you stuck one of those disks into a machine
running PC-DOS 1.00, and ran CHKDSK, it would proceed to gladly "repair"
problems with the disk rendering it unusable. (well, alot of tedious
manual repair of the DIRectory needed)
SO, MICROS~1 eventually changed CHKDSK, to not make repairs unless
you had used the /F (fix) option, and explicitly asking you whether you
wanted it to do the "repairs"
(I had an interesting conversation with Jef Raskin about his view that "if
a disk is unreadable, and therefore presumably blank, The computer
should just go ahead anf FORMAT it")
Then, they made another change. EVERY executable program included with
DOS, before it runs would check the currently running DOS version, and
refuse to run if it was the wrong DOS version running. NOT ALL programs
had a problem with running under another version, but they had to be
cautious.. That created problems with some executables, such as LINK and
EXE2BIN that were acquired with one version of DOS, but were needed on
other versions.
The solution to THAT in DOS 5.00? was SETVER. Setver lets DOS lie about
it's age! So, when you want to use DOS 2.00 LINK, you can use setver to
tell DOS, "If LINK asks the DOS version, tell it 2.00", etc.
Obviously you don't have SETVER, that came along later to solve that
problem. SO, you need to do a mnor patch.
You could seek out a copy of DOS 2.00 FORMAT.
OR, since the differences do NOT matter, you can patch FORMAT to not care
about which DOS version is running.
It will be simplest if you use a relatively old verstion of FORMAT that is
a .COM file, not a .EXE Unfortunately the filename won't work for
determining that. (later versions of DOS, when progams became too bulky
for tiny memory model, they used .EXE programs, but renamed them .COM!
Fortunately, DOS 2.11 should be ideal.
The sure way to tell whether itis REALLY .COM or .EXE is whether the
first two bytes of te file are "MZ" (Mark Zbikowski!) ALL .EXE files have
his initials as the first two bytes of the file, disunirregardless of
whether the filename claims to be .COM or .EXE
REAL .COM programs will NOT start with "MZ"
Load it into DEBUG DEBUG FORMAT.COM
(any version of DEBUG that works for you, on any computer)
Use the U command ("UNassemble")
find where it has
MOV AH 30
Int 21
CMP AX, 1e03 or whatever. (3.30)
If the next line is JNZ . . . or JNE ...,, replace that with NOPs, or a
JMP to the next instruction after the JNZ
If the line is JZ or JE, . . . repace that with JMP
OR, change the CMP AX, 1E03 to CMP Ax, 0002
IFF VER reports 2.00
DOS stores the major version number internally as a number which function
30 returns in AL, and a minor version number whigh it stores as if it had
been a 2 digit decimal number returned in AH
Therefore, your 3.30 is not 3 - 3
It is 3 - THIRTY
Yes, 3.30 thinks that its version THIRTY of DOS 3!
By removing or bypassing the comparison of version number, it will now
NEVER give "INCORRECT DIS VERSION"
We're trying another cut of the Sharp MS-DOS 2.11 image (the first one had
some issues). It has a FORMAT.COM, so hopefully that
will just work. If not, then maybe trying to extract an older FORMAT.COM
from a DOS 1.X image might be worth a try? I'm not too savvy
about boot sector stuff and DOS interrupts - maybe there is some DEBUG.COM
stuff that can help probe boot sectors of these bubble cartridges?
I'm not sure if I can borrow a DEBUG.COM from another DOS disks, will try
that also over the weekend.
DEBUG.COM will only run on the version of DOS that it shipped with unless
you do the same patch. 'course how do you run DEBUG to patch DEBUG if it
won't run until sfter you patch it? :-)
--
Grumpy Ol' Fred [email protected]
