Hi,
DavidCooper wrote:
Wow - that's a radical rewrite done at some speed, and it seems to work perfectly! I'm definitely going to try to build something on top of this, and it'll force me to work in hex which will be a challenge.
Hehe, thanks.
DavidCooper wrote:
I made a mistake in what I said there - I can't use the code in BwtSecOS to save the bootsector itself as it would save it in a state that would prevent the copy from loading, so I'd need to write code in another sector specifically to save the bootsector. I haven't looked to see how you've done things with Selfer, but hopefully you've found a way to avoid this problem.
I save everything important at 0x500 onwards; thus, nothing should be put on disk (and it should be safe to save the bootsector).
DavidCooper wrote:
All the flash drives I've worked with do have a partition on them, the location of the partition being set out in a partition table in the MBR. What I do with them is create a second partition by changing the top of the first partition in the partition table, for example turning a FAT32 partition from 15GiB to 14Gib and then making a partition for my OS at the 14GiB point. I then format the drive in Windows so that the FAT32 partition is adjusted to fit the reduced space. I think Windows simply goes by the partition table in the MBR and the byte that labels it as a FAT32 partition, but I'm going to have to check the BPB values (such as sector count) to make sure it's adjusting everything properly - Windows certainly reports a reduced capacity for the FAT32 partition after the change, but I can't remember now if I checked to see if the BPB values were also changed when I set up my flash drives, so it may be that when the FAT32 partition is full it might overrun into my partition. If that happens, the cure would be to change the BPB values before formatting the drive. I'll check the numbers later and edit the answer to that question here.
...
Because it uses CHS, it would be impossible to use it in a high-altitude partition on a flash drive, so the FAT32 partition would need to be moved to a higher LBA starting point and a second partition (second entry in the partition table) would then be created underneath it. I don't know how big that partition could be, but if the emulated floppy allows more than 80 tracks it may provide plenty of space. As you say though, the user can write their own code to write to disk via LBA, so they can concentrate on developing that code first and liberate themselves from using Selfer's save routines... only it wouldn't be able to load back in from high altitude as it always has to load in on booting via CHS, so they'd still be stuck with using low altitude LBAs.
The best way forward may be to have two versions of Selfer: one loading and saving using CHS (for floppy disks) and the other loading and saving using LBA for flash drives. In BwtSecOS I provided code capable of doing both, but it cost a lot of space and resulted in very limited byte-editing routines, although I also used up a fair bit of space with the decimal/hex mode switch: there's probably no way to fit everything we'd like into a single sector, so every solution is probably going to be a heavy compromise.
Hrm. For that, I'd also need to be aware about the partition table (and which entry I am), and then have some code for int 0x13 extended. I could create another version of Selfer for that, but I suppose everyone would be willing to simply wipe their flash drive clean for Selfer.
DavidCooper wrote:
Code:
; At si * 4 (since every si represents two bytes, i.e. two characters,
; and there are two bytes for each character in display memory) get red color.
shl si, 2
mov dword [es:si], 0x04300430
I think the 04 parts of 04300430 are the red colour, but it's dark red and hard to read. Try 0C300C30 for the brighter red.
I've changed that. I'll probably add it to the Gist with the manual.
DavidCooper wrote:
More importantly though, if I'm reading things correctly, you're loading and saving a single sector for each BIOS call, and you're also doing it backwards. This means that a real floppy disk would have to spin 65 times instead of 4 to load or save everything, and a flash drive would have to save half a megabyte of flash memory 65 times instead of 4, which means 16 times as much wear as is technically necessary. [In order to save a sector, a flash drive has to read half a megabyte, modify 512 bytes of it and write the half megabyte back again.] That could be avoided though by just saving single sectors when they're modified, so it's actually workable just so long as the user understands the risks and avoids using F5 wherever possible. There are no problems with it at all when using a disk image in an emulator, of course, which is the way most people would use it.
Yes. For reading multiple sectors, there are a lot of hassles involved (e.g., only read sectors in one track; try to read single sector if contiguous fails). Mine would be a bit slower, but it's guaranteed to work. Obviously, F4 has been provided so that an actual floppy user can avoid writing the entire floppy every time.
DavidCooper wrote:
And here's the tool, adapted from Machine Editor in my own OS. Put this in the second sector and boot Selfer:-
Code:
90 B8 00 00 8E C0 8E D8 66 B8 56 42 45 32 66 A3 00 80 B8 00 4F BF 00 80 06 1E CD 10 1F 07 66 A1 00 80 66 3D 56 45 53 41 74 01 C3 FC BE 0E 80 AD 50 AD 8E D8 5E BF 00 82 B9 00 02 B8 00 00 8E C0 F3 A4 B8 00 00 8E D8 90 BE 00 82 BF 00 84 AD 3D FF FF 75 01 C3 91 B8 01 4F 56 57 06 1E CD 10 1F 07 5F 5E B8 00 02 03 F8 EB E4
What it does is collect VESA tables to let you explore them before you try to write code to handle their content. Use the down-cursor key to scroll through them. At 8000h we have the table returned by function 4F00h int 10h. At 8200 we have a copy of the mode list, just in case the BIOS put it somewhere where Selfer can't view it. [The location where the mode list was actually put by the BIOS is found at the address and segment stated at byte 0E of the table loaded to 8000h, and on my one of my old 486s (neither work any more so I can't check) I think it was put somewhere in the screen memory area which Selfer can't reach.] From 8400 onwards we have the tables returned by function 4F01h int 10h, one for each mode in the list.
Really neat. I think I'd use something similar with Selfer, to grab off the EDID data from my older monitor (since I wanted to do that for some experimentation).
Anyway, it's nice to see one of my project reaching most of it's goals. I'm particularly happy with what all I've been able to achieve with Selfer, given the fact that I doubted I'd even fit half of it in 512 bytes in the first place.
Regards,
Shikhin