Maybe you could publish the new version regardless? I would try it immediately and would not be concerned because of Microsoft Defender at all. But then, I am on Linux (Wine) - so it is very, veery unlikely to get a Microsoft smartscreen in my face 😀
In all seriousness, I really think you could just go ahead. It is not unsual for emulators to come with false virus/trojan warnings, you could say it is almost to be expected. Prominent examples like PCSX2, PCem (I think) had something like this somewhere in their past. Since it is a false positive the warning may be gone soon anyway.
Maybe you could publish the new version regardless? I would try it immediately and would not be concerned because of Microsoft Defender at all. But then, I am on Linux (Wine) - so it is very, veery unlikely to get a Microsoft smartscreen in my face
Yesterday I figured out a workaround for one of the major issues running on opengl on linux, so I was planning on just having a linux release as well this go. I saw how Jetbrains distributes their IDE for linux - its a statically compiled executable in a tar.gz. I can certainly just do the same. And of course, you can always build it yourself: https://github.com/dbalsom/martypc/wiki/Building-MartyPC which will let you get all the new features as they are added (and experience all the new bugs)
Man... from what I'm seeing of this Windows Defender false-positive situation, it's simply infuriating. If MS keeps up its policy of apparently not giving a crap whatsoever, I suppose it's possible for affected developers to pool together and attempt a collaborative heuristics project - perhaps that could pin down the exact issue, or at least produce some useful data. But as things stand, I understand why people aren't willing to risk their projects' reputations just because Microsoft is too lazy and negligent to fix its broken crap.
That said, I certainly wouldn't mind if a new Windows build was shared somewhere outside of the github release system, to minimize the risk of your public project being tarred and feathered. 😉
Another question for the long run: is it possible to configure GLaBIOS somehow to skip the RAM check. I reboot MartyPC quit often, and waiting for the RAM check is boring 😀.
Another question for the long run: is it possible to configure GLaBIOS somehow to skip the RAM check. I reboot MartyPC quit often, and waiting for the RAM check is boring 😀.
if we had a fixed RAM config maybe, but GLaBIOS needs to determine the memory size, and that's now configurable in MartyPC. One feature I am considering is "fast boot" which could work with other BIOSes as well, basically a breakpoint somwhere late in the POST process, and we run at 400% emulation speed until we hit it. Or maybe it would take the form of a tiny com file you put in autoexec.bat that calls my service interrupt to resume normal speed.
Sometime way in the future, you should just be able to make a save state when the system has booted.
5) Some booter games do not run for me - complaining that the disks is not write-protected. But it is - the image file is made to be "read-only"! In PCE and DOSBox it is enough for such games to launch, but MartyPC does not seem to recognize that...
Can you give me an example of a booter game that checks for write-protect? Just want to test.
Sorry for the late reply - somehow I did not get a notice.
It is any of "PC booter" games by Infocom - they all require the disk to be write-protected. Like "The Hitchhiker's Guide to the Galaxy", "Cutthroats", "Zork" etc.
Sorry for the late reply - somehow I did not get a notice.
It is any of "PC booter" games by Infocom - they all require the disk to be write-protected. Like "The Hitchhiker's Guide to the Galaxy", "Cutthroats", "Zork" etc.
Okay, was able to reproduce and happy to report the new write-protect feature solves it.
So it's February 2024, where the hell is 0.2?
I'm getting there - still tackling some intransigent bugs, issues with frame pacing, sound and other issues. Another minor rework to the CPU and a major bugfix in the PIC fixed several titles where segment address wrapping occurred, improvements to the FDC and HDC enabled several different editions of Minix to boot.
After poring over the schematics for a few hours, I rewrote the EGA (again) - this time breaking out the 5 LSI controller chips into 4 separate logical modules (the two graphics controllers can more or less be treated as one). Many of the seemingly redundant register settings on the VGA make a lot more sense when you realize they were registers that existed on separate chips on the EGA with no way to synchronize their state.
Suddenly the half-dozen or so combinations of flags and mode switches that enable CGA emulation mode started to gel:
(the image is shifted to the left - something i'm hoping resolves when i properly emulate the attribute controller, display enable skew and horizontal retrace delay)
Text mode is now properly implemented on odd/even planes for glyph and attribute, although software fonts are still not implemented - glyphs are still drawn using fast, pre-rasterized row caches. I'm thinking I don't necessarily have to abandon this optimization, but I will need to be able to update font cache on the fly when writes occur to plane #2 where the fonts are stored.
MDA emulation isn't really on my radar. It would need its own DIP switch setting i think. When you can easily switch to an actual MDA device, is there a need for this?
Another lingering puzzle is what to do about proper floppy drive size emulation. Right now you have the luxury of using 1.44Mb floppy images in MartyPC, but it's sort of an accident of the lack of sector checks that it works. If I let you select the drive size, and properly behave like a 720K drive, the BIOS could recognize them, and you'd be able to format blank disk images properly, but it would sort of break 1.44Mb images from working since we're limiting how far the drive can seek.
I sort of like the convenience of not needing to worry about your drive size now in MartyPC, and as long as you aren't formatting things everything seems to work fine. How important is being able to format a floppy in an emulator? I suppose I could let you select drive size along the lines of "360k", "720k", "auto" and auto would just behave how it does now.
How important is being able to format a floppy in an emulator? I suppose I could let you select drive size along the lines of "360k", "720k", "auto" and auto would just behave how it does now.
Well, some games want to format a floppy when being installed. I have "Balance of Power" that does that.
How important is being able to format a floppy in an emulator? I suppose I could let you select drive size along the lines of "360k", "720k", "auto" and auto would just behave how it does now.
Well, some games want to format a floppy when being installed. I have "Balance of Power" that does that.
Sigh, of course they do... You CAN format, but everything comes out 360k.
I'll fix it properly of course. Just maybe not in this upcoming release.
EGA support is coming along well. The EGA emulation is character-accurate and the various duties of the various LSI chips are simulated. A similar strategy has been used for EGA as was used for MartyPC's CGA - one of two fixed resolution fields are scanned out (depending on whether the EGA is running the 14Mhz or 16Mhz clock) and an aperture into that field displayed.
Now you can enjoy Commander Keen with full overscan:
No more hardcoded font - fonts are properly read from plane #2, modelling the shift/load function of the attribute controller, so text mode pel panning should be possible (I have to find some demo that does this...)
so text mode pel panning should be possible (I have to find some demo that does this...)
I'm pretty sure FantasyLand does that. It should be a good text mode torture-test in general, although it expects the EGA to be switched to 15.7KHz-only operation (i.e. 200-line text modes).
PCjs made a big deal of being able to run it, although it gets the color palette glaringly wrong. 😀
I'm pretty sure FantasyLand does that. It should be a good text mode torture-test in general, although it expects the EGA to be switched to 15.7KHz-only operation (i.e. 200-line text modes).
PCjs made a big deal of being able to run it, although it gets the color palette glaringly wrong. 😀
It runs, but it looks like it needs vsync interrupts for the panel that pops up from the bottom. I don't currently have a way for video devices to generate interrupts, so that will require a bit of reworking.
Also I made an assumption that text mode would always be using the 16Mhz clock so my colors are wrong too 😀
EDIT: Fantasyland is also an interesting case where we're in text mode, but not using odd/even addressing or word mode.
In other news, a kind soul is helping me set up github actions to make nightly builds. So you won't have to wait to try out a prerelease 0.2 for too much longer.
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.
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?
