Firmware transfer

[windship]

Hello, a novice here. Would you kindly share how can I flash this firmware to the STM board?
Do I need to compile first? How?

[kernelcrash]

Yeah, you need to compile first. I've updated the main README.md with some notes, and also for the menu-ing program kcmfs I've updated README-kcmfs.md. It has some additional notes as it's a Z80 program and requires sdcc and hex2bin in order to build.

stm32 boards have several ways to flash them. I've included one of the easier ways in the README.md. That transfer.sh script is a one liner that uses dfu-util to flash the board over USB.

I'll note that I hadn't looked at this project for a few years (if you look at my blog or other repos you'll see I've sort of done this whole ROM/FDC thing to a few systems now. They are all variations of the same code), but a reader recently reached out to me about it. He's had a lot of success with the ROM emulation , but some issues with the FDC side of things that we are still working through. I'm not quite sure what the issue is. These things are hard to troubleshoot remotely ;-) MSX as a standard is perhaps not as standard as I'd like it to be. It works fine on my Omega MSX2 thing. And it actually works on my MSX on a Breadboard as well ... but I haven't actually tried it myself on a proper (back in the day) MSX machine.

Anyway, good luck.

[windship]

Hello again,

I tried to compile the firmware with your advice but no luck. I used this board (https://stm32-base.org/boards/STM32F407VGT6-STM32F4XX-M.html) and I had to copy some .h files manually, but compile still failed with kinds of errors. Can you give me more advice for me?

[kernelcrash]

Can you paste in some details ; the distro you used (including version), whether you used a built in gcc-arm-none-eabi, or the developer.arm.com compiler chain (and which version), and then paste in what you see when you type 'make'.

[kernelcrash]

Not sure if this helps, but if you are familiar with docker then you can do the compile inside a docker container. As an example I did this on a linux system (if you are on Mac or Windows, I imagine the hardest part is putting the zip file from ST in the right place). I've left out most of the screen output except for what I see when I run make at the end.

mkdir work
cd work
# Get the en.stsw-stm32068.zip file into the the current directory (ie. the work directory that is just created)
docker run -v .:/work -it debian:bullseye-slim

apt update
apt install -y gcc-arm-none-eabi git unzip make
cd /work
git clone https://github.com/kernelcrash/msx-rom-and-floppy-emulator.git
unzip en.stsw-stm32068.zip
cd msx-rom-and-floppy-emulator
make
## The make output should look like the following


arm-none-eabi-gcc -g -O2 -Wall -Tstm32_flash.ld -ffunction-sections -fdata-sections -fomit-frame-pointer  -DUSE_STDPERIPH_DRIVER -mlittle-endian -mthumb -mcpu=cortex-m4  -mfloat-abi=hard -mfpu=fpv4-sp-d16 -I. --specs=nosys.specs -ffixed-s0 -ffixed-s1 -ffixed-s2 -ffixed-s3 -ffixed-s4 -ffixed-s5 -ffixed-s6 -ffixed-s7 -ffixed-s8 -ffixed-s9 -ffixed-s10 -ffixed-s11 -ffixed-s12 -ffixed-s13 -ffixed-s14 -ffixed-s15 -ffixed-s16 -ffixed-s17 -ffixed-s18 -ffixed-s19 -ffixed-s20 -ffixed-s21 -ffixed-s22 -ffixed-s23 -ffixed-s24 -ffixed-s25 -ffixed-s26 -ffixed-s27 -ffixed-s28 -ffixed-s29 -ffixed-s30 -ffixed-s31 -ffixed-r10 -I../STM32F4-Discovery_FW_V1.1.0/Utilities/STM32F4-Discovery -I../STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include  -I../STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include -I../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc main.c system_stm32f4xx.c util.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_exti.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_gpio.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_rcc.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_pwr.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_syscfg.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_tim.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/misc.c diskio.c ff.c ffunicode.c stm32f4_discovery.c stm32f4_discovery_sdio_sd.c misc_handlers.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_sdio.c ../STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/src/stm32f4xx_dma.c startup_stm32f4xx.s interrupt.S -o msx-rom-and-floppy-emulator.elf 
arm-none-eabi-objcopy -O ihex msx-rom-and-floppy-emulator.elf msx-rom-and-floppy-emulator.hex
arm-none-eabi-objcopy -O binary msx-rom-and-floppy-emulator.elf msx-rom-and-floppy-emulator.bin

You can then exit the running docker container. The hex file that you want to flash (or bin file if you the flashing tool requires a .bin, not a .hex) will be in the msx-rom-and-floppy-emulator directory.

[windship]

It's too long so I captured whole log into a text file. Please check attached.
error_log.txt

[kernelcrash]

Thanks for sending that. Are you sure you downloaded the right en.stsw-stm32068.zip file from ST?. The one I have is 33042767 bytes long. MD5 is

6063f18dff8b5f1ddfafa77d1ab72ad9  en.stsw-stm32068.zip

With reference to the first error from your error_log.txt, error: unknown type name 'GPIO_InitTypeDef'; did you mean 'GPIO_TypeDef'? , if I look at the file on my computer under the path STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc/stm32f4xx_gpio.h, it has the definition for GPIO_InitTypeDef in that file. It's around line 133 in the file I have. If you don't see that then again it doesn't sound like you have the right en.stsw-stm32068.zip file from ST. I just checked now. On the ST site, you can actually just search for en.stsw-stm32068.zip and that will take you to the correct page. The MD5 matches on the copy of en.stsw-stm32068.zip that I already had.

[kernelcrash]

I am just wondering if your directory structure of where you extracted the zip file is a bit incorrect. The Makefile will look for the STM32F4-Discovery_FW_V1.1.0 directory in the level above where the msx-rom-and-floppy-emulator directory is. Here's some ls commands to add some context

$ ls -ld STM32F4-Discovery_FW_V1.1.0/ msx-rom-and-floppy-emulator/
drwxrwxr-x. 4 kernel kernel 4096 Aug  5 10:28 msx-rom-and-floppy-emulator/
drwxrwxr-x. 6 kernel kernel 4096 Oct 28  2011 STM32F4-Discovery_FW_V1.1.0/

# next commands abbreviated, 
ls -l STM32F4-Discovery_FW_V1.1.0/ msx-rom-and-floppy-emulator/
msx-rom-and-floppy-emulator/:
total 4268
-rw-r--r--. 1 kernel kernel    5030 Aug  4 23:37 defines.h
-rwxrwxr-x. 1 kernel kernel     134 Jun  8  2020 disassemble.sh
-rw-rw-r--. 1 kernel kernel    5515 Jun  8  2020 diskio.c
-rw-rw-r--. 1 kernel kernel    2438 Jun  8  2020 diskio.h
-rw-rw-r--. 1 kernel kernel  233247 Jun  8  2020 ff.c
...

STM32F4-Discovery_FW_V1.1.0/:
total 184
drwxrwxr-x. 2 kernel kernel   4096 Oct 28  2011  _htmresc
drwxrwxr-x. 7 kernel kernel   4096 Oct 28  2011  Libraries
-r--r--r--. 1 kernel kernel 130916 Oct 28  2011 'MCD-ST Liberty SW License Agreement 20Jul2011 v0.1.pdf'
drwxrwxr-x. 7 kernel kernel   4096 Oct 28  2011  Project
-rw-rw-r--. 1 kernel kernel  38208 Oct 28  2011  Release_Notes.html
drwxrwxr-x. 4 kernel kernel   4096 Oct 28  2011  Utilities

[windship]

I succeeded to compile, flash and run on my actual MSX2 machine. Thank you for your kind advices!
By the way, I can't change the page of rom list. I think it's because of keyboard type differences. I can see only first and last page of rom list. Can you check it please? My MSX is Korean model and you can check keyboard schematics here (It's Russian page but I think you can use Google Chrome translation or something) : http://www.caro.su/msx/kbd4msx.htm

[windship]

I think it will be perfect if we can change rom list page with LEFT/RIGHT cursor keys, instead of number key for each page.

[kernelcrash]

Cool. I'll have a look at that Russian keyboard page when I get some time. Meanwhile, I've just created a menu.rom that can use the number keys or the left/right keys to select pages. I'll attach it here. Can you try it and tell me if the cursor keys work. One other thing to mention is that the file listing is quite primitive, and if you have over 120 or so files in the msx directory it probably won't work properly.
menu.zip

[windship]

I tried your new menu.rom but it seems not working properly. I can see first page of rom list at the beginning, but the list disappear after pressing any key including letters(so I can't load any roms). Please check the attached video.

IMG_3618.mov

[kernelcrash]

Thanks for posting the video. Interesting. I think I made the classic mistake of 'fixing one other thing which didn't quite work' in that last menu.rom. I'd added some code to do with 'clearing the screen' not working all the time. I've undone that. I've attached a new menu.rom that has some extra debug stuff in it. Firstly, if its an unknown keycode that is pressed (well, unknown from the perspective of my code), it will print a decimal keycode number down near were it says "(? - HELP)". If my code does understand the key pressed you won't see a number. The number is only on the screen for a second or two, before the screen generally clears. I've also made it so that the Z and X keys can act as the left and right cursor keys (this is more to help us debug it). I am guessing that the keycodes for left and right arrow must be quite different on your machine. So try the menu.rom and see what number appears next to the "(? - HELP)". I can try adding those numbers in then (there is a slim possibility that you get no number and the left/right keys actually work. Like I said, I introduced a bug in that last menu.rom)
menu.zip

[windship]

I tried it and it still seems working strange. Rom list still disappear after any of key press, and wierd string shown. This string seems not change by any key(cursors, numbers, letters, ?). Please check attached video. I think this is related with Korean keyboard type or keycode, or something.

IMG_3627.mov

[windship]

How about to use kbhit() or getch() for keyboard input instead of getchar()?

[kernelcrash]

Thanks for the extra info. This is quite an interesting problem. So I'm using getchar() because that's one of the few BIOS calls I have using the SDCC setup I am using. It is just the 0x009f MSX BIOS function. So I was able to get MAME going emulating your CPC 400, and sure enough when I call getchar() I don't get anything useful back. It is obviously waiting for a key to be pressed but the value returned for any key seems the same. I've tried a few different ways to read a key and so far I am not having a lot of success. I'd prefer to leave it as some sort of BIOS call so I don't have to worry about different keyboard maps.

While I scratch my head, I've done a build (attached) that does not use the keyboard getchar() at all and just uses the gtstck() and gttrig() BIOS functions for reading the joysticks OR cursor keys and space. So it only looks at the cursor keys and space. It is super primitive. There is no highlighted cursor. All you see is a letter down the bottom right. It will say 'a' initially. If you cursor down then it goes 'b' then 'c' and so on. Cursor up will go in the reverse direction. When you've got the letter you want you can press space to select that game and the machine should reboot. Left and Right Cursor keys will go to page 2 and 3 and so on.

Selecting using the cursor is not a long term solution. I'll keep looking in to why the keyboard doesn't want to work.

I'll just note too that using the menu.rom is optional. If you leave it off the SD card, the the rom/fdc emulator board will just boot off the first ROM/DSK you copied in to the msx directory. And then you can you use the NEXT and PREV keys to go back and forth 'blindly' through the list. It helps if the board is powered seperately via its USB port. That way you can turn off your MSX computer, hit the NEXT button on the board, then power the MSX computer back on again and it should run the next rom in the msx directory.
menu.zip

[windship]

Hi, thank you for repeated modification. I tried new menu.rom and the control is successful with cursor keys. I could select and road roms.
However, I found another problem about loading a DSK file. Stored NMS8250 disk rom in SD card root, and tried to boot, but the system failed to load DSK file, and halted. My MSX have a floppy emulator (GOTEK) drive and system seems to try reading from it, not from the cart you designed. After that, I found the access led is blinking on my expansion 6-slots. I think this is related with SLTSL or something.
Now I started to feel quite sorry because I asked you to check the problem too much. I think it will be better if you dig it when you have more free time. Thank you very much for your kind answer and react.

IMG_3630.mov

IMG_3631.mov

[kernelcrash]

Yeah, I noticed you had the gotek. I'm not surprised it doesn't work. Effectively you'll have two disk ROMs loaded when you select a disk based game from the menu. I am guessing that MSX has some way of giving one disk ROM more priority than the other. In your case, it's probably given your internal disk ROM priority and hence it then goes and talks to the gotek through the internal floppy disk controller. I don't have an MSX machine with a real floppy drive, so I'm not much help. That might be 'too hard' for now. If you can find any references for how two disk ROMs are meant to work, then I can take a look.

But I've also been trying to figure out all the keyboard problems still. It is super weird, but I think I understand it. In your machine I think it must modify some other registers when the BIOS chput and chget routines are called. The C library stuff I was using has some push/pop wrappers around these BIOS functions, but I'm thinking it doesn't push enough registers and so we get really strange behaviour.

So I've ended up rewriting the entire menu in Z80 assembler, so I can easily then play around with the push/pop of registers. I have tested what I can in the MAME emulator for your machine. It looks a lot better. If you can try it, that would be good. It is keyboard only (number keys and the left and right arrow keys should work I think). When you type a letter like 'a', it should briefly show up in the lower right corner before the machine reboots. Also try the help screen. That should work. I made it so that it is either '?' or '/'.

I have the changes in an experimental-kr git branch at the moment.

I'll attach the menu.rom below

menu.zip

[windship]

Thank you for modifying of menu again! I tried it and worked perfectly. Great work!

And I found disk rom solution also - If I keep pressing CTRL key during the system booting, the internal FDD(Gotek for my system) is ignored so I can use disk.rom in SD root of our cart. I can use that CTRL key technique when any booting, including first cold boot/auto reboot after rom select/hard reset/ETC. I think you can add this in your description ^^

Additionally, I'm considering to install a small OLED screen using I2C connection on the cart, to show current rom/dsk filename. Can you give me some advice about it?

IMG_3632.mov

[kernelcrash]

Cool! I'll update the main master branch with the kcmfs menu.rom changes over the weekend (I think I will switch to this assembly version ... as it's almost easier to debug). And thanks for the tip about using CTRL. I'll try to update the README with that.

I have one of those ssd 1306 OLED screen things .. but I've never played with it. I'll try to have a look myself over the weekend to see how hard it would be to put the filename on the screen. At this sort of level of stm32 stuff, you need to add in a lot of I2C initialisation and access functions to make it all work, before adding in any of the ssd 1306 stuff (like font loading etc). In the current master branch there are basically two places in the main.c where it is calculating the filename to load from the SD card (one for when you select a file using the menu.rom, and the other for if you use the next/prev buttons). Ultimately, you would grab the filename at these points and send it to the oled screen.

I am actually about to change some of this filename stuff. I've been working on another branch 'multi-drive-support' that adds in B: drive support, and it also allows you to create subdirectories that contain a set of dsk images (eg. You might create an msx/aleste-2 directory and then put the four disks in that subdirectory. In the kcmfs menu.rom it will show as one line. When you select it it will automatically load the disk image with 'Disk 1' in the name. If you press next it loads 'Disk 2' and so on). You can try that 'multi-drive-support' branch if you like. I am just trying to test it as much as I can at the moment. There's more information in the README.md in that branch.

[kernelcrash]

I've updated the master and multi-drive-support branch with the new Z80 asm kcmfs. I've also pushed a branch called oled-ssd1306-example. It does seem to work. But it's probably something I would just leave as an experimental branch for people who want to play with it. There is more detail in the README.md in that branch. The last thing I want to do is support all the different OLED displays out there. There seems to be some magic sequence hex numbers to send to them to initialise them ... and it can vary a bit (ie I had to go searching to find out how to get my particular ssd 1306 to work as it initially didn't work). Anyway, have a play.

[windship]

Thank you for your try even it's weekend!
OLED support! It's really happy to me. I tried it and succeed. Actually I want to use 128x32 screen not 128x64, so I had to fix some register value but I did it anyway. I'm trying to pack whole thing into a cartridge shell on my MSX machine. I think you can imagine what I want to do if you check my photo :)
Folder disk set is another awesome update. It works well indeed. But from the inside folder, when I continue to change the image by pressing NEXT button, the selection is going out of the folder. But if I press PREV button, I can't back into the folder again. I think this is quite uncomfortable and will be better to fix it.
2 drive feature is great I think, but as you said, most of MSX games not supported 2 drive, so I could not have a chance to test it. Thank you anyway!

