FredPJ's feature suggestions

Support and general discussion.
User avatar
FredPJ
Posts: 31
Joined: Tue 15 Sep, 2015 1:55 pm

FredPJ's feature suggestions

Post by FredPJ » Fri 06 Nov, 2015 12:01 pm

First of all, thank you Tom for making this amazing emulator, you've been doing a great job.
These are mere personal feature suggestions that I think would make PCem even better and more user friendly. Please ignore them if they don't meet PCem's design direction.


Windowed 4:3 aspect ratio and window scaling
Options for locked windowed 4:3 aspect ratio and 1x, 2x, 3x, 4x window scaling (keeping the aspect ratio).


Tabbed settings window
The PCem settings configuration window is getting too tall for lower screen resolutions. My suggestion is to split it into 3 tabs:
- Machine (with the main machine configuration options)
- Video/Audio (with the video/graphics and sound card options)
- Hard Disks (the "Configure hard discs" window, moved to the main settings window for convenience).


Quick hard disk creation
The user would only input the new hard disk size in "0,00 GB" format, the sectors/heads/cylinders would appear grayed out. An "Advanced Settings" button would enable the sectors/heads/cylinders fields.


ISO image support
Nothing new here, many users already suggested this. Sure, it's possible to use Daemon Tools or other external software to mount disc images but it's a hassle, definitely not an elegant solution.


DVD-ROM support
As it is now, if you copy data from a DVD it will get corrupt, and installing software from DVD's will stall or crash PCem. To be honest it's quite annoying having to convert my DVD's to CD images exclusively to use them in PCem.


"Turbo" button settting
Enabled by defaut. Grayed out in unsupported machines. Although not a priority it would be a welcome little feature.


Button toolbar in windowed mode
Not quite like the clunky control panel that ppgrainbow suggested, but instead a toolbar with small buttons similar to the one in VMware Workstation or Spectaculator. It could have buttons like:
- Ctrl+Alt+Del
- Fullscreen
- Drive A and Drive B configuration
- CD-ROM configuration (if ISO images supported)
- Turbo button (if supported)
- Hard drive activity indicator

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Fri 06 Nov, 2015 4:47 pm

Options for locked windowed 4:3 aspect ratio and 1x, 2x, 3x, 4x window scaling (keeping the aspect ratio).
Option to force 4:3 - absolutely yes, and for example PCem-X does that already. But I see no point in scaling. You can't scale a real monitor, so the emulator not allowing you to scale is accurate.
The PCem settings configuration window is getting too tall for lower screen resolutions. My suggestion is to split it into 3 tabs:
- Machine (with the main machine configuration options)
- Video/Audio (with the video/graphics and sound card options)
- Hard Disks (the "Configure hard discs" window, moved to the main settings window for convenience).
I agree with that.
The user would only input the new hard disk size in "0,00 GB" format, the sectors/heads/cylinders would appear grayed out. An "Advanced Settings" button would enable the sectors/heads/cylinders fields.
But that would then require extra code to calculate the CHS parameters from any arbitrary size. Add the fact that most emulated machines can barely use a single GB of hard disk, while most of them have much more use for specific CHS parameters, I'd say this change wouldn't be a good idea.
Nothing new here, many users already suggested this. Sure, it's possible to use Daemon Tools or other external software to mount disc images but it's a hassle, definitely not an elegant solution.
How is it a hassle? While I agree built-in ISO mounting would be nice, I think the option to mount drives should still be kept, as it would also allow disc images in more accurate formats, such as MDF/MDS, to still be used.
As it is now, if you copy data from a DVD it will get corrupt, and installing software from DVD's will stall or crash PCem. To be honest it's quite annoying having to convert my DVD's to CD images exclusively to use them in PCem.
Well you'd find it much the same if you had a real period machine and wanted to copy data to it. While I agree DVD support would be a nice thing to have, it should not be a priority.
Enabled by defaut. Grayed out in unsupported machines. Although not a priority it would be a welcome little feature.
Well it could technically left enabled for all machines above a certain clock speed. PCem-X currently has just such a feature, a turbo feature which is enabled by default and disabling it halves the clock speed, but it's currently enabled even for a 8088 @ 4.77 MHz.
Not quite like the clunky control panel that ppgrainbow suggested, but instead a toolbar with small buttons similar to the one in VMware Workstation or Spectaculator. It could have buttons like:
- Ctrl+Alt+Del
- Fullscreen
- Drive A and Drive B configuration
- CD-ROM configuration (if ISO images supported)
- Turbo button (if supported)
- Hard drive activity indicator
A toolbar would definitely be a good idea.

Also, and I know there's going to be some people from the PCem and PCem-X sides attacking me for this, but, I think maybe it would be a good idea to merge the two remaining things PCem does that PCem-X does not, namely, copy-protected floppy disk images and the command line parameter to start the emulator in full screen mode, and then simply make the resulting PCem-X code the new mainline PCem, and then set up a PCem developer team that would work on the emulator, with of course Tom at the head of the team but people like me and reenigne inside too. The benefit to PCem would be enormous - it would get all of PCem-X's improvement (and there's a lot of them - more accurate 8088 emulation, better CGA emulation, etc.) without Tom having to do the slightest thing (as I'm prepared to do all it takes for him if needed), and it would stop this whole PCem vs. PCem-X conflict that I'm sure neither Tom nor me want, but unfortunately some people on both sides have decided to fight in various venues.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Fri 06 Nov, 2015 7:40 pm

I'd need to have a very long and hard look at the changes made in PCem-X before I agree to that. From what I've seen in the past there are some nasty and hacky changes that I don't want anywhere near mainline. I'd much prefer it if the useful changes were extracted from your codebase and submitted as patches for proper peer review.

I'm quite happy for an 'official' developer team to be set up, but I'm not willing to immediately give you write access to the mainline repository - maybe after a probationary period, but not straight away.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Fri 06 Nov, 2015 11:43 pm

