DaveDDS wrote on 2025-05-23, 19:31:

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.

Okay. I apologize if I've been misreading your tone, but I feel like I've been on the defensive this whole thread.

DaveDDS wrote on 2025-05-23, 19:31:

Any chance MartyPC might support 286/386 someday?

I would like to support the 286. The advantages of a cycle-accurate emulator for 286 are already a bit questionable, so it will probably stop there.
I may write a 386 or "generic x86" emulator someday for fun but it probably won't be under the MartyPC banner. But we'll see. There are efforts to decode the 386 microcode afoot as we speak, so that may be something that intrigues me enough to attempt.

GloriousCow, just read your latest blog post about the Lake Effect - quite impressive, and a very interesting read!

JAL

jal wrote on 2025-05-23, 21:25:

GloriousCow, just read your latest blog post about the Lake Effect - quite impressive, and a very interesting read!

Thanks, glad you liked it! I need to blog more - I have another one coming out soon about what I've learned so far about 16-bit bus access, speaking of the 286 and all. The mechanism by which 16-bit IO is converted to 8-bit IO for backwards compatibility is quite interesting.

GloriousCow wrote on 2025-05-23, 22:16:

jal wrote on 2025-05-23, 21:25:

GloriousCow, just read your latest blog post about the Lake Effect - quite impressive, and a very interesting read!

Thanks, glad you liked it! I need to blog more - I have another one coming out soon about what I've learned so far about 16-bit bus access, speaking of the 286 and all. The mechanism by which 16-bit IO is converted to 8-bit IO for backwards compatibility is quite interesting.

Interestingly enough, the 286 BIOS (for the IBM AT) does actually require cycle-accuracy to POST. It performs a loop (using the LOOP[nz/z] set of instructions) very early in it's POST, only allowing to proceed if the loop counter (of two nested loops if I remember correctly) is within a very small range of some 10 loops. If the range is outside that, it will beep the PC speaker and halt.
I don't know if the IBM PS/1 or PS/2 requires ot too though. Interestingly, my laptop I develop my emulator on currently (not my desktop I do most work on though, which is older) might be a successor to the IBM PS/2 from what I can see on wikipedia (through the ThinkPad line successors through Lenovo). Wikipedia lists it up to the Lenovo 3000 series, but they might be related to the IBM brand (back to PS/2) perhaps, in it's development?

jal wrote on 2025-05-23, 08:25:

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

Found that Rick 2 video from your comment- haven't seen that before, nice work! Is there a current link to your mod anywhere?

Thanks for the heads up on the North Star page... changed it to point to Wayback Machine's copy, as that page is more informative. Real shame about old-computers.com, hope it gets restored at some point.

SoftCat wrote on 2025-05-23, 10:19:

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

Yes, which brings down the vertical refresh to 59.02 Hz. Close enough to nominal to play nice with most monitors.

Those 4 extra lines shouldn't be strictly necessary: if you set the vertical displayed area to 240 scanlines, vertical blanking can start immediately after that - this lasts for 16 scanlines, so when that ends Vertical Adjust can be 6, and you're still at the normal total of 262 lines. Maybe the extra lines here are for better centering.
Some of the "borderless" sections in Area 5150 display 246 active scanlines without changing the vertical frequency, although not all may be literally visible, since this mode is kinda meant to cover the entire overscan area.

Regarding the 8080 mode, I found this:
https://pastraiser.com/cpu/i8080/i8080_opcodes.html

Is that actually what the 8080 manual specifies for it's instructions (in the NEC V20/V30 8080 mode)?
What about the instructions marked with an asterisk?

VileR wrote on 2025-05-25, 12:17:

Yes, which brings down the vertical refresh to 59.02 Hz. Close enough to nominal to play nice with most monitors.

Those 4 extra lines shouldn't be strictly necessary: if you set the vertical displayed area to 240 scanlines, vertical blanking can start immediately after that - this lasts for 16 scanlines, so when that ends Vertical Adjust can be 6, and you're still at the normal total of 262 lines. Maybe the extra lines here are for better centering.
Some of the "borderless" sections in Area 5150 display 246 active scanlines without changing the vertical frequency, although not all may be literally visible, since this mode is kinda meant to cover the entire overscan area.

I see, thank you for the explanation!
Tell me, was this issue resolved more or less sensibly?
https://www.reenigne.org/misc/cga_font.txt

superfury wrote on 2025-05-25, 13:15:

Regarding the 8080 mode, I found this: https://pastraiser.com/cpu/i8080/i8080_opcodes.html […]
Show full quote

Regarding the 8080 mode, I found this:
https://pastraiser.com/cpu/i8080/i8080_opcodes.html

Is that actually what the 8080 manual specifies for it's instructions (in the NEC V20/V30 8080 mode)?
What about the instructions marked with an asterisk?

See attached chart.
The undefined instructions on V20 do weird things, in a similar way that that the undefined instructions on V20 in native mode do. Some of them may be aliases for other instructions, but take longer.

I'm making 8080-mode V20 tests, but I had no luck convincing you to use my CPU tests in the past, so that probably won't help.

GloriousCow wrote on 2025-05-25, 15:20:

See attached chart. The undefined instructions on V20 do weird things, in a similar way that that the undefined instructions on […]
Show full quote

superfury wrote on 2025-05-25, 13:15:

Regarding the 8080 mode, I found this: https://pastraiser.com/cpu/i8080/i8080_opcodes.html […]
Show full quote

