OSDev.org

A happy ending? Someone needs to stir the pot quick.

[By the way Mike, I had a look at the place names in the hangman game source and found another typo near the top: "bueno saires".]

mikegonta wrote: 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.

That's a shame. I wrote some great apps for MikeOS. In the latest version the only assembly calls in the library is for intersegmental memory movement, which isn't needed by any of the major apps. Most of the peeks and pokes are just for library data. I could patch it up you.
Have you actually tried them? I would have though there would be no problem in running them, provided all the peeks and pokes are the proper width and no binaries code is run.

Here's my memory map of the library's data if it helps.

Prochamber wrote:

mikegonta wrote: 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.

That's a shame. I wrote some great apps for MikeOS. In the latest version the only assembly calls in the library is for
intersegmental memory movement, which isn't needed by any of the major apps. Most of the peeks and pokes are
just for library data. I could patch it up you.
Have you actually tried them? I would have though there would be no problem in running them, provided all the peeks
and pokes are the proper width and no binaries code is run.

Hi Joshua,
I see now that main the issue is with PEEKINT and POKEINT, both of which are 32 bit in the MikeOS32 Basic interpreter
and will require the Basic apps which use them to be translated also.

mikegonta wrote:Hi Joshua,
I see now that main the issue is with PEEKINT and POKEINT, both of which are 32 bit in the MikeOS32 Basic interpreter
and will require the Basic apps which use them to be translated also.

Would it not be easier to simply make these commands work with 16-bit data and match the original MikeOS?
I know the name suggests that the width is an integer (platform subjective) but the command was intended to be a word.
Perhaps you could add new commands to peek/poke 32-bit data.

How about translating some of the TachyonOS API? There's a lot of new features such as graphics drawing, mouse support and a new TUI shell.

Prochamber wrote:Would it not be easier to simply make these commands work with 16-bit data and match the original MikeOS? I know the name suggests
that the width is an integer (platform subjective) but the command was intended to be a word.

The translation part is easy and mostly done with a script. The not so easy part is determining if the 16 bit instruction needs to be 16 bit.
The intent is to translate 16 bit to 32 bit.

Perhaps you could add new commands to peek/poke 32-bit data.

The MikeOS32 peekint and pokeint commands are 32 bit. New commands would be needed for 16 bit.

How about translating some of the TachyonOS API? There's a lot of new features such as graphics drawing, mouse support and a new TUI shell.

How about translating TachyonOS to TachyonOS32?

Mike,
Where is aeBIOS actually stored? Is it in the MBR (impossible maybe? since the MBR is only of 512 bytes),
I saw the Kernel image file and found nothing called AEBIOS.BIN?
Also what do you mean by this :

> So... you're saying aeBIOS boots in pmode then switches to real mode
> to run MikeOS?

No, no and no.
aeBios, like the native motherboard BIOS is passive.
aeBIOS does not run MikeOS32.
MikeOS32 runs in PM32 and uses PM32 interrupts. aeBIOS acts as a
transparent BIOS extender.

So you mean all the aeBIOS interrupts are provided by aeBIOS? Wow?
Did you rewrite the whole list BIOS interrupts? Or something else.......
Is aeBIOS open source?