GloriousCow wrote on Yesterday, 16:11:

I will say that I love the language, I love coding in it. I feel more productive in Rust that I ever was in C. The main advanta […]
Show full quote

I will say that I love the language, I love coding in it. I feel more productive in Rust that I ever was in C. The main advantage is that I've kept up with it for three years now, unlike other projects I have attempted that usually sputter out after some months where I get frustrated or lose interest. I don't need to explain that to any programmer, we all have large directories full of half-completed projects.

That said, in terms of people being able to use my code, read it, fork it, port it, or attract collaborators, Rust has not been ideal. The 86Box project has wanted to adopt MartyPC's 8088 core emulation, but they have to laboriously translate Rust-isms with no direct equivalents in C.

If I was starting over today to make a high-performance cross platform emulator I almost certainly would choose C++. It's too late now, though, I'm kinda stuck with it unless I want to spend an entire year or more rewriting the whole thing.

I only hope that the rust ecosystem continues to grow in a healthy manner.

Makes sense. Is there a way you could turn that core emulation into a library?

GloriousCow wrote on Yesterday, 16:11:

ps: could you reply to that issue you opened?

Sorry about that! I've been very busy at work the last few days. Just responded to it.

jal wrote on Yesterday, 14:55:

SoftCat wrote on 2025-05-21, 10:25:

What are the maximum visible screen sizes in pixels possible on a real CGA monitor (with a pixel frequency of 14.318 MHz)?
Is it possible to increase the number of visible lines by reducing the frame rate to 50 Hz?

I don't have the details, but iirc the 5153 is pretty finicky about what frequencies it can run on, and can even break in case you drive it with the wrong ones. So I very much doubt it would accept 50Hz.

Yes, 50 Hz is way too far out of spec. If you feed a 5153 the wrong frequencies, it's much less likely to break than a 5151 is, but I still wouldn't try it because it's never going to sync anyway.

If you really want *a few* more scanlines... it's possible to increase the horizontal frequency a little, which the 5153 does accept. This shortens the duration of the scanlines, and brings them closer together vertically. That pushes vertical refresh above 60 Hz, so to bring it back down to the tolerance range, you then increase the *total* scanline count. (This also modifies the pixel aspect ratio, and also makes the picture darker for some reason, but you win some you lose some.)

I was able to do 16.57 KHz (H) / 60.93 Hz (V), which got me 222 visible lines without changing the V-SIZE control (see here for details)... That's still faster than 60 Hz, which means you can likely add even more scanlines and make it a bit slower. And of course if you do change V-SIZE you could fit even more visible lines within the frame.

keenmaster486 wrote on Yesterday, 17:23:

Makes sense. Is there a way you could turn that core emulation into a library?

Not easily, no. At least, not as a clean "drop-in" CPU with a C FFI. There are a bit too many internal integrations between the CPU and peripherals, maybe I could factor those out, but there's still an inversion of ownership due to Rust's ownership model and borrow checker - you might logically structure an emulator in C++ to have a Bus upon which lives a Cpu along with Memory and any peripherals. It was easier to make Rust happy by putting everything into the CPU, so the heirarchy is not what you'd expect.

GloriousCow wrote on Yesterday, 16:11:

I don't need to explain that to any programmer, we all have large directories full of half-completed projects.

I don't know what you're talking about. 😁

JAL

VileR wrote on Yesterday, 17:37:

(see here for details)

Thanks, that was in interesting read! Now I'm tempted to adjust the horizontal displayed for my Rick Dangerous 2 CGA rewrite (as RD2, like RD1, has a 256-pixel-wide visible area) 😁. Btw, the link to "North Star Advantage" is broken, as the content of old-computers.com seems taken down. There are some other links you could use, e.g. this one.

JAL

VileR wrote on Yesterday, 17:37:

Yes, 50 Hz is way too far out of spec. If you feed a 5153 the wrong frequencies, it's much less likely to break than a 5151 is, but I still wouldn't try it because it's never going to sync anyway.

