CP/M and Goteck

[KC9KEP]

Hello… I am interested in replacing my 5.25 inch drive with a Gotek. A possible issue is it the first two tracks are in single density and the remaining tracks are in double density. Has anybody handled this scenario? Thanks.
PS: I am using the HDX 2001 software.

 

[Svenska]

A raw image file cannot express varying formats directly, but the HFE format can. Both FlashFloppy and HxC support it. I haven't used HFE files myself, though.

 

[cj7hawk]

I would expect a raw image file to do exactly that as the flux change rate for a disk should be independent of the data and data encoding method used on it - rather than a disk image which hold the data in it's unencoded format - Though I'm not familiar with the HFE format yet. I assume it encodes the data stream in terms of data transitions, sectors headers and all, rather than just the sector contents then?

But I'm more curious as to what kind of machine encodes their disks that way -

David.

 

[Svenska]

A raw image file only contains the raw data, it doesn't carry any information about geometry or encoding. You need a separate mechanism to carry the information that the first two tracks contain a different format and less data than the rest, and software generally doesn't handle that for raw files. (Also, "raw image files" and "disk images" are the same thing to me. Flux images are different.)

Encoding disks that way allows an older boot ROM to load the system from disk, while still getting the advantages of a higher-density controller. It also provides some form of backward-compatibility, where older software can at least tell that the disk is unsuitable for it.

If I'm not mistaken, the HFE format originated in HxC to represent complex disk formats specifically for Gotek devices. It carries information on the sector format, track layout etc, but I never needed to look into the details. Importantly, it can be written to from the Gotek as well.

 

[cj7hawk]

Thanks Svenka - I think I'm confusing terms. To my thinking, a raw image was the data straight from the FDD, with encoding still in place. I guess they call them Flux images, though if the data rate is knows, the flux stream for each track should be possible as binary.

 

[KC9KEP]

Is anyone familiar with this utility and how to use it?

HxC2001 : HxC Floppy Emulators firmware customization page !

HxC Floppy Emulators firmware customization page

hxc2001.com

Thanks again!

 

[KC9KEP]

A raw image file only contains the raw data, it doesn't carry any information about geometry or encoding. You need a separate mechanism to carry the information that the first two tracks contain a different format and less data than the rest, and software generally doesn't handle that for raw files. (Also, "raw image files" and "disk images" are the same thing to me. Flux images are different.)

Encoding disks that way allows an older boot ROM to load the system from disk, while still getting the advantages of a higher-density controller. It also provides some form of backward-compatibility, where older software can at least tell that the disk is unsuitable for it.

If I'm not mistaken, the HFE format originated in HxC to represent complex disk formats specifically for Gotek devices. It carries information on the sector format, track layout etc, but I never needed to look into the details. Importantly, it can be written to from the Gotek as well.

I'm floundering here .. What is an "HFE" file and how do I create it?
Thanks again!

 

[GeoffB17]

Hmm, yes, this thread is getting a little confused.

One of the reasons for the creating of 'disk images' was to allow emulators to use the image as a virtual disk. So the image file needs to be able to be read/written to just like the real disk.

The use of images for data retrieval/archiving can be somewhat different.

My understanding is that the image created by the flux readers cannot be used by other software directly, I believe that it is normal to create the flux image and then convert it to a normal image that can be used directly.

'Normal' images cover a wide range of complexity, from the simplest (raw data, i.e. sector data only, no format information) to formats that CAN cope with a large range of 'oddities' in the format and hence contain a fair bit of format data, and flexibility, and may well be able to cope with the example quoted, i.e. some tracks at one format, other tracks with a different format. Dependant on the abilities of the FDC or course.

The HFE images are just a 'normal' image of sector data, but a fairly complex version that CAN code with some format oddities. HFE is the default image type for some Gotek setups, but it is possible to config a gotek to use other types. For example, I'm involved with Amstrad conputers, CPC and PCW, and here a .DSK image is used with emulators and Goteks, the basic .DSK being fairly simple, but there is also an Extended version which can handle more oddities.

Yes, it is possible that a raw image file might be read directly by boot ROM, as there is no other data in such a file, but it would be difficult to be sure that the data was in the right place in the image to be read normally. Emulators of course would need to do that, emulators for the PCW computer do boot from a .DSK image file and I'm sure other systems (emulator for computer X and image file for the same computer) will do the same. Using a raw image makes this easier, but not necessarily easy.

A while back I was looking at a process to convert HFE images to something like .DSK but the HFE image was more complex than I liked. I was looking at the HxC system but again it was much more complex than I needed.

Geoff

 

[Svenska]

Thanks Svenka - I think I'm confusing terms. To my thinking, a raw image was the data straight from the FDD, with encoding still in place.

The term "raw image" has been used for a very long time to contain the pure sector data without any format information. They have been used in emulation, but also as a way to archive and distribute floppies. For example, Linux distributions (or at least their boot disks) were provided as floppy images which anyone could write themselves for installation; IBM also shipped similar disk images on their OS/2 CD-ROMs.

Since the file itself lacks any metadata, the files do not identify themselves. FlashFloppy on a Gotek tries to identify them by file size and file extension (and allows specifying the format in its configuration file), but this is an inherently inreliable process. This is where special formats are useful and common, often designed and popularized by emulators.

I guess they call them Flux images, though if the data rate is knows, the flux stream for each track should be possible as binary.

While flux images contain all the information and are great for archiving, the files are quite large, require special hardware to be created, and cannot be used for anything as-is. A regular FDC cannot read or write flux data directly. There are other intermediate formats, such as Teledisk (TD0 files), which have been used to archive and recreate floppies to the ability of standard hardware.

