Brainstorming using Microcontroller as mapper

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Milowork
Posts: 4
Joined: Wed Jan 27, 2021 12:43 pm
Location: Xi'an, mainland of China
Contact:

Re: Brainstorming using Microcontroller as mapper

Post by Milowork »

Ben Boldt wrote: Tue Nov 17, 2020 9:51 am I did try a bit-bang loop as an experiment and it was considerably faster. I didn't measure it but I am thinking it would be fast enough. The problem is that if you bit-bang, the micro can't go off and do anything else, such as generate expansion audio.
There is a solution to this problem. When STM32 (or other microcontroller) processes audio, let 6502 execute a loop in RAM until STM32 completes processing and can respond to 6502's read operation.

The disadvantage is that it will take up 6502's cycles. You can consider moving some arithmetic intensive operations from 6502 to STM32 to make up for the occupied cycles, but this will lead to your work no longer being a ROM that can be emulated by a general emulator.
squall926
Posts: 35
Joined: Wed Jan 03, 2018 3:50 pm

Re: Brainstorming using Microcontroller as mapper

Post by squall926 »

I tried a STM32H750(1mB ram) running at 400Mhz to emulate a sms cart, but without luck.
On stm32f417(192kB ram) running at 168Mhz worked.
Trirosmos
Posts: 50
Joined: Mon Aug 01, 2016 4:01 am
Location: Brinstar, Zebes
Contact:

Re: Brainstorming using Microcontroller as mapper

Post by Trirosmos »

squall926 wrote: Sun Apr 11, 2021 8:29 pm I tried a STM32H750(1mB ram) running at 400Mhz to emulate a sms cart, but without luck.
On stm32f417(192kB ram) running at 168Mhz worked.
Yeah, I initially thought those faster MCUs would allow for much faster GPIO speeds, but unfortunately the opposite seems to be the case. I think it has to do with how far removed from the GPIO the CPU is on these micros. It has to go over four different bus arbitrers or something before getting to the peripheral.
However, a few high-speed peripherals sit on the same bus as the CPU and I think they have direct access to the pins when you configure them in the alternate mode? The FMC, LCD display controller, SDMMC and Quad SPI peripherals are all in that category. So, yeah, maybe some shenanigans could be pulled off with those.
Ben Boldt wrote: Tue Nov 17, 2020 9:51 am I really spent some time thinking of how to use DMA for this, because these micros do have really good DMA abilities. The problem is that there are multiple PRG-ROM banks. You have to use the high-order CPU address bits to decide which bank you are in; i.e. which register to push out to the extended PRG bits. With DMA, you don't have the ability to put a decision like that in there.
I thought about this for a while and I think there's a way to implement the mapper logic with the DMA peripherals alone. STM isn't super clear about this but, as far as I understand, there's no round-robin between the DMA channels (I might be completely wrong about this). So, a high-priority transfer will be finished before any of the lower priority ones begin,
You could make it so PPU /RD going low triggers two transfers: the higher priority one reads the MSBs of the PPU address and saves them in the least significant byte of the source address of another DMA channel. The lower priority one activates that other channel. That third channel now reads the bank number from a LUT and spits it out through GPIO for an external memory to use.
Using timers and configuring DMA2 channels using DMA1 transfers, you could pull off all sorts of interesting operation sequences... probably.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Brainstorming using Microcontroller as mapper

Post by Ben Boldt »

Holy cow, it never crossed my mind to use a DMA to write to control registers other DMAs, super cool idea.

I noticed the same thing with these STM32s I have here, if I toggle an I/O bit super fast, it comes out all funky like I wasn't getting all the toggles out to the pin. Older micros (16-bit, 8-bit PICs) never had that problem.
Post Reply