OSDev.org

EA 10 7C 00 00 B0 24 31 DB B4 0E CD 10 F4 EB FD 31 DB 8E D3 BC 00 7C 8E DB 8E C3 9C 58 80 F4 30 50 9D 9C 59 30 EC 84 E4 75 DB FC 88 16 00 05 B0 03 CD 10 B5 26 B4 01 CD 10 31 F6 BD 00 FE 31 FF BB 41 00 E8 54 01 81 ED 00 02 4B 75 F6 80 3E 00 7E 90 75 09 89 EB 81 C3 00 02 E9 AB 00 66 60 06 B8 00 B8 8E C0 31 FF B9 00 02 66 B8 30 0B 30 0F F3 66 AB 89 EB 01 F5 95 C1 E6 02 26 66 C7 04 30 04 30 04 BE 06 0F B9 02 00 E8 4C 01 26 88 14 26 88 74 FE 83 EE 04 C1 E8 08 E2 EE 31 F6 8A 07 E8 36 01 26 88 34 26 88 54 02 43 83 C6 04 81 FE 00 08 72 EA 07 66 61 89 EB 01 F3 30 E4 CD 16 80 FC 4B 75 04 4E E9 9C 00 80 FC 4D 75 04 46 E9 93 00 80 FC 40 75 07 89 1E 01 05 E9 87 00 80 FC 42 75 02 EB 05 80 FC 41 75 1B 8B 3E 01 05 8A 0D 88 0F 80 FC 42 74 07 46 FF 06 01 05 EB 67 4E FF 0E 01 05 EB 60 80 FC 3B 75 08 55 FF D3 5D 31 F6 EB 53 80 FC 3E 75 10 31 FF 47 89 EB C1 EB 09 83 EB 3E E8 77 00 EB 3E 80 FC 3F 75 17 55 BD 00 FE 31 FF 47 BB 41 00 E8 63 00 81 ED 00 02 4B 75 F6 5D EB 22 80 FC 50 75 0C 81 FD 00 FE 74 17 81 C5 00 02 EB 11 80 FC 48 75 13 81 FD 00 7C 74 06 81 ED 00 02 EB 00 81 E6 FF 01 E9 F3 FE 66 C1 E0 10 CD 16 86 E0 66 C1 E8 08 3C 1B 74 E9 B9 02 00 2C 30 3C 09 76 08 2C 07 3C 0F 76 02 2C 20 86 C4 E2 EE C0 E0 04 C1 E8 04 88 07 46 EB C9 66 60 93 31 F6 89 EB BE 03 00 31 D2 B9 12 00 F7 F1 88 D1 FE C1 88 C6 80 E6 01 D1 E8 88 C5 8A 16 00 05 C1 E7 08 F8 B8 01 02 01 F8 CD 13 73 0C 30 E4 CD 13 4E 75 EF B0 40 E9 32 FE 66 61 C3 0F B6 D0 C1 E2 04 C0 EA 04 B0 02 80 FA 09 7F 05 80 C2 30 EB 03 80 C2 37 86 F2 FE C8 75 ED C3 00 00 00 00 00 00 00 55 AA

• The code now loads the first few sectors from the floppy at 0x7C00 to 0xFFFF. F5 writes these all back to disk. F4 writes the current sector to disk. There is no inter-segment handling, anymore.
• F1 calls the current index. It does a simple call, so you can now return with 0xC3 (ret). Also, you don't need to save/restore BP/SI anymore.
• If the byte at 0x7E00 is 0x90 (nop), then it automatically calls it. Note that the procedure followed here is the same described in the above point.
• F6 behaves like the previous retain (copy). F8 behaves like the previous paste, which I now call move. F7 is paste, since it INCREMENTS both the pointers, as opposed to F8.

DavidCooper wrote:There's also the issue of how to make backups. Ideally you should be able to do so without using another operating system, so if you're using floppy disks you should simply be able to switch disks and press w to create a perfect copy. BwtSecOS also fails at the moment in that regard as it would save everything except the bootsector, so new code would need to be written by the user to save the bootsector (though that would be a simple matter of creating a block of seven bytes to define what's to be saved and where it's to be saved to before calling the existing save routine in the bootsector.)

DavidCooper wrote:If working from flash drives things become more problematic as some BIOSes may only support one flash drive such that it's the only place you can save the OS from within the OS. This is why being able to save through LBA to a partition is important: you would be able to edit the LBA start location before pressing w to save a copy to a new location in the partition, so if the main version got into an unrecoverable mess, the bootsector could still edit itself and change the start LBA, and then it could jump to its own first byte to load in an undamaged copy from another location in the partition. This would allow you to store thousands of copies on the same flash drive as you develop your OS and to backtrack to a stable version whenever a problem turns up.

