crazyc wrote on 2025-05-28, 22:50:

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.

I think the point is that one would have to disable the onboard peripherals on the 186, then duplicate their functionality with external chips.
But I'm mainly replying to mention that there were some NEC versions of an "IBM-compatible 80186" like the V41; where they too late or rare to make more of an impact?

The Hercules video card can be configured to generate a video signal with CGA frequencies (15.7 kHz and 60 Hz). Even the video RAM can be organized the same way as the CGA. I just don't know if a monochrome monitor will understand it. If you re-solder just one contact in the cable, you can connect it to a CGA monitor and the monochrome 640x200 mode will work.

crazyc wrote on 2025-05-28, 22:50:

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.

Yeah, that could be the case, although I haven't checked the exact addresses of the built-in stuff to see if they never cause any problems.

JAL

SoftCat wrote on 2025-05-29, 13:22:

The Hercules video card can be configured to generate a video signal with CGA frequencies (15.7 kHz and 60 Hz). Even the video RAM can be organized the same way as the CGA. I just don't know if a monochrome monitor will understand it. If you re-solder just one contact in the cable, you can connect it to a CGA monitor and the monochrome 640x200 mode will work.

The RAM on a Hercules card is organized the same way as the CGA, since it uses the same text mode scheme (1 byte character, 1 byte attribute), and the same 6845 as the CGA does, with its limitations. Except that in Hercules graphics mode, the 6845 is programmed with a character height of 4 (instead of the 2 for CGA), to be able to access all of its 384 lines, so the odd/even line problem with CGA is twice as bad, having four interlaced address blocks.

JAL

jal wrote on 2025-05-29, 19:13:

Yeah, that could be the case, although I haven't checked the exact addresses of the built-in stuff to see if they never cause any problems.

The address of the built-in peripherals is configurable, and you can e.g. set them to I/O addresses FF00..FFFF which is not going to conflict with any ISA-type hardware that is usually limited to the range 0..3FF.

jal wrote on 2025-05-29, 19:19:

The RAM on a Hercules card is organized the same way as the CGA, since it uses the same text mode scheme (1 byte character, 1 byte attribute), and the same 6845 as the CGA does, with its limitations. Except that in Hercules graphics mode, the 6845 is programmed with a character height of 4 (instead of the 2 for CGA), to be able to access all of its 384 lines, so the odd/even line problem with CGA is twice as bad, having four interlaced address blocks.

Yes, I am aware of that. Only Hercules has 348 lines in graphics mode, 2 less than EGA. In CGA compatibility mode, Hercules can be programmed to have a character height of 2. Apparently, you will need a CGA monitor for that.

SoftCat wrote on 2025-05-29, 13:22:

The Hercules video card can be configured to generate a video signal with CGA frequencies (15.7 kHz and 60 Hz). Even the video RAM can be organized the same way as the CGA. I just don't know if a monochrome monitor will understand it. If you re-solder just one contact in the cable, you can connect it to a CGA monitor and the monochrome 640x200 mode will work.

Yes, also CGA monitor needs positive V-SYNC polarity. So this signal needs to be inverted. Probably it will be too complicated for such a trivial purpose.

MartyPC 0.4.1 has been released. Mostly bugfixes, but we added the V20's 8080 emulation mode and some additional geometries for the Xebec controller.

I fixed the static compilation so it should no longer need any MSVC runtimes.

Is it possible to make a pseudo-graphic mode 128x128 (with R9 = 0) on CGA? How should CRTC be programmed? Everything is clear with horizontal parameters. What about vertical parameters? There will probably be more than one area.

SoftCat wrote on 2025-06-04, 12:35:

Is it possible to make a pseudo-graphic mode 128x128 (with R9 = 0) on CGA? How should CRTC be programmed? Everything is clear with horizontal parameters. What about vertical parameters? There will probably be more than one area.

You should probably make a new topic for this, but the problem with R9=0 is that the CRTC only has 7 bits (so can only count 128 rows + up to 31 scanlines of vertical total adjust) but CGA monitors require 262 scanlines. So setting R9=0 implies that you need to do some frame-stacking tricks to get enough scanlines between vsyncs. Is that what you mean by "there will probably be more than one area"? If not, what do you mean?

reenigne wrote on 2025-06-04, 12:55:

So setting R9=0 implies that you need to do some frame-stacking tricks to get enough scanlines between vsyncs. Is that what you mean by "there will probably be more than one area"? If not, what do you mean?

Yes, that's what I mean. How do I do the tricks to get 262 lines in a frame?
New topic here:
CGA pseudo-graphic modes

SoftCat wrote on 2025-06-04, 13:01:

reenigne wrote on 2025-06-04, 12:55:

So setting R9=0 implies that you need to do some frame-stacking tricks to get enough scanlines between vsyncs. Is that what you mean by "there will probably be more than one area"? If not, what do you mean?

Yes, that's what I mean. How do I do the tricks to get 262 lines in a frame?

The easy way is to read the CGA status register in a tight loop. Or rather several tight loops: one to find the vsync pulse, then one to find the start of the active area, then as many as you need to find the scanline that you want. Once you've synchronised the CPU with the CRTC you can reprogram CRTC registers on particular scanlines to set up the sequence of CRTC frames that you want. For example, you might set up a 127 scanline frame, then a 135 scanline frame. You'll need to program the vertical sync position register differently in the different CRTC frames as well as vertical total adjust and vertical displayed. You might also want to change the start address registers if you don't want to display the same thing in both frames. https://github.com/reenigne/reenigne/blob/mas … 00line/l100.asm is the source for the portraits effect in 8088 MPH so you can study that as an example and play around with it.

That way involves the CPU spending a lot of time reading the CGA status register, so the more advanced way is to set up the PIT to fire IRQ0 at appropriate times in the frame. By programming new periods into port 0x40 (without resetting the PIT by writing to port 0x43) you can have IRQ0s occurring at irregular intervals (e.g. scanline 0 and 100). We used that trick in some places in 8088 MPH and Area 5150. It leaves more CPU time free for other things, but is more complicated to set up, and one must be aware that interrupts being disabled for too long might lead to the effect breaking.

reenigne wrote on 2025-06-04, 13:28:

The easy way is to read the CGA status register in a tight loop. Or rather several tight loops: one to find the vsync pulse, then one to find the start of the active area, then as many as you need to find the scanline that you want. Once you've synchronised the CPU with the CRTC you can reprogram CRTC registers on particular scanlines to set up the sequence of CRTC frames that you want. For example, you might set up a 127 scanline frame, then a 135 scanline frame. You'll need to program the vertical sync position register differently in the different CRTC frames as well as vertical total adjust and vertical displayed. You might also want to change the start address registers if you don't want to display the same thing in both frames. https://github.com/reenigne/reenigne/blob/mas … 00line/l100.asm is the source for the portraits effect in 8088 MPH so you can study that as an example and play around with it.

That way involves the CPU spending a lot of time reading the CGA status register, so the more advanced way is to set up the PIT to fire IRQ0 at appropriate times in the frame. By programming new periods into port 0x40 (without resetting the PIT by writing to port 0x43) you can have IRQ0s occurring at irregular intervals (e.g. scanline 0 and 100). We used that trick in some places in 8088 MPH and Area 5150. It leaves more CPU time free for other things, but is more complicated to set up, and one must be aware that interrupts being disabled for too long might lead to the effect breaking.

Thank you very much for your detailed answer!
Please tell me, is it necessary to add 1 to registers R2, R3 and R7 to get the corresponding values? That is, if, for example, R3 = 15, then horizontal sync width = 15 or 16? What happens if R3 = 0? Otherwise, they write differently everywhere.

Hello! First time poster here. Just wanted to drop in to say that MartyPC is AWESOME!

Also, I really hope that someday MartyPC will support 286 and 386. You see, I've been doing a little assembly programming lately, and I've found that Dosbox is not accurate at all. For example, I made two versions of a the same smooth scrolling vga game "engine". On DosBox they were equally fast, but on real hardware the other one was waaay slower.

It would be nice to program using emulator for compiling and testing and knowing that your code will run the same on real hardware . It would make developing a lot easier and more flexible.

Anyhow, thank you very much for brilliant work!

86Box will get you far closer, and hyperaccuracy is not as important with 286 and 386 class machines as with the original IBM PC.

keenmaster486 wrote on 2025-08-26, 18:58:

86Box will get you far closer, and hyperaccuracy is not as important with 286 and 386 class machines as with the original IBM PC.

Thanks for the advice, I'm going to give it a go! I'm sure you're right about the accuracy. Nevertheless, I think cycle accuracy is somehow intriguing...

For a cycle exact true emulator like MartyPC, the NEC 8086 clones, like V30 and up, it's way more interesting to simulate how fast and capable a non-286 system could have been, it was me wondering about this, in my comment here : Re: The FrankenTandy 1000 SL: fastest XT in the world?

and there is the story of V'Ger XT, too : https://archive.md/UrCZD

this list too https://www.mobygames.com/game/attribute:64/s … t:-date/page:1/

There's weird stuff too, like the Inboard XT/AT 386 boards.
A 386 (or 486) CPU with 4MB 32-bit memory expansion on a XT or AT board. A bit of a middle ground between a XT/AT and a Compaq Deskpro 386, but crippled.

Been reading this thread, and just wanted to say a little something about cycle accurate emulation. If nothing else, for argument's sake …

Let’s take, say, for example an IBM Personal Computer AT, model 5170 with an EGA. Never had it, and probably never will. Still, I would love to see it programmed in the same way as 5150 (with a CGA and 640 KB RAM) was with 8088 MPH and Area 5150. It would be nice to see what a demo group could get out of a 5170, if they would not to worry that their code might not work on some other similar computers.

And taking that thought further, perhaps the same applies for all DOS computers. It would be interesting if a random 386 PC with a random VGA card would be treated as an individual computer and programmed as such. Yes, only a handful or even one such computer (I mean exactly alike) computer might even exist, so there would not be too many people who could run the demo on real hardware, but then again, for example, I cannot run 8088 MPH at home but I still enjoyed it via YouTube. (And hey, if I’m lucky, I might even experience it on a true 5150 on some day, maybe at a special demo convention or in some computer museum.)

But, to make the IBM 5170 AT/EGA demo of your dreams, you will need the real deal with real EGA monitor, and you will have to do all the programming and debugging with that old and delicate piece of hardware. Then again, if you don’t have 5150 but you do have the AWESOME MartyPC emulator, you can make a demo for a real 5150 and be 100 % sure that your code will work correctly on real hardware.

So, cycle accurate 5170 (for example) emulation might be a fun thing after all!

Oh well, dunno, just a thought. Maybe there are not people who are interested in making this type of demos anyway, or maybe quirks and glitches that need hyper accurate emulation to be exploited don’t even exist.

And yeah for sure, DosBox and 86Box will probably be more than sufficient for testing my own amateurish assembly code for 286/386. But still, I just love MartyPC’s debugging features and the IDEA of accurateness! And for some reason 86Box makes my Mode Y smooth scrolling VGA "engine" jitter a LOT while on real hardware it is butter smooth. Maybe that just a 70hz thing on my 60hz laptop screen… Luckily on DosBox it does not jitter so badly, even though it is not certainly as smooth as on real hardware.

I was thinking about doing some timing experiments on horizontal and vertical blanks and syncs with PIT, maybe to create some sort of vblank interrupts or something like that, but somehow I’m not comfortable about the idea on current emulators. Probably need not to worry though!

Whoops a long post, sorry about that...

It is true that there is a lot that has been unexplored in EGA. It has some advanced text features that don't get used much.