RISKY MSX Cart - Proof of concept.

[arkadiusz.makarenko]

I have ordered first batch of Rev1 boards.

• It moved Read and Write pins to the same port like Slot select. This way I can save one read in a slot select loop. GPIO reads/writes are fairly slow, so this way I can save another few ns.

• Electrically configure chip for DAC use, and connect to MSX. This is to progress SCC emulation

• Additional LEDs - this is to give feedback to user on which mapper is being run, flashing progress etc.

• Proper button - for cart flashing

• Preparing everything to allow programming chip using only serial. As WCH programmers are available, but not everyone has one. I just need to figure out if I can change Flash/ RAM memory allocation using serial.

• Move from CH32V307 to CH32V303. It is the same chip, but without networking, or USB HS, tiny changes on clock config and network. I can't think of any use of those features. Price is better as well, this one cost £20 delivered and taxed for 10 units.

Zrzut ekranu 2024-12-24 203354.png (165.81 KiB) Viewed 257 times

This is how I need to leave it for another 2 weeks.

[arkadiusz.makarenko]

I have migrated project to Moun River IDE 2... I know it is not great choice and I will need to eventually write proper makefile, but for now since I need debugger and few other tools It is still more convenient for me to use it.

I have started reading on SCC. There is a lot to learn. Chip emulation I see as relatively straightforward. It is just managing some registers. Some are truncating values etc. which shouldn't be difficult to replicate.
There are already implemented emulators in c. Most of code is about managing state of the chip registers.

My main challenges I can see now, are that during write cycle, I don't think I have enough time to do it. I can't guarantee or measure when it will be finished. I need to process it outside interrupt, so information about what has changed is lost at this point. I will need to rescanning data on each loop. Which is not an issue, I have plenty resources to do it, still making it as simple as possible is a challenge.

Another issue is a way to construct data for DAC and what rate transfer data to DAC. I can configure the chip to use DMA and timer, so CPU won't be involved. But I need to amend the buffer accordingly, at the right speed.

Something new to learn.

[terriblefire]

I have migrated project to Moun River IDE 2... I know it is not great choice and I will need to eventually write proper makefile, but for now since I need debugger and few other tools It is still more convenient for me to use it.

I have started reading on SCC. There is a lot to learn. Chip emulation I see as relatively straightforward. It is just managing some registers. Some are truncating values etc. which shouldn't be difficult to replicate.
There are already implemented emulators in c. Most of code is about managing state of the chip registers.

My main challenges I can see now, are that during write cycle, I don't think I have enough time to do it. I can't guarantee or measure when it will be finished. I need to process it outside interrupt, so information about what has changed is lost at this point. I will need to rescanning data on each loop. Which is not an issue, I have plenty resources to do it, still making it as simple as possible is a challenge.

Another issue is a way to construct data for DAC and what rate transfer data to DAC. I can configure the chip to use DMA and timer, so CPU won't be involved. But I need to amend the buffer accordingly, at the right speed.

Something new to learn.

I think you just write a "stuff has changed" flag during the interrupt cycle and then leave it until the cycle is over. Then build a mixed buffer of all the channels... its fine if it gets interrupted while this happens. The new mixed buffer should be double buffered so its only switched in once its built the next time the dma says it needs more data. I dont think a timer is the right approach? surely the DAC has a "fifo getting close to empty" type signal.

[arkadiusz.makarenko]

I think you just write a "stuff has changed" flag during the interrupt cycle and then leave it until the cycle is over. Then build a mixed buffer of all the channels... its fine if it gets interrupted while this happens. The new mixed buffer should be double buffered so its only switched in once its built the next time the dma says it needs more data. I dont think a timer is the right approach? surely the DAC has a "fifo getting close to empty" type signal.

Dirty Flag will be much easier to implement that checking what has changed by comparison. I won't need copy register values multiple times over.Dirty flags will just trigger recalculating each channel. It will look at each Channel frequency and volume. Then it will trigger recalculate / merging all channels to output buffer.

