MiSTer FPGA Forum

aberu wrote: ↑Mon Mar 14, 2022 3:37 am MT32-Pi is a baremetal emulator running essentially at the kernel level (https://github.com/dwhinham/mt32-pi/blo ... kernel.cpp). It's very different than MUNT. It would need to be modified significantly.

I started making a version of mt32d that bypasses ALSA completely for audio output and writes directly to /dev/MrAudio.

I ran into a problem with the pacing of the of the data and was overflowing MrAudio.

Perhaps with that improvement and an overlock MUNT on the HPS would be an improvement over its current state.

I always found curious that mt32d starts getting tempo issues way before it hits 100% on the CPU. There must be another bottleneck somewhere.

bbond007 wrote: ↑Mon Mar 14, 2022 9:03 pm

aberu wrote: ↑Mon Mar 14, 2022 3:37 am MT32-Pi is a baremetal emulator running essentially at the kernel level (https://github.com/dwhinham/mt32-pi/blo ... kernel.cpp). It's very different than MUNT. It would need to be modified significantly.

I started making a version of mt32d that bypasses ALSA completely for audio output and writes directly to /dev/MrAudio.

I ran into a problem with the pacing of the of the data and was overflowing MrAudio.

Perhaps with that improvement and an overlock MUNT on the HPS would be an improvement over its current state.

I always found curious that mt32d starts getting tempo issues way before it hits 100% on the CPU. There must be another bottleneck somewhere.

The memory speed could be a bottleneck maybe?
The speed boost on the CPU seem to translate very differently depending on the usage, the amiga running on the arm got close to 90% speed increase, while Dosbox was linear with a 50% increase for a 50% OC. So it's definitely worth looking into, even if I'm sure we can't expect the performance of a dedicated Pie.

We need to get the MT-32 in FPGA. I am not sure how much space it would take up, but it could be well worth it even if the L2 cache was a bit smaller in ao486.

thorr wrote: ↑Mon Mar 14, 2022 10:23 pm We need to get the MT-32 in FPGA. I am not sure how much space it would take up, but it could be well worth it even if the L2 cache was a bit smaller in ao486.

While it would be quite cool to make an fpga version of the mt32, it definitely would not fit in the 486 core, which is arguably the primary use for it to begin with. I think it would also probably not be as good as the software version due to the difficult getting all the filtering right.

I saw this and sort of laughed. If only it was that easy: https://www.electronicdesign.com/techno ... -the-mouse

thorr wrote: ↑Mon Mar 14, 2022 11:19 pm I saw this and sort of laughed..

I mean it would have to be a reimplementation. Not like anyone expects to take the existing C code and just "recompile".

FoxbatStargazer wrote: ↑Mon Mar 14, 2022 12:20 am MUNT_OPTIONS = -l # controls the quality of low-pass filters.

I wonder about a hybrid implementation, maybe it doesn't have to all fit in the fpga, but if there's only something like a low-pass filter that's slow and everything else can be done in the CPU, maybe we could move only that low pass filter in the FPGA.

Neocaron wrote: ↑Mon Mar 14, 2022 9:30 pm The memory speed could be a bottleneck maybe?

Perhaps, but currently, how the HPS sound works is that kernel is compiled with the "null" audio device and has essentially has no audio. It simply emulates having a device.

But obviously you hear sound right?

Well, it is transcoded to 48000 and sent to a "file" (via an ALSA option --> /etc/asound.conf), but in this case the that file is "/dev/MrAudio" which is a special character device which mixes and outputs the sound to the FPGA.

This works great for most stuff (ScummVM for example), however I think that could possibly be the bottleneck concerning mt32d.

Kitrinx wrote: ↑Mon Mar 14, 2022 10:28 pm

thorr wrote: ↑Mon Mar 14, 2022 10:23 pm We need to get the MT-32 in FPGA. I am not sure how much space it would take up, but it could be well worth it even if the L2 cache was a bit smaller in ao486.

While it would be quite cool to make an fpga version of the mt32, it definitely would not fit in the 486 core, which is arguably the primary use for it to begin with. I think it would also probably not be as good as the software version due to the difficult getting all the filtering right.

I think the intent is to run on the software side on the one core that isn't 100% running.

KremlingKuthroat19 wrote: ↑Sun Mar 13, 2022 5:24 pm Very cool development! Just curious about the possibilities. Does this mean that some cores that were impossible may be more realistic (a.k.a. N64; which I know is a longshot due to it requiring too much memory, but maybe a hybrid approach is possible with this), or is it more likely that it'll just be a performance boost for existing and new cores?

We will be Emulating ps5 with this

KremlingKuthroat19 wrote: ↑Sun Mar 13, 2022 5:24 pm Very cool development! Just curious about the possibilities. Does this mean that some cores that were impossible may be more realistic (a.k.a. N64; which I know is a longshot due to it requiring too much memory, but maybe a hybrid approach is possible with this), or is it more likely that it'll just be a performance boost for existing and new cores?

Based on my very basic knowledge, if the hybrid stuff is figured out the N64 CPU could probably run on the ARM alone with a 1.2ghz oc. But then even if that's possible the GPU of the N64 is way more complicated that what came before. So that would be years of work to implement in FPGA. And the memory is still a big problem.
Right now though with the 50% OC, I'm sure you could run an N64 emulator on the ARM side with 5 to... 10fps?. Anyone interested to try one for science?

The big problem with the N64 is it has pretty large and very fast memory busses, much larger and faster than pretty much any other contemporary device. The SDRAM boards are not particularly large and fast by comparison, and it's taking a lot of clever designing like running the SDRAM faster than the original system's memory so that it can emulate multiple different banks of memory simultaneously. No amount of trickery is going to get SDRAM that peaks out at around 160Mhz to act like RDRAM running at 250Mhz. The DDR3 ram is fast enough, but the latency will almost certainly be unacceptable.

I think it's probably possible to get the DE10-nano to run an N64, but it will be much harder and more complex than any previous core. ao486, PSX and Saturn are already pushing the limits of what the board is capable of, it would take an incredible amount of FPGA skill just to get something that runs worse than a N64 emulator on a Pi 2B.

Mr. Encyclopedia wrote: ↑Tue Mar 15, 2022 6:55 pm The big problem with the N64 is it has pretty large and very fast memory busses, much larger and faster than pretty much any other contemporary device. The SDRAM boards are not particularly large and fast by comparison, and it's taking a lot of clever designing like running the SDRAM faster than the original system's memory so that it can emulate multiple different banks of memory simultaneously. No amount of trickery is going to get SDRAM that peaks out at around 160Mhz to act like RDRAM running at 250Mhz. The DDR3 ram is fast enough, but the latency will almost certainly be unacceptable.

I'm pretty sure if video was ran on the linux side that SDRAM wouldn't really be available anyway since the CPU and video share the memory bus. The fast read speeds of the cartridges is going to cause a similar issue too. Using DDR3 is likely to cause timing and visual issues similar to current emulators.

Also, the CPU runs at such a high clock speed that it's unlikely to be stable. ao486 is clocked at ~90mhz but only runs a third of that speed, N64 would need to be cycle accurate.

Has anyone used one of those infrared laser thermometer things (with fan removed) to measure the temp before OC and after?

I have one and I could do that, but its the cheapest one from Harbor Freight. I took my own temp with it and apparently I have hypothermia...

bbond007 wrote: ↑Thu Mar 17, 2022 3:06 am Has anyone used one of those infrared laser thermometer things (with fan removed) to measure the temp before OC and after?

I have one and I could do that, but its the cheapest one from Harbor Freight. I took my own temp with it and apparently I have hypothermia...

Sadly I don't have any. I can only tell you that the heatsink doesn't feel much hotter by touch compare to no OC... That's my very precise test

bbond007 wrote: ↑Thu Mar 17, 2022 3:06 am Has anyone used one of those infrared laser thermometer things (with fan removed) to measure the temp before OC and after?

I have one and I could do that, but its the cheapest one from Harbor Freight. I took my own temp with it and apparently I have hypothermia...

External body temp is usually about 0.5-1.5 degrees lower than core body temp, so unless you stuck that thing up where the sun doesn’t shine, both the thermometer and you might be alright

bbond007 wrote: ↑Thu Mar 17, 2022 3:06 am Has anyone used one of those infrared laser thermometer things (with fan removed) to measure the temp before OC and after?

I have one and I could do that, but its the cheapest one from Harbor Freight. I took my own temp with it and apparently I have hypothermia...

I was going to get an ultra thin thermocouple and place it between the heatsink and the chip but thought it was excessive. It's going to be impossible to measure thermal junction temperature anyway.

Hi!

Has someone tried downclocking the ARM core? The best part of this is, for me, being able to keep my MiSTer cooler without a fan (I don't use any computers with fans, and my MiSTer is cooled with a good copper heatsink).

Would downclocking affect CHD decompression on cores that use it like PSX, PC-Engine CD, etc?

vanfanel wrote: ↑Sun Mar 27, 2022 6:59 pm Hi!

Has someone tried downclocking the ARM core? The best part of this is, for me, being able to keep my MiSTer cooler without a fan (I don't use any computers with fans, and my MiSTer is cooled with a good copper heatsink).

Would downclocking affect CHD decompression on cores that use it like PSX, PC-Engine CD, etc?

No, the clock for the ARM core does not affect much on the FPGA.

The ARM core, when it's normally clocked is only producing part of the heat. The other part is the FPGA cores themselves. Unless you want to downclock those too you won't be able to get it to be much colder.

amstan wrote: ↑Sun Mar 27, 2022 7:37 pm

vanfanel wrote: ↑Sun Mar 27, 2022 6:59 pm Hi!

Has someone tried downclocking the ARM core? The best part of this is, for me, being able to keep my MiSTer cooler without a fan (I don't use any computers with fans, and my MiSTer is cooled with a good copper heatsink).

Would downclocking affect CHD decompression on cores that use it like PSX, PC-Engine CD, etc?

No, the clock for the ARM core does not affect much on the FPGA.

The ARM core, when it's normally clocked is only producing part of the heat. The other part is the FPGA cores themselves. Unless you want to downclock those too you won't be able to get it to be much colder.

I am thankful for your answer, but I think it's not quite right.
I know that, of course, downclocking the ARM cores will have no impact on FPGA cores in general, but we have to consider that CHD access/decompression is made on the GNU/Linux side, if I am not mistaken. That's why I ask specifically about the CD based cores.

vanfanel wrote: ↑Sun Mar 27, 2022 6:59 pm Hi!

Has someone tried downclocking the ARM core? The best part of this is, for me, being able to keep my MiSTer cooler without a fan (I don't use any computers with fans, and my MiSTer is cooled with a good copper heatsink).

Would downclocking affect CHD decompression on cores that use it like PSX, PC-Engine CD, etc?

This driver already supports downclocking. Install the kernel and run the set_cpu_max_400.sh to halve the speed from 800 MHz stock to 400 MHz.

It runs with 140 mW less power and is even running the Cyclone V within spec as Intel only specifies a maximum of 800 MHz for this clock, no minimum.

Anything CPU bound on the Linux side is tested to be half speed. So if the decompression is on the Linux side it will inevitably be slower. I myself tested loading Neo Geo games. It was noticeably slower with underclock and faster with overclock.

Coolbho3k wrote: ↑Mon Mar 28, 2022 9:15 pm

vanfanel wrote: ↑Sun Mar 27, 2022 6:59 pm Hi!

Has someone tried downclocking the ARM core? The best part of this is, for me, being able to keep my MiSTer cooler without a fan (I don't use any computers with fans, and my MiSTer is cooled with a good copper heatsink).

Would downclocking affect CHD decompression on cores that use it like PSX, PC-Engine CD, etc?

This driver already supports downclocking. Install the kernel and run the set_cpu_max_400.sh to halve the speed from 800 MHz stock to 400 MHz.

It runs with 140 mW less power and is even running the Cyclone V within spec as Intel only specifies a maximum of 800 MHz for this clock, no minimum.

Anything CPU bound on the Linux side is tested to be half speed. So if the decompression is on the Linux side it will inevitably be slower. I myself tested loading Neo Geo games. It was noticeably slower with underclock and faster with overclock.

I tried the 400mhz mode and the Mister framework does seem a bit slower, especially rom loading and updates.
The 1.2ghz OC has been my daily clock for anything I've trown at it and not a single issue to report so far after 2 weeks.

The 50% overclock seems pretty stable, and seems well within the realm of safe overclocking for ARM processors. What remains to be seen is how this affects the life of the chip long-term and if that's worth whatever benefits we can get from the increased speed.

Mr. Encyclopedia wrote: ↑Tue Mar 29, 2022 2:00 am The 50% overclock seems pretty stable, and seems well within the realm of safe overclocking for ARM processors. What remains to be seen is how this affects the life of the chip long-term and if that's worth whatever benefits we can get from the increased speed.

I wish someone could put a thermometer to check, but I'm sure the temp increase is 2/3C at best with the 50% OC, since the power draw is only slightly higher. I really doubt the longevity would be at risk here.

Also remember it's only a 30% increase from the binned -C6 part with (as far as I know) identical silicon which has a 925 MHz core clock, a max Tjunction 15 degrees lower at 85C, and no expectations for active cooling.

Unfortunately, overclocking doesn't work for me. After setting 1200, mister crashes after loading the core or pressing F9.

Kamil wrote: ↑Tue Mar 29, 2022 9:54 am Unfortunately, overclocking doesn't work for me. After setting 1200, mister crashes after loading the core or pressing F9.

Did you try 400? If it crashes as well, there might be a typo in the file. What the amp level of your power adapter?
400 should never crash. It should just be slow

Kamil wrote: ↑Tue Mar 29, 2022 9:54 am Unfortunately, overclocking doesn't work for me. After setting 1200, mister crashes after loading the core or pressing F9.

I'm guessing you lost the silicon lottery and your chip is just not stable at 1200 As Neocaron said can you try 1000 and 400?

I have a power adapter 5V, 4A.
400 MHz works as it should.
1000 MHz sometimes crashes, even for F9.
1200 MHz crashes when loading core or F9.
I probably lost the silicon fight.

Kamil wrote: ↑Tue Mar 29, 2022 7:53 pm I have a power adapter 5V, 4A.
400 MHz works as it should.
1000 MHz sometimes crashes, even for F9.
1200 MHz crashes when loading core or F9.
I probably lost the silicon fight.

It's pretty crazy not even 1000 MHz works stable for you. That's not really a bump over stock. Seems like there's a lot of variation.

If you have a multimeter handy I'd ask you to measure the 1.1 V rail on your board.

Kamil wrote: ↑Tue Mar 29, 2022 7:53 pm I have a power adapter 5V, 4A.
400 MHz works as it should.
1000 MHz sometimes crashes, even for F9.
1200 MHz crashes when loading core or F9.
I probably lost the silicon fight.

That's like the most unlukiest luck you can get right there.