Format for TRS-80 35 Track SS/SD 5.25 floppies

[DrRGee]

I am struggling trying to read old TRS-80 floppies on a Shugart SA400.. Using ibm.fm all appears to work fine works fine EXCEPT for T17, which is the directory. I believe that the sector DAM=0xFB everywhere else, but for the directory track it is 0xFA. Looking at ibm.py L126, it looks like DAM is set as 0xFB - is there any hope to be able to specify the DAM or can you suggest another possible solution?

[keirf]

I think any directory sector anywhere on disk is DAM FA? What format are you converting to? Eg DAM byte info would be lost when converting to IMG. Otherwise simplest thing to do is accept FA as a DAM value in ibm.py.

[keirf]

I wonder how important the FA mark is to preserve? FlashFloppy supports TRS-80 by all accounts, but certainly never emits an FA mark when used with IMG files.

Anyway yes I'm basically proposing that fm_decode_raw becomes a bit more permissive. Let me make a quick change.

[keirf]

Any idea if that mark is ever used in MFM tracks?

[keirf]

Take a look at and try out branch trs. You can also see a Windows prebuilt here: https://github.com/keirf/greaseweazle/actions/runs/4844962541

(Look at bottom under artifacts. You need to be logged into GitHub to see the link.)

[jdmba]

@keirf - DAM's are just the tip of the iceberg. The TRS-80 has many copy types of copy protection which was used over the years. I don't think the TRS-80 can be specifically written for; but rather needs a lot of flexibility. Even without copy protection, mixed FM and MFM is a common format. I can certainly provide DMK images of the wide variety of TRS-80 formats out there, but am not experienced enough to answer technical questions.

[jdmba]

@keirf - There is an excellent write up of the disk formats for the STANDARD TRS-80 disks, including the DAM's, here https://www.tim-mann.org/trs80/dskspec.html

[DrRGee]

Will Do!

…