TomWalker wrote:I'd need to have a very long and hard look at the changes made in PCem-X before I agree to that. From what I've seen in the past there are some nasty and hacky changes that I don't want anywhere near mainline.
And what would those changes be? I mean, yes, sure, in the beginning, there were some hacky changes such as stupid implementations of entire Super I/O chips in FDC.C, but that's long gone now. However, if you can point out any such nasty and hacky changes that are still there, I'd be glad to find a way to get rid of them
I'd much prefer it if the useful changes were extracted from your codebase and submitted as patches for proper peer review.
That would take a lot of time. It's far easier to just bring the remaining missing things from PCem to PCem-X as PCem-X has largely been following PCem and applying PCem patches as they came. We at PCem-X also have a GitHub repository, an IRC channel for development discussion, and a Jenkins autobuild system, all benefits that would be lost if I were to simply bring PCem-X's changes to PCem.
I'm quite happy for an 'official' developer team to be set up, but I'm not willing to immediately give you write access to the mainline repository - maybe after a probationary period, but not straight away.
And why is almost a year of working on the emulator hours a day is not enough as a probationary period?

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 8:41 am

Battler wrote:That would take a lot of time.
Well yes. That's one of the costs of forking a project like this, I have pointed this out in the past.
Battler wrote:
I'm quite happy for an 'official' developer team to be set up, but I'm not willing to immediately give you write access to the mainline repository - maybe after a probationary period, but not straight away.
And why is almost a year of working on the emulator hours a day is not enough as a probationary period?
Because I've had zero oversight on what you've been working on? Junk changes like viewtopic.php?f=2&t=336 also don't help your cause.

Look, I'm sorry, but I'm not willing to take your repository wholesale based purely on your assurances that the changes are good, particularly given our history on this emulator. There already is a system for getting your changes into mainline, submitting patches and having them peer reviewed. Why not try using it? It would be much better from my point of view to have the changes submitted, reviewed and merged in independently, than take a whole different codebase and then have the far more difficult job of tracking any regressions given the enormous number of changes that have been taken simultaneously, having also lost most of the previous code history in the process of having changed repository.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Sat 07 Nov, 2015 2:40 pm

Because I've had zero oversight on what you've been working on? Junk changes like viewtopic.php?f=2&t=336 also don't help your cause.
I am human so obviously I make mistakes. And so do you honestly. :p Mainline PCem has a lot of examples of bad coding practices, such as for example the use of pointers in arithmetic in the DirectDraw and Direct3D render routines? Or the sheer amount of .c files calling functions from other .c files without #including the relevant headers first? And mind you, it's mostly GCC to blame for it for being too lax. But when reenigne started working on making the emulator compile with Visual Studio 2015 (and he succeeded in the end), all these problems became much more apparent, as unlike GCC, Visual Studio's compiler outright errors out and refuses to continue when it sees such cases.
I'm just wondering why you demand essentially perfect and mistakeless code with zero hacks from other when your own code doesn't exactly meed those standards.
Look, I'm sorry, but I'm not willing to take your repository wholesale based purely on your assurances that the changes are good, particularly given our history on this emulator.
Not just my own. For one, I have, reenigne, and possibly Trixter and Scali too, all top experts on the IBM PC, the 80888 and the CGA, to vouch for the 8088 and CGA code (as well as the one change to keyboard_xt.c). Reenigne has even contributed code, both directly and indirectly (I ported his excellent CGA composite code from DOSBox to PCem-X). And there's also at least 3 other people that have contributed code and can vouch for my changes too.
There already is a system for getting your changes into mainline, submitting patches and having them peer reviewed. Why not try using it? It would be much better from my point of view to have the changes submitted, reviewed and merged in independently, than take a whole different codebase and then have the far more difficult job of tracking any regressions given the enormous number of changes that have been taken simultaneously, having also lost most of the previous code history in the process of having changed repository.
Because in the last year, more man-hours have been spent on PCem-X and PCem, and I don't mean this as an offense, just as a statement of fact. Consider the fact that PCem was developed by one single person, while PCem-X was developed by 5 people, actually make it 6 (the person who reported those exploits to you, contributed too), at least two of whom (me and SA1988) essentially work full time on the project, plus one extra person who is spending an awful lot of time fixing bugs in our networking code and has set up the Jenkins autobuild system. Add to that at least a few others that have spent a lot of time testing all of my changes, finding bugs, pressuring me to fix them, and so on.
So basically, if we were to do things your way, we would lose our entire system of IRC channel, GitHub, and Jenkins, and probably half the man-hours spent on the project would go to a waste because you'd probably reject half the changes. That, and I'd possibly risk a lynch mob, since at least 3 out of the people that worked wouldn't like that.
I proposed a solution which would take less time and cause less grief to people, while you're rejecting it and instead proposing a solution which takes more time, and risks causing more grief to people. I hope to see now why I am not exactly eager to try your way. If PCem-X was a small thing with only me working, and only working a little time on it, then yes, your way would be the best. But as things are, that's not exactly the case.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 3:28 pm

Battler wrote:I'm just wondering why you demand essentially perfect and mistakeless code with zero hacks from other when your own code doesn't exactly meed those standards.
I don't, I just request some basic level of peer review before code is submitted. This is a pretty standard requirement for software development, even in most open source projects.

