MSB-OS disk image available (now with hex mode)

[DavidCooper]

Disk image available here: http://www.magicschoolbook.com/computing/os-project.

This is the OS written entirely in machine code without using assembler which I announced about a month back. It's far from complete, but if you want a look at my weird programming system you now can, just so long as you have an old machine such as a 486 with an internal floppy drive, and so long as you're willing to risk blowing it up - mine's just expired, but I've been using my OS on it for years without any problems, so I think a power spike probably killed it (brought on by the bad weather). I've just tried the OS in Bochs and it doesn't load - it looks as if Bochs can't deal with non-DMA mode. I wouldn't try running it directly on anything other than a 486 because it usually fails to load, although it has been run on a very old Pentium desktop machine in the past.

I'm going to work on a new version using the BIOS to load it in a more conventional manner, but it'll be a while before that's available because I currently have no machine to work on.

[Edit - new version now works in Bochs and may just work directly on any PC too.]

[Edit on 28 June: Hex mode added, so you can now choose to work in decimals or hex.]

[Combuster]

Sounds you have a nice list of things to fix already. Why would we test it if it is most likely to just not work?

Apart from the fact that very, very few people keep old hardware around.

[DavidCooper]

I'm not asking anyone to test it - just making it available for the curious, as promised. If you aren't keen enough to dive in now, I will make sure that the next version will work with Bochs, but you will have to wait as I may have to rebuild everything from a much more primitive version which I did adapt to load using the BIOS long ago just in case my 486 stopped working, but the problem there is that I never got round to programming it to be able to save anything back to disk, so all the work to enable that will need to be done in a single programming session.

[Casm]

Disk image available here: http://www.magicschoolbook.com/computing/os-project.

This is the OS written entirely in machine code without using assembler which I announced about a month back. It's far from complete, but if you want a look at my weird programming system you now can, just so long as you have an old machine such as a 486 with an internal floppy drive, and so long as you're willing to risk blowing it up - mine's just expired, but I've been using my OS on it for years without any problems, so I think a power spike probably killed it (brought on by the bad weather). I've just tried the OS in Bochs and it doesn't load - it looks as if Bochs can't deal with non-DMA mode. I wouldn't try running it directly on anything other than a 486 because it usually fails to load, although it has been run on a very old Pentium desktop machine in the past.

I'm going to work on a new version using the BIOS to load it in a more conventional manner, but it'll be a while before that's available because I currently have no machine to work on.

I just might buy an operating system coded entirely in assembly language, but I seriously doubt the sanity of anybody who codes directly in machine code.

[DavidCooper]

I just might buy an operating system coded entirely in assembly language, but I seriously doubt the sanity of anybody who codes directly in machine code.

It's easier to work with machine code than assembler: the trick is to display everything in decimal form (which is massively more readable than hex) and index the code so that it can be updated automatically to run wherever it ends up after being moved around during an edit. I find indexed machine code programming easier than using a programming language too, so if you have an old 486 gathering dust in the attic, why not give it something fun to do and see for yourself how easy machine code can be to work with? My OS also makes program code look beautiful - it's a bit like a computer with a transparent case and pretty lights inside, only in this case it shows you the code in glowing colours while it runs.

[Casm]

I just might buy an operating system coded entirely in assembly language, but I seriously doubt the sanity of anybody who codes directly in machine code.

It's easier to work with machine code than assembler: the trick is to display everything in decimal form (which is massively more readable than hex) and index the code so that it can be updated automatically to run wherever it ends up after being moved around during an edit. I find indexed machine code programming easier than using a programming language too, so if you have an old 486 gathering dust in the attic, why not give it something fun to do and see for yourself how easy machine code can be to work with? My OS also makes program code look beautiful - it's a bit like a computer with a transparent case and pretty lights inside, only in this case it shows you the code in glowing colours while it runs.

