Cumana Reborn DSK support

This is the best place to discuss about the various Oric operating systems like Sedoric, Randos, FT-Dos, and others, as well as serious software, utilities, word processors, disassemblers, etc... that runs on oric computers.
User avatar
xahmol
Flying Officer
Posts: 177
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Cumana Reborn DSK support

Post by xahmol »

Jeff wrote:
Fri Oct 09, 2020 7:30 pm
Can you share the DSK you have used to make the test ?
Sure.

First test I did: convert a workdisk with two demo files (small BASIC sample programs from the Oric Atmos manual) saved from my Oric Atmos using my Cumana Reborn.
See workdisk.zip containing the .hfe image and the result of the export to Oric DSK which does not seem to work. Do not have an original DSK for this as this one was created on my original Oric Atmos hardware and the Cumana Reborn.
workdisk.zip
(115.91 KiB) Downloaded 39 times
Second test I did to confirm with an image where I know that the original DSK does work in Oricutron, the Space 1999 game (hope Dbug as author does not mind...)
See Space1999.zip containing original DSK, converted HFE image that does work via the Cumana Reborn on my Oric Atmos and finally the image converted back from HFE to DSK using the export to Oric DSK. Which does not work in Oricutron.
Also note the filesize from the image converted back to DSK differs from the original DSK.
space1999-en.zip
(282.23 KiB) Downloaded 35 times

User avatar
Jeff
1st Star Corporal
Posts: 14
Joined: Mon Aug 01, 2011 11:34 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Jeff »

Thanks for the tests ! I have fixed the library :

https://hxc2001.com/download/floppy_dri ... t_beta.zip

User avatar
Jeff
1st Star Corporal
Posts: 14
Joined: Mon Aug 01, 2011 11:34 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Jeff »

Dbug wrote:
Fri Oct 09, 2020 4:39 pm
-> The libhxcfe library can be used to read/write HFE files. There is a simple FDC style API to access the image's sectors :
(...)
Let me know If you want some usage examples or if you have any question about this library.
Yeah, that's quite a large API, sample code would be welcome :)
Here is one example :
This programming is reading a 80*2*9 floppy disk image sector by sector.

Code: Select all

///////////////////////////////////////////////////////////////////////////////////
//-------------------------------------------------------------------------------//
//-------------------------------------------------------------------------------//
//-----------H----H--X----X-----CCCCC----22222----0000-----0000------11----------//
//----------H----H----X-X-----C--------------2---0----0---0----0--1--1-----------//
//---------HHHHHH-----X------C----------22222---0----0---0----0-----1------------//
//--------H----H----X--X----C----------2-------0----0---0----0-----1-------------//
//-------H----H---X-----X---CCCCC-----222222----0000-----0000----1111------------//
//-------------------------------------------------------------------------------//
//----------------------------------------------------- http://hxc2001.free.fr --//
///////////////////////////////////////////////////////////////////////////////////
// File : chkdsk.c
// Contains: a floppy checker example
//
// Written by: Jean-François DEL NERO
//
// Change History (most recent first):
///////////////////////////////////////////////////////////////////////////////////

#include <stdarg.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

#include "../../sources/libhxcfe.h"

// Debug function (optional)
int CUI_display(int MSGTYPE,char * chaine, ...)
{
	if(MSGTYPE!=MSG_DEBUG)
	{
		va_list marker;
		va_start( marker, chaine );

		vprintf(chaine,marker);

		printf("\n");

		va_end( marker );
	}
    return 0;
}

#define SECTOR_SIZE 512
#define NUMBER_OF_SECTOR 9
#define NUMBER_OF_TRACK 80
#define NUMBER_OF_SIDE 2

