MartyPC \ VOGONS

MartyPC Release 0.1.2 is out today and introduces some massive performance improvements and quite a few fixes.
https://github.com/dbalsom/martypc/releases/tag/0.1.2

Now that I've completed an initial optimization pass, I'm going to work on improving MartyPC's debugger and QOL features - I've already gotten some great suggestions from VileR and others.

The feedback for MartyPC has been great, I'm glad so many people have said such kind things about it. It's been a labor of love for me over the past year, and I hope to continue working on it and making it better with everyone's help.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

mothergoose729 wrote on 2023-06-29, 23:27:

Hey Glorious Cow! I love this emulator already! I have been messing around with more accurate PC emulators lately and it's fascinating to appreciate all the nuances of these machines. Your emulator was very easy to get up and running! The ability to seamlessly toggle between RGB and composite graphics is freaking sweet, I love it!

Glad you like it!

mothergoose729 wrote on 2023-06-29, 23:27:

I know this is an initial release, so obviously there are a lot of QOL and feature improvement to make from a usability stand point. I used bios images from my PCem collection and it was hard to figure out what MartyPC needed exactly to boot. I eventually found it, but mostly just by copy and pasting tones of image files into the ROMs folder until something booted.

I've started working on better documentation. You're not the first to struggle with the ROM situation. I have an initial wiki set up, which goes into detail about the ROMs required by MartyPC: https://github.com/dbalsom/martypc/wiki/ROMs I hope to expand on this a bit as well, it was a bit more extensive but Github's outage today ate my first draft (ouch)

mothergoose729 wrote on 2023-06-29, 23:27:I have a couple of questions about the features the emulator supports right now: […]
Show full quote

1) A better machine configuration system is definitely needed. I originally thought 'why would anyone want less than 640k of ram?' but you're not the first to ask, and switching between different configurations is a bit tedious; although you can always have separate configuration files and specify them on the command line. I need to have something that specifies the size of a floppy drive - DOS currently formats everything as 360k. I thought I was being clever by making the drive type change depending on what image you loaded into it (which lets you read a 1.44MB disk on a XT), but this doesn't really work that well with the BIOS detecting drive type on boot and storing the size in the BDA.

2) There's no full screen mode, but it's definitely something on the to-do list. This will probably be part of a display system refactor that includes dual-window support, if I can manage it.

3) Sadly no, the floppy directory limitation is due to me not wanting to try to call the native file browser on 3 different platforms (although there are libraries that might help with this) and not wanting to make a custom file browser. It gets unmanageable when you have a lot of floppies (the menu just cuts off at the bottom of the screen), there's no subdirectory support, and so on. Listing additional floppy directories to scan in the config would be a good improvement, but the UI has to be improved to support it as well.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

This version is certainly a lot faster than the previous release.
In RGBI-mode even the old Core i7 can sustain 60 fps through most things.
Composite mode is still very heavy, giving only about 30 fps. but in theory, if the composite is moved to a shader, that should solve that problem.

It looks like it defaults to the Vulkan API if supported, and falls back to DX12 otherwise. There do not appear to be any alternatives to that, because on a system that has no DX12-support, it seems to use the Microsoft software renderer for DX12. Which sadly doesn't perform that well, so a fallback to DX11 or OpenGL may have been better on these systems. But I'm not sure if the library you use can give you these options.
Edit: Apparently you can just set an env var WGPU_BACKEND to 'dx11' or 'gl'. But for some reason it doesn't actually run in those configurations.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Scali wrote on 2023-07-01, 11:30:

This version is certainly a lot faster than the previous release.
In RGBI-mode even the old Core i7 can sustain 60 fps through most things.
Composite mode is still very heavy, giving only about 30 fps. but in theory, if the composite is moved to a shader, that should solve that problem.

Glad to hear things are working better. The CGA emulation on the first release was really dog slow. There are more optimizations coming. I'm thinking I can save a lot of drawing time in periods where no CGA VRAM writes or CRTC updates have occurred; I can tick the CGA as normal but just not output anything (assuming I don't clear the buffer) because in theory the frame would be unchanged. Plus I haven't even really touched the CPU, and I have several ideas there.