________________________________ From: Keir Fraser ***@***.***> Sent: Sunday, April 30, 2023 3:01 PM To: keirf/greaseweazle ***@***.***> Cc: DrRGee ***@***.***>; Author ***@***.***> Subject: Re: [keirf/greaseweazle] Format for TRS-80 35 Track SS/SD 5.25 floppies (Discussion #306) Take a look at and try out branch trs. You can also see a Windows prebuilt here: https://github.com/keirf/greaseweazle/actions/runs/4844962541 (Look at bottom under artifacts. You need to be logged into GitHub to see the link.) — Reply to this email directly, view it on GitHub<#306 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AG2N4LV45Z5TSQRJJUFKXODXDZ5D7ANCNFSM6AAAAAAXQUFLTY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[DrRGee]

OK, here is what I did last night using 1.10 gw.exe read --diskdefs "C:\TRS80\greaseweazle-1.10\diskdefs.cfg" --format=TRSSSD.80 --retries=5 --revs=5 --drive=1 --tracks=c=0-34 "C:\TRS80\greaseweazle-1.10\mydisk5ti9.img" and that yielded [cid:0865786d-506a-45f9-ad18-ba2205a05752] With all of the sectors on T17 missing. Then, I installed the zip. Moved the guitools into that directory and used: gw.exe read --diskdefs "C:\TRS80\greaseweazle-1.10\diskdefs.cfg" --format=TRSSSD.80 --retries=5 --revs=5 --drive=1 --tracks=c=0-34 "C:\TRS80\greaseweazle-1.10\mydisk5ti9.img" and that yielded this! [cid:acd0ee95-be3c-40dd-9e57-5d913893237e] TRSSSD.80 is an entry for the cfg I was working on: and contains: disk TRSSSD.80 cyls = 35 heads = 1 tracks * ibm.fm secs = 10       id=0 bps = 256 gap1=20       gap2=20       #gap3 = 84       gap3=30 rate = 125 end end The gaps are not right. I was using https://archive.org/details/insup/page/n11/mode/2up SuperUtility Plus documentation, see page 8- but it got late. I want to look at the .img and then your code but this is VERY encouraging! Thank you. [https://archive.org/services/img/insup]<https://archive.org/details/insup/page/n11/mode/2up> Inside Super Utility Plus : PowerSoft : Free Download, Borrow, and Streaming : Internet Archive<https://archive.org/details/insup/page/n11/mode/2up> Inside Super Utility Plus archive.org

…

________________________________ From: Keir Fraser ***@***.***> Sent: Sunday, April 30, 2023 3:01 PM To: keirf/greaseweazle ***@***.***> Cc: DrRGee ***@***.***>; Author ***@***.***> Subject: Re: [keirf/greaseweazle] Format for TRS-80 35 Track SS/SD 5.25 floppies (Discussion #306) Take a look at and try out branch trs. You can also see a Windows prebuilt here: https://github.com/keirf/greaseweazle/actions/runs/4844962541 (Look at bottom under artifacts. You need to be logged into GitHub to see the link.) — Reply to this email directly, view it on GitHub<#306 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AG2N4LV45Z5TSQRJJUFKXODXDZ5D7ANCNFSM6AAAAAAXQUFLTY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[keirf]

GitHub strips attachments from emails so disk images are missing. I wouldn't trust documentation for the gaps values. Especially gap3. Other gaps are more standardised. You will need to work out gap3 by trial and error right now, or send me a flux dump and I can work it out.

[DrRGee]

Yep, I have some work to do, but it is good work...quite a giggle seeing a Z-80 program that I wrote some 40 years ago 🙂 I have a 40T drive and I should be able to look at some newdos and MIII disks. very​ cool! Thanks so much.

…

________________________________ From: Keir Fraser ***@***.***> Sent: Sunday, April 30, 2023 4:38 PM To: keirf/greaseweazle ***@***.***> Cc: DrRGee ***@***.***>; Author ***@***.***> Subject: Re: [keirf/greaseweazle] Format for TRS-80 35 Track SS/SD 5.25 floppies (Discussion #306) GitHub strips attachments from emails so disk images are missing. I wouldn't trust documentation for the gaps values. Especially gap3. Other gaps are more standardised. You will need to work out gap3 by trial and error right now, or send me a flux dump and I can work it out. — Reply to this email directly, view it on GitHub<#306 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AG2N4LQQEXKG75OZXMD56ALXD2IRDANCNFSM6AAAAAAXQUFLTY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[TimothyPMann]

Model I single density (not double) wants an FA DAM on the directory track, which is normally 17 but can be another track. TRSDOS won't be able to find the directory if it's written with another DAM. So if you're creating Model I TRSDOS disks you'll need to be able to write it.

Model 3/4/4P can't write that DAM or distinguish it on read from FB. They generally use F8 on the directory track. Double density disks written on Model I with a double density adapter also use F8. Model I LDOS will tolerate F8 DAM in single density, but TRSDOS won't unless patched

[Verault]

@DrRGee Just curious how this panned out for you. The TRSSSD.80 config file you created seems like a good idea and I was wondering if you figured out the missing variables (gaps) and have a working config as of now. I have bought a kryoflux 10 years ago but a fellow enthusiast asked me to build a Greaseweazle too (as he has one) so I can help him out with Disk creation on the GW. Its built and time to start testing so I was wondering what you found out.

[DrRGee]

It has worked out rather well for me but I had some specific things in mind; verify that my 40+ year old drives work (and clean and adjust timing). See if I could read any of the original diskettes that I have. The answer is yes on both counts.

The newest version that incorporated the sector mark for the original TRSDOS format is a big plus (v1.11). I can read almost all of my old M1 TRSDOS disks that I have tried (maybe 25-30) and many that I have tried are error free AFTER I clean them and the drive head. (read to img and dsk formats). Of, course, what I would really like is to be able to specify the sector id in the config file.

I can not read any of my NEWDOS diskettes at all - I don't know how I formatted them and they probably have unsupported sector marks.

I wish the software was written in C/C++, but it is, IMO, a good product and am happy with the purchase.

Of course, I am putting off resurrecting the actual machine and when I do, I should be able to read everything as was initially intended :)

As for the gaps; I messed around with them, but I never systematically evaluated how to optimize them - mainly because I don't know how (although I thought those disk maps were pretty cool). Again, it would seem like I could easily get the actual data once I have the machine working.