The only time I have needed to worry about machine code was when I was writing a disassembler for a debugger, and, as I remember it, coding even the simplest machine code instruction required careful observation of which bits did and didn't need setting in order to achieve the desired effect. Bit flipping is a pain in hex; I think it would be even worse in decimal.

[DavidCooper]

The only time I have needed to worry about machine code was when I was writing a disassembler for a debugger, and, as I remember it, coding even the simplest machine code instruction required careful observation of which bits did and didn't need setting in order to achieve the desired effect. Bit flipping is a pain in hex; I think it would be even worse in decimal.

Then you have a seriously warped view of what machine code is - I don't do any bit flipping. If you read a processor manual you might get the idea that you would have to do that, but the reality is that you can just learn a couple of dozen numbers for the most important instructions and you can easily work out most of the rest just by adding on a number between 1 and 7 (inclusive). Within a couple of days of programming in this way, you memorise all those too and don't need to do the adding any more. The biggest challenge is the oorrrmmm bytes, but even they can be done simply by learning a few important ones and adding numbers from 1 to 7 or multiples of 8, and again you soon memorise them. That work's a small price to pay for getting a proper view of what you're doing - I've tried using assembler and it's a veritable nightmare by comparison.

[DavidCooper]

Thanks! Glad that partcopy worked, I'll check it out as soon as I have time (hopefully it's sooner than 2011).

Thanks for your help in getting me this far, but I couldn't actually get partcopy to work on my machine at all - just a subliminal glimpse of a black box on the screen every time and it was gone. Maybe I wasn't using it the right way, but I decided to try rawwrite and it worked straight away.

