Wow, this is the best book digitization result I’ve ever seen!

Thanks. What I started with was a plain text file with most of the book's content, though many source listings were missing (and the images, though some were recreated with ASCII art). I then lent the book in the Archive.org's library, and created HTML with styling to match the books styling and typography, and copy/paste the images. The missing source listings I OCRed with some online OCR tool. Took me a couple of weeks of evening hours. I'm pretty pleased with the end-result myself.

GloriousCow wrote on 2023-11-28, 16:34:

As for resizing widgets, I'd like to make any widgets resizable if it makes sense to do so, like the disassembly and instruction history and memory viewer should definitely resize to show you as much as you want to see. It's just a bit trickier - the immediate-mode flow is normally that you send the gui some data and a window expands to fit it.

What I meant by resizing/rescaling widgets was more along the lines of 'zooming out' - taking the final rendered size and scaling it down by some fixed factor, so the exact same content can take up less screen space. Since they're already rendered as textures, hopefully that wouldn't be too much of a stretch.
Ideally, individual widgets could still be resized by dragging at the borders (to control how much is shown, where applicable). Maybe the fixed scale-factor could just be a single setting in the config file.

GloriousCow wrote on 2023-12-01, 00:03:

This took a while, but the display framework I've built should be pretty flexible, and it abstracts the backend in preparation for an SDL frontend.

multiple_windows.png

A single video card can be rendered to multiple windows with different parameters. Watch 8088mph in composite and RGBI at the same time! Go nuts!

Looking awesome!

Oh yeah... now that the display has its own window, is there a chance that CGA color #0 could be made fully black (0,0,0) instead of the current very dark grey? I assumed that was done to differentiate it from the rest of the UI background, but now that won't be needed any longer. 😀

VileR wrote on 2023-12-10, 06:08:

What I meant by resizing/rescaling widgets was more along the lines of 'zooming out' - taking the final rendered size and scaling it down by some fixed factor, so the exact same content can take up less screen space. Since they're already rendered as textures, hopefully that wouldn't be too much of a stretch.

too much of a ...stretch. I see what you did there. Actually, as a happy coincidence, egui has a global zoom level setting that will apply to everything, so you could make things as big or small as you like. i just need to expose it. The fonts are already pretty tiny in places, but maybe I can add a global base font size.

VileR wrote on 2023-12-10, 06:08:

Oh yeah... now that the display has its own window, is there a chance that CGA color #0 could be made fully black (0,0,0) instead of the current very dark grey? I assumed that was done to differentiate it from the rest of the UI background, but now that won't be needed any longer. 😀

You are correct, I did that to try to tell where the hell the display border was. Since the 'padding' area is now a custom color, I've already changed it back to pure black. I've actually got a plan to make the palette customizable. Was thinking about how I wanted to switch between the "standard" and "accurate" 5153 colors, and then just figured, might as well throw that in a config. Throw everything in the config! Config all the things! This is just more in line with my eventual goal of allowing you to define a fantasy computer that never quite existed - and maybe that computer had a different palette. Go nuts.

Another thing I was pondering, is that we can have a custom renderer just for screenshots. Obviously we can take our sweet time rendering out a screenshot compared to blitting it on screen in realtime, so we can do all sorts of software processing.
One of the more interesting scenarios here I was thinking about: Could your ffmpeg scripts run on a single frame and output a single frame?

Spent the day trying to fix DPI scaling, fun. But I threw the GUI zoom option in while I was at it.

Here's 50% ( at 1.25 DPI scale)

You can shrink the windows down to near zero, with hilarious results. I tried to make a zoom slider but of course it's really hard to hold on to something that is actively growing or shrinking while you move it...