I'm in the process of bringing over reenigne's composite code; having considered what he said about emulating the analog behavior of the multiplexer and such, I realized there was no point in trying to re-duplicate his sampling work. We'll see if it is any faster on its own, but I'll also be using it as the base for the shader - it's one pass, vs my two-pass method, so that's an extra bonus. I just need to fix Flower Girl from being green and purple at the moment.

Scali wrote on 2023-07-01, 11:30:

It looks like it defaults to the Vulkan API if supported, and falls back to DX12 otherwise. There do not appear to be any alternatives to that, because on a system that has no DX12-support, it seems to use the Microsoft software renderer for DX12. Which sadly doesn't perform that well, so a fallback to DX11 or OpenGL may have been better on these systems. But I'm not sure if the library you use can give you these options.
Edit: Apparently you can just set an env var WGPU_BACKEND to 'dx11' or 'gl'. But for some reason it doesn't actually run in those configurations.

I'm surprised there even is a software renderer for DX12! I don't know about dx11 specifically but I know the gl backend is not supported on Windows, as it's targeting ES3. I can look into whether you can specify a backend from code, but I was hoping that it would "do the right thing" by itself...

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

config.rs has a 'raw_rom' field in the 'Machine' struct. It is never read actually used, but it means 1) the supplied martypc.toml file doesn't work and 2) one is left mightily confused by the error message. I am very new at Rust so it took a while to find out that 'raw_rom' was a bool field that was never read so the actual value didn't matter.

The Windows version is very, very slow -- but looks ok so far.
The Linux version (under WSL2 w/ Ubuntu 22.04LTS) is even slower AND it looks weird. That might be due to unusual DPI settings on my part.

My machine is a budget laptop from 2018 extended to 20GB RAM (Lenovo 14-some-letters). WSL2 uses llvmpipe (software) for its OpenGL/Vulkan implementation so of course its "GPU" is slow -- but I'm surprised the emulator needs to use the "GPU" so much that it matters even when the emulated cursor is just blinking (very slowly) while the emulated memory is being tested by the BIOS. The Windows version uses the built-in Intel HD Graphics 620.

I asked MartyPC to emulate the 5150 and I have no idea what BIOS ROM it used (it doesn't say -- and I dumped three of them into installs\roms\). After an eternity the emulated PC gave up with "131 FC00 ROM" -- perhaps because I "pressed" the turbo button?

Is there a way to skip the memory test for faster boots?

The Performance window has lots of values but I don't know what most of them mean. I can say that FPS=57, UPS a bit lower, Emulation time seems to be around 4-6ms, Render time seems to be around 10ms -- they all change so fast that I can't tell for sure. This is for the Windows version. I have played with egui's demo and it has lower render time (often around 3ms) despite seemingly doing more on the screen.

Yes, I did build with "cargo build --release".

PS: forgot to say I used git version 435c5592d23b34a024473cdccc014b508cf4bbec.

Attachments

• 
  Filename Screenshot 2023-07-01 204027.png File size 55.46 KiB Views 22905 views File license CC-BY-4.0

peterfirefly wrote on 2023-07-01, 19:02:

config.rs has a 'raw_rom' field in the 'Machine' struct. It is never read actually used, but it means 1) the supplied martypc.toml file doesn't work and 2) one is left mightily confused by the error message. I am very new at Rust so it took a while to find out that 'raw_rom' was a bool field that was never read so the actual value didn't matter.

That field is only used by the web player, sorry - It should have been an Option<bool> so that it is not required to be present. But I would recommend in general that if you build from source you just drop the executable into the directory structure from a release. I don't know if i'll be keeping that 'install' directory in the source tree.

peterfirefly wrote on 2023-07-01, 19:02:

The Windows version is very, very slow -- but looks ok so far.
The Linux version (under WSL2 w/ Ubuntu 22.04LTS) is even slower AND it looks weird. That might be due to unusual DPI settings on my part.