Those DACs are really dumb, those have couple of registers only Control Register and data hold registers. There are features to synchronize how often data from hold registers are copied to proper out register (read only), but this is how far as this goes. What you mentioned can be achieved by setting up DMA to peripheral feature. But for this I have to set up rate how often data is being fed to DAC data hold register. This rate can be controlled by timer, software or external line (EXTI interrupt). At least it is my current understanding of this piece of hardware. Never used it beyond generating few basic outputs (always controlled by CPU )
My understating is if I will create buffer of the size of original SCC wavetable (or expand it proportionally ) and will deliver it to DAC at the same (or proportional) rate then I will get similar effect. This way I hope frequency on SCC register should have the same outcome on my device. Volume should be easier to implement.

Action plan (1 Channel + 1 Frequency control)
- Set up DAC/DMA/TIM and buffer as example from the producer website.
- Set up SCC mapper to read and write values to temp memory location.
- Set up dirty flags to check what changes on SCC register writes (frequency/ volume / wavetable data).
- Implement flag handling methods.
- Set up MSX software to provide very simple setup for easier debug.
- listen to weird noise a lot

Arek

[arkadiusz.makarenko]

Thanks to @erique and his work for RISKYKVM makefile, I have adapted it to use in this project as well.
I will add docker and automated builds later on to both projects.

I am looking for solution on toolchain problem. I would prefer not to use WCH patched GCC, and move to official GCC release.
But this would have impact on a important feature which I use, fast interrupt. Which makes only one cycle to save/restore registers during interrupt.
There are published solutions, I just need to understand it fully before using it.

[arkadiusz.makarenko]

Today I managed to include and adapt this SCC emulation library.
https://github.com/digital-sound-antiques/emu2212

I have updated and included mapper code and I get first emulated SCC sounds out of it. I still need to adapt library and/or way to doing writes. Current code is too slow to be run inside interrupt, and I don't have mechanism yet to delegate this to main loop.

I am running out of resources on the chip. Currently with -Os (optimize for size) I have less than 1KB left. I may not be able to squeeze in all what I want.

[arkadiusz.makarenko]

I have removed Autodetect (which was rubbish anyway), and now I have just above 2KB. This is enough for now, but I need to look into trimming all not needed stuff from the core project. Like SystemInit, and some libs from startup sequence. Other elements that could be fixed, are FAT32 library, I would need to replace it with lightweight read only lib, but this is a lot of work, which I am trying to avoid for now.

[arkadiusz.makarenko]

I have received Rev 1 PCB, and updated project to use cheaper, but containing all the same relevant hardware.
I know it can work as a is for basic mapper cart with 256KB available, loaded from USB Fat32 stick. But I want more out of it. I want SCC emulation. To achieve this I need to do very serious optimizations to the code.
My current understanding of the optimization required is as follows:

• some operations take more time than other, I can shave substantial amount of time by critically reviewing GCC compiler output. So loading constants from flash is expensive, but I can have few CPU registers used as global registers and those would be used to hold all most important data items, which are used constantly. So there will be no need to reload them from memory/flash on each IRQ, and many other operations.

• I need to deeply rewrite address decoding, it should be able to boil down this to much fewer and less costly operations. I have plenty RAM available, so I can use it to my advantage.

• Reduce need for branches - hello branchless programming.

• On top of it I still have options for working with naked interrupts, which may give me more time at the beginning of the interrupt.

• Another possible path is overclocking the core, but I am not keen on this at this moment.

PXL_20250108_000542107.MP.jpg (115.29 KiB) Viewed 85 times

• I really need to learn RISC V assembly, now I can read it with references and cheat sheets, but I need to really learn it

[GadgetUK164]

Cool project!!! And nice progress =D

[arkadiusz.makarenko]

I had some progress with optimising bus handling routines.
Main ones are rewriting address decoding and changing mappers values. This is done branchless now. This doesn't give enough time to handle SCC directly, but it gives me time to handle circular buffer without risk of crashing MSX.
This if good enough for now. There is still a lot of optimisations which could be done, but this needs to get dropped to Assembly level. I am not sure if I want to do it. Maybe I will revisit it later.

I got some progress with SCC as well. I missed obvious thing that emulating library was returning int16, and dac needs uint16. Second was realising that 3.3v dac output us far too high. I will need to add voltage divider to this.