On top of that, given your attitude to date and the state of the few patches you have submitted, I frankly don't trust you at all and am unwilling to take pretty much anything you say on faith.
Look, I'm sorry, but I'm not willing to take your repository wholesale based purely on your assurances that the changes are good, particularly given our history on this emulator.
Not just my own. For one, I have, reenigne, and possibly Trixter and Scali too, all top experts on the IBM PC, the 80888 and the CGA, to vouch for the 8088 and CGA code (as well as the one change to keyboard_xt.c). Reenigne has even contributed code, both directly and indirectly (I ported his excellent CGA composite code from DOSBox to PCem-X). And there's also at least 3 other people that have contributed code and can vouch for my changes too.
Why don't you let them speak for themselves then? If they've contributed as much as you say, I'd quite like their view on this.
There already is a system for getting your changes into mainline, submitting patches and having them peer reviewed. Why not try using it? It would be much better from my point of view to have the changes submitted, reviewed and merged in independently, than take a whole different codebase and then have the far more difficult job of tracking any regressions given the enormous number of changes that have been taken simultaneously, having also lost most of the previous code history in the process of having changed repository.
Because in the last year, more man-hours have been spent on PCem-X and PCem, and I don't mean this as an offense, just as a statement of fact.
And what exactly does that have to do with anything? You could have spent decades working on the emulator and I'd still want to review the changes before I accept them, because time spent has nothing to do with quality.
So basically, if we were to do things your way, we would lose our entire system of IRC channel, GitHub, and Jenkins, and probably half the man-hours spent on the project would go to a waste because you'd probably reject half the changes.
But you don't know that do you? Your extreme reluctance to submit any of the changes means that I don't know if I'll reject any of them or not. And if you focus on not throwing all your toys out of the pram because I won't take your entire codebase verbatim, you'll notice I haven't said anything about IRC or Jenkins.

Loosing man-hours of work was an inevitable consequence of your decision to fork, and to maintain that fork without attempting to contribute back. If you'd been more prepared to work with me then we probably wouldn't have had this problem, would we?
I proposed a solution which would take less time and cause less grief to people, while you're rejecting it and instead proposing a solution which takes more time, and risks causing more grief to people.
Interesting that the grief it causes me is apparently irrelevant.
I hope to see now why I am not exactly eager to try your way. If PCem-X was a small thing with only me working, and only working a little time on it, then yes, your way would be the best. But as things are, that's not exactly the case.
I don't particularly want to hand over large amounts of control of the project to someone I don't trust, and who has been frequently antagonistic towards me and the way I do things, and has been unwilling to work with me.

If you were prepared to discuss and compromise, we could probably come to some arrangement, though it is very unlikely that you'll get everything you want. But if you want me to hand over the project to you, which is the impression I've got from you for at least the last year, then you can just fuck off.

Alegend45
Posts: 85
Joined: Sat 26 Apr, 2014 4:33 am

Re: FredPJ's feature suggestions

Post by Alegend45 » Sat 07 Nov, 2015 5:05 pm

Well, I wrote the nVidia emulation, and I think that code is relatively clean. It can only do VESA though, as development has stalled at trying to get the Win9x drivers to work. I tried submitting that code to you in the past, but you rejected it after seemingly barely looking at it. That's why I started developing for PCem-X. Because Battler's approach is "All developers are equal" instead of one guy working on everything with occasional patches. I daresay that development has been faster for PCem-X than vanilla. And regressions? There are no known regressions between PCem-X and PCem at this moment to my knowledge, and there's been A LOT of testing done. Face it Tom. Your emulator has grown beyond you. And instead of trying to suppress the other versions and claiming that your version is the One True PCem (tm), you need to accept that other people have things to contribute too, and instead of making them do all the work for you and then not even recognize it, you need to embrace new contributions, albeit after testing and review.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Sat 07 Nov, 2015 5:31 pm

TomWalker wrote:
Battler wrote:I'm just wondering why you demand essentially perfect and mistakeless code with zero hacks from other when your own code doesn't exactly meed those standards.
I don't, I just request some basic level of peer review before code is submitted. This is a pretty standard requirement for software development, even in most open source projects.

On top of that, given your attitude to date and the state of the few patches you have submitted, I frankly don't trust you at all and am unwilling to take pretty much anything you say on faith.
Look, I'm sorry, but I'm not willing to take your repository wholesale based purely on your assurances that the changes are good, particularly given our history on this emulator.
Not just my own. For one, I have, reenigne, and possibly Trixter and Scali too, all top experts on the IBM PC, the 80888 and the CGA, to vouch for the 8088 and CGA code (as well as the one change to keyboard_xt.c). Reenigne has even contributed code, both directly and indirectly (I ported his excellent CGA composite code from DOSBox to PCem-X). And there's also at least 3 other people that have contributed code and can vouch for my changes too.
Why don't you let them speak for themselves then? If they've contributed as much as you say, I'd quite like their view on this.
You can find all of them in #pcem-x on irc.ringoflightning.net and I'm sure they'll be able to speak for themselves there. A few of them are here on this forum too, namely Alegend45 (though I admit his attitude is not exactly the best, sigh...), SA1988, and slipstream), and another, RichardG tried to register here last year but to this date his account hasn't been approved, and he suspect it's because you might be thinking he's Win95Fan because of similar IP ranges (but he's absolutely not Win95Fan). You can PM them and ask them for what they think, or if they want, they can chime in and say their (as I see Alegend45 has done it already).
There already is a system for getting your changes into mainline, submitting patches and having them peer reviewed. Why not try using it? It would be much better from my point of view to have the changes submitted, reviewed and merged in independently, than take a whole different codebase and then have the far more difficult job of tracking any regressions given the enormous number of changes that have been taken simultaneously, having also lost most of the previous code history in the process of having changed repository.
Because in the last year, more man-hours have been spent on PCem-X and PCem, and I don't mean this as an offense, just as a statement of fact.
And what exactly does that have to do with anything? You could have spent decades working on the emulator and I'd still want to review the changes before I accept them, because time spent has nothing to do with quality.
You're right that time spent has nothing to do with quality. My point was just that, I think the approach you propose would be too unequal, just that.
Also, and this is the one thing I agree with Alegend45 with, you have ignored some of the submissions, one even by me. Specifically, in the IDE/ADAPI thread on this forum, I have identified some issues and outright provided fixes for them. For some reason, even after I linked to my proposed fixes from Vogons, you still haven't looked at them, and I'm just puzzled why.
So basically, if we were to do things your way, we would lose our entire system of IRC channel, GitHub, and Jenkins, and probably half the man-hours spent on the project would go to a waste because you'd probably reject half the changes.
But you don't know that do you? Your extreme reluctance to submit any of the changes means that I don't know if I'll reject any of them or not. And if you focus on not throwing all your toys out of the pram because I won't take your entire codebase verbatim, you'll notice I haven't said anything about IRC or Jenkins.
Well I admit I didn't entirely understand the full extent of your proposal. To me it just sounded like "hand me over my changes in a format I prefer, and screw everything else", which is why I flipped. And yes I do admit I have this tendency to interpret people's statements the worst way and it sometimes causes me to jump the gun.
Loosing man-hours of work was an inevitable consequence of your decision to fork, and to maintain that fork without attempting to contribute back. If you'd been more prepared to work with me then we probably wouldn't have had this problem, would we?
The reason I forked the project was because of the increasing size and extent of the changes, and because I wanted people to be able to test my changes before they went into the mainline so that I wouldn't provide you with half-done hacks.
Edit: Well, SA1988 was right. It was actually him that originally forked it over the networking stuff, but then I took over (with his permission of course, and because I started doing the majority of the coding), and then the fork status was officialized. I always wanted to eventually bring my changes to mainline PCem, but at the same time I wanted people to be able to test them as they were made so as to make sure that by the time the changes reached the mainline, they would be good and working, rather than bad hacks. So it wasn't done to deprive you of our changes, or to push my ego for that matter, it was done so as to present you in the end with well-tested quality changes.
I proposed a solution which would take less time and cause less grief to people, while you're rejecting it and instead proposing a solution which takes more time, and risks causing more grief to people.
Interesting that the grief it causes me is apparently irrelevant.
I never said that. I said that one solution would cause more grief than the other. Of course, all grief is relevant. My point was merely that I'm not sure causing grief to several people to save one person from grief is necessarily the right thing to do. But I do agree I was too inconsiderate and I apologize for that.
I hope to see now why I am not exactly eager to try your way. If PCem-X was a small thing with only me working, and only working a little time on it, then yes, your way would be the best. But as things are, that's not exactly the case.
I don't particularly want to hand over large amounts of control of the project to someone I don't trust, and who has been frequently antagonistic towards me and the way I do things, and has been unwilling to work with me.

