MiSTer FPGA Forum

From a fan's perspective, who is responsible for ao486 for MiSTer development? Is it largely Sorgelig? I see a few PRs from a few others, and I see ElectronAsh is working on PCI / video card integration. I don't interact much on Discord, so I am mostly blind to any info on there.

ash2fpga wrote: ↑Tue Sep 29, 2020 1:20 am From a fan's perspective, who is responsible for ao486 for MiSTer development?

You can find the list of direct contributors on the github page: https://github.com/MiSTer-devel/ao486_MiSTer
Kitrinx also helped out a bit but AFAIK gave the code to Sorgelig for review instead of doing PRs.

the ao486 core is so large that you can't simply add something.
you have to move things around or left something out, to get some room.
you can easily break something in the process.

Sorg spent weeks on this core, he knows this core better than anyone.
he has almost rewritten half of the core

A lot of reworks been done in ao486, so it's not as large as in beginning. There are enough resources for more features. More expansion cards can be implemented without problems.

That is awesome news! I vote for a fully featured MPU-401 with intelligent mode. Right now Monkey Island 1 doesn't sound right. I am not sure if SoftMPU would fix it or not. Also, a math coprocessor / FPU would be cool. I guess most important to me would be implementing the SVGA so it doesn't require the scaler and acts like a real video card would and not have all the jitter / sync problems that happen without the scaler. Right now everything is scaled so it doesn't look right. I am not complaining and am very thankful for all the amazing work that has already been done to this core.

I don't think Sorgelig was entertaining new requests for features, just that some room has been freed up for future endeavors. You've asked for things that have been asked for many, many times -- and some of them won't ever happen on MiSTer as it exists today, due to lack of resources available on the FPGA itself.

Understood. I was just excited that there is more room left. Another idea to fit more stuff on there would be to have choices available in the menu to enable and disable optional things like FPU, sound cards, etc. so you could choose what you need and it would tell you the FPGA resources required for each item and how many are free.

That's not really how it works. You can't dynamically load or unload FPGA constructs like sound cards. The entire FPGA is loaded before you ever get to a menu.

Yeah, I know, but I was thinking that after resetting and applying the menu options, it could reload the core again.

_Which_ core? A core is a single file containing every component. What you're describing would require dozens (or hundreds) of different cores, all compiled slightly differently. It won't work.

I forgot that it had to be compiled before being loaded. I guess an alternative idea would be to have two or three different cores depending on what was needed.

Is it possible to add an MPU-401 and an FPU? (if a developer picks it up, that is).

What I'm trying to ask is if it's technically feasible, or if there is a limitation from the MiSTer platform (FPGA size or otherwise) that would prevent any of these to be implemented on the AO486?

Cheers,

Hardware midi would be great. Also, if enough room I have a voodoo 2 I could send out to be logic scanalyzed for voodoo2 SLI. Or an AWE64 Gold. Probably be hard to hook up a printer, but some sort of usb printer support would be amazing. That and hopefully the already present video and sound improve. Some dos games like oregon trail deluxe have major issues still and windows 3.1 video does not work as well as 95 yet.

Televicious wrote: ↑Tue Oct 06, 2020 6:57 pm Hardware midi would be great. Also, if enough room I have a voodoo 2 I could send out to be logic scanalyzed for voodoo2 SLI. Or an AWE64 Gold. Probably be hard to hook up a printer, but some sort of usb printer support would be amazing. That and hopefully the already present video and sound improve. Some dos games like oregon trail deluxe have major issues still and windows 3.1 video does not work as well as 95 yet.

Games that run on a Vodoo card (even the first one) require a processor that is much faster than what the core is currently capable of (or ever will be capable of), so it will never happen - at least on this version of the MiSTer.

Also, none of the games that currently run on the hardware simulated by ao486 would sound better witth an AWE64 Gold as the games do not have support for it... that card came a lot later.

When talking about ao486, we need to keep our expectations period appropriate.

NightShadowPT wrote: ↑Sat Oct 10, 2020 10:54 am

