• Please review our updated Terms and Rules here

Software Defined Commodore ROMs

P

piers.rocks

New Member
Joined
Jul 16, 2024
Messages
4
I've just released a new open source replacement ROM solution which supports the PET, VIC-20, C64, IEEE/IEC disk drives and other retro systems - so might be useful for some on this forum.

https://piers.rocks/u/sdrr

Its aim is for a single hardware solution to be able to emulate multiple different ROM types and chip select behaviour. It supports emulating 2364, 2332 and 2316 ROMs, and the chip select behaviour (which was mask programmed, and differed between ROMs) is configurable. This replacement can store multiple different original ROM images, each with different ROM types and chip select behaviour, and will switch between those at boot time based on jumpers. It uses a $2 STM32 microcontroller with few components, and the PCB is the same form factor as the original ROM socket. It can be reprogrammed without removing it from the host system, using a $5 programmer.

I've posted an introductory video about it here, demoing it on the C64 and VIC-20:


I'm happy to answer any questions about it on this thread.
 
I found the video a bit slow going, though I bet it's good for people with less technical knowledge of all this stuff than I have. Watching at 1.5x helped. The only suggestion for a change I'd make to that is to demonstrate reprogramming the character ROM with a different character set to provide a more dramatic demonstration of reprogramming in situ (though I liked the speed change thing, which you should keep, and perhaps that's good enough).

Overall I am pretty damn impressed by this project. Not just the design itself, but its quite well documented. The one thing I might change is to provide an additional technical summary and theory of operation aimed at people already familiar with how old ROMs, modern microcontrollers, etc. work that would quickly bring out the essential technical details, but at a higher level than your deep technical details document. (If you're interested, I could help write that up.)

Another nice thing to have would be suggestions for an externally mounted switch that could be used to switch between the images so you don't have to open up the case to re-jumper to do that.

I actually have a use for this: it would be excellent for the 2364 expansion ROM socket in my NEC PC-8001. Looking at your list of supported MCUS I expect that a 100 MHz STM32F411 version would work fine (it's some really slow ROM IIRC, maybe 350 ns?) I'd rather just build the 166 MHz STM32F405 version so I don't need to worry about it. But that requires the unverified Rev E motherboard; do you have plans to test and verify this one soon?

Also, I'd imagine that one would also be able to use the assembly service of JLCPCB or similar (I don't know if OSH Park offers assembly services, but JLCPCB is much closer to me anyway). Have you looked into this at all?
 
Thanks @cjs for the input:
  • There's very few youtubers I don't put on 1.5x and wouldn't expect anything less :-)
  • Yes, I kinda wished I'd flashed a new char set, but think the screen corruption when erasing/reprogramming is a fairly good demo of hat's happening.
  • I'd certainly welcome any documentation input you'd give - although I think I have an idea what you have in mind. May knock something out today.
  • I've put together a HW design for a very small wifi/bluetooth daughterboard (ESP32-C3-MINI-1 based), which would also reprogramming the device without re-opening the case. That'll take some firmware work though - to get the SWD working on it. Certain an externally mounted switch could be added to the current design using the jumpers and/or a socket connected to the SWD pins.
  • I think the ROMs in the C64 are 2364-450ns (kernal/basic) and 2332A-350ns (char ROM). The F411 is very close to the edge as a char ROM - I found I had to clock it to at least 98MHz to avoid artifacts. So it's possible you'd need the F405, so definitely worth going for that just in case. I've seen that the F446 can go up to 180MHz, so I'm also adding support for that, but it'll take a few weeks to get hold of a few to test with.
  • The rev E is on its way from a couple of fab house - it'll likely be a few weeks before it arrives and I can test.
  • I tend to use seeedstudio for PCBA, but think they're all pretty similar. Not sure at this point what the cost for would for small runs. IME the cost very dramatically reduces with volume. I plan to investigate when I've got a stable hw design.
 
Oh, it would also be worth adding pointers to sources for proper "IC-style" pins to go into the socket on the host instead of the presumably machine-tool pins you're using to go into the socket on the host. Those won't even fit in the socket of my PC-8001, and even for sockets that do accept those larger pins, I worry about damage to the socket because the pins are so much larger than the legs of ICs.

Here are some examples of special pins for PCBs that have the dimensions of standard IC pins. Sorry that these pages are all in Japanese, but the pictures should make things clear, and perhaps from the part numbers you can find Western sources and English documentation.
(I recently purchased samples of all of the above so, assuming I can find them in the pile of crap on my workbench, I can probably answer further questions about them that require physical examination of them.)
 
piers.rocks said:
I've put together a HW design for a very small wifi/bluetooth daughterboard (ESP32-C3-MINI-1 based), which would also reprogramming the device without re-opening the case.
Click to expand...
I am totally good with just bringing wires out of the case for the programmer. In fact, I personal would prefer that because Bluetooth seems to bring a lot of extra configuration pain for no real gain, at least for me.

BTW, one of the members of my Tokyo Retrocomputing group works for ST, and he suggested this as "the cheapest and most compatible" programmer. (It's well under $20.)

piers.rocks said:
I've seen that the F446 can go up to 180MHz, so I'm also adding support for that, but it'll take a few weeks to get hold of a few to test with.
Click to expand...
Ok, I'm going to put a pin in this until you've done that. I'll follow this thread with anticipation. :-)
 
I got some special ROMulators made for work use - I was pretty insistent that the supplier used pins that would definitely not cause damage to our ROM IC sockets on our unobtanium CPU boards. They heeded my warning... They were recommended by @Hugo Holden I think.

Dave
 
If anybody finds a part orderable from the US for the good pins please post it.
 

Attachments

  • IC_pins.jpg
    IC_pins.jpg
    22.4 KB · Views: 6
Last edited:
Al Kossow said:
I uploaded a couple of mechanical drawings and this picture to http://bitsavers.org/components/akizukiDenshi
Click to expand...
Akizuki Denshi is just the shop selling these; according to the product page the manufacturer is 株式会社マルコ精密工業, or Maruko Precision Industries in English. (That's not anywhere on the datasheet; I have no idea why.)

That company, which seems to do mainly lead frames for electronics parts, doesn't seem to have a web site that I can find. I did notice that some of Maruko Precision's parts have been taken over by Act Japan, but I don't see those pins in any of the lists of parts that Act Japan is now providing.

I knew I'd seen something else before somewhere, and it was those flip-pins. I think I even have a few.
 
cjs said:
Ah, now I see what we're waiting on for the F446 version. Nice!
Click to expand...
Just verified the F446RCT6. They serve up a C64 char ROM just fine at 180MHz and I validated the clock speed by measuring STM32 MCO1 pin.

Of course they should serve the C64 char ROM just fine - it needs around 80MHz. So plenty of capacity for faster systems. - would seem like the F446 could serve ROMs for systems at least twice as fast.

The F446 is currently overclocked to 300MHz in my C64. This about the max it seems to be able to achieve stably, although I haven't done much testing. It feels about the same temperature as the F411 kernal ROM running at 100MHz next to it.

If I extrapolate from the C64 char ROM originally being a 350ns, this may mean that SDRR with an F446 overclocked to 300MHz can serve as a 100ns (or even sub 100ns) ROM - but the reality is it's likely to be more complicated than that.

I've also found that the GD32F405RGT6 (cheaper than the STM32F446RC/RET6) can be overclocked to around 300MHz as well.

The STM32F405s operate around 20% slower than the other chips for this application - or put another way, you need to clock them 15-20% faster than the others to get the same results. Bit weird this, but I _think_ it's because they are actually an older design than the F401/411/446, and have a worse AHB bus matrix. They are still decent but the GD32F405s seem to be the best buy:
- same price as STM32F405RGT6
- cheaper than STM342F446RC/RET6 and with more storage
- can be clocked at least as fast as the F446.

Hope that's helpful!
 
You must log in or register to reply here.
Back
Top