GloriousCow wrote on 2024-08-28, 19:39:

FreddyV wrote on 2024-08-28, 19:28:

I mean is there enaugh disk image available in all the format so that it is worth adding support ?

There is a significant body of images from both historical archival efforts as well as modern ones. It might be enough to support just the modern formats, but supporting the older ones may be helpful in the case where such images may be the only existing images of that particular software. It's true you can always convert some format to another, but such efforts can be tricky. I've seen posts on VOGONS with someone explaining a dozen different steps using the PSI tool, that even I barely understand. It would be nice to just be able to throw any format you might encounter at MartyPC and have it work without needing a doctorate in floppy engineering.

Hi,

The PicoMEM is acting at BIOS interrupt level, it means that not all the fonctionality of these images will be possible.
This limlit the compatibility, but can surely be better then nothing, not all the disk has copy protection.

Excuse me for asking, but the Area 5150 demo in martypc has been malfunctioning since version 0.2.0, especially with the credits at the end being a complete mess, and still not fixed to this day.

chenke wrote on 2024-09-06, 06:39:

Excuse me for asking, but the Area 5150 demo in martypc has been malfunctioning since version 0.2.0, especially with the credits at the end being a complete mess, and still not fixed to this day.

Yes. It's been a struggle. There is a good reason that this effect breaks emulators. The end credits effect is extremely fragile, not just for being cycle-counted, but because of the elaborate way that the effect is set up using a chain of interrupts. Any changes to device or CPU timings tends to break it, even if they are provably a fix or accuracy improvement in some other area. I have a lot I could say on this topic, and in fact, I am giving a talk on Area 5150 tomorrow at 11AM at VCF Midwest. 😀

If your primary interest is playing Area 5150, I would stick to version 0.1.3 for now. I will be making sure that it works properly in the 0.3.0 release along with all the new floppy goodness.

GloriousCow wrote on 2024-09-06, 17:18:

chenke wrote on 2024-09-06, 06:39:

Excuse me for asking, but the Area 5150 demo in martypc has been malfunctioning since version 0.2.0, especially with the credits at the end being a complete mess, and still not fixed to this day.

Yes. It's been a struggle. There is a good reason that this effect breaks emulators. The end credits effect is extremely fragile, not just for being cycle-counted, but because of the elaborate way that the effect is set up using a chain of interrupts. Any changes to device or CPU timings tends to break it, even if they are provably a fix or accuracy improvement in some other area. I have a lot I could say on this topic, and in fact, I am giving a talk on Area 5150 tomorrow at 11AM at VCF Midwest. 😀

If your primary interest is playing Area 5150, I would stick to version 0.1.3 for now. I will be making sure that it works properly in the 0.3.0 release along with all the new floppy goodness.

Oh, I hope to see a video recording of your speech so that people who can't attend in person can study it carefully. Thank you.
https://hackertracker.app/event/?conf=VCFMW2024&event=57212

chenke wrote on 2024-09-09, 02:20:

Oh, I hope to see a video recording of your speech so that people who can't attend in person can study it carefully. Thank you.
https://hackertracker.app/event/?conf=VCFMW2024&event=57212

All the talks are recorded and will be posted to youtube.

My talk on Area 5150 has been uploaded.
https://www.youtube.com/watch?v=VWQB6HmqKig

A minor correction - the scanline polling is actually for display enable, not hblank, as that is the meaning of the bit reflected in the CGA's status register. Other than that, I hope people enjoy the talk. The last bit talks about why the end credits is hard to emulate. All the demo footage you see in the talk was recorded on the dev branch of 0.3; I want to say the end credits run successfully 1/4 of the time you try them. When I've finished most of the floppy work I will sit down and try to figure out why, once and for all. Then I'll try to set up some sort of regression test so it never breaks again.

Ah! That was great, really enjoyed learning some of the shenanigans that made this wizardy possible as I really had very basic clues! Thanks for the talk, and for sharing 😀

Does MartyPC work under Windows 7? For some reason I get an error with bcryptprimitives.dll in Windows 7. Which version of Windows is best for MartyPC?

SoftCat wrote on 2024-09-16, 20:50:

Does MartyPC work under Windows 7? For some reason I get an error with bcryptprimitives.dll in Windows 7. Which version of Windows is best for MartyPC?

I haven't intentionally done anything to break Windows 7, but I can't say I test it either. If I had to hazard a guess, it sounds like the sha1 library I recently added might be trying to load that dll, which isn't present in Windows 7.

I personally use Windows 10. Any hardware still running Windows 7 is probably not going to run MartyPC that well...

