My CFTBL has been in pieces since I stripped it down about 15 years about - it's my favourite. Never played Strange Science or Cosmos - I've never really played much from before early 90s.

No, you're right, doesn't seem like JLC do shared projects. pcbway keep offering to sponsor me, but I'm not looking for sponsorship, but it does seem like maybe I need to explore getting them to fab. OSHPark don't do assembly do they - just fab? I use them for very small PCBs, but TBH the Chinese tend to get me my PCBs faster!

I wonder if me doing a video on the JLC order process would be useful for people. It's pretty straightforward once you have all the correct files lined up and know which options to check. Although I think US shipping is pricier from JLC than to the UK.

I don't remember the UART/serial comms question! Did I respond to it?

So, I do have a "cunning plan" to do something similar to your suggestion to allow the ROM to be controlled via the host. In fact Jim Brain's WriteROM has already shown it's possible - essentially detecting a special "knock" read sequence on the ROM to put it into some special mode, and then allow the host to rewrite the contents of the ROM.

Instead, could use the same approach to communicate with the host via USB. That's a really cool idea.

My expectation is that something like this is probably only viable on Fire, as that has 2 cores - one for regular ROM serving, the second to detect read addresses and run a USB stack. In fact it might be difficult even to both detect read addresses and run USB stack on the spare core - but may be able to free up both cores with rom serving just on PIOs.

I'll wait for H2 and your offer is generous, I will PM you details shortly. Thank you!

This is a bit far afield from the original topic -- where to get hardware -- but if I get deep into the wishlist, could One ROM USB be programmed to either A) serve more than 16 images i.e. 24 or 32 images, perhaps by redefining what one of the lines on the existing board does and using a jumper there instead or B) be capable in a given configuration to have some images served as 2332 and others as 2316?

I'll provide a lot more detail later so we can build a config/firmware but essentially right now the existing Pincoder ROM set looks like this:

System 3-6 test ROMs, nineteen in total, with each being 2K and going into a 2316. (Most people program 2716 for these.)