I'm floundering here .. What is an "HFE" file and how do I create it?

When I learned about Gotek's a long time ago, HxC2001 was the only useful firmware for those devices. The HFE format has been designed for this firmware, and allows it to handle some oddball formats (such as yours) while still being able to be read/written from the Gotek hardware. It is also supported by FlashFloppy now.

In order to create those files, the best way is to probably follow the step-by-step guide from the original author: https://hxc2001.com/download/floppy_drive_emulator/HxC_Floppy_Emulator_Software_User_Manual_ENG.pdf

edit: I've looked at the software and can't find a way to easily create a multi-format file. FlashFloppy can specify such formats in IMG.CFG, but I can't create an empty file for you - you'd need to specify the actual format much more accurately. I don't know what system you are trying to use with a Gotek, the format may already be predefined in the tools.

 

[norwestrzh]

>> But I'm more curious as to what kind of machine encodes their disks that way -

There are a number -- Cromemco and (I believe) some CompuPro systems.

It is quite possible to provide for this rather strange disk format with the flash floppy stuff. I run it on a Cromemco CP/M and CDOS box.

Roger

 

[ldkraemer]

KC9KEP,
Can you make an *.IMD file of one of your Boot Floppy's, and include the information
in your Disk Parameter Block (DPB)? That would be a good starting point.

HxC can Load and Covert that image to one of several formats.

Larry

 

[shirsch]

A raw image file cannot express varying formats directly, but the HFE format can. Both FlashFloppy and HxC support it. I haven't used HFE files myself, though.

I don't think that's correct for FlashFloppy firmware, which provides a means for separately defining individual tracks or track ranges. Sometimes an HFE is simpler, but it's not the only workable approach.

 

[Svenska]

I don't think that's correct for FlashFloppy firmware, which provides a means for separately defining individual tracks or track ranges.

Yes. In case I wasn't clear, that is exactly what I meant when I wrote this:

FlashFloppy on a Gotek tries to identify them by file size and file extension (and allows specifying the format in its configuration file)

;-)

 

[peterbbu]

If you use Flash Floppy firmware on your GoTek, then you can use either HFE files which are flux change bitstream plus some meta data, this is largely agnostic to disk format or you can create an img.cfg file and use .img files, which are arrays of blocks. [However, please note that the 360 Kb disk occupies ~ 1 MB in HFE format]

Research Machines 380Z and 480Z (a UK educational computer supplier) uses single density (FM) encoded track 0 and the rest of the disk is double density (MFM) encoded. Please note RM is further complicated in that the 2 sides of a disk are treated as separate logical disks. Track 0 is 16 sectors of 128 bytes. Track 1-39 are 9 sectors of 512 bytes. (note the RM CP/M BIOS handles the deblocking of the 512 byte physical sectors into 36 logical 128 byte sectors which is what is presented to CP/M)

an example img.cfg extract included below.

# 5.25" 2SDD 166+166kb
[::363520]
cyls = 40
heads = 2
gap = auto
rpm = 300
step = 1
file-layout = sequential
tracks = 0
secs = 16
bps = 128
mode = fm
rate = 125
id = 1
tracks = 1-39
secs = 9
bps = 512
mode = mfm
rate = 250
id = 1

Hope this helps

Peter

 

[peterbbu]

Think of a Gotek with Flash Floppy as the equivallent of a physical drive. As with a physical drive there are a number of parameters that can be configured and a number of different types of drives. (3.5", 5.25", 8", 40 Track, 80 Track, or High Density, single or double sided) Different drive manufacturers / models have differing step and head settling times, these are configurable. Once your Gotek emulates the physical drive type in your system you need to look at the disk controller, this takes the flux change stream to / from the disk heads after amplification and encodes the information onto this stream using FM (SD), MFM (DD), RLL (a compressed variant of MFM), GRC (as in Apple II). This datastream is then further divided into sectors. Sectors have headers (head, cylinder, sector number, sector size). When you initally format a new floppy disk you are dividing the disk into tracks (determined by the stepping) and tracks into sectors, each sector has its own header. followed by the data area and a crc value.

If you use HFE then in effect you have a file of the flux changes, how you encode / interpret this is upto your controller and the HFE knows nothing of what it is holding, it is probably the most flexible and a number of RAW disk capture boards: Greaseweazle, Kryoflux etc can read the flux changes from a drive and write it out to a file HFE. In addition there is some meta data such as number of tracks and whether to single or to double step the heads.

.img files are an array of blocks, the data contents of the disk sectors and FF needs to be told how to interpret those blocks. Disks can have mixed format but you will need a more complex img.cfg file to tell FF firmware how to process the blocks. Note there are 2 ways to interpret the blocks: a) 'Sequential' all the blocks on one side of a disk are in sequence and b) 'Interleaved' sectors for a given cylinder are from side 0 followed by the sectors from side 1 for the same cylinder. FF copes with either and indeed if you wish to create an even more complex img.cfg you can arrange for your system to process either layout automatically depending upon the filename of the disk image in use. There are potentially performance differences depending upon how your system treats tracks and cylinders. eg RM treat each head as a separate logical disk therfor it is more efficient to use 'Sequential' layout. However, my system copes with 'Interleaved' layout as well it just needs to be told which is it dealing with. (Interleaved is perhaps more relevent to some MSDOS formats that treat both sides as a single disk, of which there are two schemes 'up and over' (where a double sided 40T disk uses track 0-39 on side 0 followed by tracks 40-79 on side 1) vs 'cut through' (sectors on side 0 followed by sectors on side 1 for each cylinder).

Hope this helps

Peter