OSDev.org

MikeOS32 is the 16 bit real mode MikeOS translated to run as 32 bit protected mode. [edit: Update new MikeOS website]

Good to see it getting an upgrade.

I've just tried it in Bochs and QEMU. Is it crashing every time I try to run a .bas option in the menu or is it just very slow and I'm not waiting long enough to see it start up? The infinite number of irets in the Bochs log suggests the former, and it does the same if programs are launched from the command line.

Is there a faster way to scroll through Basic and text files when viewing them? PgDn and PgUp do nothing. Also, in the text editor, F3 (New) and F2 (Help) do nothing. The only way I could create a new file was to copy an existing one with a new name (which works, and the copy with a new name survives a reboot), but it would take a lot of time to delete its content.

The keyboard program appears to work, judging by the Bochs log, but I'd need to run it directly instead of in an emulator to hear any sound. I might risk that later.

In hangman.bin (which certainly does work) it misspells Kigali as Kigalo (though that would be the right spelling for it in an Esperanto version of the game).

Looking forward to exploring it further when the bugs are fixed.

[Edit: I can't get MikeOS 4.4 (16 bit version) to run to compare it, perhaps because the image size is 1794K - Bochs and QEMU both refuse to recognise it.]

Edit2: I'd be interested to know how you've gone about porting it to 32-bit mode. Is the 32-bit mode BIOS interface program you link to from your own page a key part of it? Are the apps still running in 16-bit mode or have they been ported too?

Hi David,

Which version of Qemu are you using? I'm running 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) and experience none of the bugs you listed. Same with VirtualBox. Well, except for "Kigalo" -- thanks, nice catch

DavidCooper wrote:Edit: I can't get MikeOS 4.4 (16 bit version) to run to compare it, perhaps because the image size is 1794K - Bochs and QEMU both refuse to recognise it.

I'm not sure where you got that disk image from, but the one supplied in the mikeos-4.4.zip file in the disk_images directory is definitely the right size:
Mike

M-Saunders wrote:Which version of Qemu are you using? I'm running 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4)
and experience none of the bugs you listed. Same with VirtualBox.

Hi Mike,
Most of the problems are with my translation, not the original. As you know I translated the source with a script as
well as some changes by hand to accommodate the 32 bit upgrade. Obviously I missed a few.
However, there is a bug in the source - basic.asm (since 4.3) which somehow didn't make it into the binary
distribution. It did however make it into my translation.It should of course be int 10h.

M-Saunders wrote:I'm running 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) and experience none of the bugs you listed. Same with VirtualBox. Well, except for "Kigalo" -- thanks, nice catch

Sorry - I had selected the wrong image. The right one works fine, now that I'm using it. Looking forward now to trying out more of MikeOS and its apps.

(I'm sure Kigalo isn't the most important thing to fix, but it'll be interesting to see if it ever is corrected given how extremely unimportant it is from the programming point of view).

DavidCooper wrote:

M-Saunders wrote:(I'm sure Kigalo isn't the most important thing to fix, but it'll be interesting to see if it ever is corrected given how extremely unimportant it is from the programming point of view).

It's still wrong though, so I'll make a 4.4.1 release with a couple of other small fixes rolled in. MikeOS still gets around 2,000 downloads per month (despite it not being actively developed at the moment) so I'd rather not leave things languishing, no matter how minor.

Mike

DavidCooper wrote:I've just tried it in Bochs and QEMU. Is it crashing every time I try to run a .bas option in the menu

Hi David,
I've fixed my translation "bugs". The crashing was probably this.
I had to remove the excellent work of Joshua Beck because his Basic language programs contain
"POKE"d real mode code that won't run in PM32. These include calc.bas, draw.bas, memedit.bas and mbpp.bas.

I'd be interested to know how you've gone about porting it to 32-bit mode. Is the 32-bit mode BIOS interface
program you link to from your own page a key part of it?

Yes, aeBIOS makes it possible.

Are the apps still running in 16-bit mode or have they been ported too?

Everything, including the MikeOS "boot sector" is PM32.

mikegonta wrote:I had to remove the excellent work of Joshua Beck because his Basic language programs contain
"POKE"d real mode code that won't run in PM32. These include calc.bas, draw.bas, memedit.bas and mbpp.bas.

What's the problem with using POKE in PM32?
Isn't it enough to implement PEEK/POKE for flat address space + create appropriate page tables?

Nable wrote:

mikegonta wrote:I had to remove the excellent work of Joshua Beck because his Basic language programs contain
"POKE"d real mode code that won't run in PM32. These include calc.bas, draw.bas, memedit.bas and mbpp.bas.

What's the problem with using POKE in PM32?

Hi Nable,
No problem at all - PEEK and POKE work. It's the real mode code that gets "POKE"d that doesn't work in PM32.

Isn't it enough to implement PEEK/POKE for flat address space + create appropriate page tables?

aeBIOS supports paging, but paging has not been enabled for MikeOS32.

I think this thread is really about aeBIOS, with MikeOS32 just being a powerful demo of what aeBIOS can do. It makes it easy to convert a 16-bit OS into a 32-bit OS and may therefore appeal to a lot of people who have built simple real mode operating systems but who don't want to get to grips with things like making mode changes themselves. It's a neat idea (I think Brendan released a similar program a while back, though I forget the details), even though it involves a lot of switching between real and protected modes (which it does it on every interrupt) - while these switches take a lot of clock cycles, they're barely noticeable on today's fast processors. An application running under an OS modified in this way would be able to reach a linear framebuffer and would only need to do a small amount of work to set up a high resolution VESA mode. Ideally code to do this could be added to aeBIOS to make that easier for them too.

Hi David,

DavidCooper wrote:I think this thread is really about aeBIOS,

Not really ... that would be OT.

with MikeOS32 just being a powerful demo of what aeBIOS can do.

Actually, all the power belongs to Mike Saunders and his brilliant MikeOS.
MikeOS32 barely scratches the surface.

It makes it easy to convert a 16-bit OS into a 32-bit OS and may therefore appeal
to a lot of people who have built simple real mode operating systems but who
don't want to get to grips with things like making mode changes themselves.

I've answered your alter ego here.

It's a neat idea (I think Brendan released a similar program a while back, though I
forget the details), even though it involves a lot of switching between real and
protected modes (which it does it on every interrupt) - while these switches take
a lot of clock cycles, they're barely noticeable on today's fast processors.

Now that you have mentioned his name, I am expecting his very knowledgeable and
much respected criticism to fall upon my head.

Hi Mike,

I was just trying to work out what the advantage of MikeOS32 would be over MikeOS given that the latter doesn't need to keep switching mode all the time. To take proper advantage of MikeOS32, it'll need to become a much more complex OS than it currently is. Is that the plan?

Anyway, I just thought the more interesting part of the story here was aeBIOS and I didn't want any OS developer who has got stuck with a real mode OS and who might be skim reading through this thread to miss the point that it could be something worth looking into as a very neat fix to get them into a place where they can get much better use out of the hardware. It's an impressive piece of work which deserves more recognition than your modesty is allowing it. It's also shown me a neater way of interacting with the BIOS than I've been using up to now, so I'll be able to tidy up part of my OS as a result.

DavidCooper wrote:I was just trying to work out what the advantage of MikeOS32 would be over MikeOS given that the latter doesn't need to keep
switching mode all the time. To take proper advantage of MikeOS32, it'll need to become a much more complex OS than it
currently is. Is that the plan?

There is a plan brewing here.

Hi,

DavidCooper wrote:Anyway, I just thought the more interesting part of the story here was aeBIOS and I didn't want any OS developer who has got stuck with a real mode OS and who might be skim reading through this thread to miss the point that it could be something worth looking into as a very neat fix to get them into a place where they can get much better use out of the hardware.

Except it doesn't work like that. Instead of being stuck with "single tasking drivers that only support part of the hardware badly, where doing anything useful with the hardware breaks everything" in real mode; people would just be stuck with "single tasking drivers that only support part of the hardware badly, where doing anything useful with the hardware breaks everything" in protected mode.


Cheers,

Brendan

Brendan wrote:Except it doesn't work like that. Instead of being stuck with "single tasking drivers that only support part of the hardware badly, where doing anything useful with the hardware breaks everything" in real mode; people would just be stuck with "single tasking drivers that only support part of the hardware badly, where doing anything useful with the hardware breaks everything" in protected mode.

Picture the scene. Someone gets the idea in their head that they want to build an app on top of a simple operating system and they happen upon MikeOS. It's a monotasking OS, but that's okay as they aren't interested in running anything else on it at the same time. They develop a little game perhaps with text-mode "graphics", or maybe they switch to an 8-bit colour mode with blocky pixels (which might not be square) or a 4-bit colour mode with smaller pixels (which might not be square). This may have happened long ago, and they've tied themselves to this OS to the point where they'd rather not have to switch to using someone else's.

Having built their game, they then get excited when they hear about MikeOS32 and think it could potentially enable them to use a graphics mode with higher resolution and that better fits the screens of modern machines, but they run up against the ambition lock of the OS designers and find that they would have to try to fight their way round this barrier by reading the VBE3 spec and doing all the hard work themselves. They'd really rather just be able to ask the OS to set up the ideal screen mode for them and then work with the dimensions it returns to their app. They ask the OS developers for help and are informed that MikeOS is a simple OS intended for educational purposes, so it doesn't want to be cluttered up with anything that would unlock the slightly less modest ambitions of some of the app developers who have decided to use it. This is a shame, because it's much more fun playing with a high resolution graphics mode with the right shape of pixels and with 24 or 32-bit colour, and making that easy for the app to access is in no way adding clutter - it's transforming the potential look of the simple apps that run on it by adding a very modest amount of code.

Now, if we suppose that there are a number of simple real mode operating systems out there with a similar ambition lock in place, many of them could be unlocked by adding a binary blob with new functionality which an app can call to bypass that ambition lock. It would be a shame if aeBIOS had its potential killed off by the ambition lock of the OSes it is aimed at enhancing. What aeBIOS really is is an independent operating system component which can be bolted on to give it protected mode capability (although it does also require the OS code to be reassembled to run in 32-bit mode), but it provides only a small advantage (the app would have easier access to memory which may or may not exist and which may or may not be safe to use) while creating some disadvantages (slower interrupts and the need for someone to reassemble the OS to make a new 32-bit version of it every time the real mode version is updated). If the operating system itself isn't going to take full advantage of the new possibilities provided to it by aeBIOS, the way round that would be for other new operating system components to be provided independently in the same way to bypass that problem, and they could potentially be bundled in with or as part of aeBIOS. It isn't only VESA modes that could be made easy for apps to access, but code to set up high definition audio could be provided this way too, and code to load and save files using FAT32 storage, all bypassing any ambition lock of the OS designers.

Sure, it isn't going to turn a simple real-mode OS into a multitasking OS liberated from the BIOS (which will soon be extinct on new machines), but it could still make a substantial difference for a simple app trapped in a simple real-mode OS, at least it could do so until such time as the extinction of the BIOS kills it off. Even then if you get rid of all the ambition lock, there's no reason in principle why an EFI-booted version of the OS couldn't still run its existing 32-bit apps in a machine with no BIOS by using an enhanced version of aeBIOS which does all the work itself directly instead of calling the BIOS, while the OS itself could remain as simple as MikeOS. I'm not suggesting that this is the right way to take things forward, because extinction for all these real mode OSes may be a better future for them, but it does need to be made clear where MikeOS is going so that any app developers who might get sucked into it know if it's worth hanging on in there or if they should bail out. A 32-bit version may only serve to give them false hope of better things to come, while in reality it may be a dead end. This could go either way.