Shikhin wrote:

• I still have 7 bytes to spare, and maybe I can remove back any dependence on function keys, if you've got some other cool idea. I hope I've done everything you described in your last but one post. A manual, describing the location of everything important, would be written, as soon as we figure out which one should be the final version.

DavidCooper wrote:There's also the issue of how to make backups. Ideally you should be able to do so without using another operating system, so if you're using floppy disks you should simply be able to switch disks and press w to create a perfect copy. BwtSecOS also fails at the moment in that regard as it would save everything except the bootsector, so new code would need to be written by the user to save the bootsector (though that would be a simple matter of creating a block of seven bytes to define what's to be saved and where it's to be saved to before calling the existing save routine in the bootsector.)

For floppies, I suppose you could simply switch them, yes.

I don't think anyone has a partition on a typical flash drive. You could, however, save it in different LBAs inside the flash drive via changing one value in the EventLoop.Write/EvenLoop.Save functions. I'll add that to the manual, obviously. Also, note that you can probably create a more "terse" backup system in the second sector yourself!

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.

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.

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.

DavidCooper wrote:

Code: Select all

    ; 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.

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.

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: Select all

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.

EA 0F 7C 00 00 B0 24 31 DB B4 0E CD 10 EB FE 31 DB 8E D3 BC 00 7C 8E DB 8E C3 9C 58 80 F4 30 50 9D 9C 59 31 C8 84 E4 75 DC FC 88 16 00 05 B0 03 CD 10 B5 26 B4 01 CD 10 31 F6 BD 00 FE 31 FF BB 41 00 E8 5B 01 81 ED 00 02 4B 75 F6 89 EB 80 C7 02 80 3E 00 7E 90 0F 84 BC 00 66 60 06 B8 00 B8 8E C0 31 FF B9 00 02 66 B8 30 0B 30 0F F3 66 AB 89 EB 01 F5 95 C1 E6 02 26 66 C7 04 30 0C 30 0C BE 06 0F B9 02 00 E8 55 01 26 88 14 26 88 74 FE 83 EE 04 C1 E8 08 E2 EE 31 F6 8A 07 E8 3F 01 26 88 34 26 88 54 02 43 83 C6 04 81 FE 00 08 72 EA 07 66 61 30 E4 CD 16 89 EB 01 F3 80 FC 4B 75 04 4E E9 AB 00 80 FC 4D 75 04 46 E9 A2 00 80 FC 50 75 06 83 C6 28 E9 97 00 80 FC 48 75 06 83 EE 28 E9 8C 00 3C 6B 75 07 89 1E 01 05 E9 81 00 3C 6D 75 02 EB 04 3C 70 75 1A 8B 3E 01 05 8A 0D 88 0F 3C 6D 74 07 46 FF 06 01 05 EB 64 4E FF 0E 01 05 EB 5D 3C 72 75 0C 55 56 1E 06 FF D3 07 1F 5E 5D EB 4D 3C 73 75 0E 31 FF 47 C1 EB 09 83 EB 3E E8 6E 00 EB 3B 3C 77 75 17 55 BD 00 FE 31 FF 47 BB 41 00 E8 5B 00 81 ED 00 02 4B 75 F6 5D EB 20 3C 78 75 0C 81 FD 00 FE 74 16 81 C5 00 02 EB 10 3C 7A 75 13 90 90 81 FD 00 7C 74 04 81 ED 00 02 81 E6 FF 01 E9 E4 FE 66 C1 E0 10 CD 16 86 E0 66 C1 E8 08 3C 1B 74 E9 B9 02 00 2C 30 3C 09 76 02 2C 07 86 C4 E2 F4 C0 E0 04 C1 E8 04 88 07 46 EB CF 66 60 93 31 F6 89 EB BE 03 00 31 D2 B9 12 00 F7 F1 88 D1 FE C1 88 C6 80 E6 01 D1 E8 88 C5 8A 16 00 05 C1 E7 08 F8 B8 01 02 01 F8 CD 13 73 0C 30 E4 CD 13 4E 75 EF B0 40 E9 2C FE 66 61 C3 0F B6 D0 C1 E2 04 C0 EA 04 B0 02 80 FA 09 7F 05 80 C2 30 EB 03 80 C2 37 86 F2 FE C8 75 ED C3 00 55 AA

