4 Jul
2005
4 Jul
'05
9:29 a.m.
Hi Grumpy :-)
On the Windows 2K machine I used /F:720 to get a 720K format. On the
Linux machine I used /dev/fd0D720, which should be equivalent. It was
definitely a 720K format, as other parts of the copied DOS 3.3 diskette
were readable. Only parts of track zero were consistently bad across
the multiple diskettes, and they were not flagged as bad on the other
machines. Even when formatting on the Jr (booted with the original DOS
diskette and trying to format double density) the format fails.
I wasn't aware of DOS 3.2 and 3.3 falsely reporting media problems when
straddling a 64K boundary. I wasn't running with TSRs, but the Jr has
timing problems of it's own. I don't think this was the problem though
- DOS 3.3 was fine.
So it still looks like a double density diskette prepared in a 1.44MB
drive works fine on modern machines, but isn't quite right when the
1.44MB drive is running on an old controller. Like a timing issue.
Double density diskettes cut on genuine 720K drives work fine.
I'm thinking of getting a special breed of Teac 1.44MB. It has a
different model number, and it has jumpers and a modification procedure
published by Teac to make it a substitute for an original 720K drive.
That would be an interesting experiment.
4 Jul
4 Jul
2:38 p.m.
On Mon, 4 Jul 2005, Michael B. Brutman wrote:
Hi Grumpy :-)
On the Windows 2K machine I used /F:720 to get a 720K format.
Good
On XP, you'll have to switch to /T:80/N:9 (incomplete support of /F: )
Also, of course, be sure to include /U in your FORMAT command line, or it
will leave existing [wrong?] format on the disk.
For the Jr to properly recognize/handle 720K, you'll need to include
DEVICE = DRIVER.SYS /F:2 in CONFIG.SYS when booting the Jr..
On machines with NON-IBM BIOS, you can usually get away with DRIVPARM
instead.
I wasn't aware of DOS 3.2 and 3.3 falsely
reporting media problems when
straddling a 64K boundary. I wasn't running with TSRs, but the Jr has
timing problems of it's own. I don't think this was the problem though
- DOS 3.3 was fine.
FORMAT doesn't properly handle errcode 9 from Int13h. Although DMA can
not straddle a 64K boundary, FORMAT makes no effort to check/move the
buffer. (As Tony says, "They did WHAT??")
If you are getting "bad media" messages CONSISTENTLY from FORMAT, load or
remove a TSR or a device driver, to move the buffer.
So it still looks like a double density diskette
prepared in a 1.44MB
drive works fine on modern machines, but isn't quite right when the
1.44MB drive is running on an old controller. Like a timing issue.
Double density diskettes cut on genuine 720K drives work fine.
Are you bulk erasing the diskettes?
FORMAT often fails to wipe out all residual formatting, particularly on
track 0.
HOWZBOUT: If you FORMAT on a real 720K drive, does read/write work OK?
I'm thinking of getting a special breed of Teac
1.44MB. It has a
different model number, and it has jumpers and a modification procedure
published by Teac to make it a substitute for an original 720K drive.
That would be an interesting experiment.
Aren't there any 720K drives around?
The Jr works very nicely with SA465, Teac55F, etc. drives to give 5.25"
720K (like the JX model!) using DOS 3.20, 3.3x, or SOME OEM versions of
MS-DOS 2.11.
If you are using the original godawful Qume 142 drives, then you may need
to mess with Int1Eh, or run DOS 2.10. (Those POS drives have timing
problems - they take so long to step that most OS's will time-out waiting
for them)
--
Grumpy Ol' Fred cisin at xenosoft.com
7064
days inactive
7064
days old
1 comments
2 participants
participants (2)
-
cisin＠xenosoft.com -
mbbrutman＠brutman.com