MiSTer FPGA Forum

I keep getting this error when trying to run Warcraft 2. Does not seem to matter what memory configuration I am using or whether its FreeDos, Dos 6.22 or Dos 7.1. Anyone know what might be causing it? I suspected it might have been a problem with the VGA bios, but it does not change anything when I change back to pre-cache cores and MiSTer files and bioses. Is this an error other people get?

I have made a VHD with a bunch of shareware games for DOS, using FAT16 format. I will update it later with one where I installed the Warcraft 2 demo, because this one is just with the installer.
http://dionysus.dk/software/DOS/Sharewa ... 0games.rar

I noticed that the pre-cache core seem to have much better memory performance. MemoryTest=286, OpcodeTest=99, VidramtTest=82... everything being over 70, but the last score is just 80 and it sees the CPUspeed as 80MHz.

The cache cores are tested with memorytest=88, OPcodeTest=37, VidramTest=45, so much lower scores, except the last one, being 242-245. Not sure what it means. Maybe the TopBench tool is not very good at testing this.

I also tested Game Wizard 32 Pro again and it does work with the old MiSTer file. I can even use Cache20 to run Game Wizard with this core.

I wonder if I can use this older MiSTer file with newer cores and get VESA support and Game Wizard to work... that would be nice.

Update: Tried running TopBench using different MHz settings, and it keeps getting the same scores... I guess I need to try some other bench marking tool.

Update 2: I have found that the Game Wizard problem I am having is 100% related to the VGA bios. If I use the old VGA bios. This one:
https://github.com/MiSTer-devel/ao486_M ... /boot1.rom

I can get Game Wizard 32 Pro to work with Cache20-29 as long as I use this old bios. But not any of the updated VGA bioses from the dev branch and not with any of the Tseng bioses. This seems strange, especially because the shareware version actually does work with all the bioses. Maybe because the full version has more features that are disabled in the shareware version.

Update 3: I got Warcraft 2 running. I ran it under Windows 95, and it runs great under Windows 95. I figured I would try the same with Descent, and it does begin to launch, but then after loading its data it crashes.

Update 4: Got the demo of Diablo 1 and Starcraft 1 running in Windows 95

thorr wrote: ↑Thu Jul 30, 2020 11:54 pmI have a Roland Sound Canvas and a Roland UM-One mk2 and would love to be playing Dos games with it (and Munt).

It might be a bit cumbersome to setup, but you could connect your Sound Canvas to a windows PC and use the midilink UDP function to use it with the Mister.

SuperBabyHix wrote: ↑Fri Jul 31, 2020 12:43 am

thorr wrote: ↑Thu Jul 30, 2020 11:54 pmI have a Roland Sound Canvas and a Roland UM-One mk2 and would love to be playing Dos games with it (and Munt).

It might be a bit cumbersome to setup, but you could connect your Sound Canvas to a windows PC and use the midilink UDP function to use it with the Mister.

Thanks. Midilink UDP sounds awesome for getting MIDI out of the MISTER using the Roland UM-One mk2, but the ao486 core still depends on SoftMPU which is a software TSR in DOS. I am hoping for a hardware MPU401 so we no longer need SoftMPU. It would emulate a MPU401 card in an ISA slot that is just "there" without the TSR and you could select it when running the sound setup. This would then be used in combination with Midilink UDP.

I understand there would be advantages to having a hardware mpu401, but you could still use your Sound Canvas with SoftMPU in the way I described.

Was anyone able to get Joystick support working in Win95. I always get "not connected" in the control panel. I tried the 2 axis 2 buttons Joystick that - as far as I recall - work without drivers and the Gravis Gamepad Pro that needs drivers. I installed the Xperience 4.5 drivers from Gravis but had no luck.

bbond007 wrote: ↑Thu Jul 30, 2020 9:59 pm

Cebion wrote: ↑Thu Jul 30, 2020 6:26 pm
I'll post my configs later so we can check what qemm did.
Qemm 8.03 btw, I only installed it because Bond wrote in Midilink that it is necessary for softmpu.

EMM386 also works as well. Some people reported problems (like hung notes) when using it with SoftMPU, but that has not been my experience...

Now I use a DOS 6.22 boot menu with QEMM 9.1 and EMM386 configs...

I had some issues like stacking notes but then it also happened in scummvm on my real computer so the china cable for 10€ is the fault i guess.
I ordered a Roland UM One, and it should arrive today. Other than that I also never had issues.

Edit:

Cable Arrived and no hanging notes / stacking notes, so the cable really was the culprit.

thorr wrote: ↑Fri Jul 31, 2020 2:09 am

SuperBabyHix wrote: ↑Fri Jul 31, 2020 12:43 am

thorr wrote: ↑Thu Jul 30, 2020 11:54 pmI have a Roland Sound Canvas and a Roland UM-One mk2 and would love to be playing Dos games with it (and Munt).

