exxos's Atari, Amiga & retro forum

Typo, meant 1 byte per pixel.. I corrected it.

we would have from 8mhz to 16mhz to 32mhz, to 48mhz.. so 6x more bandwidth easily. Design aim is 50mhz. But thats mostly CPU limit.. FPGA MMU to FPGA shifter may even get 100mhz speeds.. So 12x rate could be possible if all logic is fast enough (probably not).

Though if shifter had own video ram, we could for example load a static background image, and move a sprite around all internally in shifter. background would be direct copy by shifter from video ram to RGB output.. sprites could be done the same way.. just need more video ram. This way , at least that simple example, wouldn't need to update the whole frame from ST-RAM each time. So leaves more time for CPU, DMA etc.

exxos wrote: 20 Aug 2018 17:02 Though if shifter had own video ram, we could for example load a static background image, and move a sprite around all internally in shifter.

I feel like this would be going a bit too far outside the ST's design for my comfort, into Sega Megadrive territory.

I can only speak for the existing FPGA shifter - it doesn't have enough RAM to do it anyway (less than 15KB), and not enough pins to add an external ram bus. Enough for bigger palettes and increased colour depth, though.

With a FPGA MMU, like 10ns, maybe 10ns SRAM.. data loading to the shifter will be extremely fast. Of course if we run everything at normal 8MHz then nothing should break. It could be possible to switch between 8MHz and 50MHz so anything which needs timing dependent stuff can run as normal, but loading to shifter can be done at 50MHz.. not sure if it be useful or not, but the key of faster MMU opens the doors to almost anything.

As mentioned before, blitter can run 50MHz or even higher speeds, once I get to test the suska blitter, we could even add more features in there if needs be.

As another thought.. the MMU itself could have some new functions built in.. for example a new register to quickly clear a block of ram... Once the CPU loaded start and end address, internal counters can clear the RAM contents very quickly internally. Had the thought while talks in other threads talking about fast clear of backgrounds for drawing next screen..

Blitter can likely do fast work with screen clear also as has direct access to RAM, but still takes some time to complete. Not sure how many cycles it would take to clear full screen area ? In anycase, internal MMU counters could do block clear faster and no need to use CPU or blitter for main work (only for address setup).

I was just wondering, given a lot of the slow-down for the ST is due to sharing the memory between the CPU and video sub-system, would a redesign using dual ported RAM for the screen memory be a good idea?

Of course, for full compatibility the wait states would have to be emulated but in other modes it would allow the CPU far more cycles.

stephen_usher wrote: 21 Aug 2018 18:47 I was just wondering, given a lot of the slow-down for the ST is due to sharing the memory between the CPU and video sub-system, would a redesign using dual ported RAM for the screen memory be a good idea?

I already talked about adding ram to shifter a few posts up..

exxos wrote: 21 Aug 2018 18:56

stephen_usher wrote: 21 Aug 2018 18:47 I was just wondering, given a lot of the slow-down for the ST is due to sharing the memory between the CPU and video sub-system, would a redesign using dual ported RAM for the screen memory be a good idea?

I already talked about adding ram to shifter a few posts up..

But surely that different to having dual ported main memory?

stephen_usher wrote: 21 Aug 2018 18:58 But surely that different to having dual ported main memory?

What options are there for dual port 16MB SRAM controlled by a PLD ?

I must admit that I don't know anything about the interfacability other than people on other projects mentioning it. If it's not possible then it's not possible. It was merely a thought as this is a suggestions thread.

stephen_usher wrote: 21 Aug 2018 20:55 I must admit that I don't know anything about the interfacability other than people on other projects mentioning it. If it's not possible then it's not possible. It was merely a thought as this is a suggestions thread.

Its a good thought, but I dont think its really possible. SRAM only has 1 IO channel, and that's what the new MMU core uses.. It would probably need a lot of work to get running and I can't redo the entire MMU in FPGA, only re-use suska code and add simple bits to it.. I will think about it though.. but even RAM "multiplexed" between CPU ^ SHIFTER, at 50MHz its going to rocket along anyway.