forum.defence-force.org

Maybe worth contacting someone on an Atari forum, to ask for a hand - and at the same time see if such a card can dump Oric disks

I contacted the HxC author with a link to the forum post, and he answered something (google translated) like that:

Apart from a formatting issue (gap, track skew, different interleave ...) I do not see what could explain that.
If you have floppy streams from a Kryoflux or SCP card, you can use the HxC software to view the floppy disk content graphically.

Yep I am confused too. There must be something stupid I am not seeing.

I used readdsk today to dump the contents of the DD and the HD disks, just in case writedsk2 was doing something strange with the interleave. After all it relays on go32_dpmi to format tracks and write sectors.... In any case both images are exactly the same and contain no interleaving. Guess what? They are the same because readdks reads sectors in order 1,2,3,... not as they appear on the track (of course).

So no info can be extracted this way... Just so you don't lose time.

We need a way to inspect the disk contents with other kind of tools.

Chema wrote: ↑Thu Mar 15, 2018 7:14 pmWe need a way to inspect the disk contents with other kind of tools.

That's why there are all these devices: Kryoflux, Catweasel, etc... which are designed to read floppy content at the lowest possible level by using their own custom controllers which are custom controlled, so they can emulate and read any time of floppy format known to mankind.

It's commonly used by people who archive software in order to get binary perfect files, including protections and all weird artefacts.

As a side note, it is not that the disk is being written as high density, because if I remove the tape covering the hole write2dsk fails completely

Chema, what model is your Oric floppy? Else I guess you are using Silicebit's controller, right?

Uf, not sure. The floppy is an old SAMSUNG, IIRC... so old it has a switch to select DS0-3 (not even a jumper). The controller, yes... it is Silicebit's Microdisc clone.

Chema wrote: ↑Thu Mar 15, 2018 10:37 pm As a side note, it is not that the disk is being written as high density, because if I remove the tape covering the hole write2dsk fails completely

Though I don't belive it much myself, I'm still wondering if it can't be something related to density.
Removing the tape to write gives errors. But what happens if you write with the tape, then read without the tape? Does it fail?

If it doesn't fail, that means that the taped hole affects something at writing, but doesn't affect the reading. So maybe you wrote at DD speed (250kBps, hole taped), but what speed was used for reading, DD of HD (500kBps for HD) as the hole is ignored?

OK, it seems unlikely, and I guess it could be tested on a PC too... Writing a fake DD then testing reading speed, compared to a 100% DD disk reading speed.

Okay, mystery solved, thanks to Fabrice. He pointed me out that writedsk2 does NOT format a track if writing does not fail, so if a disk has been used for the Oric before, the interleaving is not maintained.

I am not sure why it behaves this way or what are the conditions, but I used Nibble and verified that the slow disks did not have the interleaving, while my HD disks (never used before for Oric) had. So I took one DD disk, formatted it under MSDOS and used writedsk2 again, and the loading was as fast as with the HD disks in the video.

I really think that writedsk2 should have an option to format the track before writing every time, because this is quite annoying!

So, that was it. I knew it should be something stupid along that line.

So the bottom line is: Yes interleaving does work and has a noticeable impact on the loading times

Now the question is: Are we sure that 5 is optimal?
Could you format another floppy, and then write with interleave 4 or 3 to test and see if it gets faster or slower?

Also, has anyone tried the version of FloppyBuilder 1.2 I attached earlier on this thread so I can push a new OSDK out?

hehe No. I did not test any other interleaving factor. The theoretically optimal was 3, but it was a bit too close, so 4 should be better. I really have to test, but in any case the speed now is nearly the one in the emulator, which is great!

Also I did not test the floppybuilder version you posted... I have version 1.001 what are the changes?

We also could talk about the changes in the loading and loader code, because it is now cleaner and supports Telestrat (does not boot, but works) and Jasmin, but they need some cleaning, normalizing. You can see the changes I made in the Blake'7 sources in the repository.

I have asked Fabrice about the possibility of adding an option to writedsk2 so it formats each track before writing. I really think that should be the default behavior.

EDIT: Just tested and it seems to work, produces a correct disk (tested on the emulator) with the correct interleaving (checked with an hex editor)

Anything else I should check?

This version also fixes the CRC and 0x4E / 0x22 gap2 values.

If it works for you, I'll push a new OSDK tomorrow

iss wrote: ↑Wed Mar 14, 2018 9:42 am... the interesting part: writedsk2 first tries to write the sectors and if the operation fails then it formats the track and repeat the writing...

He, I was close in my guess, "just" my conclusion was wrong . Anyway, it's easy to change writedsk2, so it always first formats the track with the interleave from input image - I'll try to make it, but I need first to install the right compiler.
About the new FloppyBuilder - the compilation under Linux/GCC fails in Floppy.cpp in line #398: Removing the typecast (void*) solves the issue, i.e. change to: BTW, another good option to play with interleave is SAMdisk (it's already discussed in the forum)....

Made a couple of tests with interleaving... 3 and 4 give similar results to 5, so I guess that once the sector is not missed and we have to wait for a full rotation, times get quite close. In fact I could not time any difference (a bit above 6 secs both 3 and 4), but I think that interleave of 3 produced quicker loading, as the floppy icon flickered quicker, but sometimes missed the sector (it was too close...), compensating the overall time, and making it even slower than 4 (or so it seemed to me).

About making writedsk format the track before writing, I think it should be an option (default or not). I asked Fabrice, because I don't want to touch the sources without his approval, but yes, it should be easy to do.

Attached is the quick hack writedsk2f (source & dos executable). It should always format tracks before writing.
It's only proof-of-concept. I agree to wait Fabrice's approval for any further releases!
Also having always-format as option is very good idea.
In source is implemented a workaround which adds <CR> to all <CR><LF> sequences in sector data - IMO this is related to very old MS-DOS versions and is not needed anymore... To build DOS executable I used cross DJGPP. The cross toolchain was build from zero very quickly with build-djgpp - great piece of software!

iss wrote: ↑Thu Apr 14, 2016 10:34 pm But I just saw the sad news: Gareth Thomas, Blake's 7 actor, dies aged 71... RIP.

So sad... Blake's 7 actor Paul Darrow dies at 78 RIP, Avon!