Comment by cyberpunk2066
2 days ago
Easily one of the most impressive passion projects I've seen here in a long time. Out of curiosity, why did you opt to write your own C compiler?
2 days ago
Easily one of the most impressive passion projects I've seen here in a long time. Out of curiosity, why did you opt to write your own C compiler?
Had a rule for myself that I wanted to write everything myself, and it had always been a “goal” of mine to build one. So it just kinda fit together
Really worthwhile goal no matter what anybody says :)
Did a little testing myself.
Tried it on some bare metal, looks pretty good.
There were two phases, wouldn't fit in a single comment.
Wrote RetrOS-32.img to a blank SSD and it boots in CSM/Legacy mode.
That's a nice milestone right there :)
This was on a tiny Lenovo desktop about as old as an x240. These are low-power, run on the same Thinkpad A/C adapter, so there are some similarities to a laptop.
But the cursor wasn't very responsive and wouldn't come down below the very top rows either so could not sign in. Using mainstream wired mouse & kybd. (The PC has 8GB memory, in the login box it showed the nominal 15mb, but extended memory was a negative number, about 8GB itself.)
Then I remembered things like the x240 often have a touchpad that is recognized as a PS/2 mouse, not USB. Moved the SSD to an old tower that has a PS/2 mouse and kybd and then could sign on. Cursor was still quite a bit sluggish, but it worked. This one has 12GB memory and the reported extended was about 464mb so it looked realistic in the login box.
It boots! It works nominally! It's some kind of Golden IMG already, so congratulations!
Back at the Lenovo I do boot to DOS from time to time, and I enable Legacy USB in the BIOS so I can use the USB mouse for DOS which had no concept of USB. After booting DOS, if I want to use the mouse I still have to load DOS mouse drivers, just like the 1980's but this firmware setting fools the old pre-USB DOS mouse driver so it will handle the USB mouse & kybd that people are using now. This setting has been there for ages since the PS/2 sockets on PC's started becoming scarce. Checked the BIOS, and Legacy USB was enabled the whole time.
However, on this Lenovo there was an additional setting, for "USB Virtual KBC Support". I don't know if I ever saw this along with Legacy USB settings in one BIOS, up to now would have assumed they were both the same thing but using different terminology. This setting was not only disabled by default, the text says this one auto-disables once an XHCI driver has been loaded. Then definitely found it to auto-disable after booting Windows.
Enabled Virtual KBC, booted to RetrOS and the USB mouse could log in. More sluggish cursor than on the PS/2 machine though.
Plus there were some untyped characters that would sometimes appear when logging in, or admin would duplicate itself so username said adminadmin after you typed in the password below.
Still has a huge negative number in the login box for extended mem, that was not a show-stopper, mem appears normal when looking at the system stats once logged in.
I would now imagine this Virtual KBC setting emulates how mouse & kybd are presented to a VM?
Interesting finding that DOS does not require this setting for a USB mouse to work on bare metal, but RetrOS does.
Have not put it through its paces thoroughly, focusing on the bare metal aspect.
Second phase began examination of sector structure using DMDE 3.6. A very good aid for understanding boot structure, which I hardly ever use for data recovery but it will do that too. Like other hex editors, hex appears on the left, ASCII on the right. But that's only in "Hexadecimal/Text" Mode which is the default, and you're naturally looking at sector 0 to start with when you open an IMG in DMDE. Scroll down for all the rest of the sectors as far as the eye can see. The different Modes correctly "interpret" only a handful of particular sectors that are expected to conform to that mode. When a non-default Mode is chosen correctly for a key sector, you are presented with a template showing fundamental structures underlying the partitions, filesystems, and/or OS, according to that mode. You can also directly edit these essential parameters on the template and it will update the hex accordingly, but it needs to be right.
Key sectors containing things like the Partition Table, or a bootsector (Boot Record) are also supposed to be ones that do not change whether or not there is an OS (or any files) in the filesystem or not.
Break that down a little bit, a partition table should not change whether or not the partition(s) are formatted or completely blank. Not supposed to matter whether you are going to use the partition for DOS, Windows, Linux or whatever.
Then a bootsector doesn't even exist until its partition is formatted to begin with, then it reflects the "geometry" that the formatting process seemed to think was best for that filesystem based on the information it had available.
Neither of these should change after that, and be completely independent of whether there are any files in the filesystem.
It's probably best to build on as firm a foundation completely consistent with regular old PC's and it really looks like this is going pretty well using FAT16.
Once you have copied the IMG to a SSD, you could look at either IMG or hardware in DMDE and see the same thing. You do have to kind of figure I checked the IMG for potential bootability before I did anything on bare metal ;)
It is intriguing. There were other anticipated possibilities for an IMG to be bootable, like floppy mode or "large floppy" mode, which start with only a bootsector located at sector 0, no partition table is needed since there is never more than one partition.
Sector 0 right now is reminiscent of a FAT16 bootsector, looking at it in "FAT/FAT32/NTFS Boot Record" Mode, it displays real well. With FAT, you will see there are two different entries for Total Sectors.
By the time FAT16 came around, the upper Total had already been deprecated. You are using it for a full total of 65535 sectors which works so far but it should be in the lower Total Sectors entry for this template on FAT16. The upper entry should be 0 instead.
Then interestingly, looking at sector 0 in Partition Table mode, you do have a (un-needed at this time) partition table, in the usual position within the final bytes of sector 0. The 65535 total sectors are independently designated there (same total as above in the bootsector code that takes up the bulk of the bytes in sector 0 above) but there is no CHS geometry in place, and DMDE flags a "Relative Sector" of 0 as incorrect because it's expected to always be something other than 0. There's a number of structural features that can cause DMDE to flag them other than this too.
With sector 0 in DMDE you hit Editor > Partiton Table and all you're seeing interpreted is the last dozens of bytes of sector 0, it's only meaningful if there actually is a partition table in sector 0. There would be a maximum of 4 primary partitions in place. You can change this part all you want without having an effect on the code existing in the earlier bytes of sector 0 (such as an MBR ordinarily). But if you've got partitions the partition table better be sensible or it could fail to point directly to where the target code is.
No real partitions at this point so you can just go into Edit Mode and zero out the top primary partition line:
80 0E 0 0 0 0 0 0 0 65535
You have to hit File > Apply Changes. Then the partiton table is completely gone. And it will still boot just the same.
Random finding; there's a gfx_destory_window in sector 284 that looks like a typo.
Nothing in the OS should ever be hardcoded to rely on specific sectors, instead everything needs to be relative to the "Hidden Sectors" in the FAT which determine the offset which is the actual bootsector location for a primary partition.
The bootloader needs to be independent, and the OS itself needs to function regardless of what sector its partition starts on.
2 replies →