Floppy duplication

[Dbug]

This could have been posted in the tape/disk section, but it's generic enough to warrant a discussion here

I had pre-ordered the game Hibernated 1 - Director's Cut for the Oric, because it's always nice to have some original games in boxes.

Anyway, fast forward some time, and the game is still not available, so I poked them and they answered that they actually never did any Oric game before, were struggling to make them and would be happy if I could help.

Then sent me the DSK files so I could take a look, and indeed it's a typical Pinforic game, using the old distribution (since then Chema and Fabrice made a new version for Hugo Labrande's Tristam Island adventure game which also used Pinforic, and which thanks to them now fits on one single disk (would have to go back to the 2020 discussion to see if I remember well).

Anyway, the question was how to duplicate these games, so the approach I tried was to use the PC, but all these Kryoflux, Greaslewazleafdsgjnsadfkgj etc... are not very simple to use. I tried to plug a 3" drive on my Atari Mega STe to see if I could use Fast Copy Pro, but despite the drive being properly detected it failed during the format phase... so since my Oric has a Microdisc AND a HxC connected together, and since I can play the entire game on the Oric using the HFE files loaded from the HxC, why not just make the physical floppies ON the Oric, using the two devices as A- and B-

For the boot disk, it's easy because it's SEDORIC format:

• Format a disk using the INIT A,17,42,S command to create a single sided floppy with 42 tracks of 17 sectors
• Copy the files from the SD card to the physical floppy using COPY "B-*.*" TO A
• Create an auto start with INIST followed by CLS:!INTERPR.COM

The problem is for the second disk, which is in MSDOS format with 512 bytes per sector: Can you actually use any Sedoric command to do that, or do you need to go low level and program directly the FDC?

I vaguely remember that Symoon was doing some "read track" tests some time ago, not sure how far he's gone, but basically I need a small program that given a source and destination can format and copy a disk with 512 bytes per sector, ideally doing some checks to verify that data is properly copied (many floppies have damaged surface that don't read back properly).

Technically, a generic program that can do this type of format/copy/verify, for both 512 and 256 bytes per sector would be nice, because that would make it easier to automate the duplication.

Suggestions on how to do that would be welcome!

[Symoon]

Sadly I've gone nowhere with my disk experimentations, because of spare time limitations, and IIRC too high expectations about track reading being able to override reading problems (including bugs in the FDC).

I know this doesn't answer to your "full Oric" project (which is a good idea), but did you simply try using Writedsk with an old PC?

I don't think Sedoric can work with 512 bytes per sector, but I wonder if some conversion tools did not exist. I'm quite sure an old ceo meet video showed someone at least reading them.

[Dbug]

I know this doesn't answer to your "full Oric" project (which is a good idea), but did you simply try using Writedsk with an old PC?

I unfortunately do not have a working old PC with a floppy disk controller :-/

[Symoon]

At least the FDC 1793 states that "Tracks may be formatted with sector lengths of 128, 256, 512 or 1024 bytes."
So maybe an Oric operating system could be patched to format with 512?

[Dbug]

Oh we know that the Oric floppy disk and controllers have no problem with the MSDOS format, it's purely a software issue.

I could get my sleeves up and do that myself, but I'd like first to ask around if somebody already did that (I also sent a mail to André).

In theory, just with Read Track and Write Track (which also formats) it should be possible to do a blind copy:

Code: Select all

FOR SIDE=0 TO MAX_SIDE
  FOR TRACK=0 TO MAX_TRACK
     READ_TRACK A,SIDE,TRACK
     WRITE_TRACK B,SIDE,TRACK
  NEXT TRACK
NEXT SIDE

[Steve M]

Old PC is easiest way to write MSDOS disk and you can write Oric disks with Euphoric installed.

A cheap Win98 laptop is they way to go, but people are asking high prices for anything old on Ebay etc.

[Chema]

I use a win98 laptop just for this. Obviously, only 3.5 disks, not 3 inches.

I once asked for a low level disk copy oric native program, doing what Dbug is suggesting. That would be super useful for duplicating disks.

Do you know who could really help here? Yep. Fabrice Frances.

[iss]

https://forum.defence-force.org/viewtop ... 398#p16398
It still work in progress but works for basic sector copy with known disk layout params. It's very interesting topic for me to make an universal copy program so maybe it's time to unfreeze this project

[Symoon]

In theory, just with Read Track and Write Track (which also formats) it should be possible to do a blind copy:

Went there before, remember the "random" $C2 extra bytes? :/
https://forum.defence-force.org/viewtop ... 263#p15263
(I have edited the 1st post of the thread to give eplanations of what happened)

Maybe not important if it's just a matter of formatting though? I don't remember (or gave up before fully understanding) if they can occur anywhere in the track or just inside sectors data, but I remember Nibble (the hex editor program) when reading a track, re-reads each sector to replace the data from the track read command because of its "bad quality"!

[Dbug]

https://forum.defence-force.org/viewtop ... 398#p16398
It still work in progress but works for basic sector copy with known disk layout params. It's very interesting topic for me to make an universal copy program so maybe it's time to unfreeze this project

That would be awesome.
Known disk layout params are totally fine, in most cases the floppy will have been generated either by Tap2Dsk or FloppyBuilder anyway, so we know what the format is, in most case it would be something like:
- 1 or 2 sides
- 17 or 9 sectors
- 40/41/42 tracks or 80/81/82 tracks
- 256 or 512 bytes per sector