When you say slow, do you mean moving debug windows around? or the general emulation performance? Can you take a screenshot of the Performance window?

peterfirefly wrote on 2023-07-01, 19:02:

My machine is a budget laptop from 2018 extended to 20GB RAM (Lenovo 14-some-letters). WSL2 uses llvmpipe (software) for its OpenGL/Vulkan implementation so of course its "GPU" is slow -- but I'm surprised the emulator needs to use the "GPU" so much that it matters even when the emulated cursor is just blinking (very slowly) while the emulated memory is being tested by the BIOS. The Windows version uses the built-in Intel HD Graphics 620.

What model CPU does it have?

The GPU is not used to emulate the CGA, so what you see on the emulated screen is largely irrelevant. It is used to composite the display buffer with the GUI windows - I'm a bit surprised that this has turned out to be such a challenge for a lot of PCs. I might make an SDL front end for lower-spec machines or configurations where a fast GPU isn't available.

peterfirefly wrote on 2023-07-01, 19:02:

I asked MartyPC to emulate the 5150 and I have no idea what BIOS ROM it used (it doesn't say -- and I dumped three of them into installs\roms\). After an eternity the emulated PC gave up with "131 FC00 ROM" -- perhaps because I "pressed" the turbo button?

minuszerodegrees says that 131 is the 'cassette port wrap-around (loopback) test', interesting. Does it boot with Turbo off?

I think I will add a Machine Info window that will show which ROM is in use; but in general, it will pick the newest set by release date. So if you have all three known versions of the 5150 bios in the ROMs folder it will use the October '82 BIOS.

peterfirefly wrote on 2023-07-01, 19:02:

Is there a way to skip the memory test for faster boots?

In general, I'd recommend emulating a 5160 with the 1986 BIOS unless you have a specific interest in the 5150. MartyPC will hot-patch the 1986 5160 BIOS to speed up the memory test dramatically, because I got tired of waiting ages for it to boot myself. I could do this for every BIOS version, but it's just a matter of finding the right offsets and defining the patches for each ROM.

peterfirefly wrote on 2023-07-01, 19:02:

The Performance window has lots of values but I don't know what most of them mean. I can say that FPS=57, UPS a bit lower, Emulation time seems to be around 4-6ms, Render time seems to be around 10ms -- they all change so fast that I can't tell for sure. This is for the Windows version. I have played with egui's demo and it has lower render time (often around 3ms) despite seemingly doing more on the screen.

'Render time' reported by MartyPC isn't EGUI's render time, so we can't compare the two, it's mainly comprised of three steps: converting the indexed color CGA output to RGBA, scaling it, and optionally converting it for composite monitor simulation.

Your render time is extremely high - mine is well under 1ms. So you're bumping up against 16ms frame times, which means you won't be keeping 60fps. Can you go to Display menu and uncheck 'Correct Aspect Ratio' and tell me what that drops your render time down to? 0.1.2 introduced SIMD-enabled aspect correction, and I'm wondering if you have some CPU incompatibility - if turning off aspect correction drastically improves render time that would be a smoking gun.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

> But I would recommend in general that if you build from source you just drop the executable into the directory structure from a release. I don't know if i'll be keeping that 'install' directory in the source tree.

Ok, didn't know that.

> When you say slow, do you mean moving debug windows around? or the general emulation performance? Can you take a screenshot of the Performance window?

emulation performance.

> What model CPU does it have?

i3-7100U, running at 2.40GHz (power is plugged in and I turned all the power saving off).

>The GPU is not used to emulate the CGA, so what you see on the emulated screen is largely irrelevant. It is used to composite the display buffer with the GUI windows - I'm a bit surprised that this has turned out to be such a challenge for a lot of PCs. I might make an SDL front end for lower-spec machines or configurations where a fast GPU isn't available.

Yes, I found your shader. Isn't it just a simple image copy, possibly with a bit of filtering?

> minuszerodegrees says that 131 is the 'cassette port wrap-around (loopback) test', interesting. Does it boot with Turbo off?

Nope. Same error. I quit the emulator and started it again to be sure.

> I think I will add a Machine Info window that will show which ROM is in use; but in general, it will pick the newest set by release date. So if you have all three known versions of the 5150 bios in the ROMs folder it will use the October '82 BIOS.

I'd be happy with a println!

> In general, I'd recommend emulating a 5160 with the 1986 BIOS unless you have a specific interest in the 5150. MartyPC will hot-patch the 1986 5160 BIOS to speed up the memory test dramatically, because I got tired of waiting ages for it to boot myself. I could do this for every BIOS version, but it's just a matter of finding the right offsets and defining the patches for each ROM.

I wanted to see Arena 5150 -- but I'll gladly take that speed hack!

I haven't tried the 5160 emulation yet.

> 'Render time' reported by MartyPC isn't EGUI's render time, so we can't compare the two, it's mainly comprised of three steps: converting the indexed color CGA output to RGBA, scaling it, and optionally converting it for composite monitor simulation.

Oh, I thought it was.

> Your render time is extremely high - mine is well under 1ms. So you're bumping up against 16ms frame times, which means you won't be keeping 60fps. Can you go to Display menu and uncheck 'Correct Aspect Ratio' and tell me what that drops your render time down to? 0.1.2 introduced SIMD-enabled aspect correction, and I'm wondering if you have some CPU incompatibility - if turning off aspect correction drastically improves render time that would be a smoking gun.

Doesn't seem to make a difference. I also looked at the GPU% in Task Manager. It is around 8.7% with or without "Correct Aspect Ratio" when there are no egui windows open and the CPU is running and doing memory test. I know the 620 is very slow compared to a modern, real graphics card -- but it can do 400 GFLOPS and 24 Gtexels/s. I have no idea what it spends 8.7% on!

I'll play with 5160 and hopefully figure out how to use Tracy in the next couple of days. I'll get back when I know more. So far this rust + egui + shader journey has been great fun so I definitely want to continue.

https://github.com/wolfpld/tracy

(I haven't figured out how to use Vogons' quotes yet -- sorry about that.)

Attachments

• 
  Filename Screenshot 2023-07-01 215508.png File size 48.21 KiB Views 22883 views File license CC-BY-4.0

peterfirefly wrote on 2023-07-01, 20:02:

I wanted to see Arena 5150 -- but I'll gladly take that speed hack!

Good news, Area 5150 works fine on a 5160.

peterfirefly wrote on 2023-07-01, 20:02:

Doesn't seem to make a difference. I also looked at the GPU% in Task Manager. It is around 8.7% with or without "Correct Aspect Ratio" when there are no egui windows open and the CPU is running and doing memory test. I know the 620 is very slow compared to a modern, real graphics card -- but it can do 400 GFLOPS and 24 Gtexels/s. I have no idea what it spends 8.7% on!

All the stuff in 'Render time' is being run on your CPU, not your GPU. I know that sounds a little counterintuitive considering we associate 'Rendering' with the GPU. Maybe I should rename it to 'Buffer Processing' or something less confusing.

Is there a chance you could install cargo flamegraph https://github.com/flamegraph-rs/flamegraph and generate one (just for a few seconds even) ? it might help me get an idea of where the slowdown is on your system.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

> All the stuff in 'Render time' is being run on your CPU, not your GPU. I know that sounds a little counterintuitive considering we associate 'Rendering' with the GPU. Maybe I should rename it to 'Buffer Processing' or something less confusing.

I got that. I still don't understand why it is using 8.7% of my GPU! And reducing the GPU usage would make a large difference for WSL2.

That's why I want to run Tracy on it.

> Is there a chance you could install cargo flamegraph https://github.com/flamegraph-rs/flamegraph and generate one (just for a few seconds even) ? it might help me get an idea of where the slowdown is on your system.

There is every chance! But not tonight...

I've successfully ported reenigne's composite code, and putting them side by side really shows off the deficiencies in my algorithm:

Filename old_vs_reenigne.png File size 125.84 KiB Views 22827 views File comment Old MartyPC composite vs new (reenigne) method File license Public domain

With the added benefit of it being nearly 4x faster. Since it's one pass I can completely skip the composite signal conversion step the old algorithm had to use. Still want to make it a shader, but having a reasonably fast software path is a good thing.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

With the much faster composite now in place, I've added a web demo for 8088MPH:

https://dbalsom.github.io/martypc/web/player. … l?title=8088mph

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Really nice! How are you compiling your Rust software into JavaScript?

That's fantastic-looking composite emulation -- best I've ever seen in a Javascript emulator -- and even runs realtime 60fps. I'd ask for a fullscreen button, or a double-click to enter/exit fullscreen, but that's only a nice-to-have.

Bugs:
1 -- Second bug, it's not letting me zoom the canvas image via the common CTRL+scrollwheel (zoom webpage) -- it resists resizing. I'd like to go 200% to fill more of my screen.
2 -- There's a very minor raster glitch in the Kefrens bars in 8088MPH in the Javascript version of your emulator. Not sure if it's because of the settings chosen, or your emulator;
3 -- It seemed to skip over some sections of demo (maybe a late buffered Enter key)

UPDATE: There was a behavior where pressing Enter in the startup gradient tester didn't work, but restarting browser worked to fix item 1! But see item 3

mdrejhon wrote on Yesterday, 23:46:

Really nice! How are you compiling your Rust software into JavaScript?

wasm is a native target of the rust compiler, so it's pretty easy. The only things I had to change was turning the file open/read operations into web requests.

mdrejhon wrote on Yesterday, 23:46:

That's fantastic-looking composite emulation -- best I've ever seen in a Javascript emulator -- and even runs realtime 60fps. I'd ask for a fullscreen button, or a double-click to enter/exit fullscreen, but that's only a

Wish I could take credit, but it's reenigne's composite code now... mine was close, but the colors were a bit dull. (and a lot slower)

mdrejhon wrote on Yesterday, 23:46:

1 -- Second bug, it's not letting me zoom the canvas image via the common CTRL+scrollwheel (zoom webpage) -- it resists resizing. I'd like to go 200% to fill more of my screen.

I am not a web developer by any means, so forgive me if there is some jank to this page.

mdrejhon wrote on Yesterday, 23:46:

2 -- There's a very minor raster glitch in the Kefrens bars in 8088MPH in the Javascript version of your emulator. Not sure if it's because of the settings chosen, or your emulator;

Sometimes there's a vertical discontinuity in the background lines, is that what you mean? If not, could you screenshot it?

mdrejhon wrote on Yesterday, 23:46:

3 -- It seemed to skip over some sections of demo (maybe a late buffered Enter key)

I've watched this demo eight million times and didn't see any scene get skipped when i tested it, what effect was skipped?

EDIT: Okay, finally caught it skipping the Delorean effect after about a second. Not sure what that's about, but I suspect timer issues...

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

I just found out if I zoom before I refresh before Run, it works! I get 200% fine.

By default, you have:

1<canvas tabindex="0" data-raw-handle="1" width="768" height="576" alt="MartyPC WASM Player" style="width: 768px; height: 576px;"></canvas>

If I zoom 200% while running, I get an unresized emulator and it still stays:

1<canvas tabindex="0" data-raw-handle="1" width="768" height="576" alt="MartyPC WASM Player" style="width: 768px; height: 576px;"></canvas>

If I zoom before I refresh before Run, it works and correctly scaled:

1<canvas tabindex="0" data-raw-handle="1" width="768" height="576" alt="MartyPC WASM Player" style="width: 384px; height: 288px;"></canvas>

It's clearly a confusing part of the web standard. The style of width/height is based on the logical units, so you need to divide the style's width and height by the page zoom factor (an API is available).

(It may be that the stuff inside the canvas is "fighting" against the zoom)

I don't know if you did that part of the HTML or if a compiler did it -- but just letting you know!