Regarding the 8080 mode, I found this:
https://pastraiser.com/cpu/i8080/i8080_opcodes.html

Is that actually what the 8080 manual specifies for it's instructions (in the NEC V20/V30 8080 mode)?
What about the instructions marked with an asterisk?

See attached chart.
The undefined instructions on V20 do weird things, in a similar way that that the undefined instructions on V20 in native mode do. Some of them may be aliases for other instructions, but take longer.

I'm making 8080-mode V20 tests, but I had no luck convincing you to use my CPU tests in the past, so that probably won't help.

OK. That should be doable.
What happens with undefined ('-' marked) instructions? Do they throw an #UD exception?

superfury wrote on 2025-05-25, 15:46:

What happens with undefined ('-' marked) instructions? Do they throw an #UD exception?

AFAIK, the V20/V30 doesn't implement the #UD exception.

superfury wrote on 2025-05-25, 15:46:

OK. That should be doable.
What happens with undefined ('-' marked) instructions? Do they throw an #UD exception?

V20 has no UD. They do weird things. My theory is that they end up in undefined microcode slots.

I'm currently converting the CPU tests to a binary format, with included ANSI C to read them. No JSON, no Rust required.
I don't know if that piques your interest or not.

VileR wrote on 2025-05-25, 12:08:

Found that Rick 2 video from your comment- haven't seen that before, nice work! Is there a current link to your mod anywhere?

Unfortunately not (yet), it's not 100% perfect yet, and I've been wanting to rewrite RD2 for a while now since it's dog slow on an original PC (regardless of graphics) as it's clearly written by someone without any knowledge on 8086 assembly, and the CGA video driver is very inefficient. But if you DM me I could send you a copy. (On that channel you can also see the other levels, played in and recorded with DosBox.)

JAL

mkarcher wrote on 2025-05-25, 15:49:

superfury wrote on 2025-05-25, 15:46:

What happens with undefined ('-' marked) instructions? Do they throw an #UD exception?

AFAIK, the V20/V30 doesn't implement the #UD exception.

Really? Isn't it implementing the 80186 instruction set, which defined the #UD exception for the first time?
Edit: Checked both NEC V20 and V30 manuals. Indeed, it implements 80186 instructions, but unlike the 80186, no #UD vector is implemented? Doesn't that break 80186 software?

superfury wrote on 2025-05-26, 22:27:

Really? Isn't it implementing the 80186 instruction set, which defined the #UD exception for the first time?
Edit: Checked both NEC V20 and V30 manuals. Indeed, it implements 80186 instructions, but unlike the 80186, no #UD vector is implemented? Doesn't that break 80186 software?

Why would said software require UD exceptions to function?

superfury wrote on 2025-05-26, 22:27:

Edit: Checked both NEC V20 and V30 manuals. Indeed, it implements 80186 instructions, but unlike the 80186, no #UD vector is implemented? Doesn't that break 80186 software?

Implementing the 80186 instruction set, which was by and large also the 80286 real mode instruction set, has little to do with software written for the 80186, as the 80186 is what we'd nowadays call a microcontroller, having peripherals like interrupt controller, DMA controller and timers internally. However, they reside at different addresses than the PC/XT had them, so it's not possible to build a PC compatible using a 80186. So software targeting the 80186 would have larger problems than the absence of an undefined opcode exception.

JAL

jal wrote on 2025-05-27, 17:27:

Implementing the 80186 instruction set, which was by and large also the 80286 real mode instruction set, has little to do with software written for the 80186, as the 80186 is what we'd nowadays call a microcontroller, having peripherals like interrupt controller, DMA controller and timers internally. However, they reside at different addresses than the PC/XT had them, so it's not possible to build a PC compatible using a 80186. So software targeting the 80186 would have larger problems than the absence of an undefined opcode exception.

It's not just that the 80186 peripherals reside at different addresses than the PC peripherals, they are also designed differently. The PC peripherals are actually 8080 peripherals, and generally designed for 8-bit systems. The interface between the 8088 and those peripherals is just 8 bits wide (not that surprising, as the 8088 doesn't have a 16-bit data bus). On the other hand, the peripherals on the 80186 generally make use of the 16-bit internal bus width - even in the 80188. The programming interface of the 80186 peripherals is different to the interface of the PC peripherals.

GloriousCow wrote on 2025-05-23, 19:01:

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

I've "published" an improved edition of my emulator-testing tool on my site,
and started a topic to let people know it exists:

Tool to help evaluate emulator .vs. actual PC performance

mkarcher wrote on 2025-05-27, 19:11:

It's not just that the 80186 peripherals reside at different addresses than the PC peripherals, they are also designed differently. The PC peripherals are actually 8080 peripherals, and generally designed for 8-bit systems. The interface between the 8088 and those peripherals is just 8 bits wide (not that surprising, as the 8088 doesn't have a 16-bit data bus). On the other hand, the peripherals on the 80186 generally make use of the 16-bit internal bus width - even in the 80188. The programming interface of the 80186 peripherals is different to the interface of the PC peripherals.

Thanks, didn't know the 8018x used different peripherals. Good to know.

JAL

so it's not possible to build a PC compatible using a 80186

This isn't quite true and although it doesn't make a lot of sense there is one real example of it, the Triumph-Adler P50. It would be more accurate to say that it's not possible to build a PC compatible using a 80186's internal peripherals.