It might be a bit cumbersome to setup, but you could connect your Sound Canvas to a windows PC and use the midilink UDP function to use it with the Mister.

Thanks. Midilink UDP sounds awesome for getting MIDI out of the MISTER using the Roland UM-One mk2, but the ao486 core still depends on SoftMPU which is a software TSR in DOS. I am hoping for a hardware MPU401 so we no longer need SoftMPU. It would emulate a MPU401 card in an ISA slot that is just "there" without the TSR and you could select it when running the sound setup. This would then be used in combination with Midilink UDP.

Actually, SoftMPU requires EMM386, so it makes it a challenge to use MT-32 with Ultima 7, for example. HardMPU, especially with a physical MIDI-out directly from the MiSTer would be amazing. I wonder if an adaptor could be created for the User I/O port.

Sorgelig has implemented an opensource uart, that means it no longer costs a couple thousand dollars to compile the core....

Also, RobertPeip increased the size of L2 cache, by double.

You won't believe it: I am playing Strike Commander CD on ao486 latest cache version. It is perfectly playable using maximum detail options (textures on etc.). Maybe 20 fps, or even higher. Awesome! Joystick and mouse works, too! Music, sound effects and speech works, intro works, all perfect it seems.

IAmParadox wrote: ↑Fri Jul 31, 2020 8:06 pm Sorgelig has implemented an opensource uart, that means it no longer costs a couple thousand dollars to compile the core....

Also, RobertPeip increased the size of L2 cache, by double.

Where did you see this?

EDIT: Never mind, wasn't following the dev branch

When I use the "MiSTer" binary included in the ZIPs (provided by bbond007 on the first page) I can never get any pictrure, not on my VGA monitor (it reports 15KHz, quite strange for a PC) nor in my HDMI output. I've tried to enable both VGA Scaler and scandoubler and nothing. Has anybody managed to get that binary working?

Chris23235 wrote: ↑Fri Jul 31, 2020 5:41 am Was anyone able to get Joystick support working in Win95. I always get "not connected" in the control panel. I tried the 2 axis 2 buttons Joystick that - as far as I recall - work without drivers and the Gravis Gamepad Pro that needs drivers. I installed the Xperience 4.5 drivers from Gravis but had no luck.

For anybody trying it, I found the solution. Don't use the all-in-one Xperience driver software, but the 2 floppy discs for the Gravis Gamepad Pro. Calibrating still doesn't work under Windows 95 (it pops up and then closes instantly), but the Gamepad seems to work now.

Schyz wrote: ↑Fri Jul 31, 2020 8:50 pm When I use the "MiSTer" binary included in the ZIPs (provided by bbond007 on the first page) I can never get any pictrure, not on my VGA monitor (it reports 15KHz, quite strange for a PC) nor in my HDMI output. I've tried to enable both VGA Scaler and scandoubler and nothing. Has anybody managed to get that binary working?

yes i just copied it to my sd card

Schyz wrote: ↑Fri Jul 31, 2020 8:50 pm When I use the "MiSTer" binary included in the ZIPs (provided by bbond007 on the first page) I can never get any pictrure, not on my VGA monitor (it reports 15KHz, quite strange for a PC) nor in my HDMI output. I've tried to enable both VGA Scaler and scandoubler and nothing. Has anybody managed to get that binary working?

are you using the bootx.rom files, as well? and put the mister in the root of the fat directory?

Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

rhester72 wrote: ↑Fri Jul 31, 2020 10:09 pm Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

I haven't used the software, at all, yet, is there more than one device? maybe you have the wrong one selected?

IAmParadox wrote: ↑Fri Jul 31, 2020 10:20 pm

rhester72 wrote: ↑Fri Jul 31, 2020 10:09 pm Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

I haven't used the software, at all, yet, is there more than one device? maybe you have the wrong one selected?

There are lots of compile targets, but given the Cyclone V is the FPGA on the DE10 Nano, I'm taking it as read it's the correct one . It's also the target I've used to compile every other core without issue - I suspect the switch to an open-source UART may have pushed things over the edge, but if there's any clever means of better optimizing the fit, I'm not aware of one (hence the question).

rhester72 wrote: ↑Fri Jul 31, 2020 10:09 pm Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

Yes !!!!!

i just did it !

IAmParadox wrote: ↑Fri Jul 31, 2020 10:09 pm are you using the bootx.rom files, as well? and put the mister in the root of the fat directory?

No, the issue is that I cannot even see the main Menu, the issue happens from the moment I turn on the MiSTer, I don't reach the point of starting ao486. Are you using HDMI or VGA?

EDIT: The issue is that I was transferring the file with Filezilla instead of WinSCP. Now it works great.

tontonkaloun wrote: ↑Fri Jul 31, 2020 10:59 pm

