That is very cool! Well done! 😀

That's really impressive - well done! I'm going to have to find some more ways to break it now... 😁

That's massive. Hats off! Some other emulators have been getting close, but yours does appear to be the first to pull off complete accuracy in all sections.

What's more, it correctly represents what is seen on the monitor, by rendering a fixed region - overscan included - and allowing the emulated 6845 to determine the parameters of the active area. This approach has been inexplicably rare in PC emulation (as opposed to say the C64, Amiga, or Amstrad CPC)... but that's really the only passable way to emulate effects like raster repositioning/resizing, per-scanline scrolling, and over-the-border graphics.
We're still working on an improved 'final' version, and I typically do my coding on my modern PC, so this could potentially make my dev/testing cycles quite a bit more efficient. :-)

One minor point: I'd look into the interpretation of CGA's Mode Select register when bits 1 and 3 are both clear (-VIDEO -GRPH, i.e. text mode with VRAM output disabled). In this specific case, the border/overscan shows the background color determined by Color Select, but the active video area (within the 6845's H/V Displayed limits) should always show color 0. -VIDEO basically makes the CGA pretend that its memory is zeroed, so in text mode that's character 0 with both attributes black.
For instance, compare the parallax section's roll-in/roll-out at https://youtu.be/zADeLm9g0Zg?t=461 vs. https://youtu.be/BdM5j96tEpE?t=462 from the real hardware. Regions with -VIDEO display color #6 in your emulator, where the actual CGA displays #0... although that part was kind of an oversight in the party release, so that's one of the things I've been meaning to fix!

VileR wrote on 2023-05-25, 08:42:

What's more, it correctly represents what is seen on the monitor, by rendering a fixed region - overscan included - and allowing the emulated 6845 to determine the parameters of the active area. This approach has been inexplicably rare in PC emulation (as opposed to say the C64, Amiga, or Amstrad CPC)... but that's really the only passable way to emulate effects like raster repositioning/resizing, per-scanline scrolling, and over-the-border graphics.

It didn't start out that way, I kept trying to derive effective resolution from the CRTC registers and I constantly ran into issues in 8088MPH dealing with the logic for it. I think I saw this very advice from either you or Scali on here, and I had some good input from one of the oldschool CPC guys, so I switched things up to draw into a 912x262 back buffer which is really rather convenient as I just clock the CGA and the clock cycle increments my video pointer, just adjusting on hsync and vsync. I know there are some discussions about refactoring the CGA rendering in 86box to do the same.

I have to confess my favorite part of the demo, despite all the amazing effects, is "Let's Really Push The Boundaries" where you erase the overscan. When I saw that initially I literally yelled "HOW" at the screen, so there was no way I wasn't going to make that transition pixel-perfect.

VileR wrote on 2023-05-25, 08:42:

We're still working on an improved 'final' version, and I typically do my coding on my modern PC, so this could potentially make my dev/testing cycles quite a bit more efficient.

I'd be thrilled if demo authors found it useful. It does have some extensive debugging and logging facilities I imagine could be useful for coding. You can see the current raster position while single stepping, and see the CRTC, PIT, and PIC registers in realtime... There's full instruction and cycle-based logging which you can toggle on and off. I'd be open to feature requests as well, if there was something you've always wanted in an emulator.

VileR wrote on 2023-05-25, 08:42:

One minor point: I'd look into the interpretation of CGA's Mode Select register when bits 1 and 3 are both clear

This was one of the last changes I made and it was to fix the intro text in the Elephant effect which was otherwise displaying a solid black bar background instead of the gradient lines it should. Clearly I missed some little detail, good catch 😀

GloriousCow wrote on 2023-05-25, 12:10:

It didn't start out that way, I kept trying to derive effective resolution from the CRTC registers and I constantly ran into issues in 8088MPH dealing with the logic for it. I think I saw this very advice from either you or Scali on here

Ah yes, VileR and myself are the OG overscan/border fundamentalists!
Anyway, very good job on the emulator, and interesting to see that you've written it in Rust. I've not heard of Rust being used for emulation before. I'll probably be checking out the code at some point.

And speaking of 8088MPH... How does your emulator fare with that? Could you also post a video of it (assuming it gets acceptable results, which seems like a safe assumption given how well it handles Area5150)?

Scali wrote on 2023-05-25, 14:04:

And speaking of 8088MPH... How does your emulator fare with that? Could you also post a video of it (assuming it gets acceptable results, which seems like a safe assumption given how well it handles Area5150)?

I haven't been 100% satisfied with my CGA composite simulation and wanted to improve it a bit before making a final video. But here are some screenshots...

GloriousCow wrote on 2023-05-25, 12:10:

It didn't start out that way, I kept trying to derive effective resolution from the CRTC registers and I constantly ran into issues in 8088MPH dealing with the logic for it. I think I saw this very advice from either you or Scali on here, and I had some good input from one of the oldschool CPC guys, so I switched things up to draw into a 912x262 back buffer which is really rather convenient as I just clock the CGA and the clock cycle increments my video pointer, just adjusting on hsync and vsync. I know there are some discussions about refactoring the CGA rendering in 86box to do the same.

I have to confess my favorite part of the demo, despite all the amazing effects, is "Let's Really Push The Boundaries" where you erase the overscan. When I saw that initially I literally yelled "HOW" at the screen, so there was no way I wasn't going to make that transition pixel-perfect.

Ha, that's more or less the reaction we hoped to provoke. 😁 In fact as far back as 8088 MPH, one not-so-secret hope was to inspire the emulation scene to level-up in terms of accuracy, so it's awesome to see people stepping up to the plate (and now actually making it happen)!

Speaking of CPC, one thing I've discovered fairly recently is Logon System's Amstrad CPC CRTC Compendium: http://logonsystem.fr/html/engdownloadlogon.htm (latest version, 1.5). A lot of it isn't directly applicable to CGA, mostly just the parts relating to 'type 2' (MC6845) CRTCs, but it's still a very useful piece of work.

GloriousCow wrote on 2023-05-25, 12:10:

I'd be thrilled if demo authors found it useful. It does have some extensive debugging and logging facilities I imagine could be useful for coding. You can see the current raster position while single stepping, and see the CRTC, PIT, and PIC registers in realtime... There's full instruction and cycle-based logging which you can toggle on and off. I'd be open to feature requests as well, if there was something you've always wanted in an emulator.

Those extra debugging features sound mighty helpful indeed. As for other features, I guess I'd just need to try it out - are you planning a binary release in the near future? (I could always try to build from source, just not familiar with the requirements/toolchain.)

Scali wrote on 2023-05-25, 14:04:

Ah yes, VileR and myself are the OG overscan/border fundamentalists!

(*knocks on random people's doors*) "Hello, do you have a moment to talk about our Lord and Savior, the Border Area?" 😁

GloriousCow wrote on 2023-05-25, 14:50:

I haven't been 100% satisfied with my CGA composite simulation and wanted to improve it a bit before making a final video.

Have you had a look at reenigne's code based on data sampled from the CGA's chroma multiplexer output? There's a DOSBox patch with it at Re: CGA Composite Mode under DOSBOX (Commited r3804) (and I think 86box has since started using it too). Still the most accurate one out there.

Just saw this as well. Guess I'll just have to try and run it on UniPCemu and see how it performs or breaks.
I guess it might work, but cycle accuracy on the CPU might affect it a bit (seeing the remaining issues in 8088MPH still being a bit of cycles off last time I ran it, although only affecting the racing the beam part).

Some effects might run more easily due to the CRTC emulation in UniPCemu's graphic cards (unlike most other emulators like PCem etc.).

I guess it's also running in NTSC composite mode?

VileR wrote on 2023-05-25, 21:58:

Ha, that's more or less the reaction we hoped to provoke. 😁 In fact as far back as 8088 MPH, one not-so-secret hope was to inspire the emulation scene to level-up in terms of accuracy, so it's awesome to see people stepping up to the plate (and now actually making it happen)!

Even the name Marty is a reference to all the Back To The Future stuff in 8088MPH. I renamed it to MartyPC because googling "Marty Emulator" is all FM Towns stuff. It's an unfortunate name collision, but I tried to think of a new name and came up blank.

VileR wrote on 2023-05-25, 21:58:

Speaking of CPC, one thing I've discovered fairly recently is Logon System's Amstrad CPC CRTC Compendium: http://logonsystem.fr/html/engdownloadlogon.htm (latest version, 1.5). A lot of it isn't directly applicable to CGA, mostly just the parts relating to 'type 2' (MC6845) CRTCs, but it's still a very useful piece of work.

Yep, I have a copy. It's quite the tome. It's evidence that even after getting Area5150 running, there's a whole world of behavior I have yet to tackle and future demos might exploit. I have an MC6845 connected to a Teensy microcontroller too, but I haven't explored it any where near in as much depth as the 8088. That's a future blog article, or two. Hey, maybe I can come up with my own effect!

VileR wrote on 2023-05-25, 21:58:

Those extra debugging features sound mighty helpful indeed. As for other features, I guess I'd just need to try it out - are you planning a binary release in the near future? (I could always try to build from source, just not familiar with the requirements/toolchain.)

I suppose the smart thing would have been to wait to crow about this until I had a proper release, but my goal is to get one out the door this weekend. Just need a bit of polish on the more user friendly fuzzy features and some basic docs. Speaking of releases, how would you feel about me possibly including 8088MPH/Area 5150 with my binary release? My thoughts were it would be great to give people a way to experience the demos as intended themselves "out of the box", but I completely understand if you'd rather not have it distributed that way. I am not sure what the etiquette is there, so apologies if that suggestion is gauche.

VileR wrote on 2023-05-25, 22:05:

Have you had a look at reenigne's code based on data sampled from the CGA's chroma multiplexer output? There's a DOSBox patch with it at Re: CGA Composite Mode under DOSBOX (Commited r3804) (and I think 86box has since started using it too). Still the most accurate one out there.

I immediately found the whole color composite thing to be utterly fascinating. I've read your blog posts about it dozens of times, but I never really fully comprehended it. I understood the basic concept but the implementation details were still a mystery.

Believe me, it's was tempting to lift a lot of reenigne's work and of course I still stand on his shoulders by using his microcode disassembly, but my overall philosophy approaching this was to treat the IBM PC like a great big puzzle box I had to figure out. I didn't want to implement anything I didn't understand.

And boy did I not understand how the hell composite artifact color worked. In black and white, sure, the diagrams on your blog make it fairly simple. You can even do a simple 16-slot color LUT with 4 pixels as your input the high res monochrome CGA modes in the most naïve implementation. Do some luma sampling first and multiply and you even get a passible result. But as soon as you add color, it all falls apart. So I bought an oscilloscope and I sat down with the CGA schematic and an "Old style" CGA card fresh from ebay and I spent a few weeks figuring out how to convert the flower girl image from the raw RGBI source. That's when I learned about the multiplexer, and the fact that you have to model half-hdots as certain colors are out of phase by half a cycle. You may recall I emailed you for permission to use your art for a planned blog post about all that. My code isn't the most accurate, but I'm still proud of it. Just not quite satisfied. For example, in the CGA type detection screen, i'm somewhere between "NEW" and "OLD" despite modelling old-style. Just probably have some values wrong somewhere.

Sometimes these efforts can make you feel a bit silly, though. I was expecting the implementation of CGA wait states to be fiendishly difficult. I spent a few days deriving the CGA wait state algorithm from the schematic and the whole thing collapses down into a 16-slot look up table from the lower 4 bits of the CGA clock. Something I would have immediately seen peeking at the 86box CGA source, but then I would have a magic table of numbers I didn't really understand. Did I waste my time? Maybe. Was it worth it? I think so. It's that kind of esoteric, pointless technical knowledge that really impresses during dinner conversation.

superfury wrote on 2023-05-25, 22:40:

I guess it's also running in NTSC composite mode?

Nope, this one is straight RGB. If you can run 8088MPH I'd say 85% of the demo will likely run fine, as it's mostly CRTC rather than CPU tricks. The three effects that will likely fall down are the Tetra3D effect which relies on accurate interrupt timings and implementation of at least one undocumented 8253 feature, and the Wibble and Lake (end credits) effects near the end, which are all perfectly cycle-counted but introduce a lot more instruction types than Kefrens did, and subsequently hit a few more different bus delay scenarios. They're also less forgiving then Kefrens, which you could get to hold sync even when not cycle accurate. If you miss your timing in the end credits of Area 5150 the whole thing tends to turn into colorful spaghetti.

Wow, that's impressive, and the debugger looks nice too from the screenshots!

GloriousCow wrote on 2023-05-26, 01:41:

Speaking of releases, how would you feel about me possibly including 8088MPH/Area 5150 with my binary release? My thoughts were it would be great to give people a way to experience the demos as intended themselves "out of the box", but I completely understand if you'd rather not have it distributed that way. I am not sure what the etiquette is there, so apologies if that suggestion is gauche.

The demoscene originated from the cracking scene, so originally the whole point was to distribute it freely (including software that wasn't legal to freely spread of course).
Once demos became standalone products, they were generally considered 'public domain'.
In fact, in the early 90s there were some companies that would bundle public domain software on sets of disks that could be ordered via mail.
In certain demos you'll find messages that specifically prohibit this without permission, as it would effectively mean the demos were not being spread for free, and the company making the disks would make a small profit.
Demos were meant to be spread for free, via BBSes (and later the internet of course), and disk swapping/copy parties.

And since there were still traces of the cracking scene, there's an unwritten rule that others can freely disassemble and modify/fix your code and distribute the fixed version (as long as they are not passing it off as their own work of course. When you actually try to modify graphics or audio and make it look like your own demo, or if you try to take graphics and audio and re-use it in your own work, it is considered 'ripping', which is 'lame'... as opposed to ripping graphics/audio from games, which was considered acceptable, especially in the early C64 days).
The most famous such demo is probably State Of The Art by Spaceballs: https://www.youtube.com/watch?v=89wq5EoXy-0
The end screen shows a message "Skid Row debugged it".
Skid Row being another demo/cracking group, who apparently fixed some bugs. This fixed version became the most widely spread version of the demo.

Anyway, this is how I see the general tradition of spreading/modifying demos in general.
I can't make any specific calls about 8088MPH or Area5150.

GloriousCow wrote on 2023-05-26, 01:41:

It's an unfortunate name collision, but I tried to think of a new name and came up blank.

Biffulator, making other emulators like a tree and get out of there?

Impressive! It is nice that the overscan borders are emulated! 👍

OK. Now testing the demo in UniPCemu...
So far it starts out fine until the vertical color scrolling (after 'pushing the boundaries') at least.
One weird thing is that the overscan is black when the demo starts until the pushing the boundaries sets it to blue?
Continuing the demo...
Vertical raster bars thing works properly.
Blocky graphics as well...

OK. Mostly went fine, but somehow the overscan seems to always seems to be black?
During the 3D vector part. it runs almost 100%, except the area between the 3D object going up and down has black between the jumping area and the top and bottom static pictures?
Then sometime later during the watery effect on the elephant/goblin/chaplin part the display is recognisable, but the rendering goes wrong somewhat (the CPU speed crawling to 2% realtime speed). You'd almost think that the CPU is in IPS clocking mode instead of cycle-accurate mode. Or it's going slightly wrong combined with the RAM hammering being too much with the latest RAM optimizations since 8088 MPH ran (didn't verify that part yet).

Then some static screens like with the woman with the glasses part, which render fine.

Finally the end credits look slightly garbled?

It's almost like every 8 scanlines it's off by 1 character clock (shifted to the left)?
Its seems to match the pattern seen at the right border of the active display?
The effect on the bottom half of the screen looks to be running fine, although has the same issues as the top half (but mirrored vertically ofc).

It looks like the start each scanline of the credits is sometimes moved left by 2 or 3 character clocks. This static pattern seems to repeat on all scanlines?
Like:
0
3
0
0
0
0
0
3
0
3
(repeated for the entire height of the screen)

The above being character clocks shifted left.
It doesn't seem to move in any way while the credits are playing, so that would be an indicator it's properly running in cycle-accurate mode and the top of the screen is at a non-moving position (so that's correct at least)?

So basic scanline timings would be fine, but within seems to depend on what scanline it's rendered at (with some scanlines shifted off-screen, depending on line number modulo something)?

The wavy line effect seems to be running fine on the credits screen. It's just the characters being shifted probably, depending on the line number (it seems to be static accross the screen and not moving, which is a good sign)?

Looking closely, you can see that the pattern of the red sun shifts matches the pattern on the right border (sun shifted left equals added pixels on the right border of the image).

1:22:18 of recording: Viler greets message with 2 rows done. Very slow at 2% realtime speed 😒
Edit: Thinking about it, the shift to the left is exactly one character width in the font displayed in the red background? Don't think that's a coincidence.

After all that, luckily no spaghettification detected. So the main weird things that happened was the chaplin/alien/etc. image being superimposed on a part of itself somehow (running at 2% as well), the overscan always being black (except at the end on the intro it became blue until 'widening' happened, black for the remainder of the demo), the credits having a off-by-one character issue depending on the scanline on the screen (it has a distinctive pattern repeated accross about every 8 or 16 scanlines). It looks like it's repeating every 3 text rows at the credits (the 2nd text row having something extra shifted). The first extra shift being at the greets rows (right at the first and third scanline of it).

Edit: Little bit of sound capture (this is at the part the red R is displayed in the recording) during the credits:
https://www.dropbox.com/s/79nmig8ltnhs6i5/are … apture.wav?dl=0

The capture of most of the demo is still to come... Uploading atm.

superfury wrote on 2023-05-30, 09:59:

OK. Mostly went fine, but somehow the overscan seems to always seems to be black?

Should be easy to fix. The color control register controls the overscan color.

superfury wrote on 2023-05-30, 09:59:

During the 3D vector part. it runs almost 100%, except the area between the 3D object going up and down has black between the jumping area and the top and bottom static pictures?

This effect switches between text and graphics modes mid-screen. If you see a black bar, that's a result of the tetrahedron, which is intended for graphics mode, being drawn in text mode. There's nothing too devious about this effect other than requiring accurate interrupt timing.

superfury wrote on 2023-05-30, 09:59:

It's almost like every 8 scanlines it's off by 1 character clock (shifted to the left)?
Its seems to match the pattern seen at the right border of the active display?

You're on to something. The graphics in memory are indeed shifted by one byte (one character column). This is due to a trick where the two rows of one CRTC frame are cleverly organized so that the second rows of all the CRTC frames can be stacked. The first 'row' of each CRTC frame is a single character wide column, cleverly hidden in the right overscan.

superfury wrote on 2023-05-30, 09:59:

It looks like the start each scanline of the credits is sometimes moved left by 2 or 3 character clocks. This static pattern seems to repeat on all scanlines?

No such trickery is occurring. Each scanline is pretty much set up the same way. Since the CRTC updates are all cycle-counted though, if you are off at all you may see scanlines of different shapes and sizes occurring, sometimes with interesting patterns. I saw a lot of different kinds of spaghetti in my debugging...

superfury wrote on 2023-05-30, 09:59:

It doesn't seem to move in any way while the credits are playing, so that would be an indicator it's properly running in cycle-accurate mode and the top of the screen is at a non-moving position (so that's correct at least)?

Actually, that's a bad sign. If you see two static scanlines at the top of the screen, some space, and then the garbled output, that means the effect ISR is late. It is set to repeat every screen with a reload value of 19912. You get two scanlines just from the last values programmed into the CRTC. The interrupt should trigger *above* those two lines late on scanline 20, entering into the ISR procedure itself around scanline 21.

GloriousCow wrote on 2023-05-30, 12:44:

Should be easy to fix. The color control register controls the overscan color. […]
Show full quote

superfury wrote on 2023-05-30, 09:59:

OK. Mostly went fine, but somehow the overscan seems to always seems to be black?

Should be easy to fix. The color control register controls the overscan color.

superfury wrote on 2023-05-30, 09:59:

During the 3D vector part. it runs almost 100%, except the area between the 3D object going up and down has black between the jumping area and the top and bottom static pictures?

This effect switches between text and graphics modes mid-screen. If you see a black bar, that's a result of the tetrahedron, which is intended for graphics mode, being drawn in text mode. There's nothing too devious about this effect other than requiring accurate interrupt timing.

superfury wrote on 2023-05-30, 09:59:

It's almost like every 8 scanlines it's off by 1 character clock (shifted to the left)?
Its seems to match the pattern seen at the right border of the active display?

You're on to something. The graphics in memory are indeed shifted by one byte (one character column). This is due to a trick where the two rows of one CRTC frame are cleverly organized so that the second rows of all the CRTC frames can be stacked. The first 'row' of each CRTC frame is a single character wide column, cleverly hidden in the right overscan.

trick_spoiler.png

superfury wrote on 2023-05-30, 09:59:

It looks like the start each scanline of the credits is sometimes moved left by 2 or 3 character clocks. This static pattern seems to repeat on all scanlines?

No such trickery is occurring. Each scanline is pretty much set up the same way. Since the CRTC updates are all cycle-counted though, if you are off at all you may see scanlines of different shapes and sizes occurring, sometimes with interesting patterns. I saw a lot of different kinds of spaghetti in my debugging...

superfury wrote on 2023-05-30, 09:59:

It doesn't seem to move in any way while the credits are playing, so that would be an indicator it's properly running in cycle-accurate mode and the top of the screen is at a non-moving position (so that's correct at least)?

Actually, that's a bad sign. If you see two static scanlines at the top of the screen, some space, and then the garbled output, that means the effect ISR is late. It is set to repeat every screen with a reload value of 19912. You get two scanlines just from the last values programmed into the CRTC. The interrupt should trigger *above* those two lines late on scanline 20, entering into the ISR procedure itself around scanline 21.
isr_late.png

The 3D vector is actually displaying. So are the text area above and below it (from the edge of active display). In the recording, I can see that the graphics part with the animated 3D object (where the area is the height of the 3D vector object) in between the text area 'graphics'.
The weird thing is that while those 3 areas themselves are correct, I see the vector area moving up and down with the animation. In that area, above the area until where the top area ends and below the vector area until the text area of the bottom part starts there's black always.
The vector area itself contains the vector object (that's doing it's thing like in the official youtube video) and the remainder of it's scanlines filled with the proper blue color.
But the area above the position of the vector (from the top scanline of the vector until the end of the top ANSI from hell image as well as from the scanline below the vector object (so the height of the 3D vector object after the start of it (where it's positioned at various points during the animation) until the start of the ANSI from hell that contains the bottom part of the image. That 'black area' is always black. Perhaps the same kind of overscan being black issue as with the other parts of the demo?
Ofc I see the area with the vector image (that shrinks etc.) jumping up and down the screen like in the Youtube video. But the area it's not currently at being black from the moment the vector ball leaves(making it black) or enters it (making the scanline the proper colors).

The screen itself isn't bobbing or shaking or anything during the credits. It's just as stable as the image in the official video of the real hardware on Youtube. It's just that some scanlines are aligned differently.
The animation has no effect on that, the scanlines don't move horizontally or vertically at all (and the screen output size is constantly the same and stable).
So it's just like the official recording in that regard, just some specific scanlines (depending on the modulo of the scanline number) being shifted left on specific scanlines. The animation that's running on the screen as well as the gradual rendering of the text characters from the credits doesn't affect that either (nothing that's on the screen moves to a wrong location at any point, other than the horizontal move that's always constant during the entire credits).

Also, like I said in my previous post, never saw ANY spaghettification at all. The only real weird image was that of the alien part (with those 3 characters being interposed on a part of the image that's displaying correctly in the top-right corner of the screen).
Edit: Took the parts of the recording that fail and made some shorter clips of them from the large (slightly over 2 hours long) recording of the entire demo running inside UniPCemu:
https://www.dropbox.com/s/qyjillfqkd80kry/202 … 150%20.zip?dl=0

As you can see, the vector part has the issue of the area above and below the graphics area (between the graphics vector area that's bouncing up and down and the top/bottom text areas of ANSI from hell (it looks like ANSI from hell at least)) is black instead of the proper light cyan color.
A small part of the credits running is also included. As can be seen, the image that's rendered is stable on the CRT output. It's just that the contents are shifted on some specific graphics rows (or text rows, don't know what mode it uses, didn't check). Say if it's for example shifting left on scanlines 1,3,7,14 (not really those, but just an example), it's doing that for every frame at exactly the same scanlines, which never changes during the entire credits (so the entire output is stable in that way). So at least the entire amount of pixels in a frame is constant. The display isn't bobbing or distorted in any other way (stable output resolution and active display area).

The part with the alien is recognisable, with a part rendering 'correctly' (the elephant), never being morphed in any way during the animation.

Edit: Btw, there was one non-standard BIOS Option ROM loaded in the emulator. It's a simple BIOS extension for interrupt 1Ah that adds XT RTC timer support (the 1.2 version of the timer) in the BIOS (the source code for it can be found on my bitbucket account, at https://bitbucket.org/superfury/unipcemu_pcxtbios_at . It hooks interrupt 15 (for it's memory allocation support), 19 (for installation during boot) and 1Ah (for the actual timer support, adding the new functions introduced on the AT, adjusted for the XT RTC chip (of the Samtron 88S))). Although if the 1Ah interrupts functions of the RTC aren't called by the demo, it shouldn't be a problem (seeing as some can take quite a long time, depending on the RTC clock inputs and synchronization settings(on UniPCemu this is configurable)) and just add a few more instructions to execute in that case (the hook, a INT15h call to get it's data area from itself (allocated at INT19h handler after POST) and a stack setup with far return to the original INT15h handler).

I've made an initial Windows release of my emulator, available here:
https://github.com/dbalsom/martypc/releases/

Interested to see what people think. I'm open to suggestions and feature requests!