If you were prepared to discuss and compromise, we could probably come to some arrangement, though it is very unlikely that you'll get everything you want. But if you want me to hand over the project to you, which is the impression I've got from you for at least the last year, then you can just fuck off.
I never once stated I wanted you to hand over the project for me, neither now nor last year so I'm not quite sure where you're getting that. Even a few posts ago, I clearly said, that even if we agreed on doing things my way, you'd still be the project leader and I'd be under you. How exactly is that wanting the project handed over to me?
Let me make this clear: I do not in any way want PCem handed over to me. I don't even like project management, I prefer coding. I just want a solution to end this fork stuff and the unfortunate conflict that has arisen over it. But I want a solution that is two-sided. I am of course prepared to negotiate and reach a compromise and am open to all proposals.

- Alegend45: While you have raised some valid points and I appreciate your help, I kindly ask you to please not be aggressive as that only makes things worse.
Last edited by Battler on Sat 07 Nov, 2015 5:45 pm, edited 1 time in total.

SA1988
Posts: 246
Joined: Wed 30 Apr, 2014 9:38 am

Re: FredPJ's feature suggestions

Post by SA1988 » Sat 07 Nov, 2015 5:35 pm

Well, I was the one who started this fork as a reaction of you Tom not accepting my ne2000 patches (eventually improved by neozeed, whom I thank).
Also, Battler has got very accurate thoughts about early IBM PC, XT emulation, CGA emulation is almost perfect on PCem-X, also, hardcore tests like 8088MPH should be considered, as that tests everything that IBM PC originally had.
Also, other PC compatible controllers like 3-mode floppies, again, to be considered, not just for decorating, but for history purposes, especially for those who want a generic old PC from the 90s emulated.

slipstream
Posts: 2
Joined: Tue 27 Oct, 2015 10:40 pm

Re: FredPJ's feature suggestions

Post by slipstream » Sat 07 Nov, 2015 5:41 pm

About code quality: when looking at PCem-X specific stuff, I found only one issue with OBattler's code, which was promptly fixed when I pointed it out. Other than that from what I see his code has been of generally good quality; however I understand that code quality means different things to different people, so...

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 5:57 pm

I will comment properly on this in a little while, but I wanted to address one thing now :
Battler wrote:and another, RichardG tried to register here last year but to this date his account hasn't been approved, and he suspect it's because you might be thinking he's Win95Fan because of similar IP ranges (but he's absolutely not Win95Fan).
No, he probably wasn't approved because I thought he might be a spammer - this is the only reason accounts here don't get approved. If he wants to try again I'll approve him.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 7:21 pm

Also, and this is the one thing I agree with Alegend45 with, you have ignored some of the submissions, one even by me. Specifically, in the IDE/ADAPI thread on this forum, I have identified some issues and outright provided fixes for them.
I've just looked through the thread, and I can see you pointed out some issues, but I can't see the fixes. Can you point me at them? If they're there it's possible I just missed them.
To me it just sounded like "hand me over my changes in a format I prefer, and screw everything else", which is why I flipped.
You also need to understand that your proposal sounds pretty similar - you're basically saying that I should bin my development process, and adopt yours wholesale. Which basically comes across as "Tom's way of doing things is crap, adopt Battler's cos it's better", which easily turns into "Battler can run this emulator better than Tom can". If this is a serious misinterpretation then I apologise, but this is how you come across.

For clarity, my position is this - I am not willing to accept an entire different codebase, unreviewed. I'm sorry, but that is not negotiable, it's just not something I'm comfortable with. The options are either that I can review the whole thing, which will take forever, possible literally. Or you can break down the individual changes, and I can review them one by one. To me this is a much more sane course of action, which could actually get done, allow discussion about which changes are actually wanted, and most likely lead to useful discussion about how to move different areas forwards. It will take a while, but I believe it will be for the better.

