STM32F407ZET6 board compatibility

[windship]

Hello again, here's my another curiosity question lol

As you told, STM32F407 board has 128KB of ROM size limitation because of physical SRAM capacity. So I wondered if there are another board has more SRAM or expand feature, and I found this. It has extend SRAM points so we can get more SRAM, so it means we can load ROM bigger than 128KB in theory.

And here's my actual try:

I just used the firmware you provided for this big board too, but yeah, it didn't work at all. I connected IO pins to follow previous process(same number & same connection).

Do I have to use another package for compile, not STM32F4-Discovery_FW_V1.1.0? Do I must change IO pin connection? Any help will be appreciated!

[kernelcrash]

Do you have any info about how the SRAM is memory mapped in that board? I have some of the stm32 boards that have SDRAM and they use a completely different type of memory interface such that the memory doesn't quite work like normal memory that you would attach to a CPU (you have to remember that these are microcontrollers rather than pure CPUs). In the stm32f4 this is the FMC (flexible memory controller). I think accessing SRAM still uses this FMC thing. It's an awkward thing to use as it requires initialisation, and often the dedicated pins for a SRAM or SDRAM attached conflict with pins you would like to use for other purposes.

I know for the stm32f429 board with SDRAM I had, accessing the SDRAM was complicated and slower than you would like it to be. The only way that would have been feasible would have been quite complex and have wait states inserted at appropriate points to make it work. Originally I had the idea of using the stm32f429 board with 8MB SDRAM as some kind of cheap Amiga RAM expansion .. but I ended up giving up. It just didn't work.

I'd really like the stm32f7 boards to come down in price. The F7 is quite nice. Some like the stm32f767VIT6 have 512K of ram. There is one board on aliexpress (search for "stm32f767vi development board") that looks interesting, but its still a lot more expensive than the stm32f407 boards. I have not bought one.

And before you ask, I have also tried the stm32h7 boards (like the stm32h750) and the H7 actually has a completely different architecture that makes them worse than the stm32f4 in terms of how I use these boards. The stm32f4 can drive the GPIO pins far faster than a stm32h7.

[windship]

The maker shop said it's "Reversed SRAM extension location". So I think it points somewhere about 'Reversed' area in this memory map: And they saying the SRAM is 1MB. That's what I know.

[kernelcrash]

In many way, trying to use the SRAM on that board is like starting a new project. There are a few things that make it a bad choice;

• So the ZET6 has the same 192K internal ram like the VET6 and VGT6. That ram can be 'generally' accessed in a single cycle. So at 240MHz you can access it in 4 or 5ns. The interrupt code that emulates ROM reads is trying very hard to get data on the Z80A databus as early as it can, so it can leave it stable for as long as possible. I was just rereading my original article on my blog and I said something like the MSX memory cycles are either 690ns or 560ns, and my code was taking between 250 and 270ns to get some data onto the Z80 databus (ie. this is with the code being able to access ram in 4 or 5ns to grab a byte to shove on the bus. The SRAM is most likely going to have an access time of closer to 50ns, so roughly 10 times slower. In theory, getting data on the bus (now) between 300 and 320ns. In theory that might work. But it could end up being higher than that depending on the megarom mapper being emulated. I guess the later and later you get valid data onto the bus, means that the overall ROM emulation is less and less likely to work. My policy is to try like crazy to get data onto the databus as early as possible to increase the chances of everything working OK.

• That FMC (or FSMC) interface to the SRAM is not completely like a traditional address and data bus that you would have say on a Z80 based system. There's a chunk of code required to initialise it, and if it were me I would spend a fair bit of time just confirming it is actually working correctly. I'd also be testing to see whether you can consistently access it in 50ns. Sometimes these things are not as consistent as you would like them to be (these ARM microcontrollers have so many things that can vary the results). And the other huge problem is that the pins used on the ZET6 to talk to the SRAM are GPIO pins, but you can only use specific ones. When I looked at an example ZET6 board schematic, it had many PD and PE pins going to the SRAM for the FSMC. Of course the ROM emulator uses the PD pins and PE pins for connecting to the Z80A of the MSX computer. There's no way you could 'share' them, so you would have to rewrite the entire emulation code using a different set of pins ... which would take some work. Glancing at that example ZET6 board schematic again, there are so many pins dedicated to the FMSC interface, that I doubt you could find any pins elsewhere to make it work. There are spare GPIO pins, but you really need 'one entire set of 16 pins together' for the Z80 address bus, and another set of 8 all together for the data bus. I find the PA and PB pins are a bit problematic as they often have other uses, and quite a few of the PA port pins are not 5V tolerant.

So , it's not like its got an extra 512K or 1MB of RAM at the same speed as the internal 192K. Yes, it's got extra RAM, but it's a lot slower and the interface to the RAM takes up a lot of the pins that you would like to use for other purposes.

[windship]

Whoa, thank you for detailed explanation. I couldn't understand all of your comment, but now I know "It's possible but not simple and clean". You can consider it when you have free time later. Thank you again!