make bignoboot : No rule to make target 'files/gitignore/288data'

[merinfor2021]

Hi there @prochazkaml ! :smiley: Just got your new message from Suduko check - Issue #10 and I'm happy to see your progress: so many new commits, and also nice plans to backport the new MikeOS features so that MichalOS stays best-of-the-best ! :wink: Well, I just tried to build a "big 2.88MB floppy" (since these are also supported by coreboot+SeaBIOS of my G505S laptop) - but got this problem:

make: *** No rule to make target 'files/gitignore/288data', needed by 'build/images/michalos288.flp'. Stop.

Also happens for make big . Please, could you take a look? Meanwhile I will do a great in-depth test of your latest new MichalOS :hugs:

[prochazkaml]

Hi! For the time being, this 2.88 MB floppy is reserved only for PCMTEST.APP - it is still formatted as a 1.44 MB floppy, but the upper 1.44 MB is used as storage for raw PCM data, which you have to supply yourself (see pcmtest.asm for instructions).

However, this will change in the near future, as I'm planning to completely rewrite the entire disk driver to support drives other than 1.44 MB floppies (among other things, such as FAT16/32 support (as they're basically the same as FAT12), directory support, better file handling routines etc.).

By the way, if you're wondering why there haven't been any commits in the past month, let's just say that I got a "new" toy to play with:

A beautiful little 486 laptop (more specifically, it's a DX4 @ 75 MHz) with 8 MB of RAM and a simple VGA chipset with a (slightly faulty, but usable) 640x480 screen - all in all, the perfect testing hardware for MichalOS. (if you're wondering why there's a piece of metal covering a part of the screen - that's the CPU heatsink, which I had to bend to get to the floppy drive bay 😀)

It's been keeping me busy for the last month, as it didn't come with a hard drive and its floppy drive was broken. Currently, I'm building a floppy drive emulator using fddEMU along with my own custom PCB so that I'll be able to load floppy images from a microSD card and cycle through them with buttons sticking out the floppy drive slot and a few 7-segment displays to see what's being selected.

(yes, those are wires soldered directly to the contacts of a SD to microSD card adapter - you can't get a cheaper microSD card slot than this! 😁)

The PCB already works and the laptop boots just fine into DOS (I've already had a few sessions of Wolfenstein 3D on it (as it just barely fits on a single floppy) and I can't complain, it works great), but to select different floppy images, it has to be controlled over a serial link with another computer. The second step is to build a board with the already mentioned buttons and displays, which will send and receive data over the same serial link, then I'll just have to build a 3D printed case for it, close the whole thing up and finally enjoy it!

One problem with it is: MichalOS doesn't properly boot on it 🙁. It gets past the bootloader fine, but when the kernel is trying to load any files, it fails (because the current disk driver is utter crap - this is one of the reasons I want to just rip it out and write a better one).

So that's where I've been. I'm planning to finish building the floppy drive this year (as one of the school homework I've been assigned with is a "show-and-tell" video about my computer, so I thought it would be great to do it with this one 😁), MichalOS work will follow soon after that!

[merinfor2021]

@prochazkaml Wow, all that looks wonderful, especially your custom DIY board is really awesome! :open_mouth: :+1: Would be nice if you could share the schematics after the completion of your board - that could be a great help if I'd ever try to build a similar device but for the quick switching between the various BIOS images. By the way, it seems such the floppy emulators already exist, just too expensive...

Speaking of 2.88 MB floppy - I understand its' limited use nowadays, just a small report that currently it couldn't be build at all. Maybe a part of Makefile which produces files/gitignore/288data is missing?

[prochazkaml]

Thanks! Of course I'll share the schematics & firmware for both boards when I'm done. I know that such floppy emulators exist, but they usually don't fit into laptops (as those use slim form factor drives with an incompatible connector) and, as you've said, they're way too expensive.

Back to the issue, files/gitignore/288data is a file which you create yourself. The opening text in pcmtest.asm sums it up nicely:

