Open gilliands opened 1 month ago
keirf
commented
2 weeks ago Can you share a raw dump of a Greaseweazle-written disk? Then we can see exactly the distribution of how the data lines up to sector marks.
Making writes take proper account of sector marks for each sector is not a simple piece of work, and best avoided if it's not really necessary.
gilliands
commented
2 weeks ago I will grab a blanked disk, initialize it (format) on the machine and post a raw read of the disk.
Gillian
On Tue, 12 Nov 2024, 08:09 Keir Fraser, @.***> wrote:
Can you share a raw dump of a Greaseweazle-written disk? Then we can see exactly the distribution of how the data lines up to sector marks.
Making writes take proper account of sector marks for each sector is not a simple piece of work, and best avoided if it's not really necessary.
— Reply to this email directly, view it on GitHub https://github.com/keirf/greaseweazle/issues/500#issuecomment-2469849773, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALP6DEBXURF65PN3G4YFT3D2AGZTLAVCNFSM6AAAAABQHYKVTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRZHA2DSNZXGM . You are receiving this because you authored the thread.Message ID: @.***>
Issues are missing sector sync bytes or CRC errors when reading sectors across the disk when written using v1.20 from both locally archived as well as other .nsi images.
I think the issue is the hardware is expecting fairly tight timings relative to the sector holes and if there is any garbage or timing misalignment, the controller is seeing spurious sync marks in the garbage or missing the real ones and picking one up from within the data. As I understand it, GW is writing whole tracks relative to the initial index mark and not relative to each sector pulse start. As it is, if the sync data byte isn't found within x8C byte times from the sector pulse, it gives up.
I think we need to find a better way to write each track and either improve the accuracy of the inter sector gaps or write the data timed to the sector holes.
Potential ideas: a) Write each track as 10 sector come mini-tracks starting from the detecting sector zero and use each sector hole as an index to write the next sector come mini-track. The writes will then naturally align with each sector hole. b) Modify the sector writing code to wait for a sync pulse to trigger the 96us window delay and then write the preamble,, sync, data and check bytes. No data needs to be written at the end of the sector but it's a good idea to erase the track between Sector pulse and preamble. c) If we can't sync writes to the actual sector holes we could calibrate the rotation time by monitoring an initial couple of revolutions of the disk and keep a running average thereafter. We then use the actual rotation time to accurately calculate the inter-sector gaps and place each "soft" sector so that they will more accurately sit relative to each physical sector's index hole.
In any case, it would be a good idea to enable the erase head to sweep the disk of any previous data that could be interpreted as a sync byte before we write the preamble.
Simulating hard sector disks using a soft sector floppy - besides punching additional holes in a standard soft sector floppy, There is a virtual sector generator that synthesizes hard sector pulses on a soft sector floppy and it does the calibration trick and generates the pseudo sector pulses at the appropriate time. https://deramp.com/vsg.html If only kicks in if it sees index pulses every 200ms or so otherwise it passes through the hard sector pulses which arrive every 20ms or so.
*N Format parameters:**
Disk contains 10 hard sectors - an index hole + 10 other holes. Hardware detects sector zero by finding an extra "early" index pulse generated by the 11th hole sitting in between two sector holes. Other pulses are detected and an internal window generator is triggered from the falling edge of the index pulse (the leading edge)
Single density: falling edge of index L : 96us delay : 16 bytes x00 : Sync byte xFB : 256 bytes data : check byte
Check byte is a running XOR of every data byte initially seeded with zero. I don't know if the erase head is turned on early at the start of the sector pule to clean up any old preamble/sync pulses.
Double Density:
falling edge of index L : 96us delay : 32 bytes x00 : Sync byte xFB : 512 bytes data : check byte.
Disks are single sided but double density controllers can support double sided drives and tracks number side 1 0:34 (outside to inside) and side 2 35:69 (inside to out) so track 0 and 69 are on the outer edge of the floppy.
With real hardware, initiating a write cycle writes a zero to the disk when the window timer expires which is why the NDOS code only writes 15 (31) zero bytes to to the disk.
To complicate matters, single density disk formatted on a double density controller may contain a special double length 512 byte sector at T1:S8.
More information can be found here: https://retrocmp.de/northstar-hrz/ns-hrz_p02_hs.htm Initial boot code for single and double density controllers as well as NSDOS can be found here: https://deramp.com/downloads/north_star/hardware/Single%20Density%20Controller/PROMs/NSBOOTV2.ASM https://deramp.com/downloads/north_star/hardware/Double%20Density%20Controller/PROMs/NSBOOT.ASM http://www.hartetechnologies.com/manuals/Northstar/NSDOS.ASM