FredPJ's feature suggestions

Support and general discussion.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Wed 11 Nov, 2015 9:36 pm

Are you thinking of bit density on the disc, rather than the bit rate coming into the FDC? Because, given the same disc, a drive spinning at 360 rpm is going to produce a higher bitrate, and hence shorter bitcell period, than one at 300 rpm, simply because it's going faster!
Well, I'm simply noticing that with your formula, the bitrates are correctly lower for lower data rates, and therefore longer periods, but for higher RPM, they are higher, which doesn't sound right to me, especially considering the fact that at a higher RPM, you can fit less data on the disk than at a lower RPM. Hence why at 500 kbps, you'll fit 12500 bytes onto a single track at 300 rpm, but 10416.6666... bytes at 360 rpm. It's also why 5.25" high density media have lower capacity than their 3.5" counterparts.
Simply put, if the disk is spinning faster, it's going to reach end of the track (remember, each track is a circle) faster, hence why at the same data rate it's going to be able to write less data onto the track because the end of the track will be reached sooner in time. It's also why formats were chosen in a conservative way, because the floppy drive standard prescribes a +/- 2% tolerance for motor speeds, so a drive can easily spin up to 2% slower, which means it will be able to fit slightly less than what it nominally should onto a single track.
The OS/2 museum mentions this here: http://www.os2museum.com/wp/floppy-capacity-math/ as it's talking about the FD1968 utility:
OS/2 Museum wrote:The reason why this utility remained unknown is that it didn’t work on most systems. The problem is that not all drives run at exactly 300 rpm; even manufacturer specifications typically allow 1-2% slower or faster speed. And if a drive rotates faster, the capacity goes down—because the FDC has less time to read or write the data on each track.

A drive that spins 1.5% faster (304.5 rpm) could only store about 98,522 bits or 12,315 bytes per track. That’s not enough to store 3 sectors holding 12,288 bytes of data due to the required per-sector overhead (which is at least about 30 bytes per sector plus required gaps). A similar problem would occur if the FDC processed data at a rate slightly slower than 500 kbps. Of course if the drive rotated slightly slower, there would be more room on the disk… but that cannot be assumed to be the case.
So as the motor speed goes up, capacity goes down, so the bit cell period should be longer, at 360 rpm it should be about 6/5 or 120% of what it is at 300 rpm, while the bitrate should be 5/6 of what it is. But, I might be misunderstanding what you're saying and therefore be wrong.
I'm not denying that all that stuff's needed somewhere, just not necessarily there, and not necessarily calculating it on every access.

I've been doing some thinking about how this is all structured, and I think we should make use of the fact that on mainline (as of v10), FDC, drive and disc are all abstracted from each other, rather than having everything together as was done pre-v10 and in PCem-X. Ideally, I think we should have :

