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?

GloriousCow wrote on Today, 14:10:

Can you try the web version of MartyPC at least?

Sure: MSDOS 2.11 booted on MartyPC (WEB)

1                                                                              
2           0+         632                                                       
3         632+         603                                                       
4        1235+         603                                                       
5        1838+         638                                                       
6        2476+         603                                                       
7        3079+         604                                                       
8        3683+         603                                                       
9        4286+         603                                                       
10        4889+         638                                                       
11        5527+         603                                                       
12        6130/          10=         613                                          

Seems pretty abysmal, but I don't know how indicative a "web" application
would be over the native MartyPC running on my machine.

Does the WEB version download some sort of actual (native host) executable,
is it in some sort of interpreted code?

Perhaps because the test pgm does call DOS to get the current time, on every
look, and actually prints that time when the second changes this may take
longer via the web. The times do seem to still be coming out at good 1second
intervals.

It does just buffer the loop-counts and perform the addition display and
average calculation after the test in finished.

Just for "fun" I'll run the test on my "real" DOS systems and see how it
compares.

And also "just for fun", here's the same program compiled for DVM
(not x86, but still an emulated processor)

1           0+     1879953
2     1879953+     1864407
3     3744360+     1858804
4     5603164+     1880892
5     7484056+     1869355
6     9353411+     1871804
7    11225215+     1856847
8    13082062+     1854945
9    14937007+     1866856
10    16803863+     1844644
11    18648507/          10=     1864850

And YES .. all these tests were done on the same I7 machine running Win7Pro

