Hi, new registrant, first-time post; I searched but could not find an explanation of this. I am looking at the file format specification here.
While being aware of the limits of double density media and capture mechanisms, is there a hardware reason for not supporting playback of hypothetical higher bit-rate images?
I am specifically interested in a higher clock rate because it allows less-regular media to be represented. So not to try to represent an unrealistic number of flux transitions, but to give more flexibility over the placement of transitions.
I am specifically thinking of fuzzy bits in this enquiry: transitions that are deliberately placed on the boundary of two transition windows so that whether they fall one way or the other is essentially random given aerodynamics, motor fluctuations, etc.
If 1,000 kbit/sec were permissible, one could encode a double density track with fuzzy bits by taking the 500 kbit/sec, introducing a 0 bit between every existing sample, then nudging the fuzzy bit over into one of the new 0 samples.
So still a representation of a real double density disk, of the sort that really existed, just for raising an arbitrary limit.
I find it hard to believe that it really is the case that nobody has previously asked, so please don't hesitate with a quick reply to the effect that I'm asking a dull duplicate question, but if so then a pointer to the existing answer would be appreciated.
Why is HFE bit rate capped at 500kbit/sec?
Re: Why is HFE bit rate capped at 500kbit/sec?
This is simple : none of the currently existing hardware are able to support reliably higher data rate.
Anyway if you want to support copy protection, HFEv3 is a better choice.
Anyway if you want to support copy protection, HFEv3 is a better choice.
Re: Why is HFE bit rate capped at 500kbit/sec?
Sorry, I think we're now having this same conversation in two places, but in case this is the better forum: is documentation available for HFEv3? I have sought it but failed in my attempt.
Re: Why is HFE bit rate capped at 500kbit/sec?
No documentation yet.
Re: Why is HFE bit rate capped at 500kbit/sec?
Do you have any expectations as to when documentation might become available?
I seem to be able to locate only documentation of version 1.1; does version 2 exist and, if so, was it documented?
I seem to be able to locate only documentation of version 1.1; does version 2 exist and, if so, was it documented?
Re: Why is HFE bit rate capped at 500kbit/sec?
No, nothing else exist. and this is not in the priority list.
for which purpose do you need this ?
for which purpose do you need this ?
Re: Why is HFE bit rate capped at 500kbit/sec?
It's would like rather than need, please don't take this as an imposition or some sort of warped statement of entitlement.
I'm from the world of whole-machine emulation. HFE has become a de facto exchange format on the Amstrad CPC because it can store images that the older CPC-originated DSK format cannot. E.g. it is actually preferred by SugarBox ("Fix a bug in saving DSK file. It should no longer crash (anyway, if you can avoid using it, prefer HFE or IPF format !)"), and is supported by several others, including my own.
Since implementing it for the CPC, I've received a request also to allow it as a source for Oric software, and over in Electron/BBC world we've never really had critical mass behind a file format that attempts accurately to represent a disk. It's almost entirely implicitly-numbered sector dumps and commercial software that was cracked and transcribed. There are a couple of contenders but my preference would be to push HFE since it has traction elsewhere and because it has been formulated the right way around — it answers the question of 'how do I represent a floppy disk', not trying to couple that job to a particular machine or disk controller or any of the other pitfalls you'll also have noticed in the various per-machine disk image formats.
Therefore it would be useful to have the latest specifications both (i) because good HFE support is important for being a good emulator of some platforms already; and (ii) because it would help to make a case for HFE as a preferred exchange format elsewhere.
I know exchange is a byproduct of what you've built, separate from your main interest, but I was hoping you'd be willing to help out with the emergent usage.
Re: Why is HFE bit rate capped at 500kbit/sec?
HFE V3 is similar to the HFE V1. The difference is that HFEv3 tracks can embedded some operation codes to change bitrate, and do some others operations in real time.
You can see the opcodes in the sources :
https://sourceforge.net/p/hxcfloppyemu/ ... 3_loader.c
You can see the opcodes in the sources :
https://sourceforge.net/p/hxcfloppyemu/ ... 3_loader.c
Re: Why is HFE bit rate capped at 500kbit/sec?
Cool, thanks! I can work with that. Code is often very practical documentation.Jeff wrote: ↑Tue Mar 06, 2018 10:31 pmHFE V3 is similar to the HFE V1. The difference is that HFEv3 tracks can embedded some operation codes to change bitrate, and do some others operations in real time.
You can see the opcodes in the sources :
https://sourceforge.net/p/hxcfloppyemu/ ... 3_loader.c