Booting Minix 2.0.2 on PC XT fails silently

[rationalism]

Booting Minix 2.0.2 on PC XT fails silently

[rationalism]

@dbalsom Hey, I found the answer to this - the disk image wasn't a full 360 KB. I appended zeroes with dd until it was 360 KB, and now it boots.

Before I expanded the floppy disk image, I also tried booting the image XTBOOT.IMG/XTBOOT.MNX, which was suggested in case of an error. This floppy booted successfully, and displayed the Minix prompt, which asked the user to insert the root floppy, then hit a key. However, when I ejected the old floppy and inserted the root floppy (TINYBOOT.IMG/TINYBOOT.MNX), the emulator read for a few seconds, then crashed with "Read error A0".

[dbalsom]

Other than adding a yaml file to play around with Github CI, the main branch is positively ancient, and has none of the other minix fixes.

[dbalsom]

I don't really have a usable development branch for you to try at the moment. multi_monitor is the newest branch, but it also requires you to have a completely new configuration file.

[dbalsom]

I do need to show some sort of error message in the GUI when a disk image fails to load.

[rationalism]

@dbalsom Thank you! I tried cherry-picking this commit:

392d73c

and unfortunately it still hung after hitting the = key. I tried checking out that commit and running, and it failed with this error message:

warning: `martypc_pixels_desktop` (lib) generated 55 warnings (run `cargo fix --lib -p martypc_pixels_desktop` to apply 30 suggestions)
    Finished release [optimized] target(s) in 1m 06s
     Running `target/release/martypc`
Failed to parse configuration file. There may be a typo or otherwise invalid toml:
missing field `keyboard_type` for key `machine` at line 188 column 1

Happy to keep trying if there's a valid config file available for a later commit

[lautis0503]

Other than adding a yaml file to play around with Github CI, the main branch is positively ancient, and has none of the other minix fixes.

That is.

I've tried MINIX 2.0 before, but won't report the issue until MINIX 1.1 and 1.5 are confirmed to run correctly. So let's forget MINIX 2.0 now.

As for configuration file, it will not be updated in the development branch. Read the code and modify it yourself like I did before.

[dbalsom]

As for configuration file, it will not be updated in the development branch. Read the code and modify it yourself like I did before.

Well, it could be. The original idea of the /install folder is that I'd have the assets/files that MartyPC needed to run in there, so you could use it as a base for your MartyPC installation. So I just need to check in an updated toml there.

At this point it would be a lot to ask someone to try to derive the new config format from the code. I've moved the definition of the toml-mapped data structures from the config module to the modules that own them, so you'd be looking all over them. And there's now window definitions, and shader presets, and video card declarations, and all sorts of new stuff, and well... it's not just a matter of setting a few missing flags anymore.

I've been trying to make most of the config fields optional so that if I add something it doesn't immediately break with older configs - it will just use some sensible default instead - but that's not always possible.

The new display manager system is mostly stable with just a few UI settings needing to be wired up. The new scaler/shader system is stable. EGA is still a work in progress but the fundamental changes needed for it are done and so most of what's remaining there wont' affect the rest of the core. So this weekend I hope to get everything merged back down to the 0.2.0 branch.

I will try to remember to check in the config and tag 'stable' commits going forward so more people can effectively test the development branches.

[dbalsom]

@lautis0503 @rationalism

I've merged things down and set the default branch to 0.2.0.

If you want to check it out and test any Minix stuff, I have confirmed that you can clone the repo, 'cd martypc\install', and 'cargo run', and the emulator will start with the included martypc.toml. It's very different than the existing toml, but there are enough comments in there it should be self-explanatory.

I checked in GlaBIOS (with permission) so the emulator can run straight from the repo.
An external icon file is no longer required.

[rationalism]

@dbalsom Thanks a lot! Tried this, it compiled and ran successfully

