MiSTer FPGA Forum

Thanks for the Floppy disable trick, I'll try that later tonight!

For CD I use "Magicdisc". It's free, no idea if it works with audio CD, can't see why not.

I am beginning to question the usability of Daemon Tools... it worked for me with Dr. Brain 3 and 4, but Diablo keeps crashing and it uses the CD quite a bit I think, which I am pretty sure is why it has these issues. I think a no-cd crack might make the full version of Diablo run as well as the shareware version. There is overall something strange about drives and disk speeds with the MiSTer. But in DOS CD emulation is working for me, so I am thinking maybe I should stop hoping to be able to use audio CDs or at least if I am not using audio CDs, maybe I should use something much simpler than Daemon Tools. I think the tool I use for DOS also does support Windows, if it has to.

I was trying GTA for Windows and managed to get it running more than I could in DOS, but that only meant getting to the main menu of the game and trying to start a game. But it then crashes at some point after trying to start a game. But what is interesting is the different things I tried for getting it to run, and disabling the virtual disk does help. I tried enabling it and then I could not get GTA into the game menu before it crashed.

Q47 wrote: ↑Sat Aug 08, 2020 9:23 pm

jordi wrote: ↑Sat Aug 08, 2020 9:00 pm I've seen this strange scroll artifacts on 2d games

See right part of the screen:
https://www.youtube.com/watch?v=fVMoYMJb3hk

It's strange as it only happens on horizontal scrolling.

This is just hw/coding limitation of that era. Video under explains this on NES. Why you see it is simply because your screen doesn't do overscan anymore as CRTs did back in the day.

https://www.youtube.com/watch?v=wfrNnwJrujw

I'd just like to point out that this scrolling issue in ao486 is a bug in it's implementation of vga. It doesn't handle per pixel panning correctly and leaves the final scanline pixels not drawn if per pixel panning is other than 0. It has nothing to do with overscan and it's very different from what happens with nes. If you play the game on a real pc, it works just fine even if you are looking at the regions beyond normal scan limits and you can easily verify that less pixels are actually drawn with ao486 than are drawn on a real pc. This bug can be seen in most ega and vga games which utilize per pixel panning registers for scrolling (like keen 4-6, supaplex and many others). It's easiest to see that too few pixels are drawn with game like supaplex where the scrolling part of the screen is separated with linecomp function that creates the statusbar. Linecomp section is drawn in full all the way to the edge, while simultaneously the scrolling part is clearly not and remain black where the statusbar is not when per pixel panning is other than 0. I'm pretty sure the bug is in vga.v-file.

thorr wrote: ↑Fri Aug 14, 2020 7:43 am - The Incredible Machine 2 demo doesn't have any picture but I can hear the music.

I have the same problem with Incredible Machine games. The only game that works for me from the series is "The Even More Incredible Machine".

rsn8887 wrote: ↑Wed Aug 19, 2020 5:41 pm

thorr wrote: ↑ - The Incredible Machine 2 demo doesn't have any picture but I can hear the music.

I have the same problem with Incredible Machine games. The only game that works for me from the series is "The Even More Incredible Machine".

I think this is same issue as with Betryal at Krondor. During intro, some screens (resolution 640x360) are blank but music is heard. Looks like some graphics modes are not shown correctly.

Goingdown wrote: ↑Wed Aug 19, 2020 6:44 pm I think this is same issue as with Betryal at Krondor. During intro, some screens (resolution 640x360) are blank but music is heard. Looks like some graphics modes are not shown correctly.

What is your vsync_adjust set to for ao486? At 2, it can sometimes take longer to "double-sync" than the screen lasts, resulting in this effect. Setting VSync to 60Hz and vsync_adjust to 0 can help with that.

I found a fix for Daemon Tools.

It is ending up to become a few special settings for Windows. Disable CD pre-load cache and I am thinking it also makes sense to disable HDD cache as well while we are at it. I got the idea when trying out Virtual CD and reading through special setup issues about it, and it would require you to do this. So I tested with Diablo and it used to crash within the first 2 minutes before when using Daemon Tools to make a Diablo CD for the game.

I am pretty sure this means we can use audio CDs, but have not done any tests with audio CD games. Many of them are DOS games and Syndicate Wars f.ex. I highly doubt is going to run well from Windows. But I guess it might be a good test anyway if it is able to run from Windows.

The other special Windows fix for the MiSTer was to remove the floppy drive controller. You can even still use the floppy drive without it.

I have begun testing MiSTerFS with Windows and it is possible to use it with Windows by adding it to the Windows Autoexec... but it wont allow you to use it for anything much. It might run some exe files if they are DOS based, because the command prompt is able to acces it normally, but otherwise using files in general comes up with a "file not found" error. For some reason it can still open text files. I have gotten MiSTerFS to be much more stable under DOS though. All versions of DOS even.

During the beta releases I was able to run ao486 with the VGA scaler off, force doublescan and the output looked to me like it should if I was using actual hardware on my 17" Dell CRT monitor on VGA. With the official release the monitor goes out of sync whenever a game loads but syncs fine on DOS prompt. Is this a bug or is it not possible to output this way any more?