• Previous sector is now via 'z', while next sector is accessed via 'x'. Run is 'r', retain is 'k', move is 'm' and paste is 'p'. 's' saves the current sector; 'w' writes all of them.
• I simplified some code in the Input hex thingy. The way I see it, smaller case should've stopped working. However, it still works (which is mildy funny). I suppose it's some side-effect of the way I convert ASCII to hex. I'll go through it via the Bochs debugger anyway, just to ensure I don't introduce any bugs.
• The down key moves 40 bytes ahead. The up key 40 bytes before. The problem is that this fails at the last line, since it's not exactly 40 bytes, and it moves a little more ahead. I hope everyone can bear with that.

DavidCooper wrote:Having worked with it for a while I can tell you a few of the things that could be better but are probably impossible to improve given the limitations of space. Not having the ability to move the cursor up and down the screen means it takes a long time to get it where you want it. To fix that would probably need too much extra code, so I doubt it can be done without losing other functionality.

DavidCooper wrote:Something that might be possible to fix is the cursor position after using F1 - it jumps back to the start of the sector instead of staying where it was when F1 was pressed.

There is something that's very easy to fix though, and that's the crash that happens if the code you run with F1 changes DS - a push and pop around the call would fix that. And I've just tested ES - i see that it causes a freeze on ret if it's been changed, so that's two pushes and two pops required.

DavidCooper wrote:Realistically though, while we've both shown that one sector is enough for a self-contained development system to continue to build itself and an OS, it would actually be better to use two sectors and make something that's good enough for the user to be happy to go on using its display & edit routines for some time rather than immediately feeling the need to write something better to replace them. Rather than going on polishing something that will always be an unfortunate compromise, it might be better to build a 1KB system, although that could still be done by starting with a single-sector system which can be used to modify itself to turn it into a more polished 1KB development system. It might be possible to write everything in such a way that extra functionality can be patched into the first sector from the second to remove all the major deficiencies while still depending on the original routines, and the code in the third sector can then be run automatically if there's a nop in its first byte, just as happens with the first byte of the second sector already.

DavidCooper wrote:With BwtSecOS I was able to patch in new code to allow vertical cursor movement, or rather the equivalent of it as the cursor actually stayed where it was while everything else moved, but the display & edit code works in such an uncomfortable way (for experimental artistic reasons) that it would need complete replacement. The trick would be to write code that can still go on being used while the functionality is enhanced, and the challenge would be to minimise the amount of dead code in the bootsector once the enhancements have been added - ideally all of it should continue to be useful.

Shikhin wrote:I've ... added your extension as a comment (on the Gist page, not in Selfer.asm).

[*]I simplified some code in the Input hex thingy. The way I see it, smaller case should've stopped working. However, it still works (which is mildy funny). I suppose it's some side-effect of the way I convert ASCII to hex. I'll go through it via the Bochs debugger anyway, just to ensure I don't introduce any bugs.

[*]The down key moves 40 bytes ahead. The up key 40 bytes before. The problem is that this fails at the last line, since it's not exactly 40 bytes, and it moves a little more ahead. I hope everyone can bear with that. [/list]

I also added two consecutive NOPs in the code, which are preceded by a (short) jmp. The purpose of this is that you can replace these bytes with a jump to your own code, which can add additional input parsing. For example, you can test for a key like 'i', which can enable or disable interrupts. Of course, you got to jump back from your code to where the short jmp was supposed to jump. I'll detail this in the manual, if this is the last version.

Let's just celebrate the fact that Selfer has achieved most of what we planned, anyway.

Oh, and if you want to send in some donations, I'd be willing to accept! </shameless-plug>

EDIT: It appears as if the Hexadecimal Input code accepts both upper and lower case as a side effect of the way it converts it. Woot!

DavidCooper wrote:I don't know how you managed it, but you've found yet room for functionality that I thought wouldn't fit. We both missed something though, and this is more good news - the BIOS can do some more of work for you. When you had < and > functions, I noticed that they only worked if you held the shift key down. I now notice that the functions tied to various letter keys don't work if you hold the shift key down, and in the source code I can see that you used lower case. It looks as if the protection against accidental presses of these keys can be obtained simply by changing them to capital letters in the source so that a shift key has to be used with them, so this is far better than putting them on the F1-F12 keys. No protection needed on z and x, of course, and k probably doesn't need it either.

DavidCooper wrote:

Shikhin wrote:I've ... added your extension as a comment (on the Gist page, not in Selfer.asm).

I'd like to improve it a bit as I was being very lazy when I wrote it, using hex numbers I already knew rather than working out others which would have been more direct. Also, because you've removed the freeze/crash on ret if DS/ES modified problem, I can cut my code down further.