; ------------------------------------------------------------------
; MichalOS PC Speaker PCM Demo
;
; WARNING: This demo uses the top 1.44 MB of a 2.88 MB disk.
; To generate a compatible image, run your favorite song through
; FFmpeg to convert it to a 11025 Hz 8-bit PCM file:
; 
; ffmpeg -i <inputfile> -f u8 -acodec pcm_u8 -ac 1 -ar 11025 <outputfile>
; 
; Then, move the output file to files/gitignore/288data. After that,
; you can generate the 2.88 MB image by running:
; 
; make big
; ------------------------------------------------------------------

At the current time, the upper 1.44 MB of the 2.88 MB floppy is not accessible by the filesystem, if you open the file manager, you'll see that you have the same free space as with a regular 1.44 MB. I added the make big option just for testing PCMTEST.APP, it will have no effect on anything else in the OS.

Of course, when I will be rewriting the disk & filesystem driver, I will make sure that you'll be able to generate a full 2.88 MB (or possibly more, ideal for a HDD) image whose filesystem will utilize all of the space on the drive. But as of now (with the legacy MikeOS disk driver), this is not possible.

Please consider this issue unfixable for the time being, as there's nothing I can do to fix this with the current driver. I added the "bug" label for myself so that I can see later that the Makefile needs to be updated when I'm done writing the new driver, so that it will generate a proper 2.88 MB image.

[merinfor2021]

@prochazkaml Thank you, I understand it now :smiley: By the way, it seems I can't boot the latest MichalOS floppy too - just put it into my G505S's coreboot+SeaBIOS and tried to boot, but it hangs at

Loading MichalOS kernel... OK
Loading FILEMAN.APP

Not sure when this problem came, as it has been a while since my last update...

[prochazkaml]

Well, that's the exact same issue I encountered on my 486 laptop. One more reason to rewrite the disk driver!

[merinfor2021]

@prochazkaml Dear Michal, I wish you lots of happiness in this New Year! Achieve all your goals and may your wishes come true :partying_face:

[prochazkaml]

I wish you a happy New Year as well!

The year's starting off very well for me, as I got the floppy drive emulator working and the laptop can finally be sealed up. Here's how it currently looks like:

It's not 100% finished (the emulator's circuit boards (yes, there are 2 of them now) are held in place with hot glue rather than a solid 3D printed housing, the 3D printed buttons have a tendency to "fall in", the busy/idle indicator is a bit janky etc.), but those are just minor issues. What matters is that it works and it boots into an OS!

I'm definitely looking forward to finally give MichalOS some more care and attention that it deserves!

[prochazkaml]

Quick update - I have written a new low-level disk driver for MichalOS!

The new low level driver now supports the following:

• the drive can be up to 2 TB in size! (that's a BIOS limit, can't get around that, but still, woah)
• support for both CHS (floppies, old HDDs) and LBA ("new" HDDs, supported since ~1995, up to 2 TB) addressing, the driver automatically selects the best one based on the drive present
• automatic change detection - when the driver detects that the disk has been changed (the BIOS keeps track of that for us), it polls the new disk parameters (i.e. when you boot from a 1.44 MB floppy and replace it with a 720 kB one, the driver will recognize that before loading any data from the drive)