The floppy issue is probably the same issue that prevents the OS/2 IBMFLPY.ADD from loading and just locking up. It's the controller code. I've been slowly working through that code and building local versions to see if I can make some progress, but it is slow going and a pretty big learning curve.

flynnsbit wrote: ↑Wed Aug 19, 2020 11:04 pm The floppy issue is probably the same issue that prevents the OS/2 IBMFLPY.ADD from loading and just locking up. It's the controller code. I've been slowly working through that code and building local versions to see if I can make some progress, but it is slow going and a pretty big learning curve.

I have begun scratching the surface of FPGA development, but so far it sure seems complicated and very different from my usual .NET C# programming.

Isstanar wrote: ↑Wed Aug 19, 2020 10:52 pm During the beta releases I was able to run ao486 with the VGA scaler off, force doublescan and the output looked to me like it should if I was using actual hardware on my 17" Dell CRT monitor on VGA. With the official release the monitor goes out of sync whenever a game loads but syncs fine on DOS prompt. Is this a bug or is it not possible to output this way any more?

Seems like it is not currently possible. Some discussion here: VGA Output, Scalers, and CRTs

Has anyone an idea what core the uploader was using in this video?

https://www.youtube.com/watch?v=BrB4eukTqIQ&t=784s

He has some interesting options like overclock (restores the 100 MHz setting) and somd VSync options.

What do you mean what core? Ao486 of course with batch files controlling the osd settings via sysctl.exe and the 100 MHz option is hidden for a reason

Didn't knew, that it is possible to change the core OSD settings via batch files. Thanks for the Info. Looked this topic up, didn't found anything. Can someone give me a hint, were I can find more about these batch modifications?

@Chris23235 : viewtopic.php?p=8590#p8590

breiztiger wrote: ↑Thu Aug 20, 2020 7:59 am @Chris23235 : viewtopic.php?p=8590#p8590

Many thanks!

decod81 wrote: ↑Wed Aug 19, 2020 5:01 pm

Q47 wrote: ↑Sat Aug 08, 2020 9:23 pm

jordi wrote: ↑Sat Aug 08, 2020 9:00 pm I've seen this strange scroll artifacts on 2d games

See right part of the screen:
https://www.youtube.com/watch?v=fVMoYMJb3hk

It's strange as it only happens on horizontal scrolling.

This is just hw/coding limitation of that era. Video under explains this on NES. Why you see it is simply because your screen doesn't do overscan anymore as CRTs did back in the day.

https://www.youtube.com/watch?v=wfrNnwJrujw

I'd just like to point out that this scrolling issue in ao486 is a bug in it's implementation of vga. It doesn't handle per pixel panning correctly and leaves the final scanline pixels not drawn if per pixel panning is other than 0. It has nothing to do with overscan and it's very different from what happens with nes. If you play the game on a real pc, it works just fine even if you are looking at the regions beyond normal scan limits and you can easily verify that less pixels are actually drawn with ao486 than are drawn on a real pc. This bug can be seen in most ega and vga games which utilize per pixel panning registers for scrolling (like keen 4-6, supaplex and many others). It's easiest to see that too few pixels are drawn with game like supaplex where the scrolling part of the screen is separated with linecomp function that creates the statusbar. Linecomp section is drawn in full all the way to the edge, while simultaneously the scrolling part is clearly not and remain black where the statusbar is not when per pixel panning is other than 0. I'm pretty sure the bug is in vga.v-file.

Also there are some VGA games or menus that use a 60-70fps hardware panning, which seems a bit choppy. Just go to "controls"menu in supaplex, and you see what happens. Again this is something to do with the "per pixel panning" register. I programmed some demos using it, and they seem to scroll OK, but there is clearly something missing.

The 100mhz setting was added as an "overclock" feature under hardware in the update released 16/8, if I am not mistaken. If you want to do it through the OSD.

The 100mhz overclock option is not visible in my MiSTer (updated with last versions), and by the videos on youtube the option is visible in some but not in others, de10-nano diferences?

Caldor wrote: ↑Thu Aug 20, 2020 9:58 am The 100mhz setting was added as an "overclock" feature under hardware in the update released 16/8, if I am not mistaken. If you want to do it through the OSD.

That's what is shown in the video too, but I don't have this in my version from 16/8.

Chris23235 wrote: ↑Thu Aug 20, 2020 10:47 am

Caldor wrote: ↑Thu Aug 20, 2020 9:58 am The 100mhz setting was added as an "overclock" feature under hardware in the update released 16/8, if I am not mistaken. If you want to do it through the OSD.

That's what is shown in the video too, but I don't have this in my version from 16/8.

Oh yeah... that is actually my video. I was a bit surprised to see this option, because I was pretty sure I did not get it at first when I upgraded to the 16/8 one, but I figured I had just overlooked it.

Maybe its because I have the sysctl.exe file on in my AO486 folder? Not even sure I do, it is probably only on my VHDs. Maybe if I boot from certain VHDs I wont have the option. Or maybe running sysctl will activate it? Except I am pretty sure I have not run the file yet.