DavidCooper wrote:

I also added two consecutive NOPs in the code, which are preceded by a (short) jmp. The purpose of this is that you can replace these bytes with a jump to your own code, which can add additional input parsing. For example, you can test for a key like 'i', which can enable or disable interrupts. Of course, you got to jump back from your code to where the short jmp was supposed to jump. I'll detail this in the manual, if this is the last version.

That's good, but I'm wondering if it might be better to put the nops at the start of .Input - I think that would allow the user to add code not only to test for other key presses, but also to eliminate all the unused keys that might lead to accidental modifications of bytes.

DavidCooper wrote:

Let's just celebrate the fact that Selfer has achieved most of what we planned, anyway.

Indeed - it's looking very good now. I'd still like it to be able to boot from a high partition and to write everything in four BIOS calls so that it can be used elegantly on flash drives, but that is asking too much as a lot of functionality would need to be moved out of the bootsector and then rebuilt in the second sector. Maybe an alternative version of Selfer which doesn't work on floppy disks could solve that problem though while keeping everything else in the bootsector - having two versions would be a reasonable compromise, and floppies are sufficiently obsolete that any user working from a flash drive (if they want to work directly on real hardware rather than within an emulator) probably wouldn't care if their code can't be run from a floppy disk any more than they'd like it to be run from paper tape with holes punched in it. Optical disks aren't too attractive either, so the most important place to be is on something that behaves like a hard drive.

EA 0F 7C 00 00 B0 24 31 DB B4 0E CD 10 EB FE B4 41 BB AA 55 CD 13 72 ED 31 C0 8E D0 BC 00 7C FC 66 8B 4C 08 8E D8 88 16 00 05 66 89 0E 02 05 B0 03 CD 10 B5 26 B4 01 CD 10 31 F6 BD 00 FE 31 FF BB 41 00 E8 59 01 81 ED 00 02 4B 75 F6 89 EB 80 C7 02 80 3E 00 7E 90 0F 84 BA 00 66 60 B8 00 B8 8E C0 31 FF B9 00 02 66 B8 30 0B 30 0F F3 66 AB 89 EB 01 F5 95 C1 E6 02 26 66 C7 04 30 0C 30 0C BE 06 0F B9 02 00 E8 4F 01 26 88 14 26 88 74 FE 83 EE 04 C1 E8 08 E2 EE 31 F6 8A 07 E8 39 01 26 88 34 26 88 54 02 43 83 C6 04 81 FE 00 08 72 EA 66 61 30 E4 CD 16 89 EB 01 F3 80 FC 4B 75 04 4E E9 AB 00 80 FC 4D 75 04 46 E9 A2 00 80 FC 50 75 06 83 C6 28 E9 97 00 80 FC 48 75 06 83 EE 28 E9 8C 00 3C 6B 75 07 89 1E 01 05 E9 81 00 3C 6D 75 02 EB 04 3C 70 75 1A 8B 3E 01 05 8A 0D 88 0F 3C 6D 74 07 46 FF 06 01 05 EB 64 4E FF 0E 01 05 EB 5D 3C 72 75 0C 55 56 1E 06 FF D3 07 1F 5E 5D EB 4D 3C 73 75 0E 31 FF 47 C1 EB 09 83 EB 3E E8 6E 00 EB 3B 3C 77 75 17 55 BD 00 FE 31 FF 47 BB 41 00 E8 5B 00 81 ED 00 02 4B 75 F6 5D EB 20 3C 78 75 0C 81 FD 00 FE 74 16 81 C5 00 02 EB 10 3C 7A 75 13 90 90 81 FD 00 7C 74 04 81 ED 00 02 81 E6 FF 01 E9 E6 FE 66 C1 E0 10 CD 16 86 E0 66 C1 E8 08 3C 1B 74 E9 B9 02 00 2C 30 3C 09 76 02 2C 07 86 C4 E2 F4 C0 E0 04 C1 E8 04 88 07 46 EB CF 66 60 BE 06 05 66 31 C9 66 89 4C 04 66 89 4C 0C 66 C7 04 10 00 01 00 66 03 5C FC 89 6C 04 66 89 5C 08 C1 E7 08 B4 42 01 F8 8A 16 00 05 CD 13 72 03 66 61 C3 B0 40 E9 2F FE 0F B6 D0 C1 E2 04 C0 EA 04 B0 02 80 FA 09 7F 05 80 C2 30 EB 03 80 C2 37 86 F2 FE C8 75 ED C3 00 00 00 00 00 00 00 55 AA 