I know that this sounds like basic stuff that any OS should support (and you'd be right), but MikeOS (and by extension, current MichalOS) doesn't (as it only supports 1.44 MB floppies, nothing more, nothing less).

I even added a little wrapper routine for the INT 13h call (BIOS call for handling drive access), as some BIOSes erase certain registers, do not set the carry flag properly (which signifies if an error occured) or destroy the upper 16 bits of some 32 bit registers (I remember this being a problem with your BIOS, if I'm not mistaken):

; --------------------------------------------------------------------------
; os_int13 -- Perform a BIOS 13h call with extra precautions
; IN/OUT: depends on function in AH, high 16 bits of all 32-bit registers preserved, carry set if error

os_int13:
    call .roll          ; Some BIOSes destroy (16..31) of all 32 bit regs
    pusha
    clr ax              ; Some BIOSes need the upper word of EAX = 0
    call .roll

    stc             ; Some BIOSes do not set CF on error
    int 13h

    call .roll
    popa
    call .roll
    ret

.roll:
    pushf
    ror eax, 16
    ror ebx, 16
    ror ecx, 16
    ror edx, 16
    ror esi, 16
    ror edi, 16
    ror ebp, 16
    popf
    ret

If I then call this function anywhere in the driver, I can be confident that if a fault occurs, it's very likely to be my fault and not due to a bad BIOS implementation.

So yeah, that's where I'm at. I still have a long road ahead of me, but with enough perseverance, I hope that I'll end up with a working and practical disk driver. Some stuff that still remains to be done are:

• sector caching system (so that disk access isn't painfully slow, especially on floppies, and doesn't lead to unnecessary write cycles, especially a problem with SSDs)
• partition table support (as currently, the drive must be formatted without one - this is almost never the case in the real world)
• input filename parsing with proper path traversal - relative ("../docs/test.txt"), absolute ("fd0:/docs/test.txt" - I'm probably going to label floppy drives as "fdX:/" and hard drives as "hdX:/", what do you think?)
• new filesystem driver and API (yeah, this one's going to hurt)
  • FAT12/16/32 support
  • file handles (so that an application doesn't need to load the whole file into memory when working with it) with standard-ish calls that you might have seen on UNIX (open, close, read, write, seek)
  • directory support (although this won't be as hard, I'll just have to keep track of whether the current directory is the root directory or a directory that needs to be loaded by traversing the FAT)

Yeah, that's going to be a lot of work.

As a side note, I finally ironed out all of the weirdness that plagued my laptop floppy drive. Now, the buttons now do not fall in, the status indicator now works properly and it's held together by a proper 3D printed enclosure, which means I can finally hold it in my own hands without it falling apart!

Do you see it? It's now held together by screws! Screws!

Look at how thin the whole thing is (12.5 mm)! Anyway, I had a lot of fun making it, and after installing it into my laptop and a quick session of Wolfenstein 3D, I can say that it works flawlessly. I'll release the PCB/3D design and firmware (for both boards) soon (now that I know that it works).

[prochazkaml]

Right, so I sort-of bodged the new low-level disk driver into the existing FAT12 FS driver, and the OS boots without problems!

However, we're far from victory. What this means is that while the low-level driver works (and all of the old low-level code has been ripped out), I still need to create a new FS driver from scratch (as this one is still quite crap) as well as all of the fun stuff which I mentioned in my last post.

Also, this new low-level disk driver currently has LBA support disabled, so it can only use the old CHS addressing (which is mainly used for floppies, which are still the main target anyway). The LBA code is in place, all I have to do is to spin up a QEMU VM with a virtual hard disk and check to see if it works, probably do some bugfixes on the way.

I still haven't tested the new driver on my 486 to see if it finally boots on it. It's currently an hour before midnight and I really don't want to wake anyone up, so I look forward to testing it tomorrow. 👍

EDIT: Sadly, it still doesn't, meaning that the FS driver itself is buggy. I know that it isn't due to the low-level disk driver, as the floppy activity LED on the laptop only flashes briefly and then turns off.

[prochazkaml]

SUCCESS!!!

...well, sort of. For some reason, after the OS is booted up and the config file is "saved" (nothing actually saves, not sure whether that's due to a driver error or a quirk in my floppy emulator), it cannot load any new files, meaning that it cannot load anything beyond the File Manager, which is loaded into memory on startup.

And as you can see, it reports bogus information (the kernel is definitely not >200 MB in size). I'll have to investigate this further, but for now, I'm just happy that it boots up at all.

(in case you were wondering, the laptop's BIOS was erasing a certain register that DOSBox didn't, so I preserve it now)

[prochazkaml]

Quick update: the write file routine is somehow broken. If I boot an image which has already passed the Demo Tour, then the OS works without problems (other than the fact that I cannot save anything):

Sweet! (well, except for that saving routine)

In case you were wondering, yes, I'm running the laptop (for testing purposes) from a lab bench power supply:

Under load, this thing draws only ~8 W (meaning that if I build a battery pack, it should last for quite a while). What's better is that this laptop doesn't really care about the input voltage being stable - I can feed it anywhere from 12 to 24 V and it will work without problems.

[merinfor2021]

@prochazkaml Hi there, Michal! Have been away for a while, and you did such a huge progress! ;-) Your DIY floppy emulator looks like a solid hardware now - and also amazing you managed to fit this all in such a narrow height), as well as the filesystem driver advances... Also, the latest MichalOS floppy boots fine and ready for testing - thank you so much for fixing this :D Now this opens a road for a big detailed test - need some time - but for now a couple of problems which I've discovered:

1) [Tiny] During the Intro tour, a part of text containing " the following shortcuts, which can " overlaps the tour schedule shown at upper right part of a screen 2) [Minor, probably reported before] The progress bar at music player is displaying the progress incorrectly 3) [Urgent] If you choose a PWM sound driver (either normal or max volume) and then go to "Polyphonic piano (Adlib)" at PLAYER.APP, then after choosing "how many notes at once" we get a MichalOS fatal error - either division by zero or invalid opcode. Encountered first on a real hardware, but luckily this is reproduce-able with DOSBox too

Hopefully you could find a moment of time to look at "3)", that will be really appreciated. Hope to write more in the near future

[prochazkaml]

Hi, hope you are doing well! Glad to hear from you after such a long time.

I completely forgot that when I introduced OS-breaking changes lately (well, in January) which made the OS unusable, I did not luckily commit them, so I just stashed them for now and the OS appears to work fine. :D

Also, I'm glad that the new disk driver works on your machine! I was a bit worried about that, as your BIOS used to be a bit wonky with INT 13h, but my new wrapper routine appears to have done the trick!

I've just fixed issues 1) and 3) (see the latest 2 commits), I am not sure what is wrong with 2), though. (Is it that some RAD files jump around? I vaguely remember discussing this, but cannot fully remember...)

[merinfor2021]

@prochazkaml regarding 2) , I meant that a progress bar (moving while the song is playing) is supposed to reach the end simultaneously with the song - but in reality a progress bar moves faster and reaches the end / restarts while a song still is going. It doesn't affect the song playback, just pure cosmetics

