Introduction && issue with Floppy

Discussion of development and patch submission.
Post Reply
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Introduction && issue with Floppy

Post by waltje »

Hi All,

Quick intro: I have been in software and hardware development since, oh, 1985 or so, and now that I am semi-retired,
can finally spend some time on projects that I never had the time for, and which need cleaning up. Its that horrible,
nasty feeling that you did not fully "close" a project, and you feel you must :P

Anyway. I have been deeply involved with the development of Minix, and, later on, Linux in its early years, and one
of those 'unfinished projects' was my Minix system. It ran on a 286/20 clone, and after three disk crashes in a row,
I gave up, switched to a new 386DX25 board with two new Conner 80MB drives, and started on Linux.

In early 1991 I was able to salvage big chucks of those crashed disks, and saved the data. In 2004 I was able to do
a restoreation onto an old laptop (adding in an IDE driver and SCSI driver while at it) and then ran out of time.

When moving to the U.S. I had to dump all my old PC stuff, so dont have any more of that here.

However... PCem to the rescue! I was able to set up a 286 clone machine that sorta mathed the system I had, and
I was able to restore my Minix system on it. I then upgraded to the 386SX clone which worked mostly well once I
updated its BIOS with the one distributed for 86Box - the one I had for PCem did not write parameters to the hard
disk, and so DOS kept seeing my 80MB drive as a 325 drive. Hint: that wont work ;-)

While working on things, I noticed that PCem often has trouble dealing with the diskette images I create, and it
turms out (by reading the relevant parts of the source) that the diskette emulator actually looks at what's in the
BPB on a diskette. That won't work when dealing with non-DOS-ish media.

Is there a reason why we have both a "Diskette A:" and "B" setting in the configuration, __and__ some auto-detect
thing in the actual driver? Would it not be easier to have an "Auto" setting in the configuration(-dialog) to enable
the BPB and/or image-size detection, or, if that is not enabled, just use the settings as per the config value?

Just wondering here,..

I might go and work on the code myself, if I can get myself to installing MinGW. Alternatively, I might see if I
can add a Microsoft C build env setup to the source distrib, and submit that...