We can keep IRC, though I'd generally prefer development discussion to happen in the forum, as then there is a more permanent record. I'd prefer to stick with Mercurial rather than switch to Git, as that way the existing history is kept, which is useful for regression testing. If we use my suggestion of splitting the PCem-X changes into seperate patches and commits, then a history is built for that as well. I don't know enough about Jenkins to really suggest anything there.
So it wasn't done to deprive you of our changes, or to push my ego for that matter, it was done so as to present you in the end with well-tested quality changes.
This would of course have been more obvious had those changes actually been submitted. You taking changes from other people, rather than pointing them here didn't help. Part of the issue is that your "I will provide patches to mainline once they're polished" transformed rather quickly into "make my branch the new mainline", which made me extremely dubious of your intentions.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 7:27 pm

Alegend45 wrote:Well, I wrote the nVidia emulation, and I think that code is relatively clean. It can only do VESA though, as development has stalled at trying to get the Win9x drivers to work. I tried submitting that code to you in the past, but you rejected it after seemingly barely looking at it.
I rejected it because it doesn't really do anything! I suggested you needed to get it a bit further before I accepted it, after all there are plenty of cards that just do VESA.
And instead of trying to suppress the other versions and claiming that your version is the One True PCem (tm),
I'm pretty certain I've never tried to suppress other versions. I may not approve of it, but I've never attempted to suppress PCem-X.
you need to accept that other people have things to contribute too
I do - that's why I accept patches. The fact that your patch wasn't accepted doesn't mean that I don't accept that other people contribute things. And I do credit and acknowledge them.
and instead of making them do all the work for you and then not even recognize it, you need to embrace new contributions, albeit after testing and review.
This is pretty much what I'm doing and suggesting...

And please drop the stereotyped aggressive autistic teenager thing, it's getting really old and I don't want to have to deal with it. You're not the only person on the autistic spectrum you know, and it's not an excuse you'll get any sympathy for here.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 7:27 pm

SA1988 wrote:Well, I was the one who started this fork as a reaction of you Tom not accepting my ne2000 patches (eventually improved by neozeed, whom I thank).
I don't remember not accepting your patches. From what I recall, you posted one patch, I made a few suggestions for changes, and you never responded with anything for submission.

Alegend45
Posts: 85
Joined: Sat 26 Apr, 2014 4:33 am

Re: FredPJ's feature suggestions

Post by Alegend45 » Sat 07 Nov, 2015 7:52 pm

TomWalker wrote:And please drop the stereotyped aggressive autistic teenager thing, it's getting really old and I don't want to have to deal with it. You're not the only person on the autistic spectrum you know, and it's not an excuse you'll get any sympathy for here.
I'm not doing anything of the sort, and I don't know why you people keep fucking saying I am! It's almost as if you're being aggressive to me!

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Sat 07 Nov, 2015 8:05 pm

(moderator note : sorry, clicked the wrong button and lost this post! Dismal screwup on my part. Will try to recover)

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 8:25 pm

I just kind of don't like the top down hierarchical approach of the development in the mainline PCem, and instead prefer the more egalitarian approach that has been established in PCem-X, and I am afraid that if I just contributed everything to you as patches, the entire atmosphere that has been built among the people developing PCem-X would be lost, and I just want a solution where you receive all the stuff I did, as much of it as possible makes it to the mainline, and the atmosphere I built in my team does not get lost.
I think the development culture is something that has to be worked on, not imposed. I have no fundamental problems with a more egalitarian approach, but for that I have to be able to trust the people I work with, and I'm afraid that trust has to be earned. This would have to be a transitional process, and will take time. And I do think more of the development discussion will have to move over to the forum to help with that; it would help reduce the feeling that there are two completely separate groups totally alienated from each other.
Also, I have two other problems with patches, but they I think are going to be easy to remedy. The first is, I have absolutely no idea how to make a patch from two different codebase
Don't, just make the patch from your codebase and it can be rebased / reworked for mainline if necessary.
The second is, while most of the changes can be done as patches or complete file submissions where files are added, some parts are going to be difficult. I already mentioned the fact my FDC changes and some of the Super I/O chips I added (eg. replaced the UM8669F used by the 430VX with a SMC FDC37C932FR with the corresponding BIOS) go hand in hand, plus the fact that the FDC code itself is completely different, so the patch would consist in every single line being different anyway, so I have no idea how to submit that meaningfully.
I think this is one of the areas where quite a bit of analysis, discussion and compromise is going to be needed, rather than just accepting one branch or the other.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sat 07 Nov, 2015 8:26 pm

Alegend45 wrote:
TomWalker wrote:And please drop the stereotyped aggressive autistic teenager thing, it's getting really old and I don't want to have to deal with it. You're not the only person on the autistic spectrum you know, and it's not an excuse you'll get any sympathy for here.
I'm not doing anything of the sort, and I don't know why you people keep fucking saying I am! It's almost as if you're being aggressive to me!
Try rereading your post, and try and see why you might be coming across that way...

t9999clint
Posts: 12
Joined: Mon 02 Nov, 2015 2:09 am
Location: Edmonton Alberta
Contact:

Re: FredPJ's feature suggestions

Post by t9999clint » Sun 08 Nov, 2015 8:20 am

Wow this is getting off topic.
Both you guys do great work, it's a shame to see the two of you bicker like this. It's clear that you both have a strong love for the PCem code base and want to see it improve, I just hope you guys can work together on this because this division is just creating a lot of wasted effort on both sides.

Tom, Even though I have worked with a lot of techs and programmers in my time, I personally haven't coded in forever so I probably should be the last one to state an opinion on this. It sounds to me that Battler and friends are just frustrated with the current system you have in place for submitting patches and are worried that their work is flat out being ignored. I don't think it really should be so much a issue of trust, but more of an issue of miss-communication. Techs like us are usually quite insecure and just want to have our work recognized. The more devoted a person is to a project the more emotional they can become because of it. So far you've kept a fairly good understanding of this so far but I felt like I needed to reiterate this. Now this whole mess is none of my business as I'm really just nothing but a lurker and a silly fanboy of the project, this is probably going to be the last you hear from me about the whole PCem VS PCem-X thing.

