Btw this is maybe why Oricutron and OricExplorer use hardcoded values...
I think that the Oric community should choose another disk image format and "redump/regenerate" the collection.
Btw this is maybe why Oricutron and OricExplorer use hardcoded values...
Between 100 and 200 "end users" per month flash the HxC firmware to Gotek. There is nothing difficult and this can be done with a simple usb cable.... Or like you do today, with an usb stick
Ok. Did not know that (just a user, never dived into the technical formats).Jeff wrote: ↑Sat May 15, 2021 4:37 pm
Once all the "hidden" dsk format constraints/specifications are cleared, i will be able to evaluate this possibility.
Please note that many (most?) Oric dsk images are corrupted/malformed : Bad header, bad sync word, bad crc... The hardware will reject most of them.
The emulator will have to fix them at the load.
Not my text just a copy paste. Will add quote tag to make that clear.
Sorry, I'm not blaming you, just trying to understand what is going on. The latest issue seems to be with your software, so I thought you be interested and maybe would like to know if there was an issue.
Code: Select all
0001fdb0 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |<GAP4> (previous sector)
0001fdc0 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e
0001fdd0 4e 4e
00 00 00 00 00 00 00 00 00 00 00 00 a1 a1 | <GAP2>
0001fde0 a1
fe 14 00 06 01 b2 cd | <index field> (Track:$14, Side:0, Sector:$06; Size:$1 (256 bytes), CRC: $b2cd)
4e 4e 4e 4e 4e 4e 4e 4e | <GAP3>
0001fdf0 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00
0001fe00 00 00 00 00 00 00 00 00 00 00 a1 a1 a1
fb 00 00 | >Data Field>
0001fe10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fe90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fea0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001feb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fec0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fed0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fee0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fef0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001ff00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e1 22 | <CRC>
0001ff10 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e | <GAP4>
0001ff20 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e |NNNNNNNNNNNNNNNN|
0001ff30 4e 4e
00 00 00 00 00 00 00 00 00 00 00 00 a1 a1 | <GAP2> (next sector)
Code: Select all
0001faf0 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e | <GAP4>
0001fb00 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e
0001fb10 4e 4e
00 00 00 00 00 00 00 00 00 00 00 00 a1 a1 | <GAP2>
0001fb20 a1
fe 14 00 04 01 d4 af | <index field> (Track:$14, Side:0, Sector:$04; Size:$1 (256 bytes), CRC: $d4af)
4e 4e 4e 4e 4e 4e 4e 4e | <GAP3>
0001fb30 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00
0001fb40 00 00 00 00 00 00 00 00 00 00 a1 a1 a1
fb 00 00 |<Data Field>
0001fb50 20 00 00 00 00 00 00 00 00 00 00 00 00 00 54 45 | .............TE|
0001fb60 53 54 20 20 20 20 20 43 4f 4d 07 06 02 40 00 00 |ST COM...@..|
0001fb70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fb80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fb90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fba0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fbb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fbc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fbd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fbe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fbf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fc00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fc10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fc20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fc30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001fc40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a5 5f | <CRC>
0001fc50 fe 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e | ?? <GAP4>
0001fc60 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e
0001fc70 4e 4e
This is just how the FDC is stopping the sector write. An extra byte is sent to avoid to have the write splice too close to the CRC field. Nothing is "faulty" here. (Please note that the there is no missing clock on this byte -> This is not a sync word...)christian wrote: ↑Sun May 16, 2021 1:14 pm I don't know why there is a $FE after the CRC of all the modified sectors but it shouldn't be there.
Oricutron may be modified to have a better dsk scanning routine but i think hxctest_hfe.dsk is faulty.
If somebody can check the gap at the end of the sector 4 track $14 in hxctest.hfe and see if the $fe byte is here or not.
If it's present then i think the firmware is responsible, if not then it's the conversion from hfe to dsk.
This depend on the FDC model : this might by only some bits with some FDC. And don't forget the write splice. The extras bit(s) + the write splice mixed with the previous data may result to any possible value.christian wrote: ↑Sun May 16, 2021 3:44 pm You're right about Oricutron.
What you are saying is that the FDC automatically adds this extra byte after the CRC, so if we format a floppy disk there will also be this extra byte at the end of the index field?
I don't remember reading this in the FDC specs but maybe I missed it.
The others GAP changes are due to the DSK->HFE conversion. Since many DSK files are malformed (bad sector header, gap length, bad crc...), i had to extract the sectors from the image, and regenerate all the tracks "from scratch"...
Not only Oricutron, at least also OricExplorer..... not sure, but maybe also TAP2DSK from OSDK?
Works! Many thanks!
Great! Can I download an updated binary build somewhere? (could not find it on the Github unless I overlooked something....)