I will experiment a bit when I get home, unless someone has an answer.

The 100MHz setting was set to debug-mode only because at that speed things get unstable. It's available, but only for testing purposes right now.

sibbi wrote: ↑Mon Aug 17, 2020 7:46 pm Thanks for the Floppy disable trick, I'll try that later tonight!

Can confirm that this worked just fine and I was able to finish the installation and get Windows 98 working.

I had to eventually move down to a 50Mhz clock however, it seems my MiSTer does not like running this core at 90Mhz for an extended period of time and as a result the emulation would lock up, usually during boot while playing the login sound, but sometimes a little later. It might be that the case I'm using has very poor airflow, I'll take it apart and see if it can be improved.

mbalmer wrote: ↑Thu Aug 20, 2020 2:37 pm The 100MHz setting was set to debug-mode only because at that speed things get unstable. It's available, but only for testing purposes right now.

But how did I get the "overclock" option then? Did I activate debug mode somehow maybe? I have been wondering how to do that, but have not found anything about it.

Caldor wrote: ↑Thu Aug 20, 2020 7:58 pm But how did I get the "overclock" option then? Did I activate debug mode somehow maybe? I have been wondering how to do that, but have not found anything about it.

I noticed that as well, almost as though it ‘took time’ for that option to ‘kick in’. Perhaps it was a fluke from testing all of those dev cores for the past three months

With the amazing ao486 core getting updates, is the github information page up to date? Specifically the 486DX33 performance CPU (no-FPU)?

With foggy memory of post-1980s computers before my first Windows 98 one, the 9min mark of Lon.tv's 25th anniversary of Windows 95 video gave some perspective. Next, looking at the Intel family line to re-learn the approximately 1989-1994 line up:

32-bit processors: the 80486 range: 80486DX, 80486DX2, 80486DX4

In technical terms, what makes the core's current status more like an 'overclocked' DX and not a DX2 or DX4 if splitting hairs? [Even without FPU implemented, I'm not calling it some hypothetical 80486SX model which was a DX with a disabled math processor].

Does anyone have an example of a retail 1990s computer make/model I could look up that would be closest in spec (capable of L1 and L2 cache)? Obviously 8GB hard drives would be Compact Flash solutions in 2020 as well as ram, etc.

The successor to the 80486 family is P5 micro-architecture: This is Pentium 1 territory, so I presume I would of heard someone on Youtube mention this if the Mister core could handle this [and... the core is called ao486 for a good reason].

Is the development ceiling or ultimate scope of this core to be the most stable and accurate overclocked 80486DX4?

The core as it stands now is an essentially unoptimized direct port of Bochs to FPGA, that then had a L1 cache-break bug fixed and a ton of other cache thrown at the problem (along with some minor tweaks). It targets the 486 'architecture' only in that it supports the 80486 instruction set (because Bochs does), but it shares next to nothing in terms of low-level architecture with the actual 80406 (nor was that a goal).

Thus, any comparisons with DX2/4 processors is moot as the architectural changes they introduced to achieve higher performance simply don't apply. This is more akin to software-emulation-atop-hardware.

It's pretty well understood that we're probably at or beyond the 80% maximum possible performance threshold, the biggest limiting factor now being sheer transistor state switching speeds in the FPGA itself. Clocks above 90MHz (internally) are not stable.

In terms of performance, yes, the current iteration of the core has a MIPS rating that approximates a 486SX/33, but that isn't because of any architectural similarities...it's simply because that's the approximate throughput of the fake semi-but-not-really-486 implementation in ao486. Remember, before the cache work, this same 486-instruction-set-compatible 'processor' pumped out blazing 80286 levels of performance.

rhester72 wrote: ↑Fri Aug 28, 2020 1:59 pm In terms of performance, yes, the current iteration of the core has a MIPS rating that approximates a 486SX/33, but that isn't because of any architectural similarities...it's simply because that's the approximate throughput of the fake semi-but-not-really-486 implementation in ao486. Remember, before the cache work, this same 486-instruction-set-compatible 'processor' pumped out blazing 80286 levels of performance.

You're being too strict.

Before the cache improvements, the speed was closer to a 386SX/20 or 386SX/25.
You may be confusing it with the first port of ao486 where the CPU was not overclocked.

Now, the performance level (depending on the application) is close to a 486DX50.

seastalker wrote: ↑Fri Aug 28, 2020 1:33 pm In technical terms, what makes the core's current status more like an 'overclocked' DX and not a DX2 or DX4 if splitting hairs? [Even without FPU implemented, I'm not calling it some hypothetical 80486SX model which was a DX with a disabled math processor].

Well, to be fair there was quite a many 486SX processors with higher than 33MHz frequency - but not from intel. Cyrix had at least 40MHz version and amd had SX processors at least to 66MHz speed. So nothing hypothetical here I would say.

Interesting fact is that Norton Utilities sysinfo detects the CPU as Cyrix 486.

IMHO because only difference between 486 SX and DX cpu was FPU, it is pretty fair to call Mister implementation "486 SX compatible CPU".