The cold weather seems to have killed my old Pentium laptop too now - it won't boot up at all, and it's the only other machine I have with an internal floppy drive that can load any version of my OS (a primitive version that uses the BIOS to load everything in but which can't then save anything back to disk).

WARNING: If you do try running my OS in its current form on a 486 (or any other kind of machine that isn't simulating a PC), keep an eye on the address in the bottom left corner of the screen when scrolling through memory with Machine Editor and try to avoid going into any areas of memory-mapped ports just in case it does some harm by reading them all. Long ago I occasionally scrolled through the area above the VGA's screen memory zone from 0 12 0 0 to 0 16 0 0 without any evident problems (on more than one machine), but that doesn't mean it's safe to do so on all machines. I was going to modify the display routine to stop reading memory in that area as a precaution, and also in the 15 to 16MB area (0 240 0 0 to 1 0 0 0, but my 486 went wrong before I was able to finish all the work I'd wanted to do before making the disk image available.

[Edit: new version no longer reads addresses in those danger zones, so the problem's gone]

I should also point out that there's a hardware bug on both the 486s I've used with my OS which makes them crash after anything from seven to nine minutes if you don't press a key during that time while the interrupts are disabled. To avoid that happening while you're away from the machine, you can either load the intr.os0 file and run the code in it starting with the byte labelled as "i on", or alternatively you can just use a weight to hold one of the keys down.

[CelestialMechanic]

Has anybody here downloaded the image and tried it? I have, and it doesn't work. Running it in Bochs gives a non-bootable floppy fatal error. Examination with a hex editor reveals that it does not have the boot sector signature at 01FEH. The code (such as it is) just rambles on through that point. No surprise that it doesn't boot. Mr. Cooper, have you actually tested your image file in an emulator or on a real machine?

I will reserve comment on the coding until I can see something from this project that actually works.

[DavidCooper]

It's very steampunk style, you know.

Is that good, bad or neither? And does that mean you've got it to work, or are you just looking at the code as hex? If you have got it running, don't press F1 until after you've pressed F11 - some change I've made in the last few days now causes a crash if you do F1 before F11 because of some synchronisation issue between different OS modules which is only sorted out after the F11 code has run.

Good news, by the way: I've managed to get my 486 working again by draining the NiMH battery for the CMOS RAM, and I've also got a primitive version of my OS working with Bochs - it loads using the BIOS instead of using my DMA-&-interrupts-off disk reading code. I'm now going to bolt the BIOS-load code onto the more up to date version of my OS so that it will work with Bochs too, so hopefully that should be available for everyone to try in a week or two (it isn't as simple as just bolting that code on because it only loads two modules and leaves you with something that crashes at the drop of a hat if you don't know which keys not to press).

Has anybody here downloaded the image and tried it? I have, and it doesn't work. Running it in Bochs gives a non-bootable floppy fatal error. Examination with a hex editor reveals that it does not have the boot sector signature at 01FEH. The code (such as it is) just rambles on through that point. No surprise that it doesn't boot. Mr. Cooper, have you actually tested your image file in an emulator or on a real machine?

I will reserve comment on the coding until I can see something from this project that actually works.

I wrote it at a time when I had to rely on trial-and-error to get a lot of things done, and I didn't know that the two bytes at the end of the boot sector were important - I have four machines which just ignore them and boot regardless, though later machines may be more fussy in that regard. You can actually set Bochs to boot despite the lack of signature by editing the "disk and boot options" and then hunting for "boot options" using the arrows to the right of all the "ATA channel"s), but it won't get you much further as it soon runs into Bochs being unable to handle the DMA being turned off. The log will show you that it exits with the processor in protected mode, and that happens because the code in the boot sector immediately loads a GDT and switches to 32-bit mode before loading the OS using an FDC device driver which sits in the boot sector. It works fine on a 486 and at least one early Pentium desktop machine. There is some self-modifying code in there, so that may be causing some sort of problem on later machines with a cache not being updated before the modified code is run. My original plan was not to use the BIOS for anything other than loading the boot sector, but I'm now abandoning that approach for a number of important reasons.

[Edit: warning removed as new version now available which solves the problems.]

[DavidCooper]

It's now time to explore the idea of Indexed machine code programming properly - you don't need a 486 to run MSB-OS on any more.

It's far from perfect, but a new disk image is now available which will run in Bochs. It looks as if a last-minute modification may have stopped the monitor program from kicking in properly when triggered by a keyboard interrupt (unless it's because of some difference in the netbook I switched to before uploading it to the Web - I'll check that later and try to put it right), so you may not be able to see that in action at the moment - it normally allows you to watch the code that's running through the processor at any time just by holding down the Esc key and pressing the # key, and because all the code is indexed such that there is a name attached to each routine, it makes it dead easy to debug a freeze as you can identify the code easily and quickly isolate whatever it is that's keeping it trapped in a loop. Anyway, I hope you have fun exploring the OS none the less as there's plenty else to see.

[Edit: I've fixed it and replaced the disk image, so download it again if you've already downloaded it before reading these words. I've also set it to load a lot faster on a slower machine by modifying a delay loop involved in timing the speed of the processor by watching the system timer variable changing in the BDA - Bochs doesn't appear to update it at all, so I added a bit of extra code some time back to escape from what would otherwise be an infinite loop, and while it only took a second on a powerful machine, it took ten seconds on my netbook. Now it'll get out ten times as quickly if it's running in Bochs.]

[Karlosoft]

Ok it's a bit late... but I couldn't post my report

The best thing of this os is that it gives you a different way to consider programming. I'm following your tutorial (It's very long can I ask you how much time did you spend to write it? ) in order to understand how to use MSB-OS... I can say that it is simply powerfull O_o
I still have lots of problem, it's pretty hard to remember how to use the machine editor, but the possibily to change context (from the guite to the editor keeping the current position) helps a lot ^_^.
Is it possible to print the documentation? I mean do you let do this? I'd like to read it on paper

[DavidCooper]

I'm following your tutorial (It's very long can I ask you how much time did you spend to write it? ) in order to understand how to use MSB-OS... I can say that it is simply powerfull O_o

Thanks for taking the time to try out the tutorial. I wrote most of it so long ago that I can't remember how long it took, but it was probably something like a couple of weeks work (for MAN1), plus the same again in numerous re-edits over the years. There are some new chapters documenting much more of the code which will appear soon, filling in all the most important gaps, along with a slightly improved version of the OS (which will work properly on a wider range of machines).

I still have lots of problem, it's pretty hard to remember how to use the machine editor, but the possibily to change context (from the guide to the editor keeping the current position) helps a lot ^_^.

I don't know if any other operating systems let you jump between two apps at the press of a single key like that (Windows comes close with Alt+Tab just so long as you only have two apps open), but maybe someone's been granted a ludicrous patent for it.

Is it possible to print the documentation? I mean do you let do this? I'd like to read it on paper

The OS has no printing capability, although it wouldn't take much code to send bytes through the parallel port to an old printer. I've no idea how to communicate with a newer printer, and USB would be an additional barrier. It should however be possible to copy and paste pages out of it from within Bochs, so I'd better try doing that myself and put the result up on my Web site to save you the trouble - then it should be easy to print out. I'll also write a page for you listing all the Machine Editor functions and the keys they're tied to.

Thanks for the feedback.

[Karlosoft]

I have an old dot-matrix printer still working that I used for some debugging aims I have already written a driver for this in one of my old os, It would be enjoying to do the same again

[DavidCooper]

There's a bit of a snag with Bochs - it keeps crashing and closing when trying to copy the screen, giving only one successful attempt each time. Even so, it'll still be the quickest way to make a printable version of the manual.

I have an old dot-matrix printer still working that I used for some debugging aims I have already written a driver for this in one of my old os, It would be enjoying to do the same again

I don't want you to get diverted into working on my OS instead of your own, but if you are keen to give it a go purely in the course of experimenting with programming with my indexed machine code programming system, I won't try to stop you. I don't know how much work is involved in using a parallel port, but if you need to use interrupts with them there should be a free location in the existing IDT which can simply be linked (using the indexing system) to a new interrupt routine which can be placed in front of "eoc".

If you add code to a code cell (such as the interrupts module), you can save the modified cell by using the F2 menu and selecting the file to be saved - no safety net is provided, so if you highlight an entry and press Return it will instantly save it. If you add code to a Machine Editor cell, you must save that modified cell either by using S or Shift+S (depending on which version of Machine Editor you're using to write the code - it's probably best to create most of the code inside the Mach.Ed1 module just in front of its "eoc" and use the blue version of Machine Editor to write all the code - this is far from ideal, but the linking system currently only works fully automatically with the three main OS modules).

When it comes to printing tx+ format files, they are essentially ASCII text files, but with a few embedded codings which will need to be jumped over. The value 0 is used instead of 32 (20h) for spaces at the end of lines, so every time you find either a 0 or 13 in the file (other than in embedded codings) you can send both a 13 and a 10 to the printer. The tabs aren't proper tabs yet, so they can simply be converted into five spaces.

Anyway, it's entirely up to you whether you really want to try doing it, but if you seriously do want to put time into this I'll be happy to help provide any information you require to make up for any missing documentation, though we'll obviously need to communicate by e-mail rather than annoying everyone by doing it here. Feel free to drop the idea at any time too, because there's absolutely no pressure on you to continue if you start - I don't want you thinking that once you've taken up some of my time you have to keep going no matter what. Your priority must be your own OS, just as mine must be my A.I. work.

[Edit: copying the manual would be best done by copying a whole DOS disk with a single large dummy file on it into memory, then copying the tx+ file(s) in on top of part of the dummy file (within the copy of the disk in memory), and then simply copying the whole thing back to disk. It will then be easy to import it into Notepad and the editing job will be as simple as selecting a single block of text out of it. I'd better write a routine to turn it into a pure txt file first though so that the 0s are turned into 32s. The biggest advantage of doing it this way is that it'll then be extremely easy to repeat the process every time the manual changes. Eventually I'll get round to supporting FAT12 directly and the problem will no longer exist.]

[Edit 2: transfer done - first part of manual now available as Open Office document]