VileR (or anyone else that's interested, I suppose)...

https://github.com/grantshandy/egui-themer

If you want to create a custom theme of your liking using this tool, export it and attach it here or otherwise find a way to get it to me, and i'll build your theme into MartyPC 😀

Great work GloriousCow!

GloriousCow wrote on 2023-12-10, 16:17:

You are correct, I did that to try to tell where the hell the display border was. Since the 'padding' area is now a custom color, I've already changed it back to pure black. I've actually got a plan to make the palette customizable. Was thinking about how I wanted to switch between the "standard" and "accurate" 5153 colors, and then just figured, might as well throw that in a config. Throw everything in the config! Config all the things! This is just more in line with my eventual goal of allowing you to define a fantasy computer that never quite existed - and maybe that computer had a different palette. Go nuts.

Ha, I like that sort of flexibility! Of course, it'll be exactly half a minute before the historical revisionism starts popping up on youtube (I can already visualize those "CGA with the C64 palette!!" videos)... but that's probably not a good enough reason to spoil the fun. You could have your 'paper white', plasma orange, no-backlight mono LCD palettes, etc.

GloriousCow wrote on 2023-12-10, 16:17:

Another thing I was pondering, is that we can have a custom renderer just for screenshots. Obviously we can take our sweet time rendering out a screenshot compared to blitting it on screen in realtime, so we can do all sorts of software processing.
One of the more interesting scenarios here I was thinking about: Could your ffmpeg scripts run on a single frame and output a single frame?

Sure, just feed a .png file to ffcrt.bat as the input. That way it's even somewhat snappier than watching paint dry. 😉

GloriousCow wrote on 2023-12-10, 23:44:

Spent the day trying to fix DPI scaling, fun. But I threw the GUI zoom option in while I was at it. […]
Show full quote

Spent the day trying to fix DPI scaling, fun. But I threw the GUI zoom option in while I was at it.

Here's 50% ( at 1.25 DPI scale)

gui_scale.PNG

You can shrink the windows down to near zero, with hilarious results. I tried to make a zoom slider but of course it's really hard to hold on to something that is actively growing or shrinking while you move it...

Bullseye! Yeah, a simple config setting should do just fine - it's probably "set-and-forget" once you find the size that works for you.
I'm temporarily stuck with a high-DPI laptop monitor, where none of the program-specific "compatibility" scaling options get it quite right, so that's what probably drove me to make the suggestion... but whenever you have lots of those debug widgets open simultaneously, this could be very helpful on any monitor.

GloriousCow wrote on 2023-12-11, 04:30:

VileR (or anyone else that's interested, I suppose)...

https://github.com/grantshandy/egui-themer

If you want to create a custom theme of your liking using this tool, export it and attach it here or otherwise find a way to get it to me, and i'll build your theme into MartyPC 😀

Ooh nice- I might have a go at it, although the gray theme you showed here already looks plenty good enough.
Could still be fun to try a beige/silver and black color scheme, to match the look of the IBM PC/XT/AT and peripherals. Or maybe to pay tribute to IBM's "Big Blue" byname.

VileR wrote on 2023-12-11, 14:59:

Ooh nice- I might have a go at it, although the gray theme you showed here already looks plenty good enough.

That's the default dark theme! if you comment out the 'theme_color' line, you can have it right now.

I'm slowly running out of features to implement in the new display manager. Full screen mode is in, and in ultrawide, it looks quite nice:

Coolness. It it already available somewhere?

jal wrote on 2023-12-12, 10:21:

Coolness. It it already available somewhere?

You can build the default branch if you want, but no releases yet. I was poking at Github CI to see if I could somehow get build on merge working, but I don't want to get too distracted messing with it. (If someone would be willing to help out there, I'd be very grateful).

I am really hoping to get a release out before the end of the year, it's just a matter of how many features I can cram in before then.
After this, I hope that future versions come out on a more rapid schedule and I'm able to integrate people's feedback in a more timely way. 0.2.0 is just addressing a LOT of technical debt from bad design decisions - it's my first emulator, after all, I wasn't going to design things right the first time. I've got a much more sensible design now to build upon. Just about every part of the emulator was refactored in some way.

GloriousCow wrote on 2023-12-12, 16:06:

0.2.0 is just addressing a LOT of technical debt from bad design decisions - it's my first emulator, after all, I wasn't going to design things right the first time.

Yea, isn't that the thing with software engineering... You need to build something to figure out how you should build it.

Scali wrote on 2023-12-12, 16:34:

Yea, isn't that the thing with software engineering... You need to build something to figure out how you should build it.

Lol, yeah, quoted for truth 😁.

JAL

VileR wrote on 2023-12-11, 14:59:

Sure, just feed a .png file to ffcrt.bat as the input. That way it's even somewhat snappier than watching paint dry. 😉

I hate to ask but would you consider a conversion of this bat file to python or sh for our linux and mac friends?

jal wrote on 2023-12-15, 10:30:

Scali wrote on 2023-12-12, 16:34:

Yea, isn't that the thing with software engineering... You need to build something to figure out how you should build it.

Lol, yeah, quoted for truth 😁.

JAL

Quite a bit of my code in Area 5150 is living testament to this principle...

GloriousCow wrote on 2023-12-15, 20:33:

I hate to ask but would you consider a conversion of this bat file to python or sh for our linux and mac friends?

Someone has already forked it and added a Python version. Haven't had the chance to test it myself, but it's at https://github.com/vegardsjo/FFmpeg-CRT-transform.

I really should've used python (or something like it) from the start... honestly, if I ever get around to doing more work on that script, I'll probably switch to python; it's certainly less cumbersome than batch scripting.

MDA needs a bit of polish but it basically works. Still need to implement 9th column glyph drawing and underline attributes...

But I was excited to share that CGA + MDA is now possible:

Very nice!

jal wrote on 2023-12-16, 20:35:

Very nice!

Thanks, it was one of the main motivations for the new display system, so i'm glad to see that finally paying off.

My CRT shader needs to be able to take a 'margin' parameter for cards that don't really produce appreciable border areas in their display fields. There's still a 'border' seen on a 5151 monitor, but it's not represented really by the CRTC timings, like it is with a CGA or a EGA in 15Khz mode, so stuff is a bit too close to the edge of the bezels as you can see here.

This means that shader profiles will be a bit monitor-specific, so you'd have a 5151 profile that adds margins and a 5153 profile that does not. But that's kinda cool, in a way.

I'm tempted to steal Tom Harte's PLL code because seeing the picture roll and 'bounce' a bit on mode changes is pretty darn cool.

I've added two much requested features, external ROM set definitions and machine configuration profiles. Previously, the ROM database was hardcoded, now it is read from TOML files in the ROM directory (which now supports subdirectories). So variants / different dumps can be easily added, and ROM developers can define their own sets. You can even set a flag that will reload a ROM set from disk when the machine is restarted.

Machine configurations define what options and peripherals are present on a top of a base machine type (which are not yet configurable, themselves, but eventually...)
So you can switch from say, an IBM 5150 with 64K of RAM and only one floppy drive, to a 5160 with a hard disk and EGA card, just with one command line parameter. You can now define how many floppies, serial ports, and. video cards you have. (or none of the above!) You can specify a specific ROM set to use, or let MartyPC autodetect the best available (newest) ROM set.

A new --romscan command line argument will list detected ROMs and what machine configurations are available based on the ROMs detected, which should help people figure out what they need, as MartyPC's ROM handling has been a bit of a sore point.