I'm now going to talk about something on topic now... ;)

All of FredPJ's suggestions are good ones that I agree with. I would also like to see an option to start the emulator in full-screen mode right when it launches. as well as maybe a way to set what resolution that full screen mode is at. I understand that it wouldn't be possible to use the native resolutions on modern gfx card drivers, but it would be nice to have a close approximation with something easy for the modern drivers to scale with (2x/4x original, etc...)

I understand this is all low priority stuff though other stuff like speed/stability is probably more important than UI changes.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Sun 08 Nov, 2015 7:22 pm

I'm thinking about how to bring PCem-X floppy-related changes to PCem's current code, and there's one big problem. PCem supports a format called FDI that originated in the Amiga community. But PCem-X supports another format also called FDI, that is however a raw image + header format originating in Japan. As the extensions are the same, and PCem attempts to judge format from extension, I have no idea how to solve the problem.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Sun 08 Nov, 2015 8:32 pm

You'd have to detect based on file content rather than extension. Assuming the mainline disc handling code as a base, you'd essentially have an fdi_load() function that read in the file header, and then called the appropriate load function.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Sun 08 Nov, 2015 11:16 pm

Alright, I'll see what I can do. Also there should be some variables added that report to the FDC the RPM and data rate of the inserted media so my fdc_checkrate() can do its checks properly, but I'm not sure how to obtain the two pieces of information from the Amiga FDI images (for raw images, I already have the code in place).
Edit: Well, and the information whether the image is FM or MFM too.

Also, about this whole problem of two FDI formats, basically, I am thinking of doing this: in disc_load(), if the extension is FDI, check if the file starts with "Formatted Disk Image File",0Dh,0Ah and if it does not, then refer the file the directly to the raw image loader, otherwise refer it to your FDI loader.

So Basically:

Code: Select all

If Extension = FDI Then
   If File Starts with "Formatted Disk Image File",0Dh,0Ah Then Proceed to loop as normal
   Else Go directly to RAW image loader for further detection
Now all that's left is solving the problem of giving the FDC the RPM and the data rate so my fdc_checkrate() can be used and can do its checks properly (it compares data rate and RPM and aborts the command with an error if they don't match, and it also takes in account 3-mode and other settings from the Super I/O chip currently being emulated (if any) if such has been received by the FDC, as well as drive type).

User avatar
FredPJ
Posts: 31
Joined: Tue 15 Sep, 2015 1:55 pm

Re: FredPJ's feature suggestions

Post by FredPJ » Tue 10 Nov, 2015 12:07 am

Battler wrote:
Options for locked windowed 4:3 aspect ratio and 1x, 2x, 3x, 4x window scaling (keeping the aspect ratio).
Option to force 4:3 - absolutely yes, and for example PCem-X does that already. But I see no point in scaling. You can't scale a real monitor, so the emulator not allowing you to scale is accurate.
Sorry, my bad, I didn't think this "window scaling" thing through. What I had in mind wouldn't be feasible due to PC's constantly using very different resolutions, please disregard it.
So yes, it would be great to have a force 4:3 aspect ratio option for windowed mode in the main PCem build.

Thanks, carry on the quality conversation.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Tue 10 Nov, 2015 4:07 am

I just stumled on this in the mainline PCem FDC code:

Code: Select all

void disc_set_rate(int rate)
{
        switch (rate)
        {
                case 0: /*High density*/
                case 1: /*High density (360 rpm)*/
                disc_period = 16;
                break;
                case 2: /*Double density*/
                disc_period = 32;
                break;
                case 3: /*Extended density*/
                disc_period = 8;
                break;
        }
}
That's... not fully correct. The basic rates are: 0 - 500 kbps, 1 - 300 kbps, 2 - 250 kbps, and 3 - 1000 kbps. The RPM is not rate-dependent, but instead depends on the drive, the media (if the drive can adjust the RPM according to the media), and extra settings that generally depend on the Super I/O chip. For example, most SMC chips have a DRTSEL option which when set to 1, it changes rate 1 to 500 kbps @ 360 RPM and fixes all other rates to 300 RPM as it's intended for 3-mode 3.5" drives, and when set to 2 I think, it changes rate 1 to mean 2000 kbps (it's meant for 2 meg tapes), and I think setting 3 is reserved. Then there's the DRATE/RWC pins which are configurable when the FDC is set to the enhanced mode, which have 4 modes (normal, data rate always 250 kbps / RPM always 300 RPM, fixed to 500 kbps @ 360 RPM, fixed to 500 kbps @ 300 RPM) (both SMC and Winbond chips support this), and then there's also the DENSEL force option which does essentially the same but separately and has 3 modes (normal, fixed to 500 kbps @ 360 RPM, fixed to 500 kbps @ 300 RPM), and which is also supported by both Winbond and SMC chips. Of course this depends on whether or not the drive supports both RPM modes, because if the drive only supports one, then no FDC option will change the RPM. PCem-X actually attempts to emulate this whole mess, and now I need to get it working on the mainline PCem FDC code.
Now, the reason for the existence of the 300 kbps data rate (rate 1) is reading double density media on high density 1.2 MB 360 RPM drives. Since an additional data rate is easier to implement (and costs less too) on a drive than a motor able to switch between two different RPM's, they decided to just speed up the data rate by the required ratio to 300 kbps, so the resulting rate of reading the floppy surface can again match the rate the data was written at on a double-density medium - the spacing of the magnetic transitions on the medium depends on both the data rate AND the RPM. I assume "period" here specifies that, which also means that a 360 RPM high density medium will not have the same period as a 300 RPM one. I think a 360 RPM high density medium would have a period of 19.2. But then again, the RPM might be handled elsewhere. I still need to find where, so I can add a global RPM variable for rate checking purposes. Granted, for the Amiga FDI images, most of it might not even be needed as probably the code already errors out if it can't find a single sector at a given rate, but I'm not sure RPM is taken into account. However, for raw images, last time I checked, mainline PCem still does a simple (fdc.rate == discrate) comparison, which the code I would port from PCem-X would replace with a much more advanced check.
Granted, I would probably need to look at disc_read() etc. or what they're called now, and implement the check there for the corresponding routines used by the raw image handler in order to only to do the check at drive level... though then I would probably need to implement a DENSEL pin between the drive and the FDC. I can already tell I'm going to have a fun time experimenting with this to get this right (and I mean this literally, I enjoy doing this :D), though it's going to take some time until I have it ready for patch submission. And that's without the sector ID stuff which I'm also going to have to implement for raw images so Eagle Computer OEM MS-DOS 2.0 boots properly, and IBM XDF-formatted images work like on real hardware (appearing as a 8-sector 1-track disk when XDF.COM is not loaded, and only working when XDF.COM is loaded). :p