int main(int argc, char* argv[])
{
	HXCFE * hxcfe;
	HXCFE_FDCCTRL * fdcctrl;
	HXCFE_FLOPPY * floppydisk;
	HXCFE_IMGLDR * imgldr_ctx;

	int loaderid;
	unsigned char track_num,side_num,sector_num;
	unsigned char databuffer[SECTOR_SIZE];
	int fdcstatus;
	int good,bad;
	int ret;

	printf("Image Checker\n");
	printf("(c) HxC2001\n");

	if(argc < 1)
	{
		printf("Syntax : %s file_image\n",argv[0]);
		exit(0);
	}

	good=0;
	bad=0;

	hxcfe = hxcfe_init();
	if( hxcfe )
	{
		// Optional : For debug purpose only.
		hxcfe_setOutputFunc(hxcfe,CUI_display);

		imgldr_ctx = hxcfe_imgInitLoader(hxcfe);
		if(imgldr_ctx)
		{
			// Load the image
			loaderid = hxcfe_imgAutoSetectLoader(imgldr_ctx,argv[1],0);
			if( loaderid >= 0 )
			{
				floppydisk = hxcfe_imgLoad(imgldr_ctx,argv[1],loaderid,&ret);
				if( floppydisk )
				{
					fdcctrl = hxcfe_initFDC (hxcfe);
					if(fdcctrl)
					{
						hxcfe_insertDiskFDC (fdcctrl,floppydisk);
						printf("\n");
						for(track_num = 0; track_num < NUMBER_OF_TRACK; track_num++)
						{
							for(side_num = 0; side_num < NUMBER_OF_SIDE; side_num++)
							{

								printf("Track:%.2d Side:%d Sectors:",track_num,side_num);

								for(sector_num = 1; sector_num < 1 + NUMBER_OF_SECTOR; sector_num++)
								{
									hxcfe_readSectorFDC (fdcctrl,track_num,side_num,sector_num,SECTOR_SIZE,ISOIBM_MFM_ENCODING,1,(unsigned char*)&databuffer,sizeof(databuffer),&fdcstatus);
									switch(fdcstatus)
									{
										case FDC_BAD_DATA_CRC:
											printf("[%d-BD!] ",sector_num);
											bad++;
										break;
										case FDC_NO_DATA:
											printf("[%d-ND!] ",sector_num);
											bad++;
										break;
										case FDC_SECTOR_NOT_FOUND:
											printf("[%d-NF!] ",sector_num);
											bad++;
										break;
										case FDC_NOERROR:
											printf("%d ",sector_num);
											good++;
										break;
										default:
											printf("[%d-UE!]",sector_num);
											bad++;
										break;
									}

								}
								printf("\n");
							}
						}

						hxcfe_deinitFDC (fdcctrl);
					}

					// Free the loaded image
					hxcfe_floppyUnload(hxcfe,floppydisk);
				}
			}

			hxcfe_imgDeInitLoader(imgldr_ctx);
		}
		// deinit the lib
		hxcfe_deinit(hxcfe);
	}

	if(good && !bad)
	{
		printf("Image 100%% ok!\n");
	}
	else
	{
		if(good)
		{
			printf("Image corrupted!\n");
			return -2;
		}

		return -1;
	}

	return 0;
}


User avatar
iss
Wing Commander
Posts: 1199
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Cumana Reborn DSK support

Post by iss »

Code: Select all

HxC Floppy Emulator : Floppy image file converter v2.0.3.1
libhxcfe version : 2.13.2.2
Compiled from sources and 'oricdsk_writer' seems to work now! Thanks for the quick fix! :wink:

@Jeff: Does this means that HxC firmware for Gotek need to be fixed too?

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

Re: Cumana Reborn DSK support

Post by Dbug »

xahmol wrote:
Fri Oct 09, 2020 8:11 pm
Second test I did to confirm with an image where I know that the original DSK does work in Oricutron, the Space 1999 game (hope Dbug as author does not mind...)
I don't mind, but Chema may mind that he is not credited as the actual author of the game (I only wrote the intro sequence)
Jeff wrote: Here is one example :
This programming is reading a 80*2*9 floppy disk image sector by sector.
Thanks :)
I would not have figured out the initialization sequence with lib, loader, image, fdc.

User avatar
Symoon
Archivist
Posts: 1934
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Symoon »