rhester72 wrote: ↑Fri Jul 31, 2020 10:09 pm Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

Yes !!!!!

i just did it !

OK..._how_ did you do it (with Lite)?

rhester72 wrote: ↑Sat Aug 01, 2020 12:50 am

tontonkaloun wrote: ↑Fri Jul 31, 2020 10:59 pm

rhester72 wrote: ↑Fri Jul 31, 2020 10:09 pm Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

Yes !!!!!

i just did it !

OK..._how_ did you do it (with Lite)?

I was able to do it with Lite. It failed the first time, but I set the device Cyclone V to the same one on the DE10 board and then ran it again and it compiled fine.

rhester72 wrote: ↑Sat Aug 01, 2020 12:50 am

tontonkaloun wrote: ↑Fri Jul 31, 2020 10:59 pm

rhester72 wrote: ↑Fri Jul 31, 2020 10:09 pm Anyone able to compile the (very latest) dev branch? I get "can't fit design in device" against the Cyclone V target in Quartus Prime Lite 17.0.2.

Yes !!!!!

i just did it !

OK..._how_ did you do it (with Lite)?

Might be because the part of AO486 that required more than Lite is now being replaced with an open source alternative, it sounds like.

From the Dev branch on GIT:

ao486.sv Use opensource UART. 10 hours ago

Caldor wrote: ↑Sat Aug 01, 2020 2:54 am Might be because the part of AO486 that required more than Lite is now being replaced with an open source alternative, it sounds like.

I'm aware, I'm the one that told Sorgelig about it.

The problem is that the fitter - at least in Lite 17.0.2 (which is the recommended build platform) - can't make ao486 fit in the available units on the Cyclone V...but that _should_ be a universal problem, so I'm trying to figure out exactly what steps anyone followed that actually got it to build (and more importantly fit).

rhester72 wrote: ↑Sat Aug 01, 2020 2:57 am

Caldor wrote: ↑Sat Aug 01, 2020 2:54 am Might be because the part of AO486 that required more than Lite is now being replaced with an open source alternative, it sounds like.

I'm aware, I'm the one that told Sorgelig about it.

The problem is that the fitter - at least in Lite 17.0.2 (which is the recommended build platform) - can't make ao486 fit in the available units on the Cyclone V...but that _should_ be a universal problem, so I'm trying to figure out exactly what steps anyone followed that actually got it to build (and more importantly fit).

Not sure what you mean. Fit in terms of the core size, or fit in terms of bandwidth or something else? If its the core size, then I think some of the changes they have been doing might have helped reduce the core size. The new UART might also be smaller... although it does not seem like it. Or at least Cache31 is the largest core yet.

Core size - or more correctly LUs, the basic unit of operation in an FPGA. Quartus tries to arrange the gates such that they have minimal overlap and thus waste the least number of LUs in a process called 'fitting' at compile time...and after the fitter is done, it says there's too many LUs required (active + waste) to fit in the constraints of the Cyclone V. Clearly that isn't the case...but I'll be damned if I can figure out why it thinks otherwise.

For what it's worth, I most seriously doubt the OpenCores 16550 implementation is smaller than Altera's commercial implementation, but I think what actually pushed it VERY close to the edge was doubling L2 cache again. I'm trying a build now without that just to see if it makes the fitter happy.

EDIT: Yeah, it's the L2 cache commit that breaks fitting...without that, the open UART core addition compiles cleanly. That means we're getting very, very close to maxing out the LUs on the CycV. That sucks.

The only other thing I changed is the optimization type. It was set to high performance (may use more space) and I changed it to balanced. After setting the exact model of Cyclone V and the performance setting, I got it compiled on Lite.

Fitting is a combinatorically complex operation which isn't just about putting a bunch of gates into a bunch of gate templates; it has to minimize pathways and meet timing guidelines as well. It tries to do this by starting with a pseudorandom starting point, and builds upon it, backing out when it encounters a problems. This is why a 75% usage design can end up not being able to be fitted.

There are options to control the amount of effort that fitter puts into this. You most likely need to set it to the maximum amount of effort. If that still fails, you don't have a lot of options without learning more about FPGAs and how to write your own stuff. You can change the seed, but that's again a statistical game. Anything else that can be changed has an impact on how the core itself functions.

Oh, and the open source 16550 is almost certainly larger than the special Altera IP; Altera often bakes in some special silicon to assist with these special IP's - not necessarily the whole thing, but some building blocks which save effort.

Sure enough, a second compile attempt let the fitter work...but I still think the LU fill is pretty close to the breaking point now for this core. Caveat emptor!

Softmpu seem to be broken with last build or just me ?

breiztiger wrote: ↑Sat Aug 01, 2020 6:38 am Softmpu seem to be broken with last build or just me ?

Yes, Bbond007 posted a fix in the UART thread: viewtopic.php?p=6914#p6914