GloriousCow wrote on 2024-09-16, 22:46:

I haven't intentionally done anything to break Windows 7, but I can't say I test it either. If I had to hazard a guess, it sounds like the sha1 library I recently added might be trying to load that dll, which isn't present in Windows 7.

I personally use Windows 10. Any hardware still running Windows 7 is probably not going to run MartyPC that well...

Thank you very much for your answer!

GloriousCow wrote on 2024-09-16, 22:46:

I haven't intentionally done anything to break Windows 7, but I can't say I test it either. If I had to hazard a guess, it sounds like the sha1 library I recently added might be trying to load that dll, which isn't present in Windows 7.

Now I'm wondering why on earth does an emulator need an SHA library 😁

JAL

jal wrote on 2024-09-19, 14:53:

GloriousCow wrote on 2024-09-16, 22:46:

I haven't intentionally done anything to break Windows 7, but I can't say I test it either. If I had to hazard a guess, it sounds like the sha1 library I recently added might be trying to load that dll, which isn't present in Windows 7.

Now I'm wondering why on earth does an emulator need an SHA library 😁

JAL

there may be alternate hashes with better performance that would suit my needs, but I was using sha1 to detect duplicate track data when reading disk images, and to compare the results of reading and writing image formats in integration tests.

Plus there's other reasons to hash things, like identifying roms in a name-insensitive manner. I was considering moving to md5 to sha for that.

GloriousCow wrote on 2024-09-15, 20:46:

My talk on Area 5150 has been uploaded.
https://www.youtube.com/watch?v=VWQB6HmqKig

A minor correction - the scanline polling is actually for display enable, not hblank, as that is the meaning of the bit reflected in the CGA's status register. Other than that, I hope people enjoy the talk. The last bit talks about why the end credits is hard to emulate. All the demo footage you see in the talk was recorded on the dev branch of 0.3; I want to say the end credits run successfully 1/4 of the time you try them. When I've finished most of the floppy work I will sit down and try to figure out why, once and for all. Then I'll try to set up some sort of regression test so it never breaks again.

Thank you so much for uploading the video and thoughtfully adding subtitles. It's absolutely fantastic!

Experimenting with this, found it very profound and thorough as it tries to be very accurate. But a humble question : from 8-10 years ago I remember an emulator for PC Booter games, it was emulating an XT with 8088/86/V20/V30. Not PCEM, neither Bochs, let alone Dosbox. This was in Windows, and it had a GUI menu.

It would be great if the lecture video could explain the principles behind the 'elephant dancing' animation in the AREA 5150 Demo. I'm very curious about how they managed to create such smooth animation using the ANSI-from-Hell technique.

chenke wrote on 2024-09-20, 13:32:

It would be great if the lecture video could explain the principles behind the 'elephant dancing' animation in the AREA 5150 Demo. I'm very curious about how they managed to create such smooth animation using the ANSI-from-Hell technique.

I'd have liked to cover more effects and go into more detail on some. If there's significant interest I could possibly make a longer-form Youtube video that adds all the stuff I wanted to include but couldn't due to time. I lost 10 minutes of my talk just showing the demo - but I didn't see a good way around it, given that not everyone at the talk would have had context otherwise.

There's really no extra tricks with the elephant that I can see. VileR (i assume) just drew a lot of frames of mr elephant, and he's a good artist! I'd leave it up to him if he ever wants to blog about how the art pipeline for Area 5150 worked. I understand there was a converter made that could take a bitmap and attempt a best-fit to text, and then that would have to be cleaned up manually.

Since he's a fairly small region of video memory, I think the bandwidth updating him isn't too severe. And when he moves up and down (like in his final fall) that's all CRTC trickery too so he doesn't have to actually be copied around. What's interesting is that "MAYBE NOT..." is actually below the elephant in video memory, but it's above him on the screen. When we do frame-restart, where things are in video memory isn't really deterministic of where they show up on the monitor! The 'electric' square waves are also pretty much static in video memory and animated with frame restart, so that doesn't take time away from animating mr. elephant.

I haven't looked into whether these sort of optimizations were done, but when dealing with ANSI-from-hell you could have implemented a sort of compression scheme, where if only the glyph or only the attribute was changing, you could save a byte on write, but I don't know if that wins you any time over just doing movsw for the whole bit.

GloriousCow wrote on 2024-09-15, 20:46:

My talk on Area 5150 has been uploaded.
https://www.youtube.com/watch?v=VWQB6HmqKig