IMG_3658.mov

[kernelcrash]

Cool. Thanks for the pictures and video. I've made a few updates. I must admit I knew the PREV button would be hard now that I have subdirectories. I've made a few changes to the oled-ssd1306-example branch which I think addresses most of the issues, but I've done minimal testing, so have a go at it. Going forwards with the NEXT button is relatively easy to code, but it get's quite complicated when you are trying to go backwards with the PREV button. In some ways the single-drive version of the code with no subdirectories makes things a lot simpler. I'm always trying to 'keep things simple' as 'testing' ends up being the big time consumer with projects like these.

[windship]

How about to use this kind of thumbwheel switch(https://uge-one.com/ts003-smd-thumbwheel-toggle-slide-dial-switch.html)? User can move PREV/NEXT with wheel, and go into a folder/execute a file with center click. Inside a every folder, such a 'BACK' or 'EXIT' menu item needed for go out. This is quite common way to do user operations in most of similar devices like as GOTEK or GBS-C.

[msxlegend]

Yeah, you need to compile first. I've updated the main README.md with some notes, and also for the menu-ing program kcmfs I've updated README-kcmfs.md. It has some additional notes as it's a Z80 program and requires sdcc and hex2bin in order to build.

stm32 boards have several ways to flash them. I've included one of the easier ways in the README.md. That transfer.sh script is a one liner that uses dfu-util to flash the board over USB.

I'll note that I hadn't looked at this project for a few years (if you look at my blog or other repos you'll see I've sort of done this whole ROM/FDC thing to a few systems now. They are all variations of the same code), but a reader recently reached out to me about it. He's had a lot of success with the ROM emulation , but some issues with the FDC side of things that we are still working through. I'm not quite sure what the issue is. These things are hard to troubleshoot remotely ;-) MSX as a standard is perhaps not as standard as I'd like it to be. It works fine on my Omega MSX2 thing. And it actually works on my MSX on a Breadboard as well ... but I haven't actually tried it myself on a proper (back in the day) MSX machine.

Anyway, good luck.

Hello. First, good job with the MSX ROM EMULATOR. I'm confused. I haven't Linux, and there is no way with windows. Can somebody send to me the compiled file? thank you so much for your help. I have already build the pcb and my sd card is completed. I hope you will help me. Regards. (to msxlegend@gmail.com)

[kernelcrash]

It helps me enormously (in terms of troubleshooting) if people can go to the effort of compiling the firmware. It is not that hard. I've added notes similar to what is noted higher up in a new README-compiling.md file. The easiest way is to just use docker to compile the firmware (and that should work in Linux, Mac and Windows) and there are specific notes in that new README file about that.

[msxlegend]

Hi, It works fine, thank you.
@windship , what is the reference of the screen board? it s amazing :)

[windship]

Hi, It works fine, thank you. @windship , what is the reference of the screen board? it s amazing :)

Hello,
You mean my screen output solution? I'm using GBS-Control DIY board and DIY RGB cable.
https://github.com/ramapcsx2/gbs-control