- Core FDC core in fdc.c/h, with SuperIO stuff separate.
- Drive emulation, probably in a new fdd.c/h. This should include motor control (including RPM calculations, based on the pins provided by FDC/SuperIO) and stepping control (separated from the FDC's view of the current track - I believe the FDC should only provide relative rather than absolute track numbers for seek commands, and a seperate recalibrate), providing the other areas with the current motor speed, track 0 state and anything else needed. From my point of view, this is the only section which needs to know what the drive type actually is (3.5" HD, 3-mode, etc)
- Disc emulation, with disc.c/h acting as manager and disc_img/fdi/whatever implementing the actual read/write/format/poll functions for each format. This will also calculate the 'correct' bit rate for the current disc/track/sector (depending on format) given the current motor speed. The fdc_checkrate() equivalent would live here, comparing this bit rate against the one calculated for current selected FDC bit rate and motor speed, and fail the current operation if they don't match. This would allow us to abstract the drive logic out of the main read/write path.
- I was also thinking about moving the poll functions from disc_img/fdi and moving them into common code. My idea was to have two poll functions - one for sector based formats (img) and one for stream based formats. This would simplify the code for adding new formats to having open/track read/track write functions for each format, and providing the common poll code with either a list of sectors, or MFM streams.

To me this seems a logical division of functionality, and should be easier to maintain/extend than having everything in one file. Your thoughts?
I find your proposal to be an excellent idea. It would make everything more logical.
Fixed point will probably be better, as that's what the timer routines already use.
True that. However then, the floppy disk periods should be multiplied by a factor of 15 to make them divisible by both 3 and 5, which would cause every possible period you could find on a PC-readable disk to be an integer.

User avatar
SarahWalker
Site Admin
Posts: 1724
Joined: Thu 24 Apr, 2014 4:18 pm

Re: FredPJ's feature suggestions

Post by SarahWalker » Wed 11 Nov, 2015 10:14 pm

Battler wrote:
Are you thinking of bit density on the disc, rather than the bit rate coming into the FDC? Because, given the same disc, a drive spinning at 360 rpm is going to produce a higher bitrate, and hence shorter bitcell period, than one at 300 rpm, simply because it's going faster!
Well, I'm simply noticing that with your formula, the bitrates are correctly lower for lower data rates, and therefore longer periods, but for higher RPM, they are higher, which doesn't sound right to me, especially considering the fact that at a higher RPM, you can fit less data on the disk than at a lower RPM.
This is all correct. The bitrate is higher with the higher RPM, but a disc revolution takes less time! Hence less data overall, or the same amount of data at a faster rate.

startmenu
Posts: 104
Joined: Sat 29 Nov, 2014 7:39 am

Re: FredPJ's feature suggestions

Post by startmenu » Thu 12 Nov, 2015 12:24 pm

force-4-3.jpg
force-4-3.jpg (154.11 KiB) Viewed 4612 times
Hmm... force 4:3 display mode(window mode)... I really enjoy this feature coz sound in fullscreen mode is choppy sometimes. Also, I hope PCem will support it.

User avatar
SarahWalker
Site Admin
Posts: 1724
Joined: Thu 24 Apr, 2014 4:18 pm

Re: FredPJ's feature suggestions

Post by SarahWalker » Thu 12 Nov, 2015 9:33 pm

Moved FDC discussion to viewtopic.php?f=3&t=351

ecksemmess
Posts: 155
Joined: Wed 18 Mar, 2015 5:27 am

Re: FredPJ's feature suggestions

Post by ecksemmess » Sat 14 Nov, 2015 9:58 am

Startmenu, that game in your screenshot looks hauntingly familiar but I can't quite place it. What is it?

(Also, I agree that a 4:3 windowed mode, preferably with window resizing enabled, would be a fantastic addition to PCem.)

startmenu
Posts: 104
Joined: Sat 29 Nov, 2014 7:39 am

Re: FredPJ's feature suggestions

Post by startmenu » Sat 14 Nov, 2015 11:15 am

ecksemmess wrote:Startmenu, that game in your screenshot looks hauntingly familiar but I can't quite place it. What is it?

(Also, I agree that a 4:3 windowed mode, preferably with window resizing enabled, would be a fantastic addition to PCem.)
It's Heroes of Jin Yong(pinyin: Jin Yong Qunxiazhuan), an RPG game developed in Taiwan.
Wikipedia: https://en.wikipedia.org/wiki/Heroes_of_Jin_Yong

ecksemmess
Posts: 155
Joined: Wed 18 Mar, 2015 5:27 am

Re: FredPJ's feature suggestions

Post by ecksemmess » Sat 14 Nov, 2015 12:48 pm

Yes! I saw it once years ago and have never been able to identify it until now. What incredible luck--thank you. :)

BigAlUK
Posts: 36
Joined: Mon 15 Feb, 2016 8:27 pm

Re: FredPJ's feature suggestions

Post by BigAlUK » Thu 07 Feb, 2019 7:53 pm

Sorry to use this old thread, but at least I'll kick off with the right tone:

Thus, first of all, thank you Tom for making this amazing emulator, you've been doing a great job. :)

Now to the question, which whilst this thread kinda entertained, it did not answer...

I'm trying to format a 1.2M IMG floppy using PC-DOS 3.0 on PCem V14 as a 5150 PC and can't get it to even recognise the presence of the 1.2M media or correctly format the media whatever mechanism changes I try. Neither the 1.2M setting nor the dual RPM variant appear to help. Am I missing a trick? Or has the feature succumbed to politics and thus never really been completed? (As in: Am I trying something that is already known not to work? Or would only work on a 5160 or 5170?) It would be useful to know simply because I can then move on and stop kicking myself for not being able to work out what I might be doing wrong.

User avatar
SarahWalker
Site Admin
Posts: 1724
Joined: Thu 24 Apr, 2014 4:18 pm

Re: FredPJ's feature suggestions

Post by SarahWalker » Thu 07 Feb, 2019 9:57 pm

The 5150 BIOS doesn't support high density floppies. You need at least an AT (5170).

BigAlUK
Posts: 36
Joined: Mon 15 Feb, 2016 8:27 pm

Re: FredPJ's feature suggestions

Post by BigAlUK » Thu 07 Feb, 2019 10:25 pm

Ok, ta - I shall look forward to when I've got to that stage (still progressing through the models and OS's)
I had suspected it might be something like that.
It's just hard to find corroborative documentation about these things.
But that makes a lot of sense.
So basically neither a 5150 nor a 5160 would've had any truck with these new fangled and unreliable 1.2M drives? :)

User avatar
JohnElliott
Posts: 101
Joined: Sun 31 Jan, 2016 7:29 pm

Re: FredPJ's feature suggestions

Post by JohnElliott » Thu 07 Feb, 2019 10:30 pm

Not with the stock floppy controller. They would have needed a replacement high-density floppy controller with its own BIOS.

Post Reply