(Admin: please let me know if that is useful to the community, and I'll work on that..)

All in all, so far so good with the virtual pee-cee ! :P

Cheers,

Fred N. van Kempen
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Introduction && issue with Floppy

Post by Battler »

While working on things, I noticed that PCem often has trouble dealing with the diskette images I create, and it
turms out (by reading the relevant parts of the source) that the diskette emulator actually looks at what's in the
BPB on a diskette. That won't work when dealing with non-DOS-ish media.
I am the one who made it look at what's in the BPB. If you could upload your disk images, I could see why the emulator is failing to misdetect them. The emulator is supposed to guess based on file size if the BPB is not valid, but there could be cases in which it could think the BPB is valid even when it's not.
Is there a reason why we have both a "Diskette A:" and "B" setting in the configuration, __and__ some auto-detect
thing in the actual driver? Would it not be easier to have an "Auto" setting in the configuration(-dialog) to enable
the BPB and/or image-size detection, or, if that is not enabled, just use the settings as per the config value?
Except drive type and media type are separate. The settings are for drive type, the auto-detection is for media type. This is so on real hardware, too - you can insert a 720 kB floppy into an 1.44 MB drive and it will work just fine.
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: Introduction && issue with Floppy

Post by omarsis81 »

Hi and welcome!
It is always nice to have a programmer around. I hope you can contribute with some code to PCem
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Introduction && issue with Floppy

Post by SarahWalker »

Glad to hear the emulator's been useful! I'm all too familiar with projects that are never quite finished.

Drive configuration - obviously the type of drive, and the format of the disc in the drive are separate issues, hence PCem has configuration of drive type and then some kind of detection for the disc image format. Mostly this is just based on file size, however the BPB handling code was contributed recently to aid handling of IBM XDF formatted discs. If it's causing problems I'm happy to add an option to disable it.

If you want to work on a Visual Studio environment then I'd be happy to add it to the repo.
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Introduction && issue with Floppy

Post by waltje »

@Battler: True, but older systems like Microport SysV/AT, Xenix, etc, etc, Minix, and even early Linux do not use a BPB at all, so its pure "luck" if the current code catches it or not. With empty file systems, this block is all-zeroes, and so the BPB code catches it and uses the image file size. If it's a boot disk, the
data in there may or may not be valid, depending on what we do with the boot sector. Raw archive disks are just "boxes with N data blocks" and so almost never will have a valid BPB.

I just did a specialized version of my bootloader where I sent the sector size to just 0, and, sure enough, the problems went away.

@SarahWalker: yes, that would be a good option, maybe per-drive.

I mostly use PCem with the AMI 486SX clone 'machine' now, in full-screen, and that works fine. Well, in PCem it does, it crashes a horrible death in 86Box, but I'll pm Battler separately about that.

On video card support:

Minix used a horrible (but effective) trick to speed up scrolling the screen. Instead of actually moving data around (copying all lines "up" one line at a time), we used the "video RAM start address" register to "move" our viewport window around, as the video memory usually had more than one page of RAM. This allowed for fast scrolling.

However, this doesn't work in most standard video 'cards' in PCem - most create junk after scrolling begins. OTI VGS works fine, so that is what I am using for now, but would like my Hercules back ;-)

Havent delved into that part of the PCem sources yet, but do the other cards implement multiple pages of video RAM as well as that start-of-ram register?

--fred
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Introduction && issue with Floppy

Post by waltje »

@SarahWalker: I will do some work to see if I can get this to behave on VS. I don't like VS itself, so will mainly work (first) on getting it to compile using the commandline compiler. Once that is done, we can add a VS project setup I guess.
ecksemmess
Posts: 183
Joined: Wed 18 Mar, 2015 5:27 am

Re: Introduction && issue with Floppy

Post by ecksemmess »

waltje wrote:On video card support:

Minix used a horrible (but effective) trick to speed up scrolling the screen. Instead of actually moving data around (copying all lines "up" one line at a time), we used the "video RAM start address" register to "move" our viewport window around, as the video memory usually had more than one page of RAM. This allowed for fast scrolling.

However, this doesn't work in most standard video 'cards' in PCem - most create junk after scrolling begins. OTI VGS works fine, so that is what I am using for now, but would like my Hercules back ;-)

Havent delved into that part of the PCem sources yet, but do the other cards implement multiple pages of video RAM as well as that start-of-ram register?
Just a guess, but last I checked there were still a few semi-obscure registers and features unemulated in the generic (S)VGA code from which most of the video cards inherit. I'm sure Sarah will be along shortly to confirm, but if you want to get started in the meantime that'll be the first thing to check.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Introduction && issue with Floppy

Post by SarahWalker »

Which particular cards are causing issues? My guess would be that wrapping probably isn't implemented correctly on some.
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Introduction && issue with Floppy

Post by waltje »

@SarahWalker: MDA, Hercules and CGA tried, all showed the same-ish behavior. I think I remember the CGA worked "sortof", the others failed to properly "wrap". As said, OTI VGA works. Others not tested.

Also - quick dive into the sources show a lot of GNUism present. Slowly going through the files one by one. Many, many warnings about scalar size reduction assumptions, which (in my book, which was, uhh, "inspired" by both Tanenbaum and Ritchie) is bad. Dunno yet how to fix these without going over the code with a microscope to see why there are so many...
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Introduction && issue with Floppy

Post by SarahWalker »

Rev 662 adds an option to disable the BPB checks.
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Introduction && issue with Floppy

Post by waltje »

Gracias! See PM for more.
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: Introduction && issue with Floppy

Post by vbdasc »

waltje wrote:older systems like Microport SysV/AT, Xenix, etc, etc, Minix, and even early Linux do not use a BPB at all, so its pure "luck" if the current code catches it or not. With empty file systems, this block is all-zeroes, and so the BPB code catches it and uses the image file size. If it's a boot disk, the
data in there may or may not be valid, depending on what we do with the boot sector. Raw archive disks are just "boxes with N data blocks" and so almost never will have a valid BPB.
And MSDOS/PCDOS v1.x have no BPB either, and incidentally some of these systems have problems with floppies too :)
waltje wrote:Minix used a horrible (but effective) trick to speed up scrolling the screen.
Acoording to Michael Abrash's book "Graphics programming black book" this is a beautiful, not horrible, trick :) So, I'd imagine that if Minix has problems with this, then some games would have problems too...
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Introduction && issue with Floppy

Post by waltje »

@vbdasc: well, #1 is now fixed by Sarah - we can turn that smartness off. :P

And on #2 ... yeah, it is, but only if the hardware (or, in this case, emulated hw) cooperates ;-) Those 'cards' work fine, until you scroll the screen. Thats when junk appears, which makes me believe we are scrolling into a region where no actual RAM exists, _OR_ it hasn't been initialized...

Not to worry though... that, too, is on SW's list now.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Introduction && issue with Floppy

Post by SarahWalker »

Wrapping on MDA and Hercules should be fixed on rev 664. It's not clear if the Hercules is supposed to support multiple pages in text mode - if it is the code will need some tweaking. MDA should be fine.
Post Reply