Forgot to reply here. Brilliant talk! It's not every day you get to watch a professional dissection of something you worked on. Got a kick out of the clever use of visualization - to illustrate how 'ansi-from-hell' is done, to peep at what's going on in VRAM with the real-time graphical memory viewer, and to show those register writes and polls overlaid on the screen output.

If there's anything I'd like to correct, it's rather minor, but I'd like to mention that the checkerboard effect isn't quite *entirely* precalculated. The idea did start out that way, but that turned out to hog way too much RAM. You may have noticed that there are a few (ahem) lookups happening during the visible part of each frame, amidst all the polling: that's how we made it fit without sacrificing either the running time, the frame rate, or the on-screen size. 😉

Of course there's plenty of other stuff in the demo that could be picked apart (reenigne's code tricks in the voxel landscape part sure deserve a detailed look!), but given the time limit, I thought you did a terrific job covering the important parts.

GloriousCow wrote on 2024-09-20, 14:20:

There's really no extra tricks with the elephant that I can see. VileR (i assume) just drew a lot of frames of mr elephant, and he's a good artist! I'd leave it up to him if he ever wants to blog about how the art pipeline for Area 5150 worked. I understand there was a converter made that could take a bitmap and attempt a best-fit to text, and then that would have to be cleaned up manually.

Since he's a fairly small region of video memory, I think the bandwidth updating him isn't too severe. And when he moves up and down (like in his final fall) that's all CRTC trickery too so he doesn't have to actually be copied around.

Yup! I'll definitely do a more detailed write-up on it - we're all planning some of those, but there's the final version to get done first (*groan*... I know). 😀 There are some inevitable real life circumstances delaying it, but it's in the pipeline.

What I can say about the elephant dance is that it was lots of fun to do. It started out as an actual flipbook animation, with each frame drawn on a piece of paper (minus the repetitions of course), which I then scanned, colored and retouched to make a hi-res looping animation. Then I scaled that down, and IIRC I did use conversion to get the general outline for the 'ansi-from-hell' frames, but nearly everything had to be manually redrawn in that mode to get it to look good.

As for the real-time part, the frames are actually delta-encoded (as you guessed), i.e. only the bytes that actually differ from one frame to the next are ever redrawn. But that was done more for space-saving reasons than for performance. Some may have noticed that the animation is 'only' 20 fps: that too was a space-saving measure, rather than running against any hard limits in terms of CPU cycles.

VileR wrote on 2024-09-20, 20:28:

Forgot to reply here. Brilliant talk! It's not every day you get to watch a professional dissection of something you worked on. Got a kick out of the clever use of visualization - to illustrate how 'ansi-from-hell' is done, to peep at what's going on in VRAM with the real-time graphical memory viewer, and to show those register writes and polls overlaid on the screen output.

Thanks for the kind words. It was very intimidating to try to do a talk on this demo justice. I don't know how "professional" it was - i'm just a hobby emudev after all. I was pleased with how the videos worked out within my slide deck - that's my first real foray into video editing with Davinci Resolve. I only gave myself about two weeks to put it all together, although of course Area 5150 has been burning in my mind for two years now.

Honestly I was inspired a lot by your excellent breakdowns of 8088 mph effects, which prove how a good visualization can really make a complicated subject click. The visualization tool in MartyPC was actually born from one of Trixter's feature requests, although I had implemented a similar feature in an ancient, win32-based hex editor tool I used for some ScummVM stuff, oh, twenty years ago. Originally it just did graphics modes, but while I was thinking about how I was going to explain the effects the thought just clicked "Visualize text mode, dummy".

VileR wrote on 2024-09-20, 20:28:

Of course there's plenty of other stuff in the demo that could be picked apart (reenigne's code tricks in the voxel landscape part sure deserve a detailed look!), but given the time limit, I thought you did a terrific job covering the important parts.

I had to think a lot about 'who is my audience' and as much fun as it would have been to pull up code listings, i think I just wanted to be able to impart to the average geek what an incredible accomplishment Area 5150 really was. If I succeeded there, then I'm very happy. I have a long blog post on the Lake effect if I ever get around to finishing it. I'd love to see a blog or two or five from reenigne about things.

I would like to suggest the following non-standard modes for EGA and CGA video adapters. I am also interested in how MartyPC will match real video adapters. There are several variants in the archive. Unfortunately, I cannot run MartyPC under Windows 7 and I do not have real CGA and EGA video adapters.
1) 768x200 16 colors for EGA;
2) 720x350 16 colors for EGA;
3) 720x182 2 colors for CGA.