xahmol wrote:
Fri Oct 09, 2020 8:11 pm
See Space1999.zip containing original DSK, converted HFE image that does work via the Cumana Reborn on my Oric Atmos and finally the image converted back from HFE to DSK using the export to Oric DSK. Which does not work in Oricutron.
I spotted a small "bug" in the header: the geometry is missing. It should always be "1" for Oric apparently. Changing it didn't solve the problem though.

According to Fabrice, years ago (don't ask me "why", I'm just re-typing what I found back ;) ):
"MFM" FORMAT, 256 bytes header :
- 8 bytes MFM_DISK
- sides (32 bits little-endian)
- tracks (32 bits)
- geometry (32 bits)
(the rest not being used at the time, planned possible usage for BD-500 disks, or whatever)

Each track uses 6250 bytes, filled by unused bytes to go up to 6400 (so it can be divided by 256).
Geometry indicates the tracks order:
1 = all tracks from side 1 first, then side 2
2 = track 0 first (side 1 then side 2), track 1, and so on.
Geometry 1 is use in the Oric world, 2 outside Oric world.

I noticed from the Space 1999 disks that the original track length is 6400, but the HFE-converted version tracks are "only" 6290 bytes long. Maybe that's a problem for the emulators?
The HFE-converted disk seems to be recognized and starts booting then hangs. Possibily some track shifting ending in some buggy behaviour?
I doubt it but who knows.

User avatar
iss
Wing Commander
Posts: 1199
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Cumana Reborn DSK support

Post by iss »

Symoon wrote:
Sat Oct 10, 2020 8:39 am
...
Absolutely correct, @Symoon!
Here are @Jeff's last changes which make Oric DSK writer working.

User avatar
Jeff
1st Star Corporal
Posts: 14
Joined: Mon Aug 01, 2011 11:34 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Jeff »

@Symoon : all of this was fixed yesterday. :D

Now i am trying to refactor the loader :

The Oric loader was coded at the Infoticaires 2008 convention ... :

Image
http://hxc2001.free.fr/infoticaires2008/CIMG4523.html

flag_fr :wink:

The "problem" is that the current loader regenerate the track instead to use the one present in the MFM DSK image. I remember that i had issues trying to use the tracks "as-it-is" + adding the missing clocks at the id and data marks.
I am not sure why, so i want to retry this solution because i want to be sure that the current Oric MFM DSK images in the wild are working directly with the real hardware and check that the sectors/formats are correctly encoded.

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

Re: Cumana Reborn DSK support

Post by Dbug »

Jeff wrote:
Sat Oct 10, 2020 12:00 pm
The "problem" is that the current loader regenerate the track instead to use the one present in the MFM DSK image. I remember that i had issues trying to use the tracks "as-it-is" + adding the missing clocks at the id and data marks.
I am not sure why, so i want to retry this solution because i want to be sure that the current Oric MFM DSK images in the wild are working directly with the real hardware and check that the sectors/formats are correctly encoded.
There's a number of DSK files that have some incorrectly computed parameters, possibly some buggy checksum, tools have been fixed, but these floppies run fine on the real hardware because WriteDSK and similar tools were ignoring these parameters and regenerating themselves :D

User avatar
Jeff
1st Star Corporal
Posts: 14
Joined: Mon Aug 01, 2011 11:34 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Jeff »

Dbug wrote:
Sat Oct 10, 2020 12:04 pm
Jeff wrote:
Sat Oct 10, 2020 12:00 pm
The "problem" is that the current loader regenerate the track instead to use the one present in the MFM DSK image. I remember that i had issues trying to use the tracks "as-it-is" + adding the missing clocks at the id and data marks.
I am not sure why, so i want to retry this solution because i want to be sure that the current Oric MFM DSK images in the wild are working directly with the real hardware and check that the sectors/formats are correctly encoded.
There's a number of DSK files that have some incorrectly computed parameters, possibly some buggy checksum, tools have been fixed, but these floppies run fine on the real hardware because WriteDSK and similar tools were ignoring these parameters and regenerating themselves :D
I have put a direct conversion mode in the loader :
https://hxc2001.com/download/floppy_dri ... t_beta.zip
(set ORICDSK_LOADER_REGENERATE_TRACK to 0)