• It expects to be passed control from a valid and generic MBR, with proper stuff set up.
• It doesn't check for 386 or not, since those bytes were used to instead check if the Int 0x13 extensions are available or not.
• I have 7 bytes left with, so maybe some interesting use can come up with them.

DavidCooper wrote:

Oh, and if you want to send in some donations, I'd be willing to accept! </shameless-plug>

Perhaps I should be asking for 1% of any donations - I hope that doesn't sound too greedy, but I've been spending a lot of time helping a rival to overtake BwtSecOS instead of developing BwtSecOS.

Shikhin wrote:I'm willing to give 49%, since you've put in almost equal effort in Selfer. Of course, 100% of nil is still... nil.

dozniak wrote:

Shikhin wrote:I'm willing to give 49%, since you've put in almost equal effort in Selfer. Of course, 100% of nil is still... nil.

Proper first step would be to convert it from a gist into a proper repository with history.

Shikhin wrote:I find it a little limiting and slow to press shift while working inside Selfer. Moreover, only 's' and 'w' really clash with hexadecimal characters -- those two should cause the minimum damage anyway (unless you save something screwed). Obviously, the final manual would tell you the address of those bytes, so then you can change that yourself.

DavidCooper wrote:

I also added two consecutive NOPs in the code, which are preceded by a (short) jmp. The purpose of this is that you can replace these bytes with a jump to your own code, which can add additional input parsing. For example, you can test for a key like 'i', which can enable or disable interrupts. Of course, you got to jump back from your code to where the short jmp was supposed to jump. I'll detail this in the manual, if this is the last version.

That's good, but I'm wondering if it might be better to put the nops at the start of .Input - I think that would allow the user to add code not only to test for other key presses, but also to eliminate all the unused keys that might lead to accidental modifications of bytes.

D'oh. I miswrote that. That should've been: "Of course, you got to jump back from your code to a specific address which I'll provide in the manual." From there, you can probably just check if input key is not hexadecimal characters at all and if not, you can jump the address I provide, or if it is a valid character, you can jump to "parse input" address. I'll provide the minor details in the manual.

cmp al, 'z'
jne .Input
nop
nop

Oh, I forgot to write this. ...

I'm willing to give 49%, since you've put in almost equal effort in Selfer. Of course, 100% of nil is still... nil.

DavidCooper wrote:It seriously isn't going to slow you down, and if you press m or p by mistake you could change an important byte without noticing. If you press r by mistake it'll typically cause a crash. If you press w by mistake you'll make 65 unnecessary rewrites of the same half megabyte block on a flash drive. These things do need to be guarded against. Even shift+s isn't going to slow you down, so I'd definitely put it on that as well.

DavidCooper wrote:I still think the nops are in the wrong place:-

Code: Select all

cmp al, 'z'
jne .Input
nop
nop

It looks to me as if they'll only ever be run when you press z.

cmp al, 'z'
jne 0x7E00

cmp al, 'i'                      ; Any character here. 
jne EventLoop.Input      ; If not 'i', must be hexadecimal input.

; DO MAGIC HERE.

; Go back to the event loop in Selfer.
jmp EventLoop.Next

DavidCooper wrote:That'll do nicely! I've just put it on a flash drive to test it, but I'm going to post this before I run it and I probably won't be back online till late tomorrow to tell you how it went. I plan to boot it from within my OS, booting it up from a subpartition of the multifloppy partition in which my OS resides (hundreds of different versions sit in different subpartitions, all of them bootable), but I will need to write a little bit of new code to line up ES:DI on a dummy partition table entry before it will work the same way with Selfer. My plan then will be to disable the w function and write new code to save everything in a manner that causes 1/16th as much wear, as well as adding code to modify the LBA stored at 502h so that Selfer too can store multiple versions of itself in different subpartitions.

DavidCooper wrote:Even if it's nil, the percentage of nothing is still crucial. I won't accept more than 10%.

Shikhin wrote:I don't see what's the problem with them remaining as Gists. If you can cite any reason to switch to full fledged git repositories hosted on GitHub, I'd be sure to consider.

dozniak wrote:

Shikhin wrote:I don't see what's the problem with them remaining as Gists. If you can cite any reason to switch to full fledged git repositories hosted on GitHub, I'd be sure to consider.

Many of the gists have 1 revision, even though they are clearly a modifications of a previous one. To see what changed, i have to chase them down, either from the posts here or from a chronological list and run manual diffs, not very handy. E.g. the selfer (extended) could just grow out of normal selfer, either as a branch or a natural development as master, not separate gist.

dozniak wrote:It's also more visible on the main github site and in your profile. Gists are much more hidden.