[merinfor2021]

@prochazkaml A few more bugs found during today's testing on a real hardware ( a virtual floppy in BIOS as usual ;-) ), will be nice if you can check this:

1. Text Editor - when you exit from it, it doesn't ask "Are you sure? All unsaved changes will be lost" confirmation - which it asks if you try to open a different text file
2. Terminal - if you do a "mv ELDREAMS.RAD ELDREAMS2.RAD" command - it will say "File already exists!" (perhaps it truncated ...2.RAD to just .RAD to avoid a long filename) - instead, is should probably say "Illegal filename (longer than X characters)
3. Terminal - when you enter the "ver" command (which is supposed to output the MichalOS version), the only thing you see is " Terminal" word with a leading space
4. Pixel Art Editor: when you enter the fill mode - it always fills the whole picture with a selected color, while the expected behavior is probably to fill only the area which is the same color as the field beneath a cursor (similar to a color fill game)
5. Disk detection test - launching it instantly gives a Fatal Error
6. Memory edit - pressing Insert always gives a Fatal Error (user triggered crash)
7. Dead pixel tester - always freezes for me, pressing Esc doesn't work
8. Cosmic Flight game - it seems impossible to collect the score above 32768, if you do that - you die? I.e. my last try I had 29660 and double modifier enabled, then collected 2 prize but instantly died, final energy score shows as "-31876" :stuck_out_tongue:
9. Asmtris - awesome music but no mute button (or no info about mute button is shown at the game's interface)

[prochazkaml]

@prochazkaml regarding 2) , I meant that a progress bar (moving while the song is playing) is supposed to reach the end simultaneously with the song - but in reality a progress bar moves faster and reaches the end / restarts while a song still is going. It doesn't affect the song playback, just pure cosmetics

Could you please tell me which songs are affected by this issue?

1. Text Editor - when you exit from it, it doesn't ask "Are you sure? All unsaved changes will be lost" confirmation - which it asks if you try to open a different text file

That was a bit of an oversight, thanks for pointing it out!

2. Terminal - if you do a "mv ELDREAMS.RAD ELDREAMS2.RAD" command - it will say "File already exists!" (perhaps it truncated ...2.RAD to just .RAD to avoid a long filename) - instead, is should probably say "Illegal filename (longer than X characters)