Does it use time from the PIT, from the CMOS or XT RTC(NC MM58167, can be used with TIMER/COM, also made a XT BIOS ROM supporting it: https://bitbucket.org/superfury/unipcemu_pcxtbios_at)?
UniPCemu has the option to sync the CMOS/XT RTC to the host time (updated at the client's bus speed). So every time it's client's time ticks 1/100th(1/10000 on XT) second, it polls and updates the CMOS time to either the host time or the emulated time (which is based on the cycles ticked by the emulated CPU). Of course, everything like interrupts (alarms etc.) is modified to behave like that as well, ticking at the same time, overflowing to IRQ as needed (detected using Unix timestamp difference with nanoseconds).

The BIOS option ROM basically hooks INT19(for setup), INT15(for memory storage, stealing a bit of RAM, which is mainly used for storing the INT15 handler as well as the hooked interrupt vectors inside itself, as well as installation detection) and INT1A, adding the RTC support (leaving the basic XT functionality to the motherboard BIOS).

DaveDDS wrote on Today, 16:31:

Seems pretty abysmal

Considering I have no idea what the numbers you are dumping into this thread mean, I can't even agree or disagree with you.

DaveDDS wrote on Today, 16:31:

, but I don't know how indicative a "web" application would be over the native MartyPC running on my machine. […]
Show full quote

, but I don't know how indicative a "web" application
would be over the native MartyPC running on my machine.

Does the WEB version download some sort of actual (native host) executable,
is it in some sort of interpreted code?

It's WASM. It's technically interpreted, but it is extremely fast.

DaveDDS wrote on Today, 16:31:

Perhaps because the test pgm does call DOS to get the current time, on every
look, and actually prints that time when the second changes this may take
longer via the web.

The emulated machine on the web is just as cycle-accurate as it is natively. Delays experienced in "human time" are irrelevant to any output the emulator produces.

DaveDDS wrote on Today, 16:31:

Just for "fun" I'll run the test on my "real" DOS systems and see how it
compares.

Provide the executable and I will tell you exactly what output it produces on an IBM 5150.

If the numbers are some sort of loop counter, you are comparing an unthrottled DosBox to an emulator specifically trying to be a 4.77Mhz 8088.

Here are some "real" systems...

Pentium200MMX at 200mhz

1           0+       89612
2       89612+       94580
3      184192+       89596
4      273788+       89594
5      363382+       89603
6      452985+       89603
7      542588+       94581
8      637169+       89581
9      726750+       89596
10      816346+       89581
11      905927/          10=       90592

Pentium3 at 733mhz

1           0+      124099
2      124099+      131068
3      255167+      124069
4      379236+      124170
5      503406+      124077
6      627483+      124170
7      751653+      130989
8      882642+      124162
9     1006804+      124094
10     1130898+      124145
11     1255043/          10=      125504

Pentium4 at 200mhz

1           0+      270716
2      270716+      285750
3      556466+      270712
4      827178+      270710
5     1097888+      270719
6     1368607+      270712
7     1639319+      285754
8     1925073+      270717
9     2195790+      270706
10     2466496+      270718
11     2737214/          10=      273721

VIA-C7 at 1.0ghz

1           0+       95635
2       95635+       95618
3      191253+       95620
4      286873+      100935
5      387808+       95629
6      483437+       95612
7      579049+       95629
8      674678+       95603
9      770281+      100942
10      871223+       95627
11      966850/          10=       96685

PoQet PC 8088 at 2-7mhz (docs say 2-7mhz, I've not found a way to see/chg)

1           0+        1154
2        1154+        1061
3        2215+        1074
4        3289+        1073
5        4362+        1072
6        5434+        1134
7        6568+        1073
8        7641+        1072
9        8713+        1072
10        9785+        1073
11       10858/          10=        1085

Btw, I'm not sure how indicative these tests are, because the call DOS to get
the time on every iteration of the loop (which might trigger access to RTC/IO)
and they print the time each time it changes (to help confirm that an
emulator has a good sense of "real time".

I've got some ideas which should help a lot with these and will add command
options to the test to allow me to set it up in different ways. Once I've
implemented them, I will re-run the tests on all the platforms I have and see
how much things change.

superfury wrote on Today, 16:51:

Does it use time from the PIT, from the CMOS or XT RTC(NC MM58167 ...

No, I wanted to keep hardware dependencies out of it (and also didn't want to bother for a "just for fun" couple minite pgm)

I have found DOS clock to be fairly accurate in various emulators I've tried ... It's been so long since I dealt which this stuff
at low-level, I don't recall is DOS goes through BIOS somehow and reads the RTC or it it maintains it's
own local system time.

DaveDDS wrote on Today, 18:55:

I've got some ideas which should help a lot with these and will add command options to the test to allow me to set it up in diff […]
Show full quote

I've got some ideas which should help a lot with these and will add command
options to the test to allow me to set it up in different ways. Once I've
implemented them, I will re-run the tests on all the platforms I have and see
how much things change.

These tests are interesting, but would you mind making a separate thread for them?

GloriousCow wrote on Today, 18:39:

Provide the executable and I will tell you exactly what output it produces on an IBM 5150.
If the numbers are some sort of loop counter, you are comparing an unthrottled DosBox to an emulator specifically trying to be a 4.77Mhz 8088.

It's just a loop counter from one second to the next (with a lot of INT 21h AH=2Ch calls during that second.
No real meaning to the number other than comparing one system to another.

I'll attach TIMTST.ZIP which contains TI.COM as well as TI.C so you can see exactly what it does.

Please bear in mind that this was a couple min "quick and dirty - just for fun" program, no comments
and try not to laugh too hard at it!

GloriousCow wrote on Today, 19:01:

These tests are interesting, but would you mind making a separate thread for them?

I put it here because it was related to some of the discussion we've had...

But, sure - when I've added some options, made it more accurate (perhaps I will add direct access to the hardware RTC as SuperFury
suggested) and added some comments... If anyone wants to see it further, I would certainly create a dedicated thread!

DaveDDS wrote on Today, 16:31:

Sure: MSDOS 2.11 booted on MartyPC (WEB) […]
Show full quote

Sure: MSDOS 2.11 booted on MartyPC (WEB)

Copy code to clipboard

1                                                                              
2           0+         632                                                       
3         632+         603                                                       
4        1235+         603                                                       
5        1838+         638                                                       
6        2476+         603                                                       
7        3079+         604                                                       
8        3683+         603                                                       
9        4286+         603                                                       
10        4889+         638                                                       
11        5527+         603                                                       
12        6130/          10=         613                                          

Seems pretty abysmal, but I don't know how indicative a "web" application
would be over the native MartyPC running on my machine.

Here are the results from a 4.77 MHZ 8088 in an IBM 5150, the same system that MartyPC emulates by default.

I think there is a bit of a misunderstanding of what MartyPC's aims are. It is not attempting to be the fastest x86 emulator. It is trying to very accurately emulate an IBM 5150/5160.
In this case, I would argue these results are quite good.

GloriousCow wrote on Today, 19:21:

I think there is a bit of a misunderstanding of what MartyPC's aims are. It is not attempting to be the fastest x86 emulator. It is trying to very accurately emulate an IBM 5150/5160.
In this case, I would argue these results are quite good.

To be honest, my "abysmal" comment was more in comparison to others, and I don't have any working
original 4.77mhz 8088 machines any more, and I'd forgotten how slow they are.

Looks like MartyPC is indeed more accurate.

Btw I think the 86box number is higher because I had to set to 386SX mainly because my boot disk used a RamDisk
in XMS... For MartyPC I had to ignore the error and figure out a way to get the output off other than redirecting to
a ramfile (which I then copied back to the FD and could extract)
(When I tried to redirect to A: in web version, it "worked" in that the file appeared,
but my image file that I had mounted was not updated)

Any chance MartyPC might support 286/386 someday?