24 Dec
2013
24 Dec
'13
12:37 p.m.
I'm attempting to convert a TRS-80 DMK image to ImageDisk format in order
to write out a real floppy. The original was 80-track, DS, DD and indeed
the sdltrs emulator concurs and can catalog the image without incident.
The DMK2IMD utility converts it without complaint and reports:
80X6400 DSMD
250k data rate assumed
But, when I fire up IMD and write it out things stop after track 39 and
tell me that 2880 sectors have been written. That's the correct number of
sectors, but they should be spread over 80 tracks.
Clearly I'm missing something, but am not sure exactly what. The drive is
80-track DSQD and data rate is 250Kbps. I am not set for double-step and
imd believes (correctly) that the drive is an 80-track unit.
(I have also tried this with a more common 5.25" HD 1.2M drive - using
250k-->300k rate conversion - but the same thing happens)
Steve
--
24 Dec
24 Dec
1:08 p.m.
On Tue, 24 Dec 2013, Steven Hirsch wrote:
I'm attempting to convert a TRS-80 DMK image to
ImageDisk format in order
to write out a real floppy. The original was 80-track, DS, DD and indeed
the sdltrs emulator concurs and can catalog the image without incident.
The DMK2IMD utility converts it without complaint and reports:
80X6400 DSMD
250k data rate assumed
But, when I fire up IMD and write it out things stop after track 39 and
tell me that 2880 sectors have been written. That's the correct number of
sectors, but they should be spread over 80 tracks.
Clearly I'm missing something, but am not sure exactly what. The drive is
80-track DSQD and data rate is 250Kbps. I am not set for double-step and
imd believes (correctly) that the drive is an 80-track unit.
(I have also tried this with a more common 5.25" HD 1.2M drive - using
250k-->300k rate conversion - but the same thing happens)
WHAT disk format is it?
Stock TRS80 was neither DS nor QD.
Model 1 was originally SSSD 35 track/35 cylinder,
Model 3 was originally SSDD 40 track/40 cylinder,
there were NUMEROUS aftermarket setups for other formats, such as doubler
for double density on model 1, and most aftermarket OS's would support
double sided, and/or 96tpi 80 cylinder.
Could one or more of your tools be interpreting "80 track" to mean 40
cylinder double sided? (not a stock format, either)
--
Grumpy Ol' Fred cisin at xenosoft.com
http://www.xenosoft.com/FPUIB
2:28 p.m.
On Tue, 24 Dec 2013, Fred Cisin wrote:
But, when I fire up IMD and write it out things stop
after track 39 and
tell me that 2880 sectors have been written. That's the correct number of
sectors, but they should be spread over 80 tracks.
To get 2880 sectors in 40 cylinders would require 128 bytes per sector.
In MANY CP/M tools, "sector" was used to refer to a record, or
"logical"
sector, that was blocked/deblocked into larger physical sectors. Thus, 18
256 byte physical sectors would be CALLED "26 sectors"
--
Grumpy Ol' Fred cisin at xenosoft.com
http://www.xenosoft.com/FPUIB
5:02 p.m.
On Tue, 24 Dec 2013, Fred Cisin wrote:
On Tue, 24 Dec 2013, Steven Hirsch wrote:
Sorry, left out the key detail: It was an LDOS 5.1.3 diskette, and is
definitely 96tpi 80-cylinder, DS, "QD" (I don't like that way of
describing an MFM 250Kbps format, but it seems to be relatively common
usage).
And, I mistyped: IMD is claiming that 1440 256-byte sectors are being
written. Consistent with the fact that it's truncating the write after
Track 39.
I'm attempting to convert a TRS-80 DMK image
to ImageDisk format in order
to write out a real floppy. The original was 80-track, DS, DD and indeed
the sdltrs emulator concurs and can catalog the image without incident.
The DMK2IMD utility converts it without complaint and reports:
80X6400 DSMD
250k data rate assumed
But, when I fire up IMD and write it out things stop after track 39 and
tell me that 2880 sectors have been written. That's the correct number of
sectors, but they should be spread over 80 tracks.
Clearly I'm missing something, but am not sure exactly what. The drive is
80-track DSQD and data rate is 250Kbps. I am not set for double-step and
imd believes (correctly) that the drive is an 80-track unit.
(I have also tried this with a more common 5.25" HD 1.2M drive - using
250k-->300k rate conversion - but the same thing happens)
WHAT disk format is it?
Stock TRS80 was neither DS nor QD.
Model 1 was originally SSSD 35 track/35 cylinder,
Model 3 was originally SSDD 40 track/40 cylinder,
there were NUMEROUS aftermarket setups for other formats, such as doubler
for double density on model 1, and most aftermarket OS's would support
double sided, and/or 96tpi 80 cylinder. Could one or more of your tools be interpreting
"80 track" to mean 40
cylinder double sided? (not a stock format, either)
That is very possible. If it counts each side as a "track", then that is
indeed a count of 80. Problem is that the sdltrs emulator is reporting
the correct geometry when I mount the image.
I'll dig into the source for DMK2IMD and see exactly what "80X6400 DSMD"
means.
Merry Christmas!
Steve
--
7:13 p.m.
A long shot:
Some BIOS's INT13h, when using 250K, and particularly 300K, data transfer
rate will AUTOMATICALLY enable double stepping.
"Thanks a lot"
25 Dec
25 Dec
5:21 p.m.
On Tue, 24 Dec 2013, Fred Cisin wrote:
A long shot:
Some BIOS's INT13h, when using 250K, and
particularly 300K, data transfer
rate will AUTOMATICALLY enable double stepping.
I'll file that one away. Thanks for the heads-up!
Turns out the image is indeed 80-cylinder DS. I was able to write a
working diskette on a 1.2M HD drive from within the xtrs emulator (you can
assign physical drives to the emulated machine - nice feature). Still to
be determined is why the ImageDisk conversion fails.
When I read the working disk with IMD, it complains about "deleted data
marker" on track 39 but continues to read all 80 cylinders. That is
probably what's throwing the DMK2IMD tool for a loop. It has a couple of
switches that seem pertinent and I'll give that a try tomorrow. Would be
nice to understand in case this comes up again.
Steve
--
6:02 p.m.
> A long shot:
> Some BIOS's INT13h, when using 250K, and particularly 300K, data transfer
> rate will AUTOMATICALLY enable double stepping.
On Wed, 25 Dec 2013, Steven
Hirsch wrote:
I'll file that one away. Thanks for the
heads-up!
. . . be determined is why the ImageDisk conversion fails.
. . .
When I read the working disk with IMD, it complains about "deleted data
marker" on track 39 but continues to read all 80 cylinders.
Randy Cook (the original author of TRS-DOS) used some oddball data address
marks, specifically including using a different data address mark for
directory sectors than for "normal" sectors! In fact, the 179x
controller, as used in model 2 and "doubler"s was incapable of writing
some of the DAMs used on the model 1 (single density, 1771 FDC)! Because
of that, the model 3 hardware COULD NOT write a "correct" model 1 Single
Density disk. That is the main reason why the "doubler"s included an
extra socket in order to have BOTH 179x AND 1771 chips, instead of just
179x.
Therefore, THAT disk format presumably has the DIRectory on track 39.
That is
probably what's throwing the DMK2IMD tool for a loop. It has a couple of
switches that seem pertinent and I'll give that a try tomorrow. Would be
nice to understand in case this comes up again.
--
Grumpy Ol' Fred cisin at xenosoft.com
http://www.xenosoft.com/FPUIB
26 Dec
26 Dec
12:33 p.m.
> A long shot:
> Some BIOS's INT13h, when using 250K, and particularly 300K, data transfer
> rate will AUTOMATICALLY enable double stepping.
On Wed, 25 Dec 2013, Steven
Hirsch wrote:
I'll file that one away. Thanks for the
heads-up!
. . . be determined is why the ImageDisk conversion fails.
. . .
When I read the working disk with IMD, it complains about "deleted data
marker" on track 39 but continues to read all 80 cylinders.
Randy Cook (the original author of TRS-DOS) used some oddball data address
marks, specifically including using a different data address mark for
directory sectors than for "normal" sectors! In fact, the 179x
controller, as used in model 2 and "doubler"s was incapable of writing some of the DAMs used on the model 1 (single density,
1771 FDC)! Because
of that, the model 3 hardware COULD NOT write a "correct" model 1 Single
Density disk. That is the main reason why the "doubler"s included an
IIRC, LDOS on the model 1 used the normal 'deleted data marker' on the
directory track (as it did on the model 3, and indeed model 4 TRS-DOS
6.x, which is LDOS). A mdoel 3 can write a correct model 1 _LDOS_ single
densiy disk.
extra socket in order to have BOTH 179x AND 1771
chips, instead of just
179x.
Therefore, THAT disk format presumably has the DIRectory on track 39.
That would make sesne. The directoy was naar the middle of the recorded
area, on a track of about half the number of total tracks, on both
TRS-DOS and LDOS. So the nromal model 1 TRS-DOS disk (35 tracks) has the
directory on track 17. IIRC, with LDOS you can specify where you want the
directory when you format the disk, but the defuult is 'halfway along'.
So track 39 would be normal for an 80 track disk.
-tony
2:13 p.m.
On Thu, 26 Dec 2013, Tony Duell wrote:
absolutely right! key adjacency.
directory
sectors than for "normal" sectors! In fact, the 179x
controller, as used in model 2 and "doubler"s was incapable of writing
^^^^^
I suspect you mean 'model 3' here. The 179x was used in the model 2, but
27 Dec
27 Dec
12:38 p.m.
On Thu, 26 Dec 2013, Tony Duell wrote:
absolutely right! key adjacency.
Normally I wouldn't bother ('People who live in glass houses...' and all
that) but in this case the 'adjacent key' does make a differnce. Had you
said 'Mosel 3' I would not have bothered.
Anyway, from what I rememebr (and it's several years sicne I fired up the
Model 1), the LDOS disk format is pretty compatible between the M1 and
M3. An M3 vcan write an LDOS disk that will be correctly read on the M1.
-tony
directory
sectors than for "normal" sectors! In fact, the 179x
controller, as used in model 2 and "doubler"s was incapable of writing
^^^^^
I suspect you mean 'model 3' here. The 179x was used in the model 2, but
1:45 p.m.
On Fri, 27 Dec 2013, Tony Duell wrote:
Anyway, from what I rememebr (and it's several
years sicne I fired up the
Model 1), the LDOS disk format is pretty compatible between the M1 and
M3. An M3 vcan write an LDOS disk that will be correctly read on the M1.
That can be read by LDOS running on the model 1.
NOT readable by TRS-DOS running on the model 1.
But, then LDOS running on the model 1 could probably read that disk and
create a TRS-DOS compatible disk.
NOTHING running on the model 3 could produce a disk that was readable by
model 1 TRS-DOS running on the model 1.
It would not have taken much to write a trivial program that could run on
model 1, that could read track from the pseudo-model-1 disk, reformat the
track and write it back out.
Running that trivial utility would require running some other OS on the
model 1, OR getting that utility onto a model 1 TRS-DOS diskette (which
would require assembly it on model 1 TRS-DOS, or running some other OS on
the model 1 to get it onto a model-1 TRS-DOS compatible disk)
Remember Boraon Von Munchausen's role in the word "bootstrap"!
Of course, being 3 decades ago, with inadequately refreshed
dynamic wetware, MANY people who had the sense to switch over and run
LDOS/NEWDOS/DOSPLUS, etc. on their model 1s will have faulty memories of
thinking that they were still running model 1 TRS-DOS and "But, I did it
all the time!".
Besides the TRS-DOS derivatives, the model 1 also had MicroDOS (from
Micropolis), and CP/M (FMG relocated, OR Omicron,Parasitic, etc. memory
remapping hardware)
--
Grumpy Ol' Fred cisin at xenosoft.com
http://www.xenosoft.com/FPUIB
28 Dec
28 Dec
11:30 a.m.
On Fri, 27 Dec 2013, Tony Duell wrote:
Sorry, yes, I should have been clearer. A single desnity disk written by
a M3 runnign LDOS will be correctly read by an M1 running LDOS.
Anyway, from what I rememebr (and it's
several years sicne I fired up the
Model 1), the LDOS disk format is pretty compatible between the M1 and
M3. An M3 vcan write an LDOS disk that will be correctly read on the M1.
That can be read by LDOS running on the model 1. NOT readable by TRS-DOS running on the model 1.
Yes.
To clarify (and I know _you_ know this). the 1771 disk controller (as
used i nthe Modle 1) could write 4 differnet DAms. The 'normal' DAM, the
'delected' DAM and 2 specials. Most other disk controllers, includig nthe
179x can only write the 'normal' and 'deleted' DAMs.
One the modle 1, TRS-DOs wrote the directory track with one of the
'special' DAMs. As a reasuly the 179x series of controllers cannot
correctly write such a disk. On the M3, TRS-DOS used the 'deleted' DAM on
the directory track. And IIRC LDOS did that on both the M1 and M3.
But, then LDOS running on the model 1 could probably
read that disk and
create a TRS-DOS compatible disk.
YEs, I think there was a utility to do that.
NOTHING running on the model 3 could produce a disk
that was readable by
model 1 TRS-DOS running on the model 1.
Oh, be careful. Nothign runnign on a model 3 could produce a disk that
was a standard M1 TRS-DOS disk, sure. But I see no reason why there
couldn't be a utility running under M1 TRS-DOS that could read a disk
written on an M3 (porovided it was single-density). But, agreed, by
defualt, M1 TRS-DOS will not read such a disk.
What id TRS-DOS 2.3B on the M1 do? IIRC it had compatibility problems
with all older TRS-DOSes (including 2.3). Did it use the 'deleted' DAM on
the directory track? Something tells me it did.
It would not have taken much to write a trivial program that could run on
model 1, that could read track from the pseudo-model-1 disk, reformat the
track and write it back out.
I am pretty sure several such programs existed.
Running that trivial utility would require running
some other OS on the
model 1, OR getting that utility onto a model 1 TRS-DOS diskette (which
would require assembly it on model 1 TRS-DOS, or running some other OS on
the model 1 to get it onto a model-1 TRS-DOS compatible disk)
IRIC there was no program inlcuded with M1 TRS-DOs to same memory as a
/CMD file. But I guess you could ahve a BASIC progrma that could be typed
i nand which POKEd the program into memory or which created a /CMD file.
That would be _a_ way to bootstrap it.
Remember Boraon Von Munchausen's role in the word
"bootstrap"!
????
Besides the TRS-DOS derivatives, the model 1 also had MicroDOS (from
Micropolis), and CP/M (FMG relocated, OR Omicron,Parasitic, etc. memory
remapping hardware)
There was also at least one version of FORTH which was a self-booting
disk and which simply used the rest of the disk as storage for the FORTH
scrteens (4 off 256 byte sectors for each screen).
-tony
1:44 p.m.
On Sat, 28 Dec 2013, Tony Duell wrote:
The good Baron was travelling through a swamp when he began to sink
in. There was nothing overhead nor to the sides to grab. So, he
reached down and grabbed the straps of his boots, and pulling,
lifted himself out of the swamp. Hence the verb "to bootstrap"
to refer to the improbably seeming task of an OS loading itself in.
All handled by ROM code to load one sector and do a jump.
Holub once asked my WHY did MS-DOS/PC-DOS need to have
IO.SYS,MSDOS.SYS/IBMBIO.COM,IBMDOS.COM as the first two files on the disk.
It's because DOS can not FIND them otherwise until after those two files
are loaded.
--
Grumpy Ol' Fred cisin at xenosoft.com
On the modle 1, TRS-DOs wrote the directory track with
one of the
'special' DAMs. As a reasulT the 179x series of controllers cannot
correctly write such a disk. On the M3, TRS-DOS used the 'deleted'
DAM on the directory track. And IIRC LDOS did that on both the M1 and M3.
There used to be a rumor that the specific choices of which DAMs
Randy Cook used for TRS-DOS was directly due to a typo/misprint
of the DAM chart in the 1771 docs.
What id TRS-DOS 2.3B on the M1 do? IIRC it had
compatibility problems
with all older TRS-DOSes (including 2.3). Did it use the 'deleted' DAM
on the directory track? Something tells me it did.
Not familiar with that one. Possibly one that came AFTER the
introduction of the Model 3, specifically intending to provide
a model 1 OS set up for model 3 compatability.
Remember Baron
Von Munchausen's role in the word "bootstrap"!
????
29 Dec
29 Dec
11:22 a.m.
What did TRS-DOS 2.3B on the M1 do? IIRC it had
compatibility problems
with all older TRS-DOSes (including 2.3). Did it use the 'deleted' DAM
on the directory track? Something tells me it did.
Not familiar with that one. Possibly one that came AFTER the
introduction of the Model 3, specifically intending to provide
a model 1 OS set up for model 3 compatability.
27 Dec
27 Dec
5:55 a.m.
On Wed, 25 Dec 2013, Steven Hirsch wrote:
Turns out the image is indeed 80-cylinder DS. I was
able to write a working
diskette on a 1.2M HD drive from within the xtrs emulator (you can assign
physical drives to the emulated machine - nice feature). Still to be
determined is why the ImageDisk conversion fails.
When I read the working disk with IMD, it complains about "deleted data
marker" on track 39 but continues to read all 80 cylinders. That is probably
what's throwing the DMK2IMD tool for a loop. It has a couple of switches
that seem pertinent and I'll give that a try tomorrow. Would be nice to
understand in case this comes up again.
I updated to the latest ImageDisk (v1.18) and tried the DMK2IMD conversion
again with both variations of the data address mark translation switch.
Still no go.
Since I'm able to read the diskette back in IMD, I've accomplished my goal
of capturing it in IMD format (writing the image back does yield a working
disk!) But, there does appear to be some issues with the DMK2IMD
translation.
Steve
--
3793
days inactive
3798
days old
15 comments
4 participants
participants (4)
-
aek＠bitsavers.org -
ard＠p850ug1.demon.co.uk -
cisin＠xenosoft.com -
snhirsch＠gmail.com