The current filesystem driver cannot tell the difference, all it knows it that some error occured.

3. Terminal - when you enter the "ver" command (which is supposed to output the MichalOS version), the only thing you see is " Terminal" word with a leading space

Dumb mistake, was printing the wrong string. 😅

4. Pixel Art Editor: when you enter the fill mode - it always fills the whole picture with a selected color, while the expected behavior is probably to fill only the area which is the same color as the field beneath a cursor (similar to a color fill game)

Nope, this is the intended behavior. Renamed it to "erase mode" to avoid further confusion.

5. Disk detection test - launching it instantly gives a Fatal Error

Fixed, this was a kernel issue - the disk driver was seeing nonexistent drives as valid drives with 0 sectors per track, causing a crash down the line. Fixed.

6. Memory edit - pressing Insert always gives a Fatal Error (user triggered crash)

The Insert key was used by me for intentionally crashing the system while testing. Removed this leftover feature.

7. Dead pixel tester - always freezes for me, pressing Esc doesn't work

Another dumb mistake, I was accidentally writing to program/kernel memory instead of screen memory. Sorry about that!

8. Cosmic Flight game - it seems impossible to collect the score above 32768, if you do that - you die? I.e. my last try I had 29660 and double modifier enabled, then collected 2 prize but instantly died, final energy score shows as "-31876" 😛

The MikeOS BASIC interpreter (which is used in MichalOS) is internally 16 bit can only work with 16 bit signed integers (-32768 to 32767). This is not a bug, just a limitation of the interpreter.