System 7 test ROMs, nineteen in total, with each being 4K and going into a 2332. (Most people program 2532 for these, also there's a hardware hack to allow use of 2732 but it requires board modification.)

With the existing One ROM device, the plan was to likely do the System 7 first, and simply select the most important sixteen tests. Some of the tests are of very limited utility or overlap with on board diagnostics so are somewhat redundant.

I'd probably buy a second One ROM device for System 3 through 6 and just keep the two physically distinct and clearly marked.

Obviously there are limitations for the One ROM device, but if it was straightforward to mix and match 2316 output vs 2332 output, that in itself would be interesting -- as one could simply pick the most important eight tests, and have a device that would work on System 3 through 7 -- and of course going to 24 or 32 selectable ROMs would allow for a bigger test suite.

Figured I'd mention it, as it's an unusual use case. Perhaps not all that important, as multiple devices solve the problem quickly and easily.

One ROM Ice has supported 5 image select jumpers since rev F so theoretically that means 32 images. In reality One ROM currently uses 16KB per image, even for 2KB/4KB/8KB ROMs, due to the way it deals with the address lines, so the STM32's flash is the limit to the number of images.

32x16 = 512KB. It'll need a bit of experimentation on the pinball machines, but STM32F405RGT6/GD32F405RGT6 might be the best "STM32" to use, as they both have 1MB flash.

One thing that might be interesting is what kind of reset circuit/timer these machines have - One ROM Ice needs a minimum of around 1.5ms to startup (much more if you use the GD32 part) and Fire needs a minimum of around 15ms. This is way way faster than any retro machine I've tested but if the CPU is booted before One ROM boots, that is likely to cause a crash.

One ROM can store any combination of any ROM types - so yes it can store 2316 and 2332s simultaneously.

As you say, maybe it's better to have a system 3-6 rom and a system 7 anyway.

I laid out a Fire USB version today, but that only has 4 image select jumpers = 16 images (even though it has 2MB flash), due to GPIO limitations on the RP2350. Be a few weeks before I have the Fire USB in my hands.

@rramstad833 - did you PM me your contact details so I can send you a one rom? If so, I missed them - please resend!

FYI, H2s aren't with me yet, probably be another week or so.

Great minds, etc. I was going to PM you today, will do it momentarily.

Random question, because I'm lazy, I know I could figure it out from the documentation... when using X1/X2, do the multiple ROMs all fit within one slot i.e. on the Ice, it has sixteen slots... do you technically have forty eight, if you are using the X1/X2? i.e. the three ROMs share one 4K space?

Just curious.

Along those lines, in the Williams System 3 through 7 world, several ROMs are on the board, and they are treated by the CPU as being at different address spaces... it seems to me that as long as the socket has access to all the address lines OR the One ROM has hookup wire to the appropriate extra address lines, that if the image was created properly, it's likely that the single 16KB address space could be used for all of the game ROMs together. Similar in thought process to running chip select lines to the different chips, but perhaps less complicated to understand, and easier to implement... might allow for a single One ROM configuration that supports all the ROM sets for sixteen different games.

(Schematics are pretty straightforward, I think.)

Oh, the reset signal is supposed to be held for a second, so this is going to boot far far faster than the CPU does.

Strictly there are two uses for X1/X2 - you can use them to serve ROMs for multiple sockets, or you can use them for dynamic bank switching for one ROM (i.e. changing that ROM image on the fly while the system is running). I call the former "multi-ROM sets" and the latter "dynamic bank switching", but there's probably better terms waiting to be used.

You're asking about multi-ROM sets. All 2 or 3 ROMs do fit within one "slot", but on Ice the slots are either 16KB or 64Kb in size. 16KB if just serving a single ROM image, 64KB if using X1/X2 for either multi-ROM sets or dynamic bank switching. So, when using X1/X2, yes there are multiple slots, but there are fewer of them. I actually updated the capacities in /docs/MCU-SELECTION.md yesterday. I forgot what MCU I ordered with the H2 boards - F411RE I think. These have 512KB flash, of which 64KB is reserved for the firmware and ROM metadata, so you get 7 multi-ROM sets or 28 single ROM images.

The F405 can go up to 15 multi-ROM sets.

Fire/RP2350 has a larger flash (2MB) but always uses 64KB image sizes. So technically it can support 31 multi-ROM sets, but in reality even the latest hardware rev only has 4 image select jumpers so you can only access 16.

Good to hear on the reset line. Bear in mind that to switch to a different multi-ROM set or image using the regular image select jumpers, One ROM does need to be reset to load the new ROM/set into RAM. There's no reset line on the ROM socket, so generally this means a power off/on event after changing the jumpers.

It is probably possible to change the function of one of the jumpers to be a reset - so you close and open it to reset the One ROM - but that then reduces the number of image/set select jumpers available. Maybe OK on Ice given it has 5.

As to why I use 16KB or 64KB images given One ROM is serving 2/4/8KB ROMs, it comes down to software and hardware optimisations - essentially I'm loading and using 16-bit address/CS/X1/X2 GPIOs directly as an offset into RAM for lookup the ROM bytes. X1/2 are at the top of this space on Fire, so unused for regular images - hence there's actually 14-bits=16KB images. But when X1/X2 are being used that's 16-bit = 64KB image to lookup into. On Fire X1/X2 are lower down in the address space so always make up part of the offset = 64KB images.

Hope this makes sense - turned into quite a tome.

Have you come across Airfrog? It's a tiny wireless daughterboard which piggybacks on top of One ROM, and can control it - including rewriting the ROM its serving dynamically. So you could have your test suite on Airfrog, and have it constantly update the ROM code - i.e. load each new test.

Airfrog being wifi offers a web server for controlling it, and supports exposing different web UIs depending on what firmware is on the One ROM. I use it to drive a One ROM loaded with a special ROM reader firmware load, that causes One ROM to read another ROM, rather than serve ROM bytes itself.

You could also replace Airfrog with another daugherboard with a tiny OLED display and maybe a few buttons.

I had not seen Airfrog. Quite an interesting idea, and one that makes a whole lot of sense. Most people have phones or computers and why not use a lovely display on a phone instead of some cheesy small thing!

Again, I find myself limited in that I have no real experience with surface mount or having things assembled for me, so for me to try Airfrog, I'd have to find a source for one that was assembled, or instructions on how to buy one assembled.

Looks super cool, but in the short term, probably wisest for me if I try to get One ROM working with manual jumper settings to change between tests, and if I am able to get that sorted and working, then it would be logical to experiment with Airfrog.

Neat stuff!

Yeah, JLC not fabbing airfrog is a pain :-(. I've been doing surface mount for years and have struggled a bit with getting airfrog assembled.

There are vertical mount USB C connectors that might save some space. Also reduced-pin count that cope with subsets of USB C functionality such as power only and possibly USB 2 comms only.

Ice USB currently uses the STM32's ROM DFU mode, and USB from within the web browser to erase the STM32 and program an actual firmware binary to the chip. I may implement my own USB device on Ice to provide a "nicer" interface for the programmer to use under the covers, but I doubt I'll go the whole "emulate a FS" hog. I actually think the web interface approach is ideal here - long-term you'll just select the ROM images you want and "hey presto" it's programmed your ROM without you having worry about firmware files.

I've seen the vertical mount USB-C connectors, but I've avoided them here because often times you don't have a lot of clearance above the ROM (so may not even populate the image select jumpers). I've also seen pin-reduces USB-C (power on, obvs no good here), but the footprint is still larger than I have space for (between 10-20mm2 more surface area required). If JLC offer them as an option I might see whether they could be easily dropped in to replace a micro-USB on my Fire USB board.

Dropping the size (or number) of image select pins could provide space for USB-C, but I don't want USB-C enough to drop that 2.54mm/0.1" pin header pitch constraint! It makes the device so much easier to use (for example standard-size pin jumpers, standard dupont cables), and I think the right trade-off vs micro-USB/USB-C.