And yes i remember now, many MFM DSK files images are more or less broken... many CRC are broken or not computed (F7F7...)...
I understand why i made the decision to regenerate the whole track 12 years ago. Well, this sound like this will be a kind of pain to support this on the gotek. :|

What was the purpose of this file format ? From the design/specifications it should support some copy protections but since many images appears to be broken i am not sure anymore.

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

Re: Cumana Reborn DSK support

Post by Dbug »

I'm not sure, I guess Fabrice Frances would be the one to answer that.

Obviously this MFM thing was needed because the original DSK file format was updated which is why there's this "Old2MFM" program, possibly that was because some floppies are using 256 bytes per sector and some are 512 bytes per sector (like Randos), and then there's the Microdisc vs Jasmin thing.

The format itself is quite old, it came with Euphoric, and already existed when I came back in the Oric world in 1996.

User avatar
Symoon
Archivist
Posts: 1934
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Symoon »

Jeff wrote:
Sat Oct 10, 2020 2:33 pm
And yes i remember now, many MFM DSK files images are more or less broken
(...)

What was the purpose of this file format ? From the design/specifications it should support some copy protections but since many images appears to be broken i am not sure anymore.
It appeard to allow the disk transfer of protected disks indeed. A few ones (like XL-DOS) use specific bytes out of the sectors data content.
Initially, Oric emulators only used disk datas, hence the "OLD2MFM" tool to convert "old" DSK files to "new" ones with full gaps and so on.

EDIT: found back from Euphoric historic file:
V 0.91
------
- Changed the FDC 1793 emulator to handle a new disk image format (really a
bit copy of a real disk), this will allow every exotic format (eg. the
Randos system formats the first three tracks with 16 sectors (256 bytes),
and the rest of the disk with 9 sectors (512 bytes)).
The bad news is your disk images are bigger (every track is 6400 bytes,
with datas, sector id's, gaps, indexes,...) and you have to update your
disk images with the oric2mfm utility (sorry for that), but this will
soon bring great rewards for both virtual and real oric users 8-)
(anticipating, you can already examine M$-DOS disks with Nibble, like on
the real Oric: use the dos2mfm utility to convert a 720K M$-DOS raw image
to the new mfm format. M$-DOS raw images are easily obtained under Unix
with the standard dd command, or under M$-DOS with the rawread utility)

User avatar
xahmol
Flying Officer
Posts: 177
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Cumana Reborn DSK support

Post by xahmol »

Jeff wrote:
Fri Oct 09, 2020 10:00 pm
Thanks for the tests ! I have fixed the library :
Thanks! The quick service is appreciated!
The Space 1999 disk image now works converting back, however my own workdisk somehow still does not work.

See this on my Oric Atmos original hardware where three files are listed to be present on the image:
APC_0006.jpg
And this on my emulator after converting to Oric DSK, no files found:
workdisk_in_emulator.png
workdisk_in_emulator.png (9.35 KiB) Viewed 1413 times
Refers to the images in this Zip file:
workdisk.zip
(112.17 KiB) Downloaded 30 times
Any idea what still might be the issue? Might be a reason that on this image files were added on the Cumana Reborn?

User avatar
Jeff
1st Star Corporal
Posts: 14
Joined: Mon Aug 01, 2011 11:34 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Jeff »

Yes i expected this issue (see the TODO in the code...) : i need to realign the hfe data/id code...

User avatar
Symoon
Archivist
Posts: 1934
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Cumana Reborn DSK support

Post by Symoon »

Saw this announcement about HxC Floppy Emulator software:
https://www.atari-forum.com/viewtopic.p ... 01#p410201
"-> New Writer : Oric DSK images ("MFM_DISK" format)."

To be honest having no time to use it I'm completely lost in the galaxy of USB emulators and what software is for, but I suspect it's a good news for us ;)

Post Reply