9. Asmtris - awesome music but no mute button (or no info about mute button is shown at the game's interface)

I think I already mentioned this somewhere - you can mute the speaker system-wide with Alt+F2 and Alt+F3 to restore it.

[qmastery16]

@prochazkaml Good day, Michal! Hope you're having a great time :smiley: I just re-tested the latest MichalOS revision 1dc9e80

1. PLAYER.APP - progress bar behaves better now and seems to be correct for the short songs, but it restarts its position each 64 seconds. This could be verified on songs ATOMINO.DRZ (110 sec length --> 1 restart at 64 sec) and NEOINTRO.DRZ (204 sec length, 2 restarts at 64 sec and 128 sec) - probably some counter variable doesn't have enough bit width, or there's some integer division? :thinking:

2. CALC.APP - behaves incorrectly for the large numbers, i.e. a cubic root for 1000000000 (1 billion) tells 1000, but for 10000000000 (10 billion) tells 1121. A possible temp workaround is to limit the text field length. Also, seems the negative numbers aren't supported: i.e. 123/-1 tells "Cannot divide by zero"

3. CONFIG.APP - "Set the password" / "Disable the password" does not ask for an old password.

4. DEMOTOUR.APP - even if "3" is resolved, perhaps I can launch this demo tour from a File Manager to change a password without knowing an old one (although at the moment trying this gives me "Error writing to the disk! Make sure it is not read only" - maybe this "protection" works only for the virtual floppies)

5. DONKEY.APP ( which we discussed at https://github.com/prochazkaml/MichalOS/issues/11#issuecomment-986298332 ) - unfortunately it freezes, green screen and blinking _ at the left upper screen corner; ESC key doesn't help

6. EDIT.APP - when you open a multi-line text file (which maybe you have created previously), your text pointer is at one place but the typed text gets added to a place that is a few lines lower. Also EDIT.APP froze on me once, but hard to reproduce this

7. MEMEDIT.APP - cannot use "wh" command to write to a file - get "File access error!", also once with this command used improperly (forgot a filename argument) I got a MichalOS crash:

CPU: Invalid opcode Crash location: 0360:0104 Stack pointer: 1FF4

but cannot reproduce this (maybe something got to this memory area during my experiments, don't know). Perhaps it would help in the future if MichalOS could print the invalid opcode hex value at this error message?

8. PCMTEST.APP - [Space] Play/Pause does not work in this app

9. CF.BAS (Cosmic Flight game) - issue confirmed, I got 32700 points and instantly after getting one prize my spaceship has crashed. Possible workaround may be to modify the source code so that a score is stored at two 16-bit variables, hi_score and lo_score

10. Power off: I remember you tried a lot of times to make a reboot feature working, which was quite tricky considering the only other "hobby OS" which could do this successfully - was Kolibri, OS written in x86 assembly. But recently my friend Mike has rebuilt a Visopsys floppy with "/ramdisk" feature enabled - and it turned out Visopsys shutdown works too, written in a C code which is more simple than Kolibri's x86 asm, so maybe now we have a chance to resolve this mystery and possibly get shutdown working at MichalOS.

https://github.com/mikebdp2/visopsys

• files of a particular interest: https://github.com/mikebdp2/visopsys/blob/main/src/kernel/kernelShutdown.c , line ~300
• here we see a difference in behaviour between reboot and shutdown https://github.com/mikebdp2/visopsys/blob/main/src/include/arch/x86/processor.h , line ~540
• a definition of processorReboot, we seem to get away with just some inline assembly https://github.com/mikebdp2/visopsys/blob/main/src/kernel/kernelPower.c , line ~70
• a definition of kernelPowerOff, stuff seems more tricky as we need some "driverPowerOff" https://github.com/mikebdp2/visopsys/blob/main/src/kernel/kernelAcpiDriver.c , line ~200
• a definition of driverPowerOff, there is some minimal code to interact with ACPI https://github.com/mikebdp2/visopsys/blob/main/src/include/sys/acpi.h
• some ACPI defines

Thank you so much for everything :wink:

[prochazkaml]

Thank you for revisiting this project. Not sure whether it is worth the time and effort in continuing it though. See my mini-rant at the end.

1. I cannot sadly reproduce this bug on both songs using all 3 AdLib drivers, they all play perfectly from start to end without the progress bar messing up.

Here's NEOINTRO.DRZ playing perfecly fine from start to end:

https://github.com/prochazkaml/MichalOS/assets/41787099/61f8560d-d2ca-485e-914d-1cadf298cfe5

2. The calculator only works for unsigned 32-bit integers. Working with floating point numbers is an absolute pain in the ass (the main problem is converting input strings to floats and backwards, which the OS does not implement).

3. That was sort-of intentional. You could very easily create an assembly program which would modify the password for you, so there is no point in protecting the password change while logged in.

4. The "Error writing to the disk!" occurs because it is trying to overwrite SYSTEM.CFG, which the kernel does not allow. Yes, the disk access API in MikeOS/MichalOS is absolutely cursed.

5. Still didn't get around to rewriting the game in regular text mode. Sorry about that.

6. I admit that the default text editor that's bundled with this OS is a completely unstable piece of garbage. I was at first not capable of reproducing the bug, until I started recording. To be honest, I have no idea what's going on.

https://github.com/prochazkaml/MichalOS/assets/41787099/0e980989-bb4b-4183-aee4-da3af5d6930a

The best thing to do here would be to ~steal~ borrow someone else's (ideally open source) DOS text editor and port it to MichalOS. I am not however aware of any such editor.

7. Again, was not able to reproduce this bug. The "File access error!" only occurs for me when trying to write a file that already exists (same reason as issue 4).

https://github.com/prochazkaml/MichalOS/assets/41787099/97bf0146-a3c4-4897-9782-96d2a5f0f7b6

As for the crash, the memory probably got corrupted for some reason, as address 0104 when MEMEDIT is loaded definitely contains a valid opcode.

8. I know that this is getting stupid, but I really do not know what to write anymore other than "yet again, I was not able to reproduce this bug".

https://github.com/prochazkaml/MichalOS/assets/41787099/e92c972e-4da2-4ebb-bbe8-045e8908a026

9. MikeOS BASIC only allows signed 16-bit integers. No offense to the game's author (I am shocked that such game could be pulled off with the extremely limited and non-standard MikeOS BASIC interpreter to begin with), but the game's code is essentially incomprehensible to me, mainly because MikeOS BASIC forces single-letter variable names.

10. The reason for removing ACPI shutdown was simple - I removed support for 32-bit addressing, mainly because it was janky as hell, and there is no other way (that I'm aware of) that allows reading past the first 1 MiB of memory in 16-bit mode.

The correct way to do this (without rewriting the whole OS to be 32-bit) would be to write a "hypervisor" running in 32-bit mode, which would run a virtual 8086 task, inside which the kernel and all your programs would run. When needing to shut down, it would just ask the hypervisor to do that. Now, am I going to ever do that? Don't know, to be honest.

---

So, this was a depressing post, and I am truly sorry for that.

The main problem is that you cannot really easily debug 16 bit real mode x86 code on a hobby OS, you just have to prey that everything will work and that it won't break on other machines. And the lack of protected memory pretty much guarantees that a single wrong memory write, jump instruction or accidental push/pop from the stack can bring the whole system down. The crash screen (you know, the one with the white bomb on a red background) was supposed to help me with that, however, I feel like the errors are completely random, and it is impossible to backtrace, making it pretty much useless (the crash screen essentially reboots the kernel so that it is able to display itself, partially overwriting old corrupted data in memory).

This is why I particularly enjoy working with mainstream embedded systems with lots of community support (which is my actual job now, where I mainly program nRF52 or ESP32 based boards in C/C++), as debugging them is quite simple, and the most catastrophic failure mode is the system restarting. In MichalOS, you can wipe your main system drive's partition table (the one that contains your primary OS and personal data) with a single bad INT 13h call.

So, uh, yeah. I'm not sure whether I really want to do OS development anymore. The last thing I want to do is risk any of my personal machines by running the OS bare-metal.

The only real solution would be to start from scratch as a simple 32-bit protected mode OS (kinda like KolibriOS or Visopsys), ideally written in something like C (hey, haven't I said something like that sometime in the past?), but that would probably destroy the novelty of a simple 16-bit OS that fits on a single floppy disk.

Another solution would be to write a bare-metal 386-era PC emulator, inside which MichalOS would run (using Virtual 8088 mode), not sure anyone has really pulled that off, though.

In the end, I dunno. Between having a programming job and studying IT at a university, I feel like I have less and less time/will to debug my old shitty x86 assembly code. I'm truly sorry about that, but I'm no assembly programming expert. In the modern landscape, being able to program in assembly is more often than not just seen as a novelty rather than an actually useful skill anyway.

Not saying that I am abandoning this project forever, just that I have other things to do with higher priorities for the time being.

Again, I'm sorry if I have disappointed you, but this is how things are now.

[qmastery16]

@prochazkaml Good day Michal! I forgot to tell: these few "bugs" from my last message - are everything I was able to find/suggest during the multiple hours testing of the whole OS and all the programs ( had a "MichalOS day" :wink: ) . Also, these remaining issues are really minor and don't really stand in the way of all this fun of MichalOS. Even if they're hard to debug, they are low priority so please don't let this to discourage you from your project :+1: Maybe I will try to debug something by myself, since I am able to put it into BIOS and run on bare metal - luckily MichalOS never corrupted my partition table and I feel pretty safe using it.

Also, it may be possible to achieve a similar testing environment (although it won't reproduce everything) by running a special " coreboot+SeaBIOS opensource bios ROM with MichalOS floppy included" built for QEMU (just by a "-bios ./coreboot.rom" command line argument) ---> to debug MichalOS easier & faster, with the added ability of memory dumps by QEMU etc. - I provided such a testing environment for Andy (Visopsys author) here https://visopsys.org/forums/viewtopic.php?f=3&t=338 and it may be used for MichalOS floppy too, hopefully I already shared this with you before...

By the way, your MichalOS project is easily in top 3 of floppy-based hobby OSes - together with such giants as KolibriOS and FreeDOS ! :tada: recently my friend Mike Banon from 3mdeb company - has re-built your latest floppy - https://github.com/mikebdp2/MichalOS , and also updated it at the floppy collection here http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies . And this floppy collection may be included to coreboot BIOS image if a person uses a popular csbpatcher.sh script to get the unofficial coreboot patches (that are must have for coreboot-supported AMD boards such as Lenovo G505S (A10-5750M), ASUS A88XM-E (A10-6700 / A10-6800K) and AM1I-A (Athlon 5370/5350))_. So your user base may be higher than you expect :smiley: