Page 2 of 4

Re: RISKY MSX Cart - Proof of concept.

Posted: 18 Dec 2024 11:54
by arkadiusz.makarenko
terriblefire wrote: 18 Dec 2024 08:41
arkadiusz.makarenko wrote: 17 Dec 2024 20:03 After reviewing this code, now I am 100% certain that I don't have enough processing power on this chip left to do this level of calculations. Maybe with some kind of additional WAIT states (?) , but impossible in normal write cycle

Saying this, I already started looking at STM32H745
It is £15 dual ARM core 480Mhz. This would manage, but it is far more complex, and would force me to learn new usb lib.
It has massive flash, massive amount of ram, and D/A Converters. I think I have Dev board with this chip, so I can do some tests before designing new PCB.
I dont think you need to do these calculations inside a bus cycle. Just be complete by the next or next plus 1 top of frame. Remember this is an audio device and our hearing would never tell the difference.
Oh, I have plenty time when cart slots is not selected... I am rescanning gpio address and slot select only... Maybe I could squeeze something in there, if chip would allow me to time it right?

Alternatively I could add second £1 chip just to do SCC stuff only? My BOM budget for this project is £5, and I still have £2 spare :D

Re: RISKY MSX Cart - Proof of concept.

Posted: 18 Dec 2024 13:23
by terriblefire
arkadiusz.makarenko wrote: 18 Dec 2024 11:54
terriblefire wrote: 18 Dec 2024 08:41

I dont think you need to do these calculations inside a bus cycle. Just be complete by the next or next plus 1 top of frame. Remember this is an audio device and our hearing would never tell the difference.
Oh, I have plenty time when cart slots is not selected... I am rescanning gpio address and slot select only... Maybe I could squeeze something in there, if chip would allow me to time it right?

Alternatively I could add second £1 chip just to do SCC stuff only? My BOM budget for this project is £5, and I still have £2 spare :D
If you move to an interrupt service routine when the rom is selected then you can update the SCC and other housekeeping in "normal" runtime. I honestly think you have way more capacity in there than you think you do :)

Re: RISKY MSX Cart - Proof of concept.

Posted: 18 Dec 2024 15:55
by arkadiusz.makarenko
I will try to rewrite this to interrupts, but from past experience with stm32s interrupts are generally painfully slow...
Those chips have 4 fast interrupt (direct no table irq), maybe those will be useful here

Re: RISKY MSX Cart - Proof of concept.

Posted: 18 Dec 2024 18:47
by arkadiusz.makarenko
Autodetect ROM mapper won't be 100% so I need to find additional alternative.
Additional file loaded on ROM upload might be an answer.

I am doing everything what I can to avoid writing msx software

Re: RISKY MSX Cart - Proof of concept.

Posted: 19 Dec 2024 08:18
by terriblefire
arkadiusz.makarenko wrote: 18 Dec 2024 18:47 Autodetect ROM mapper won't be 100% so I need to find additional alternative.
Additional file loaded on ROM upload might be an answer.

I am doing everything what I can to avoid writing msx software
mapper type in the file extension?

Re: RISKY MSX Cart - Proof of concept.

Posted: 19 Dec 2024 12:08
by arkadiusz.makarenko
terriblefire wrote: 19 Dec 2024 08:18
arkadiusz.makarenko wrote: 18 Dec 2024 18:47 Autodetect ROM mapper won't be 100% so I need to find additional alternative.
Additional file loaded on ROM upload might be an answer.

I am doing everything what I can to avoid writing msx software
mapper type in the file extension?
Either way I go I need to rewrite In Application Programming library, which means learning a little on weird Chinese FAT32 handling lib and Flash handing methods. Nothing crazy, but I need to spend few days on it to debug it.
I have hacked something, but I am struggling now to support it and introduce changes. Time to tidy up.

Re: RISKY MSX Cart - Proof of concept.

Posted: 20 Dec 2024 00:42
by arkadiusz.makarenko
So it will be based on the file extension

File to upload has to follow this convention:

file name : cart
extension :
"ROM" AUTODETECT1
"RO2" AUTODETECT2
"R32" ROM32k
"KON" KonamiWithoutSCC
"SCC" KonamiWithSCC
"A8k" ASCII8k
"A16" ASCII16k

This list most likely will expand as there are different flavour of not mapped carts. But those should be ok with autodetection, I just need to look into this. It is not priority at this point.

Re: RISKY MSX Cart - Proof of concept.

Posted: 21 Dec 2024 22:08
by arkadiusz.makarenko
I managed to reach another goal with this project.
Today I completed rewriting the firmware to support two way communication using interrupts.
This chip has two hardware features that allow me to keep up with MSX bus using interrupts. One is HPE hardware stacking feature, which allows to save all registers in shadow registers in only once cycle, and second one is VTF - direct interrupt no need to go through interrupt table. Both are essential to release enough resources to allow me to do other stuff, like hardware emulation.
This opens the door to stuff like SCC emulation or FDD or HDD interfaces etc.

Re: RISKY MSX Cart - Proof of concept.

Posted: 22 Dec 2024 22:09
by arkadiusz.makarenko
Small progress today, I managed to figure out how electrically configure DAC on this chip. I didn't have Reference voltages connected. Fortunately voltage reference pins are just next to power supply pins, so bridging them solved the issue.
I managed to create and play clear sin wave :)

Re: RISKY MSX Cart - Proof of concept.

Posted: 23 Dec 2024 11:03
by PhilC
Good bit of progress, can't wait to see what it can do when you've finished it :)