Barbitoric has incorrect CRCs?

Anything related to the tools Tap2Wav, Tap2CD, Tap2Dsk, Sedoric Disc Manager, Tape Header Creator, WriteDsk, and generaly speaking tools related to the management of Oric data files and devices.
ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Barbitoric has incorrect CRCs?

Post by ThomH » Mon Jan 02, 2017 5:00 am

I think this is relevant here rather than in the demos section as it pertains to the version contained in a disk image and possibly to the tools related to it. But primarily it's a sanity check.

The Barbitoric disk image, as downloaded from the authoritative source contains the following sequence for describing the data of sector 2 on track 0:

Code: Select all

A1A1A1FB0000FF00D09FD09F02B90100FF0000B9E4B90000E6120078A9608500200000BACA18BD000
169228500BD010169008501A000B10099D0A7C8CCA500D0F54CD0A7A064A9A88CFEFF8DFFFFA97F8D0D0
3A9058D12038D72A8A9078D73A8203CA878A9818D14034C00E0A200EC1103F0108E1303AD180330FBA91
F8D10032057A8AD72A88D1203A9858D1403A9808D1003A01EEAEA88D0FBA000AD180330FBAD13039900E
0C8D0F2AD1003291C60A0048D74A820F8A7F005CE74A8D0F6EE72A8EE32A8CE73A8D0EB60A00488D0FDA
D10034AB0FA0A60686868A9818D1403AD1003297C6000000020444546454E43452D464F52434520202020
200D0A0000000000000
... followed by the CRC $E9A4.

Per my code, and per this example of somebody else's code — copy and paste the quoted text into the box, removing the line breaks, select 'hex', click 'calculate CRC', look at the "CRC-CCITT (0xFFFF)" value — the correct CRC is $332B.

The FDC1973 data sheet is explicit, under 'Read Sector': "If there is a CRC error at the end of the data field, the CRC error status bit is set, and the command is terminated (even if it is a multiple record command)". So the WD is supposed to verify that CRC.

Am I therefore on solid ground to argue that the disk image is encoded correctly?