Televicious wrote: ↑Tue Oct 06, 2020 6:57 pm Hardware midi would be great. Also, if enough room I have a voodoo 2 I could send out to be logic scanalyzed for voodoo2 SLI. Or an AWE64 Gold. Probably be hard to hook up a printer, but some sort of usb printer support would be amazing. That and hopefully the already present video and sound improve. Some dos games like oregon trail deluxe have major issues still and windows 3.1 video does not work as well as 95 yet.

Games that run on a Vodoo card (even the first one) require a processor that is much faster than what the core is currently capable of (or ever will be capable of), so it will never happen - at least on this version of the MiSTer.

Also, none of the games that currently run on the hardware simulated by ao486 would sound better witth an AWE64 Gold as the games do not have support for it... that card came a lot later.

When talking about ao486, we need to keep our expectations period appropriate.

Yeah, and the same seems to go for FPU. Even if MiSTer did get FPU support, the MiSTer is just not fast enough to handle fast CPUs. The limit is a 30Mhz 486SX. Maybe 35Mhz. In some ways its faster than this, but generally that is the best overall benchmark for this CPU. I guess if it got FPU support it would become a 486DX, but the games that use it would probably not benefit much from it. Quake f.ex. would still need Pentium speeds, which is a 100mhz Pentium and a fast FPU on top of that, which is one of the big differences between the 486 and Pentium CPUs. Even when a 486 did have FPU, it was not nearly as fast or accurate as Pentium FPU.

So unless we get hold of a much faster FPGA to work with, it would not make much sense to work on, other than maybe just doing it for the fun of it if some developer had the time and wanted to do it. Which would probably then be something that could be used for future FPGAs / cores.

Well, I was coming up with ideas, I figure ultrasound would be a lot to add so an awe32 would be more appropriate, but why not just go awe64 if going 32 and there's enough room, but that's a lot of IRQ and sound with a midi card as well. Probably best as is, but with better compatibility. Still some bugs in the video side and some timing things.

Some things I would like to see added for this core.

1. When adding floppies, CDs or HDDs to the core, its not very obvious in the UI how you eject them again. I know know its backspace that does this, but could be pretty nice if it was added in the view when you are adding a new disk that you can also click backspace to eject. I think there is already a scrolling text there that could have it added?

2. Could also be nice with audio CD support, but already seems to be planned for when someone figures out how it could be done for this core. Already cue/bin format is supported, but I suspect there might need to be a whole CD audio system implemented with its own FPGA logic area to make that happen as closely to how an actual PC did it back then, where it sends audio from the CD drive to the sound card. I suspect the current sound card implementation might not even support CDDA and that it might be the main obstacle?

Overall its just awesome where this core is at now and all that it supports. CD audio is mainly nice to have, since I think the core already supports playing games with CD audio, but just wont play the audio.

I have tried to ask for FPU implementation earlier and have been searching the web a lot for FPGA projects that tried to implement FPU in some way. I still think if it could become relevant to do that it probably would make sense to use the ARM FPU and map the calls to and from it... but would probably be very time consuming and the time could probably be much better spend on something else for now. Especially since it would then need a different mapper for the Minimig core because the Amiga also had its own FPU implementations.

Ultrasound - not sure it'd be all that consuming from an FPGA point of view, because the hardware itself was fairly minimalist - for example, the waveform generator for the MIDI engine was largely software-based (i.e. soundfonts). Ensoniq AudioPCI would actually be harder, and AWE *much* harder.

FPU - as has been stated before, any software _requiring_ FPU also pretty much required a Pentium, which is a bridge too far for ao486. I just can't see the point. It's not going to magically make Quake run great.

rhester72 wrote: ↑Mon Nov 09, 2020 12:10 pm Ultrasound - not sure it'd be all that consuming from an FPGA point of view, because the hardware itself was fairly minimalist - for example, the waveform generator for the MIDI engine was largely software-based (i.e. soundfonts). Ensoniq AudioPCI would actually be harder, and AWE *much* harder.

Good point, and considering there is fluidsynth already that kind of covers soundfonts so from a midi stance it's all there already. I suppose ultrasound had some FX stuff, but SB16 really covers the essentials. Someday the AWE will be inmortalized for the masses.