Ideally, what I would need:
- Possibility to select the source and target disks units, personally I don't need it to work with only one disk unit, but I guess that could be useful to duplicate physical floppies, but that would involve a lot of toasting (disk swapping) on a machine with only 64k of ram.
- Possibility to select the number of sides, tracks and sectors/sector size (could be presets)
- Possibility to do some verify/checks to compare the source to the destination to detect bad drives or floppies

We don't technically need to have an identical floppy, I don't think we have any software that checks the exact gaps and sync marks, but it has to be identical at the sector/structural content.

Maybe not important if it's just a matter of formatting though? I don't remember (or gave up before fully understanding) if they can occur anywhere in the track or just inside sectors data, but I remember Nibble (the hex editor program) when reading a track, re-reads each sector to replace the data from the track read command because of its "bad quality"!

True, it's probably sufficient to format the destination track, copy the sectors, move to the next track

Bonus question: Is it possible to use a floppy with two single sided content in a double sided Microdisc unit? As far as I can see, I can turn around the disk on a Single Sided unit, but on a double sided one it does not fit (probably because of the notch at the bottom).

If that was possible, it would mean that a Pinforic game could fit on a single disk: Boot on the "A side", then when it asks you to insert the game disk, eject and turn the floppy to expose the "B side".

Basically the idea is that 3" floppies are about as expensive as platinum, so using two disks for a game when each could fit on the same disk would be a serious cost reduction. And as a bonus, these games could be used on Single sided and Double sided Microdiscs, which is a definitive bonus.

[Chema]

In theory, just with Read Track and Write Track (which also formats) it should be possible to do a blind copy:

Went there before, remember the "random" $C2 extra bytes? :/
https://forum.defence-force.org/viewtop ... 263#p15263
(I have edited the 1st post of the thread to give eplanations of what happened)

Maybe not important if it's just a matter of formatting though? I don't remember (or gave up before fully understanding) if they can occur anywhere in the track or just inside sectors data, but I remember Nibble (the hex editor program) when reading a track, re-reads each sector to replace the data from the track read command because of its "bad quality"!

Yep, I am not sure you can use the READ TRACK command for this. What you can always do is trying to read tracks until you get an error to get the number of tracks. Then for each track, try to read sectors to figure out the number of sectors per track (could it be different for each track?), maybe trying 256/512 byte sectors to figure out sizes, etc. After you get the info, you can format the destination disk accordingly (maybe track per track).

But somewhat I think we had this conversation before, didn't we?

[Dbug]

In theory, just with Read Track and Write Track (which also formats) it should be possible to do a blind copy:

Went there before, remember the "random" $C2 extra bytes? :/

Yep, I am not sure you can use the READ TRACK command for this. What you can always do is trying to read tracks until you get an error to get the number of tracks. Then for each track, try to read sectors to figure out the number of sectors per track (could it be different for each track?), maybe trying 256/512 byte sectors to figure out sizes, etc. After you get the info, you can format the destination disk accordingly (maybe track per track).

Imo, the way to go is to have user settable parameters, but I guess it could also have a "guess" option which tries to find out the format by doing what you suggested.

The main issue is that I fear it risks damaging the 3" drives... when by mistake you try try to access over the track 40/41/42 (can't remember exactly) you can hear the drive doing terrible noise when the head tries to go past the physical limits because the drive electronics itself does not try to forbid that.

And yes, there are traced of discussions going back many years, but none of the projects or discussions has ended up with a usable released product.

Assuming ISS's program works in my config, and I manage to create a few versions of some games on my setup, then I can contact poly.play and tell them that I'm ok to do the duplication for them (the plan is that they send me the floppies, apparently they have stocks of new/never used before 3" floppies).

It's not really work I want to do, but if we can come up with something reliable and easy to reproduce, I can document that on a blog post and on a video, then we may end up having people actually produce physical versions of Oric games, which would be cool

[Dbug]

I did some horrible things today:

[iss]

The problem is for the second disk, which is in MSDOS format with 512 bytes per sector...

Slightly off-topic and maybe stupid question: why was chosen MSDOS FAT16 512 bytes per sector format for the second disk?
I'm sure @Euphoric has a good reason to do it so but I can't found the answer

Reading Pinforic manpage:

Code: Select all

       Infocom  games  consist  of a datafile and an interpreter which exe-
       cutes the instructions contained in the data file to run  the  game.
       This program is essentially a portable datafile interpreter.
       ...
       Transfer a datafile to a formatted MS-DOS double-side double-density
       disk (DSDD), i.e a 360 KB 5"1/4 disk or a 720 KB 3"1/2 disk. Be sure
       to copy the datafile to a freshly formatted disk so that the file is
       the only one on the floppy (the remaining space of the disk  will be
       used to save/restore games)

It should be OK to use the standard Sedoric sectors with 256 bytes each?

[Dbug]

That would require rewriting the infocom interpreter.
Basically the system uses up to 128KB as a kind of large virtual memory that is accessed from the game engine by seeking and loading specific sectors at offset, etc...

So yes, that would be doable, but that would require doing changes in apparently many places, retesting the entire game, etc...