Re: Transfer floppy files to CDROM?

Dave Dunfield wrote:
The 1772 also had read track and write track commands. As the name implies, these commands let you read or write the entire track in a single rotation of the disk. The write command writes the entire track, including all the inter-sector "gap" bytes. Similarly for the read track.
Which doesn't have the ability to read a raw track (the 765).

Not sure what you just said. Did you say that the 765 does NOT have that function?

Yes, thats what I mean - the 765 has a "read track" function, however it's
not a "read raw track data" function - it just reads all the sectors on the
track (data fields only - similar to just doing repeated read sector
commands). There is no "write track" function on the 765, raw or
otherwise. There is a "format" function for formatting a track, but
all you provide are the c/h/s values for each sector and gap lengths.
It's nothing like preparing a raw track image and writing it like you would
do with the 179x series devices.

Hmm. The scary part is, I _KNEW_ all of this at one time. I disassembled the BIOS's for both the Kaypro (1793) and Teletek (765), so was pretty intimate with the commands. Was a long time ago.

I *really* wish the PC has chosen the 179x series for the FDC - it would
have made the job if imaging foriegn diskette formats on the PC so
much easier!

Indeed!



The computers of the day used an interleave factor, skipping one or more sectors in a given operation, to give the computer time to process the selection of the next sector (including, of course, deciding when to stop).
This is complicated in the case of CP/M which was designed in the era
of hard-sectored disks, so it uses an internal "skew" table which translates
logical sectors to physical sectors (unlike most later soft-sector systems
which simply format the disk with the physical sectors interleaved, and use
a 1:1 logical to physical).

Not all. IIRC, the Kaypro skipped every other sector. Write all evens, then all odds. Etc.

Yes, and people did even weirder things than that - which emphasizes my
point that under CP/M, physical sector numbers are basically meaningless
(or can be with certain systems). Later systems, designed for soft-sector
disks from the get-go usually have more straightforward sector numbering
(but not always!)


The complication is that the skew table is built into BIOS, and NOT stored
at any specific location on the disk ... the original CP/M system just "knows"
the logical to physical mapping - you need to know the skew in order to
make sense of the sector numbering.

Yeah, but that's the point of my friend's hack. He could read the disk without knowing the disk format it was written in, and he could decipher all the info -- even sector size -- from the data on the disk.

And my point is that unless he knows the "skew table", he doesn't know
what logical order those sectors are represented. That information is
simply not available on a CP/M disk (unless it's a bootable disk and
you take apart the BIOS - not something that lends itself to automatic
detection).

Yes, he _DOES_ know that. Not from any format data stored on the disk, but from the data file itself. Again, that's why he required a large text file to be written to a clean floppy. If you find "War and Peace," say, with data scrambled into 512-byte chunks, it doesn't take a rocket scientist to suspect that the file has 512-byte sectors with some kind of skew table. By rearranging the sectors until they seemed to be in contiguous order, he could figure out the skew table.




Ok. Thanks for clearing that up. I guess what my format program did was to leave the track image in memory, and change only the track number bytes. Apparently, the Kaypro version must have rebuilt the data. Not sure just why, but I suspect it was legacy from the "standard" BIOS functions supplied by DR.

Probably just to make the code a bit easier - since you need to re-generate
the CRC's you could: A) Create the headers once in memory then patch and
re-read them to generate the CRC's, or B) just create new headers and CRC's
as you go. I don't see a huge speed advangate to A, while B might be a
bit simpler (only one operation).

Um ... the CRC's are generated in the FDC chip, right"


You could avoid re-generating the data blocks and CRC's - since these
should all be "blank formatted" - that might be where you saved some
time. In "getting it out the door", Kaypro may have just simply generated
the entire track.


Dave

--
dave06a@ Low-cost firmware development tools: www.dunfield.com
dunfield. Classic computer collection: www.classiccmp.org/dunfield
com

.

Relevant Pages

  • Re: Help with cdrecord
    ... Andrew Robinson wrote: ... There are a total of 358366 sectors of 2Kb each. ... This is the total available disk data size. ... audio format, ...
    (Fedora)
  • Help on disk format when upgrade dosFS patch.
    ... format the SCSI disk, I found the disk format is a little bit different ... total number of sectors: 4,233,600 ... first cluster is in sector # 525 ...
    (comp.os.vxworks)
  • Re: Transfer floppy files to CDROM?
    ... single rotation of the disk. ... not a "read raw track data" function - it just reads all the sectors on the ... which simply format the disk with the physical sectors interleaved, ...
    (comp.os.cpm)
  • Re: Recovery of Disks project (CBM disk formatting mysteries...)
    ... On top of the empty sectors being written, I would note that the ROM disassembly shows the following other things happen to the tracks during the CBM format. ... It then measures the difference between the amount of each disk pattern, and does the whole thing over and over again until it "figures ...
    (comp.sys.cbm)
  • Re: sbp2port.sys, IEEE 1394 port driver
    ... The commands are vendor commands and should be allowed to be ... and that PIO data transfers are in integer numbers of sectors. ... > finished that can format SmartMedia correctly as the SSFDC requires. ... > manufacturer's name and model number of some hard drives in a USB 2.0 ...
    (microsoft.public.development.device.drivers)