(if I implement my emulated WD to check the CRC then Sedoric rejects the disk as faulty and hence Barbitoric fails to load. With a quick peek I can find no evidence that either Euphoric or Oricutron actually checks this CRC, but I'm no expert on those. It strikes me as possible that various output tools might have the same deficiency as floppy controllers will usually generate this value for itself. But surely it's more likely that I'm in the wrong?)

jede
Pilot Officer
Posts: 122
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Re: Barbitoric has incorrect CRCs?

Post by jede » Mon Jan 02, 2017 11:15 am

Hello,

Demos (barbitoric, vip3, vip4) had been built with the first version of floppy builder.

It was a simple tool : it takes the binary, split into 256 bytes (size of a sector) and write it in a dsk in the sector offset. It means that others infos are not changed. CRC are data of another dsk.

To correct this, you could extract data from sectors, and rebuild the dsk with others tools (I don't know if new floppy builder manage CRC etc).

Sedoric can't read the disk : There is no sedoric on the disk, and it does not use sedoric format.

Oric boots on boot sector, load a "loader" which reads positions of each parts. For example, a picture is written on a single track, sector by sector. Next part follow the same steps.

User avatar
Chema
Game master
Posts: 1971
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Barbitoric has incorrect CRCs?

Post by Chema » Mon Jan 02, 2017 3:42 pm

Mmmmm and if the drive logic checked the CRC and issued an error, the loading code ignored it, if I remember correctly. That was one of my own modifications in the new code.

Which, incidentally, remembers me that in my changes, I am doing a few retries before giving up. I have to check the code, but I am not sure what would happen if there is an error. Maybe these retries are performed, then give up, but the game does nothing and, as the data itself is ok, game runs normally.

However, each sector read is being done several times, with a strong impact on performance, which is something we do have. Oh, if only Oricutron had an option to output disk commands or errors to a log file or something...

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric has incorrect CRCs?

Post by ThomH » Mon Jan 02, 2017 4:18 pm

jede wrote:Sedoric can't read the disk : There is no sedoric on the disk, and it does not use sedoric format.
The very first sector of the disk contains the text:
SEDORIC SEDORIC V3.006 01/01/96
Upgraded by Ray McLaughlin
and Andr{ Ch{ramy

See SEDORIC3.FIX file for information
(with my hex editor presumably preferring { to é for predictable reasons)
Chema wrote:Mmmmm and if the drive logic checked the CRC and issued an error, the loading code ignored it, if I remember correctly. That was one of my own modifications in the new code.
If loading with CRC checks enabled, the Oric runs from 'insert operating system disk' to 'no operating system on disk'. It reads the first sector successfully, twice, then the third sector successfully, twice, then attempts to read the second and fails. Without CRC checks, the demo loads successfully. The only difference being whether the CRC error bit is set when ending the command.
jede wrote:To correct this, you could extract data from sectors, and rebuild the dsk with others tools (I don't know if new floppy builder manage CRC etc).
I'll write a quick tool to do it. Fingers crossed the latest floppy builder is outputting valid .DSKs.

jede
Pilot Officer
Posts: 122
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Re: Barbitoric has incorrect CRCs?

Post by jede » Mon Jan 02, 2017 6:16 pm

The very first sector of the disk contains the text:

SEDORIC SEDORIC V3.006 01/01/96
Upgraded by Ray McLaughlin
and Andr{ Ch{ramy

See SEDORIC3.FIX file for information


(with my hex editor presumably preferring { to é for predictable reasons)
Yes because the disk used was a sedoric disk, but everything is deleted except this :)

VIP3, asm2k2, VIP4 etc have this method. A tool could correct these disks. If someone wants to do it :)

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric has incorrect CRCs?

Post by ThomH » Mon Jan 02, 2017 6:25 pm

I wrote 90% of a tool this morning but it's probably still imperfect, and right now I'm elsewhere. Work so far is here but I'll shout out when it's actually done. At the minute failings are: one disk image at a time; when testing a "fixed" Barbitoric, somehow it had dropped an expected sector.

(which could mean it's putting modified tracks back into the wrong place, somehow corrupting IDs, etc; I didn't really get much investigation time)

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric has incorrect CRCs?

Post by ThomH » Mon Jan 02, 2017 6:44 pm

All fixed, the tool fully works. It's vanilla C99 so should work anywhere.

A corrected Barbitoric is attached. Any hope of having this replace the current download? Otherwise, having broken DSK images circulate makes supporting accurate emulation really difficult.
Attachments
barbitoric2.dsk
(525.25 KiB) Downloaded 26 times

User avatar
Dbug
Site Admin
Posts: 2321
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Barbitoric has incorrect CRCs?

Post by Dbug » Mon Jan 02, 2017 7:27 pm

Could somebody try to use writedsk on this version of the DSK and check that it still loads correctly on an Atmos with Microdisc or a Telestrat?

I know for sure that the original version worked just fine on real machine, that probably means that WriteDsk was doing some magic when writing the floppy, probably also mean that doing a ReadDsk from the WriteDsk would give a different result with the original version and the same result with the new version?

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric has incorrect CRCs?

Post by ThomH » Mon Jan 02, 2017 10:45 pm

I definitely think that would be an appropriate test.

In the meantime, I'll just confirm the testing I've done. You'll see that it prints a little status report on how many CRCs it felt the need to fix after being run. That being the case:

Code: Select all

1337.dsk: Completed; 32 tracks found, 1088 CRCs checked, 0 fixed
ANIM.DSK: Completed; 160 tracks found, 5440 CRCs checked, 0 fixed
ANIM2.DSK: Completed; 160 tracks found, 5440 CRCs checked, 0 fixed
FONTEDIT.DSK: Completed; 40 tracks found, 1280 CRCs checked, 0 fixed
HYPCATFR.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
HYPERCAT.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
IMAGES1.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
IMAGES2.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
IMAGES3.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
IMAGES4.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
IMAGES5.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
IMAGES6.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
MINISED2.DSK: Completed; 44 tracks found, 1496 CRCs checked, 0 fixed
MODEM.DSK: Completed; 42 tracks found, 1428 CRCs checked, 0 fixed
ORICDOS.DSK: Completed; 160 tracks found, 5120 CRCs checked, 0 fixed
QVC42.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
QVC43.DSK: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
SEDORIC3.DSK 2: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
SLIME.DSK: Completed; 40 tracks found, 1280 CRCs checked, 0 fixed
barbitoric.dsk: Completed; 84 tracks found, 2856 CRCs checked, 1107 fixed
demomagx.dsk: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
f83v24f.dsk: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
f83v31f.dsk: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
f83v31g.dsk: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
forth83.dsk: Completed; 38 tracks found, 1292 CRCs checked, 0 fixed
ftdos.dsk: Completed; 82 tracks found, 2788 CRCs checked, 0 fixed
patricia.dsk: Completed; 160 tracks found, 5440 CRCs checked, 0 fixed
pulsoids.dsk: Completed; 164 tracks found, 5576 CRCs checked, 0 fixed
randos.dsk: Completed; 40 tracks found, 762 CRCs checked, 0 fixed
sedoric2.dsk: Completed; 162 tracks found, 5508 CRCs checked, 0 fixed
sedoric3.dsk: Completed; 84 tracks found, 2856 CRCs checked, 0 fixed
space1999-en.dsk: Completed; 30 tracks found, 1020 CRCs checked, 0 fixed
stratsed.dsk: Completed; 164 tracks found, 5576 CRCs checked, 0 fixed
So of my little local collection, only Barbitoric was found to have any problems. Which is confidence building, albeit not definitive.
Last edited by ThomH on Mon Jan 02, 2017 10:47 pm, edited 1 time in total.

User avatar
iss
Flight Lieutenant
Posts: 470
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Barbitoric has incorrect CRCs?

Post by iss » Mon Jan 02, 2017 10:46 pm

I tested both images with Microdisk controller and HxC drive - both work fine.
I'll try to make real floppy disk with Writedisk soon, but looking at sources of Writedisk and Writedisk2 -
they use BIOS int 13h to write sector-by-sector and this BIOS interrupt requires as input only data buffer
with plain data (i.e. only 256 bytes), so the CRC in the DSK file is simply ignored.

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric has incorrect CRCs?

Post by ThomH » Tue Jan 03, 2017 2:18 am

Further on this, I'm finding that quite a few of the PC-produced pieces of work that are slightly older have incorrect CRCs but none of the things imported from a real Oric or that are more recent (including 1337 and Space: 1999). I've also filed a bug against Oricutron alleging that it doesn't check CRCs so I'm sure a qualified developer will confirm or deny. If we confirm no ill effects from a physical write to floppy — though it sounds like there couldn't possibly be any — I guess a check of everything on Pouet is possibly sensible.

Quick question: can anybody think of a way that an emulator could make a pretty good guess as to whether a DSK was simply miscalculated or whether it intends to have incorrect CRCs e.g. as a software protection mechanism? Did the first version of floppy builder do anything that might tip the hat, like always use the same incorrect CRCs, or always produce them using some particular method that could be reproduced?

User avatar
Dbug
Site Admin
Posts: 2321
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Barbitoric has incorrect CRCs?

Post by Dbug » Tue Jan 03, 2017 8:58 am

Could you check these ones:
- http://www.pouet.net/prod.php?which=64343
- http://www.pouet.net/prod.php?which=65688

they will probably fail to, if they do, then it means I probably forgot to call the compute crc somewhere in the FloppyBuilder :)

User avatar
iss
Flight Lieutenant
Posts: 470
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Barbitoric has incorrect CRCs?

Post by iss » Tue Jan 03, 2017 11:28 am

Yep, the calculated CRC in FloppyBuilder is always 0xE122, which is exactly the correct CRC for A1A1A1FB + 256 x $00.
'compute_crc' should be called not only in 'Floppy::CreateDisk()' but also in 'Floppy::WriteSector()', 'Floppy::WriteFile()' and 'Floppy::ReserveSectors()'.
I made the changes and now everything seams to be ok.

ThomH
Pilot Officer
Posts: 71
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric has incorrect CRCs?

Post by ThomH » Tue Jan 03, 2017 1:25 pm

Dbug wrote:Could you check these ones:
- http://www.pouet.net/prod.php?which=64343
- http://www.pouet.net/prod.php?which=65688

they will probably fail to, if they do, then it means I probably forgot to call the compute crc somewhere in the FloppyBuilder :)
I got:
OricTech.dsk: Completed; 84 tracks found, 2856 CRCs checked, 170 fixed
Zerofx.dsk: Completed; 84 tracks found, 2856 CRCs checked, 263 fixed
Versions that my tool believes fixed are attached.

EDIT: also from amongst those obtained from Pouet (EDIT2: and those that come with Oricutron):
BornIn1983.dsk: Completed; 84 tracks found, 2856 CRCs checked, 83 fixed
BuggyBoy.dsk: Completed; 84 tracks found, 2856 CRCs checked, 2697 fixed
LCP2004.dsk: Completed; 84 tracks found, 2856 CRCs checked, 2697 fixed
PushingTheEnvelope.dsk: Completed; 84 tracks found, 2856 CRCs checked, 1389 fixed
Quintessential.dsk: Completed; 84 tracks found, 2856 CRCs checked, 1288 fixed
vip3.dsk: Completed; 84 tracks found, 2856 CRCs checked, 1154 fixed
vip4.dsk: Completed; 84 tracks found, 2856 CRCs checked, 1288 fixed
Attachments
CRC fixes.zip
(1.49 MiB) Downloaded 26 times
OricTech.dsk
(525.25 KiB) Downloaded 24 times
Zerofx.dsk
(525.25 KiB) Downloaded 24 times

Godzil
Squad Leader
Posts: 755
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Barbitoric has incorrect CRCs?

Post by Godzil » Sat Jan 07, 2017 12:33 pm

iss wrote:I tested both images with Microdisk controller and HxC drive - both work fine.
I'll try to make real floppy disk with Writedisk soon, but looking at sources of Writedisk and Writedisk2 -
they use BIOS int 13h to write sector-by-sector and this BIOS interrupt requires as input only data buffer
with plain data (i.e. only 256 bytes), so the CRC in the DSK file is simply ignored.
To be honest, I will not trust the Cumulus to be 100% accurate on floppy emulation, but the HxC+FDC that's weird that with incorrect CRC it works.
Edit: Ho no wait! I know what's happening! The HxC does not use the format we use for floppy but it's own format, and you have to convert. I highly suspect that "errors" like invalid CRC are corrected at that point of the process, the converter must have the assumption that the dsk file can't really have a CRC error, so it recalculate the CRC on the fly, a bit like it we were writing using an FDC where we don't give the CRC value.


DBug: for the written floppy, it is higly probable that the CRC in the image is ignored and the floppy controller calculate it's own. Yes after checking it's exactly that, when you write a track, you use the "magic" number F7 that trigger a "CRC Write" from the FDC (See http://bitsavers.informatik.uni-stuttga ... _May80.pdf page 14 bottom and page 17 for an exemple of track write with IBM format)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest