superfury wrote on 2024-02-18, 18:22:

GloriousCow wrote on 2024-02-18, 14:54:

FantasyLand doesn't seem to use pel panning, which is interesting. It uses the preset row scan register for smooth vertical scrolling, but horizontal scrolling appears character based.

Just curious, how do you handle the monitor's borders? I get weirdly sized black borders on top,bottom,left,right (at non-equal widths according to VGA signal specs) of blanking in UniPCemu? Do you perform some special post-processing when displaying that (happens on all video cards, depending on the mode. The only graphics mode that seems horizontally centered is 640x480 mode 13h it seems)? Usually a small left and large right side blanked border?

Here's an a debug view:

Dark blue is hblank, bright blue hsync period.
Magenta at the bottom is vsync. I end up showing the border through vblank as it's quite long.

This represents the entire internal display field buffer - this is always scanned out, but usually only some aperture into it is displayed. When we reach hsync, we begin a fixed count after which we return to the left edge of the buffer, when we reach vsync, we begin a fixed count after which we return to the top of the buffer. This is a rough simulation of a monitor - a monitor will only spend so much time in hsync or vsync even if those periods are programmed very long. This also takes into account the programmed value of horizontal retrace delay.

An aperture definition in MartyPC is basically an X,Y offset into this buffer plus a width and height. There is one set of apertures per pixel clock, and the user is presented with the options to fully crop the image (for traditional, borderless resolutions) , view 'monitor-accurate' overscan, or view the entire display field (debug view)

For EGA, the 14Mhz display field buffer is 912x262, same as CGA.
The 16.257Mhz display field buffer is 744x365.

- Anyone happen to know why sometimes the forum won't show inline images?

GloriousCow wrote on 2024-02-18, 19:01:

Anyone happen to know why sometimes the forum won't show inline images?

Yeah, it's weird. I asked the same thing months ago in the forum feedback thread and got nothing, which must mean that this extremely convoluted issue is still being feverishly investigated. 😉

GloriousCow wrote on 2024-02-18, 14:54:

FantasyLand doesn't seem to use pel panning, which is interesting. It uses the preset row scan register for smooth vertical scrolling, but horizontal scrolling appears character based.

Hmm - I'll admit that I was lazy and only looked it up on youtube (https://www.youtube.com/watch?v=czfGt5iNuSQ), but if I pause the video and then use the ",/." keys to go frame-by-frame, I can see the horizontal component panning at sub-character intervals... it's noticeable at 2:39 or 2:52, for instance.

VileR wrote on 2024-02-18, 20:43:

GloriousCow wrote on 2024-02-18, 14:54:

FantasyLand doesn't seem to use pel panning, which is interesting. It uses the preset row scan register for smooth vertical scrolling, but horizontal scrolling appears character based.

Hmm - I'll admit that I was lazy and only looked it up on youtube (https://www.youtube.com/watch?v=czfGt5iNuSQ), but if I pause the video and then use the ",/." keys to go frame-by-frame, I can see the horizontal component panning at sub-character intervals... it's noticeable at 2:39 or 2:52, for instance.

Seems like it, doesn't it. I was just looking at the pel panning readout in my debug window, and it just seemed to stay 0, but that can suffer from aliasing effects.

EDIT: confirmed with a debug that the pel panning register never gets written to, except for 0. although, i wouldn't count it out - it could be handled in the irq2 ISR which I am not executing due to lack of vsync interrupts.

EDIT2: Ok, got irq2 hooked up to the EGA. Despite having a bit to clear the interrupt, it looks like the interrupt should clear automatically at the end of vsync, which makes me wonder what the point of that bit is... but anyway fantasyland is now setting the pel pan register, but using values 0-F. Not sure what is supposed to happen for values above 7?

GloriousCow wrote on 2024-02-18, 21:36:

Seems like it, doesn't it. I was just looking at the pel panning readout in my debug window, and it just seemed to stay 0, but […]
Show full quote

VileR wrote on 2024-02-18, 20:43:

GloriousCow wrote on 2024-02-18, 14:54:

FantasyLand doesn't seem to use pel panning, which is interesting. It uses the preset row scan register for smooth vertical scrolling, but horizontal scrolling appears character based.

Hmm - I'll admit that I was lazy and only looked it up on youtube (https://www.youtube.com/watch?v=czfGt5iNuSQ), but if I pause the video and then use the ",/." keys to go frame-by-frame, I can see the horizontal component panning at sub-character intervals... it's noticeable at 2:39 or 2:52, for instance.

Seems like it, doesn't it. I was just looking at the pel panning readout in my debug window, and it just seemed to stay 0, but that can suffer from aliasing effects.

EDIT: confirmed with a debug that the pel panning register never gets written to, except for 0. although, i wouldn't count it out - it could be handled in the irq2 ISR which I am not executing due to lack of vsync interrupts.

EDIT2: Ok, got irq2 hooked up to the EGA. Despite having a bit to clear the interrupt, it looks like the interrupt should clear automatically at the end of vsync, which makes me wonder what the point of that bit is... but anyway fantasyland is now setting the pel pan register, but using values 0-F. Not sure what is supposed to happen for values above 7?

Afaik it depends on the pixel mode.
During 8 pixel character clocks it MOD 7. So 8-F=0-7.
During 9 pixel character clocks 8=0, 0-7=1-8. Above 8 is undocumented. I simply made it 0 there.
Perhaps it aliases 1-8 to 9+? You'd need to check real hardware on that.

superfury wrote on 2024-02-19, 08:09:

Afaik it depends on the pixel mode. During 8 pixel character clocks it MOD 7. So 8-F=0-7. During 9 pixel character clocks 8=0, 0 […]
Show full quote

Afaik it depends on the pixel mode.
During 8 pixel character clocks it MOD 7. So 8-F=0-7.
During 9 pixel character clocks 8=0, 0-7=1-8. Above 8 is undocumented. I simply made it 0 there.
Perhaps it aliases 1-8 to 9+? You'd need to check real hardware on that.

Have you tried FantasyLand in UniPCemu?

GloriousCow wrote on 2024-02-19, 13:37:

superfury wrote on 2024-02-19, 08:09:

Afaik it depends on the pixel mode. During 8 pixel character clocks it MOD 7. So 8-F=0-7. During 9 pixel character clocks 8=0, 0 […]
Show full quote

Afaik it depends on the pixel mode.
During 8 pixel character clocks it MOD 7. So 8-F=0-7.
During 9 pixel character clocks 8=0, 0-7=1-8. Above 8 is undocumented. I simply made it 0 there.
Perhaps it aliases 1-8 to 9+? You'd need to check real hardware on that.

Have you tried FantasyLand in UniPCemu?

I think I did once, but can't remember. I'll try when I have the time to try it.

I did try PGAME (https://pcem-emulator.co.uk/phpBB3/viewtopic.php?t=3089) on the VGA though (and got it running alongside Jazz Jackrabbit), which both use smooth scrolling on VGA 256-color modes.

Edit: Immediately on start-up, some odd character generator issues perhaps? Or odd/even/char height issues?

Edit: Hmm... Pressing any key to start the demo gives me a black screen for some reason?

I see that the VRAM plane 2 has actual correct fonts loaded at least.
The CRTC keeps getting a CRTC start address registers loaded with A5xx (A46D for example) values for some reason? And there's nothing to display there?
Edit: Oddly enough, that only displays the bottom overlayed part when I force it to 0?

Edit: Huh? Putting weird values into the start address causes the bottom window (the description parts that explains all within the scrolls) to be shifted left off the screen?
Edit: Weird. Forcing the top windows start to 0 still puts it at the bottom of the screen?

The row size is calculated at 190h it seems (that's in planar VRAM addresses)?

Edit: After reading some of the EGA documentation again, I noticed something. It isn't mentioned that the CRTC (3x1/3x3/3x5/3x7) index register is write-only (unlike all other index registers)? Is it actually readable on EGA?
Edit: Looking further, neither does the Sequencer index register mention that it isn't readable or write-only?
Edit: Hmmm... Perhaps some extra display types are needed to be emulated? UniPCemu defaults to EGA enhanced mode. So now I'll need to add the CGA-compatible EGA (on on on off) and CGA (off off off on), according to https://www.pcjs.org/software/pcx86/demo/ibm/ega/ ?

Edit: EGA normal mode added now at least fixes those interleaving empty lines?

Edit: I see the blue cursor now, as well as the top of the overlay?

The map itself seems blank. Also the latter part of the overlay isn't rendered somehow? It's just the top bit of the 'scroll' on left and right borders?

Edit: Ah! It eventually displays the animations just fine?

Most VRAM plane 0/1 rendered are filled with nothing (black) somehow though? But the 'cursor' animation is displayed.

Edit: OK. Compared to the pcjs emulator it's displaying the scrolls in it's entirety (PCJS seems to cut off the bottom 2 character rows containing the bottom of the scroll)?
The scroll (top window as the VGA calls it, the split window at address 0) seems to render fine now.
The display is configured for CGA 5153 mode now.

The map itself is still empty/blank (like it's black text etc. on black background, except for the cursor/eye) somehow? But I can see it's actually scrolling about, as I see the messages change in the top window and the cursor is obviously showing scrolling and 'recentering' (as good as that works in text mode) while doing so.

Perhaps some VRAM (the map itself to be exact) is being written to the wrong memory location somehow?
Edit: Hmmm... What if one of the maps isn't loaded into VRAM?
I have drive A and B mirrored by mounting the same disk image in read-only mode.

Edit: Hmmm...

But that didn’t completely solve all the problems. Just before FLAND.EXE begins its automated demo, it reads three 64K files (B:ATTR.MAP, B:CHAR.MAP, and A:SPEC.MAP) directly into planes 1, 0, and 3 of EGA RAM, and for some reason, the third file is loaded from drive A, which of course fails when a different disk is in that drive.

I have it mounted as both disks, but perhaps it's not working?
That's B:ATTR.MAP and B:CHAR.MAP to be exact?

Dumped state for a bit and looked at VRAM. Plane 0 is filled with 20h only it seems and plane 1 with 07h only? Plane 2 seems to have proper font data loaded at least.
Other than the top window's text etc. (everything that's in the scrolled window at the bottom of the screen), nothing seems to be loaded in planes 0 and 1? So ATTR.MAP and CHAR.MAP failed loading somehow?
I do have 2 floppy drives emulated, perhaps that's related?

Thanks to the assistance of coldbrewed I now have nightly builds of MartyPC available. These are currently based on the 0.2 branch with EGA support.

It's a little convoluted downloading them, but the process is basically go to the actions tab:
https://github.com/dbalsom/martypc/actions

Click the latest action for the platform you want (windows, linux or mac)
The build will be under "Artifacts" on the page that takes you to.

Known issues -
EGA is still not 100% complete / bug free
Area5150 wibble and lake have issues

Just downloaded the nightly linux build, looks great so far! Just one thing, I think you have to be logged into github to be able to download files under actions.

Ok, it took me a little longer than expected, but MartyPC 0.2.0 is finally out.

https://github.com/dbalsom/martypc/releases/tag/0.2.0b

The changelog is pretty enormous but the main features are:

• New Display System: multiple scaling options, multi-window and multi-adapter support, fullscreen, shaders and more
• New video cards: MDA and EGA
• New machine configuration system
• New ROM definition system
• New keyboard emulation with scancode translation support, macros and hotkeys
• New cycle logging option: sigrok logic analyzer compatible CSV - use with my sigrok 8088 decoder* to get a very unique view of your code!
• Dozens of device fixes and accuracy improvements

*https://github.com/dbalsom/marty_tools/tree/m … _decoders/i8088

Sounds good. Will give it a spin if I have the time.

Please welcome the newest machine type to the MartyPC family, the Tandy 1000.

The Tandy graphics video gate array (TGA) is built off of MartyPC's quite mature CGA implementation, with the proper TGA font (Thanks VileR), 9-row text mode support, video A0 memory map and page register support, and of course 4bpp modes.

The unique memory system required a little reworking of MartyPC's internals - as the TGA has no VRAM itself, I had to implement functionality for a MMIO device to remap system memory.

I still need to work out a few things - like the final wait state algorithm. And no 3-voice sound yet.

PCJr shares the TGA adapter type with some minor sub-type differences. But the PCJr machine needs a bit more work to get going - mainly PIO mode for the FDC. Thankfully the Tandy will switch to DMA mode for the FDC if it detects a DMA controller, which was typically included on a memory expansion card, so it didn't have to wait until I implemented PIO. The hard disk controller was also pretty much compatible with the IBM Xebec controller - so that works too!

Nice! Can't wait for the Tandy sound to work, so I can port some SAA1099 stuff to Tandy. But having the gfx is also quite nice, in the future I'll try to port Rick Dangerous 2 (which never got a proper Tandy mode, unlike RD1, even though there are traces of it in the EXE) to Tandy.

I can't recall whether you already support Plantronics graphics? If not, it should be pretty easy to support, as it's a simple extension of CGA.

While we're at it, how about some Hercules?

Cool.

I really like MartyPC, the wait for the new version was well worth it! And the emulated hardware reminds me very strongly of my first DOS PC - VGA (which could also do Hercules, I think it was an OAK chipset), 1 MB RAM, 40 MB HDD.
There is just one difference, it was an 80286. I seem to remember you wrote that MartyPC will probably only emulate 8086, because cycle-exact documentation for 80286 CPUs and later is not available. I´m curious, is that so or maybe one day far, far down the road there may be a chance for 286 or even 386? Just asking, this is not even a suggestion, you are awfully hard at work already!

jk3one wrote on 2024-05-14, 21:14:

There is just one difference, it was an 80286. I seem to remember you wrote that MartyPC will probably only emulate 8086, because cycle-exact documentation for 80286 CPUs and later is not available. I´m curious, is that so or maybe one day far, far down the road there may be a chance for 286 or even 386? Just asking, this is not even a suggestion, you are awfully hard at work already!

I definitely would like to tackle the 286. I think it is doable, but I will have to adapt my research and validation methods. The 286 lacks some of the status lines I used with the 8088 to detect instruction boundaries. But with ample abuse of the trap flag, perhaps we can still figure something out.

I think the main problems are 1) the whole protected mode shenanigans (though you could just forego on that) and 2) that there isn't a single standard 286 like the 8088 was. There's countless manufacturers and clock speeds (6 MHz up to 25MHz), so there's not one single target.