If you really want *a few* more scanlines... it's possible to increase the horizontal frequency a little, which the 5153 does accept. This shortens the duration of the scanlines, and brings them closer together vertically. That pushes vertical refresh above 60 Hz, so to bring it back down to the tolerance range, you then increase the *total* scanline count. (This also modifies the pixel aspect ratio, and also makes the picture darker for some reason, but you win some you lose some.)

I was able to do 16.57 KHz (H) / 60.93 Hz (V), which got me 222 visible lines without changing the V-SIZE control (see here for details)... That's still faster than 60 Hz, which means you can likely add even more scanlines and make it a bit slower. And of course if you do change V-SIZE you could fit even more visible lines within the frame.

Thank you for the information!
Here in Trixter's video, starting from 2:51, the 90x30 character mode (720x240 pixels) is set. The line frequency remains the same 14318/912 ~ 15700 kHz, but an additional 4 lines are added to the total number of frame lines.
https://archive.org/details/CGACompatibilityReferenceVideo

I did some very basic speed tests:

I've found that BIOS 55ms tick isn't always accurate on some emulators, but
time of day clock is much more so. The test program basically "counts" during
each second (with a bit of overhead, it did have to read the time-of-day clock
etc. between each count)... It did display the times as the second changed,
and it did seem pretty accurate over the 10 seconds that the test ran. I've
edited those time displays out of the output as they give no useful info.
(without a stop watch)

The only x86 emulators I have working so far are DosBox, VMwarePlayer and
86box - I could only get 86box to boot 360k images, and VMware to boot
1.44m - so I ended up using DOS 2.11 and 5.00:

DosBox direct (Cycles=max)

1           0+      167871
2      167871+      157711
3      325582+      157894
4      483476+      155856
5      639332+      159895
6      799227+      167897
7      967124+      157027
8     1124151+      159108
9     1283259+      158569
10     1441828+      158649
11     1600477/          10=      160047

MS-DOS 2.11 booted under DosBox

1           0+      127267
2      127267+      126339
3      253606+      129378
4      382984+      128463
5      511447+      129352
6      640799+      128622
7      769421+      127822
8      897243+      135515
9     1032758+      127404
10     1160162+      128826
11     1288988/          10=      128898

MS-DOS 2.11 booted under 86BOX (IBM AT 286)

1           0+        3383
2        3383+        3349
3        6732+        3541
4       10273+        3353
5       13626+        3354
6       16980+        2977
7       19957+        3354
8       23311+        3353
9       26664+        3542
10       30206+        3353
11       33559/          10=        3355

MS-DOS 5.00 booted under DosBox

1           0+       96752
2       96752+       91501
3      188253+       90086
4      278339+       90514
5      368853+       89763
6      458616+       96621
7      555237+       88096
8      643333+       91144
9      734477+       91197
10      825674+       89693
11      915367/          10=       91536

MS-DOS 5.00 booted under VMWARE Player 7

1           0+      147794
2      147794+      156330
3      304124+      148641
4      452765+      148625
5      601390+      147869
6      749259+      148511
7      897770+      157437
8     1055207+      148506
9     1203713+      147451
10     1351164+      148662
11     1499826/          10=      149982

Can't say they are super-accurate (it was a very quick-and-dirty test), but clearly DosBox is *way* faster than 86box
(and it really feels it) - there may be more settings I can use to improve it - I'll have to keep playing.

(Forgot one)
MS-DOS Player (i8086) for Win32 console

1           0+     1652202
2     1652202+     1653233
3     3305435+     1635576
4     4941011+     1652354
5     6593365+     1650668
6     8244033+     1646306
7     9890339+     1653886
8    11544225+     1663768
9    13207993+     1655537
10    14863530+     1654762
11    16518292/          10=     1651829

DaveDDS wrote on Today, 11:52:

(Forgot one)
MS-DOS Player (i8086) for Win32 console

Can you try the web version of MartyPC at least?