Edit: Also, citations:
- SMC FDC37C665 Super I/O chip datasheet;
- SMC FDC37C932FR Super I/O chip datasheet (I will, among other things, bring a patch that changes the 430VX to a BIOS using this chip as it's much better documented than the UMC chip the 430VX currently uses on PCem, and much better in terms of functionality);
- Winbond W83877F datasheet (explains stuff excellently that even the SMC datasheets fail to explain, such as how the whole FDC enhanced mode stuff actually works);
- National Semiconductors PC87306 datasheet (this is the actual Super I/O chip used by the Endeavor/AT, and I'm going to bring its emulation with a patch);
- OS/2 museum.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Tue 10 Nov, 2015 9:12 pm

Yep, there's a typo in that switch statement. Not that it affects much, as disc_period only controls the rate at which the drive is polled and has no effect on the actual data. PCem mainline doesn't emulate motor speed, except as a bodge to force 360k disks to read at 300 kbps instead of 250.

Just had a look at your fdc_checkrate() function. It looks a bit... over-engineered? To me anyway :). I'd have thought all you'd need is :

- a function to determine motor speed for the current drive with the given DRATE/RWC bits
- a function to determine bitcell timing/period (equivalent of disc_period) based on the current motor speed and selected FDC data rate
- then just compare that with the bitcell timing for the current disc. If they don't match, then head down the 'sector not found' path.

This is for normal images anyway, where all you need to know is 'for this data rate and motor speed, will the FDC successfully read anything?'. For stream based formats like FDI, you'd attempt to decode to MFM for each possible period and read the one selected by the current data rate. This caters for jokers who like to mix data densities on the same disk, or even on the same track. I have seen the latter done, albeit not on the PC.

This approach seems a lot simpler to me anyway. Any reason why it wouldn't work?

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Tue 10 Nov, 2015 9:56 pm

- TomWalker: Yes, but PCem-X also emulates drive types, so not only is the selected motor speed and data rate compared against that of the image file, but it is also compared against what the chosen drive type supports. So if you specify a non-3-mode 1.44 MB 3.5" drive in configuration, an 1.2 MB image will never be read successfuly, for example. Drive type also affects what meaning DENSEL has - for example, 5.25" high density drives will specify 360 RPM for DENSEL 1, and 300 or 360 RPM for DENSEL 0 (depends on whether the drive is dual-RPM or not), while 3.5" high density drives will specify 300 RPM for both DENSEL 1 and 0, except for 3-mode drives which will set the RPM to 360 if DENSEL is forced to 0 while the data rate is also 0 (500 kbps). And all DRATE/RWC do is essentially force certain behaviors of the DENSEL pin, so their operation because of that also depends on the drive type.

So for example, let's say the inserted image is 1.2 MB (360 RPM, 500 kbps), and you selected data rate 0, fdc_checkrate() basically does something like this:
- What's the currently selected datarate? 0;
- Is the disk of a class matching this data rate? Yep;
- What RPM is the disk of? It's a disk that unformatted would be 1.6 MB capacity, therefore 360 RPM;
- What RPM is the drive currently set to? I the FDC think it should be 360 RPM but the drive is still saying 300 RPM;
- Sector not found it is then.

However, I do do some redundant checks in fdc_checkrate()... checks that are already done when loading the image and result in the disk class getting set to -1 (invalid) which fdc_checkrate() also checks. Plus I need to get rid the whole disk class stuff and replace it with RPM and data rate variables per drive.

Now, I also need to add some DENSEL, RWC, etc. variables to the drive structure so the FDC can pass DENSEL etc. to the drive.
This is for normal images anyway, where all you need to know is 'for this data rate and motor speed, will the FDC successfully read anything?'. For stream based formats like FDI, you'd attempt to decode to MFM for each possible period and read the one selected by the current data rate. This caters for jokers who like to mix data densities on the same disk, or even on the same track. I have seen the latter done, albeit not on the PC.
Not sure if that would even be possible on the PC, though maybe it would be... basically issue READ DATA to read 1 sector at one density, switch to another desnity, and then issue READ DATA to read the next sector at the new density, and so on. I actually admit that until just now, I never even thought of this possibility.
you'd attempt to decode to MFM for each possible period and read the one selected by the current data rate
Yeah, but the period is affected by the RPM too, and because of that, so is disk capacity. Let's use 500 kbps data rate for example. A track recorded at that data rate will hold ~12500 bytes unformatted at 300 RPM, but only ~10416 bytes unformatted at 360 RPM. I forgot the formula used but it's written in some article on OS/2 Museum. It's the whole reason why the 300 kbps data rate came along in the first place - because 300 kbps at 360 RPM has the same period as 250 kbps at 300 RPM.

Well, I actually went and Google for this now. Link: http://www.os2museum.com/wp/floppy-capacity-math/ .

Let me quote:
OS/2 Museum wrote:A standard 3½” floppy drive rotates at 300 rpm, that is 5 revolutions per second (300 / 60). Given a 500 kbps data rate, the FDC can record exactly 100 (500 / 5) kbit (kilobits), or 12,500 bytes, on a single track. At 80 cylinders and 2 sides, that’s 80 * 2 * 12,500 or exactly 2,000,000 bytes (2 MB) of data.
Now if you use 360 rpm instead, this gives 6 revolutions per second (360 / 60). At 500 kbps, the FDC can record exactly 500 / 6 = 83.3333333... kilobits or 10,416.666666... bytes on a single track. And since both 300 / 6 and 250 / 5 yield the same result, ie. 50 kilobits or 6250 bytes per track, it explains why the 300 kbps data rate came about. :p

So to operate correctly, the stream processor should be made aware of the rpm too, as that also affects the period.
except as a bodge to force 360k disks to read at 300 kbps instead of 250.
Careful though, they will read at 250k on 360k drives, though. And those drives also come with an additional caveat - specific behavior during seeking, which pretty much all BIOS'es existence rely on. The old PCem code (not sure about what the new one does for seeking) kept only one counter for track number - fdc.track. However, on real hardware, two counters are essentially in existence - the PCN counter of the FDC, and of course the actual position of the drive head. Now what happens is, to verify if the drive type is actually the one set in CMOS SETUP, the BIOS seeks well beyond track 39, to like, track 50 or thereabout, and then then moves back one by one until the TRK0 pin is 1 (verified by one of the two SENSE STATUS commands, I forgot which now), and checking what the FDC reports as PCN. If the FDC reports anything other than 0, then the drive is 40-track, as it means the initial seek to track 50 or so ended with the FDC's PCN counter at the requested track but the head actually stopped moving when it reached the maximum track it could rest on, which then caused the TRK0 pin to become 1 before the FDC's PCN counter reached 0. If however, the PCN is 0, then the drive is an 80-track drive.
This is another case where emulating actual drive types came in handy, as I could then make the emulated drive and FDC behave correctly for the chosen drive type, and get around all the "Floppy disk(s) fail: 40" errors in Award BIOS'es.

Edit: Oh and there exists also the unusual combination of 300 kbps and 300 RPM to achieve slightly more bytes per track. The 2M utility actually allows formatting disks this way, as does, I think, mr. Hochstätter's FDFORMAT. It's probably due to the fact that a low-density drive might support 300 kbps but is always 300 RPM, and therefore media can be formatted in this unusual way. This yields 300 / 5 = 60 kilobits or 7500 bytes per track, which is a bit more than the 6250 of standard double density. This yields exactly 1.2 megabytes unformatted capacity at 80 tracks (and 600k at 40 tracks), with, from what I've seen, up to 1 MB formatted for 80-track media.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Tue 10 Nov, 2015 10:26 pm

Battler wrote:- TomWalker: Yes, but PCem-X also emulates drive types, so not only is the selected motor speed and data rate compared against that of the image file, but it is also compared against what the chosen drive type supports. So if you specify a non-3-mode 1.44 MB 3.5" drive in configuration, an 1.2 MB image will never be read successfuly, for example.
Yes, but with what I described this should work - the disk would have a bitcell period of (1/500000) / (360 / 60) = 0.333us, while the FDC/drive combination would expect a bitcell period of (1 / 500000) / (300 / 60) = 0.4us. So it would correctly fail to read anything.

Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: FredPJ's feature suggestions

Post by Battler » Tue 10 Nov, 2015 11:30 pm

Yeah, you're indeed right, my point is just that what the FDC/drive combination would expect, depends on:
- State of the DENSEL pin, which depends on data rate, RWC, and DENSEL;
- The data rate itself;
- How the selected drive type interprets the set combination of the DENSEL and data rate pins;
- The format of the inserted image (because if that's not in a format the selected drive type supports, it will always return "sector not found").

Hence why all the stuff is needed in fdc_checkrate().

Edit: You calculate bitcell period as (1 / rate) / (rpm / 60), but shouldn't it actually be (1 / rate) * (rpm / 60)? Because with the formula you used, the unit we end up with is seconds squared per revolution, and a longer period for 300 rpm than 360, while with mine, the unit is revolution, and the period is longer for 360 rpm (which is consistent with the fact that at 360 rpm, the individual bit cells are spaced more than at 300 rpm). But I will admit I don't know enough so I might as well be wrong.

Edit #2: (1 / (rate / 100000)) * rps * 16 seems to yield values that match the periods specified in the PCem code.

Edit #3: Shouldn't period be float or even double, and not int? Because eg. 1.2 MB floppies (500 kbps @ 360 rpm) have a period of 19.2, for example.

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

Re: FredPJ's feature suggestions

Post by SarahWalker » Wed 11 Nov, 2015 6:42 pm

Edit: You calculate bitcell period as (1 / rate) / (rpm / 60), but shouldn't it actually be (1 / rate) * (rpm / 60)? Because with the formula you used, the unit we end up with is seconds squared per revolution, and a longer period for 300 rpm than 360, while with mine, the unit is revolution, and the period is longer for 360 rpm (which is consistent with the fact that at 360 rpm, the individual bit cells are spaced more than at 300 rpm).
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!
Battler wrote:Yeah, you're indeed right, my point is just that what the FDC/drive combination would expect, depends on:
- State of the DENSEL pin, which depends on data rate, RWC, and DENSEL;
- The data rate itself;
- How the selected drive type interprets the set combination of the DENSEL and data rate pins;
- The format of the inserted image (because if that's not in a format the selected drive type supports, it will always return "sector not found").

Hence why all the stuff is needed in fdc_checkrate().
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?
Edit #2: (1 / (rate / 100000)) * rps * 16 seems to yield values that match the periods specified in the PCem code.
It's entirely likely that the periods in the existing code aren't correct. The *16 is because currently PCem is calculating byte period, rather than bitcell period.
Edit #3: Shouldn't period be float or even double, and not int? Because eg. 1.2 MB floppies (500 kbps @ 360 rpm) have a period of 19.2, for example.
Fixed point will probably be better, as that's what the timer routines already use.

Post Reply