How important is cycle-accurate emulation of a 286? By the time the 286 came around, most PCs were clones. You could target exact emulation of the 5170, but what programs would you be able to run that you couldn't before?

The original PC and XT were the trailblazers, so when you're targeting them in the early 80's, you're targeting those specific machines. But later on you targeted not a specific machine, but the PC platform as a general standard. Seems to me like cycle accurate emulation loses its importance in that realm.

keenmaster486 wrote on 2024-05-15, 16:06:

How important is cycle-accurate emulation of a 286? By the time the 286 came around, most PCs were clones. You could target exact emulation of the 5170, but what programs would you be able to run that you couldn't before?

The original PC and XT were the trailblazers, so when you're targeting them in the early 80's, you're targeting those specific machines. But later on you targeted not a specific machine, but the PC platform as a general standard. Seems to me like cycle accurate emulation loses its importance in that realm.

Isn't the IBM AT the last official IBM XT-compatible motherboard ROM BIOS requiring cycle-accuracy to POST? Although I only tested XT, AT and Compaq Deskpro 386 (8088, 80286 and 80386 base platforms respectively). If the 80286 isn't running within the correct speed range, it will fail to POST and hang itself (requiring cycle-accuracy in real mode at least).

superfury wrote on 2024-05-15, 19:01:

Isn't the IBM AT the last official IBM XT-compatible motherboard ROM BIOS requiring cycle-accuracy to POST? Although I only tested XT, AT and Compaq Deskpro 386 (8088, 80286 and 80386 base platforms respectively). If the 80286 isn't running within the correct speed range, it will fail to POST and hang itself (requiring cycle-accuracy in real mode at least).

I doubt it, as even the first 286s were rated for different speeds (as was the 8088, for that matter). Cycle accuracy is important if you have a fixed frequency and are counting cycles, but with variable clock speed that is no longer possible.