• Please review our updated Terms and Rules here

Reading 2040 disks on a Catweasel

Right, but wouldn't 8050 disks have some really obvious other differences, even on the tracks you could read, like being higher density (more sectors per track or higher clock than 14mhz) and so on? And 8250s would be double sided. Or did the 8050 run on 14mhz clock and somehow get so many sectors on a track? I'll keep banging on it. I know my memory about some of it is faulty because I found a disk (damaged) with source to an assembler version of my Basic game "Time Trek" and I had completely forgotten I had tried to write that. (I don't think I ever finished it, nor is it that important to recover as who wants an assembler PET startrek at this point?) I mainly want to recover source for all the different versions of PAL , POWER, (Pet1/2/4 and C64) Checker King (Pet/Atari/Apple) and Atari Microchess. I have many of these now (have not found the Atari disks yet) as well as the cross assembler I wrote and some game source I did on Unix. But who knows what else is in these disks! I also have an Atari ST hard drive with some source code I would really like to recover but I fear turning it on after 25 years.
 
Out of curiosity, would it matter if one takes a 5.25" floppy disk that is certified for 100 tpi and use it with a 48 tpi drive? I can't imagine it would be an issue, as I still understand the tpi rating as a figure of maximum density the disk can hold, not that those are pregenerated grooves into the disk. I kind of understand why a 8050 which formats 77 tracks on a 100 tpi drive can't be said to be totally reliable formatting 77 tracks on a 96 tpi disk, but going in the other direction probably never should be a source of confusion.

I can't bother to look up the number of sectors per track on a 8050 drive, but the numbers posted in the log while reading this floppy disk as a 35 track are consistant with what you would expect to find on a 2040/1541 type disk. I agree that if the disk was of a different format, sync marks etc probably would be at different locataions and the software would bail out with more errors than it now does.
 
I don't think diskette "certification" is much of an issue any more; in the early days of diskette manufacturing and QC diskettes were certified for 96 TPI or double-sided use, but IMO any good quality double-density/double-sided diskette will work equally well in all Commodore/Apple/Atari diskette drives. Since many/most of these drives didn't have an index sensor even hard-sectored diskettes can often be used. Of course, like the DD/HD isssue with PCs it's not a good idea to mix different formats on the same diskette without bulk-erasing first.

Although I still think a Catweasel might be able to read some 96TPI tracks on a 48TPI drive, as Anders points out those log entries do indeed look like a 1541 type 17-21 SPT disk.

Any chance this is just a bad disk drive?

And Brad: where are you these days? Any chance someone local to you could look at and maybe archive these disks on the type of drive/system they were written on?
 
I am in the Bay Area. And I have the 2040 drive (presuming it still powers on) and the PET buried in storage. I may even have a 1541 somewhere. Main reason I came here is the Windows official driver could not decode these disks at all, and the linux one got a few of them but the rest still run into some problems.

I am curious as to how the Catweasel works as far as the number of sectors on a track. Indeed, I am curious as to how CBM puts more sectors on the outer tracks than on the inner ones, and how that is encoded? I mean yes, there is more physical length to the outer tracks so it makes sense you can put more sectors on them. But one revolution takes just as long on the inner and outer tracks, and if you are writing with a 14mhz clock you get the same number of clocks per revolution (2.3 million) on the inner and outer tracks. Long ago I had presumed it wrote faster there. Likewise with the 8 and 9 sector tracks of MSDOS disks, I had always assumed with fewer bytes per track you wrote them more slowly. A lot of this is a blur now. I know that some systems used the index mark, others had a soft index mark (and long ago there were even systems with hard index marks, one per sector.) So I am curious what is going on with this decoding.
 
Back
Top