• Initially, a bunch of debug windows appeared in the emulator and could not be closed, but I fixed this by disabling debug mode in the .toml config file
• The error message "epaint: WARNING: pixels_per_point (dpi scale) have changed between text layout and tessellation. You must recreate your text shapes if pixels_per_point changes." was printed over and over on the command line extremely rapidly (tens of thousands of times per second).
• The mouse cursor appears to be slightly misplaced (ie., the menu option that gets highlighted is something like ~40 pixels to the lower right of where the tip of the mouse cursor arrow icon is displayed on the screen)
• Minix 2.0.2 disk image hangs after booting as before (boot, hit "=", a loading screen is displayed with a table of available memory, then hangs)
• CPU usage appears to be very high with the new version (my fan quickly spins up), even when nothing is happening on the emulator

[dbalsom]

@dbalsom Thanks a lot! Tried this, it compiled and ran successfully

I think all these things (except the Minix issue) are basically related.

I think you have DPI scaling enabled (not really sure how this works in linux)

• something is going wrong with dpi scaling and making egui unhappy
• the mouse cursor is off because the dpi scaling isn't working
• the mouse cursor being off meant you couldn't close the debug windows
• your cpu usage is extremely high because printing a log entry to the console is relatively expensive to do, and it's being spammed

can you give me more info about your graphics card / window manager etc ? if you can find your DPI settings somewhere that would be useful.

[rationalism]

@dbalsom I'm running an RTX 3060 on Ubuntu 22.04, happy to run other diagnostics if that would help

[dbalsom]

@dbalsom I'm running an RTX 3060 on Ubuntu 22.04, happy to run other diagnostics if that would help

Well, the good news is turning on DPI scaling in Windows produces the same error, so it's just something buggy with my DPI handling in the new display manager. I'll update here when I have a fix to try.

[lautis0503]

Got three compiling errors.

Compiling martypc_pixels_desktop v0.2.0 (...\martypc\frontends\martypc_pixels_desktop)
error[E0446]: private type `MouseData` in public interface
   --> frontends\martypc_pixels_desktop\src\emulator\mod.rs:65:5
    |
65  |     pub mouse_data: MouseData,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private type
    |
   ::: frontends\martypc_pixels_desktop\src/lib.rs:182:1
    |
