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.
I was trying to make 3" disks of Pulsoids, but I found out that the .DSK in Oric.org had 82 tracks, I tried to convert it to a 42 tracks file, it worked just fine in Oricutron, but when I tried to convert it to .HFE (or .IMD) using the HxC software the program exploded.
But since these games are only using a fraction of the available storage, my idea was just to format a new floppy in 42 tracks and copy the files, so what I did was to boot Oricutron with SEDORIC3.DSK in drive A, PULSOIDS.DSK (82 tracks) in drive B and UNFORMATED.DSK in drive C.
Dbug wrote: Fri Sep 12, 2025 7:02 pm
If someone feels like checking if something's wrong with my files, they are attached to this post.
Well, Jeff@hxc2001.com pointed the problem - it's the incorrect size of the DSK file.
Here are the actual details:
the main issue is in Oricutron - after any write operation DSK's size is automatically extended to:
2 sides * 128 tracks * 6400 bytes + 256 bytes header = 1638656 bytes!
The bug is that the header is NOT updated with the new sides/tracks values. Source:
if( rawimglen )
{
// FIXME: this is temporary solution to allow
// low-level formatting up to 128 track per side
if( 143360 != rawimglen && rawimglen < 128*2*6400+256 )
rawimglen = 128*2*6400+256;
buf = malloc( rawimglen );
if( !buf ) return NULL;
}
As workaround you can patch the header with hex-editor:
20250913_013530.jpg
... and then hxcfe will work and the new HFE image will be good,
... but this is a very ugly hack.
Else, I will be very happy to discuss and to find a proper solution for this (bare in mind Oricutron knows nothing about the logical DSK layout). Actually I've posted about it in the past (click) and now I reopened the github-issue #152...
You do not have the required permissions to view the files attached to this post.
Ok, makes sense, and the Greaseweazle is smart enough to only write the 42 tracks I specified in the geometry parameters even if the physical file was larger.
I understand expanding the file during the formatting, but when I checked the header I did have "MFM_DISK 2 sides 42 tracks", is that written by Oricutron?
Could it not be as simple as handling a truncation of the file when Oricutron unmounts the disk, so either when swapping for another disk or before quitting if there was any changes made to the disk?
And the diff 2-magnetix.dsk vs. 3-magnetix.dsk is exactly as by you:
20250913_150456.jpg
Off-topic here: beside the issue "Oricutron writes DSKs" I'm very eager to have discussion about an "Oric media library" which can easily compare and classify TAPs and DSKs by their content. I've started someting with TAP files and it looks promising so far but it stil in "theory phase"...
You do not have the required permissions to view the files attached to this post.
iss wrote: Sat Sep 13, 2025 1:14 pmOff-topic here: beside the issue "Oricutron writes DSKs" I'm very eager to have discussion about an "Oric media library" which can easily compare and classify TAPs and DSKs by their content. I've started someting with TAP files and it looks promising so far but it stil in "theory phase"...
Well, having known checksums of file contents for disk and tapes would definitely help with finding corruption issues, but also differentiating the various versions of the same game. There are probably already standardized way to do that?
I was about to post here that you should give a try making DSK files with Euphoric but didn't want to interfere as I hadn't read the problems in detail.
But for information, Dbug and I just solved the Magnetix copy problem by using Euphoric. At least this is solved!
iss wrote: Sat Sep 13, 2025 1:14 pmOff-topic here: beside the issue "Oricutron writes DSKs" I'm very eager to have discussion about an "Oric media library" which can easily compare and classify TAPs and DSKs by their content. I've started someting with TAP files and it looks promising so far but it stil in "theory phase"...
Well, having known checksums of file contents for disk and tapes would definitely help with finding corruption issues, but also differentiating the various versions of the same game. There are probably already standardized way to do that?
I support the idea, wishing you luck!
Some original programs exist in 3 or 4 different (silent) releases: fast or slow mode, silent fixes, Atmos/Oric-1 versions, new batches with new protections, and some probably being batches that used the same program but from a different master, with different bytes in the header, etc.
Having a way to catalog, CRC them and have a comment section alongside would be great.
It would be great if the CRC could ignore the synchro bytes and the extra bytes (after the end of the program) that sometimes exist in TAP files. But that won't be easy when the content hold specific loading routines using specific synchro etc.