182 | struct MouseData {
    | ---------------- `MouseData` declared as private

error[E0446]: private type `KeyboardData` in public interface
   --> frontends\martypc_pixels_desktop\src\emulator\mod.rs:66:5
    |
66  |     pub kb_data: KeyboardData,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private type
    |
   ::: frontends\martypc_pixels_desktop\src/lib.rs:232:1
    |
232 | struct KeyboardData {
    | ------------------- `KeyboardData` declared as private

error[E0446]: private type `Counter` in public interface
   --> frontends\martypc_pixels_desktop\src\emulator\mod.rs:67:5
    |
67  |     pub stat_counter: Counter,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private type
    |
   ::: frontends\martypc_pixels_desktop\src/lib.rs:111:1
    |
111 | struct Counter {
    | -------------- `Counter` declared as private

rustc/cargo 1.72.0 in Windows.

[lautis0503]

MINIX 1.1 boots now, but not MINIX 1.5

[dbalsom]

@rationalism DPI issues should be fixed now, or at least, not completely broken. I can't say anything about Minix yet.

I think it makes sense to approach Minix issues by version number, so I'll investigate 1.5 first. It may be a little bit before I can dig in, most of my work in the near term is on finishing 0.2.0, and I'm concentrating the front end for that. There is one remaining CPU fix to do, though, that might coincidentally help things.

[lautis0503]

This is floppy images of MINIX 1.5.
Attention, some files are in wrong size ('cause they are expected to be written to real floppies), so you need to expand them to 720K.
I got a file from somewhere on the Internet explaining the floppy images.

Minix 1.5 3"1/2 for the IBM PC,
XT, AT, 386 and PS/2

Disk numbering:
01: PC Boot Disk
02: AT Boot Disk
03: Universal Boot Disk
04: Root File System
05: System Binaries #1 (/usr)
06: System Binaries #2
07: System Binaries #3
08: Operating System Sources
09: Command Sources #1
10: Command Sources #2
11: Networking Sources
12: Boot Disk with ST 506 Hard Disk

3.5" 720K disks (no double step on imagedisk),
Universal Boot Disk uses BIOS calls for disk
access, so should work often if not always,
but should be slower too.
Disk 3 boots succesfully in VMWare, still
has problems in VPC.

standard user= ast
password = Wachtwoord
root password = Geheim

[lautis0503]

MINIX 1.5 REFERENCE MANUAL

[rationalism]

@dbalsom Tried pulling the branch and running again, got this error during compilation:

error[E0599]: no method named `set_debug_on_hover` found for struct `egui::Context` in the current scope
   --> lib/frontend/marty_egui/src/lib.rs:415:22
    |
415 |             egui_ctx.set_debug_on_hover(true);
    |                      ^^^^^^^^^^^^^^^^^^ method not found in `Context`

For more information about this error, try `rustc --explain E0599`.
warning: `marty_egui` (lib) generated 6 warnings
error: could not compile `marty_egui` (lib) due to previous error; 6 warnings emitted

[rationalism]

@dbalsom Update: cargo run worked but cargo run -r had the compilation error above

[dbalsom]

@dbalsom Update: cargo run worked but cargo run -r had the compilation error above

already fixed. this function only exists in egui in debug mode, which is odd... why not just stub it out in release?

[rationalism]

@dbalsom Here is the result of running this command in the most recent version of version_0_2_0, then trying to boot the Minix 2.0.2 floppy:

RUST_LOG=debug,naga=error,wgpu_core=error,marty_core::devices::hdc=trace cargo run -r &> log.txt

log.txt

[dbalsom]

well, no unimplemented command warnings.. the xebec controller protocol is rather similar to the floppy disk controller, in that is is annoying and filled with lots of random little status bits. I imagine minix is unhappy about the way i set or don't set one particular bit.

[dbalsom]

Some progress with Minix 2.0. I have the jumpers on the HDC hardcoded for two drives, which doesn't seem bother DOS even when one is missing, but Minix will error out if it can't read the partition table of the non-existent drive 1. I plan to fix this to set the jumpers based on the number of drives specified in the configuration, but just for now I added a second VHD.

It loads the RAM disk extremely slowly. I am not sure if that's normal or not.

[dbalsom]

it booted, but floppy reads are just way too slow to be practical. I think it may be expecting a certain status bit in the sense bytes, and is just timing out in a non-fatal way.

[krangerich]

It loads the RAM disk extremely slowly. I am not sure if that's normal or not.

How is it compared to Minix 1.2? I'm currently studying 1.2 in depth (your debugger saved my sanity multiple times).
With 4.77 Mhz and normal floppy timings, it takes ~60 seconds to load a 240kb ram disk on 86box (using 360kb images) - that's why I'm usually running it with 16 Mhz and turbo timings.

[dbalsom]

It loads the RAM disk extremely slowly. I am not sure if that's normal or not.

How is it compared to Minix 1.2? I'm currently studying 1.2 in depth (your debugger saved my sanity multiple times). With 4.77 Mhz and normal floppy timings, it takes ~60 seconds to load a 240kb ram disk on 86box (using 360kb images) - that's why I'm usually running it with 16 Mhz and turbo timings.

I haven't tried 1.2. 1.5 loads very quickly now, just a few seconds. But I don't have proper floppy drive timings either, so it's probably much faster than hardware.

[dbalsom]

Minix 2.0 is loading much faster now after I implemented the Read Sector ID command for Minix 1.5
Minix 1.5 issues the command and waits for an interrupt, forever, which causes a hang if the drive does not respond.
Minix 2.0 times out instead, which just resulted in very slow drive operation.

I think that's all the Minixes working, now. I just need to figure out how to install to the hard drive...

[lautis0503]

I think that's all the Minixes working, now. I just need to figure out how to install to the hard drive...

There's guides in MINIX 1.5 Reference Manual. But that's not quite easy as MS-DOS or contemporary OSes.

[lautis0503]

MINIX 2.0.2. TINYBOOT and then TINYUSR1. Two Unrecoverable write error.
Machine config is 5160, CGA, two 360K floppies, no hard drive.