16 bit wide ROMs (eg. Amiga Kickstart)

[going-digital]

It appears it might be possible to extend support to 16 bit wide ROMs (I'm thinking Amiga Kickstart). A 512Kbyte ROM does leave 8K SRAM left for workspace and stack which I think is viable.

Work in progress hardware: https://github.com/going-digital/A600ROM/tree/main/hardware that uses the RP2354B for the extra GPIO and built in flash. Address bus is on contiguous GPIOs, in order. Data bus is also contiguous GPIOs, although order shuffled. Routed as a 2 layer board to match a 27C400 footprint.

Firmware will be a bit bare bones due to restricted SRAM, but it's not like it needs to do much. And the PIOs and DMA look extensible to 16 bits.

[piersfinlayson]

Yes, I figured that a 40 pin ROMs doable up to 512KB images, leaving 2x4KB for stack. I'd probably use an RP2350B with external flash due to RP2350B vs 2354 availability. Complexity in handling BYTE mode dynamically, but prob doable with different PIOs triggered based on BYTE being selected or not. I'd probably also go for 4 layer to make routing more feasible, but likely doable given the additional space under the RP2350B. Decoupling caps a challenge unless requiring dual layer (top and bottom) assembly.

[going-digital]

Yup - I came to the same conclusions. I've got it routed in 2 layers - but it only just fits, and I did move decoupling to the rear. I wonder how often 8 bit mode is used in designs, considering that an 8 bit only device will always be cheaper than 8/16 bit due to lower packaging costs. Might not be worth the effort to support 8 bit at all.

Should be possible to shoehorn in a flash chip - it would probably need to go on the back though due to track density.

My project has the design all tracked out on 2 layers already and it's passing DRC compliant with JLC design rules (4/4 thou 1oz process). Only DRC violations come from the USB socket (pads/hole proximity) and 0402 (silkscreen/pad proximity) which may need fixing. If that saves you some time then feel free to modify/republish/use it any way you wish, no strings attached. Might save you some routing headaches!

Looking forward to seeing your design!

[piersfinlayson]

Depending on how you expecting PIOs to work with this design, there may be a problem. If the same PIO SM/block is reading the OE/CE line state and manipulating the data lines, that cannot be done - as to access OE/CE on pins 38/39 requires GPIO_BASE to be set to 16. But this is a PIO block setting, meaning you then can't access the data lines on GPIOs 0-15.

My writeup below explains how I think this can all work (and I think also adds proper /BYTE support).

[piersfinlayson]

(The flash chip would fit on the top side of that board just fine. It might be worth moving the voltage regulator to above the RP2350 (that's how I'd do it, as my VR is already up there), but even with it below the RP2350 I reckon the flash can be made to fit.)

The below writeup uses these pin references:

Whether BYTE mode is actually required I'm not sure, but I think it can be handled as follows:

Have two independent sets PIOs+DMAs:

• The 8-bit chain first checks if BYTE mode activated. If so, read a 19-bit address (starting at "first" - aka left most - address line, finishing with A-1 - see later). Add it to 0x2000 (well, the 13 left bits of 0x2000) like is done by the existing firmware. Pass onto DMA. DMA reads 8 bit address and passes onto 8 bit data output PIO, which writes to 8 data lines.

• The 16-bit chain first checks if BYTE mode deactivated. If so, read 18-bit address (starting at first address line) and also a null bit as the LSB. Add it to 13 left bits of 0x2000. Pass to DMA. DMA reads 16 bit address and passes onto 16 bit data output PIO, which writes to data lines. This might be done by reading in the address lines "right", then 13 bits of 0x2000 (with auto-push threshold set to 31 - so LSB is 0), or push 13 bits of 0x2000 left first then left push 18 address bits then left push a 0 bit with "in null, 1". The latter is an extra cycle, but may not matter - the DMAs need at least 1 wait cycle from the addr PIO anyway.

The CS PIO also needs to be /BYTE aware. Again, use two independent PIOs. CE/OE/BYTE need to be contiguous. One CS PIO is testing for 0b000 (BYTE mode active - 8 data lines set to outputs), the other is testing for 0b001 (16-bit mode, 16 data lines to outputs). This might require mov x, pins; jmp x != y with y preloaded to 0b001, which is how the One ROM PIO algorithm handles non-contiguous CS lines, like the 2332 with Fire 24 hw revs C/D. However, the 16-bit CS is ONLY doing the single jmp x!= y, so it's the same number of cycles as the 8-bit case, unlike when we have non-contiguous CS lines.

How does the address read PIO also access the BYTE pin, as its input pins would be set to the address lines, not the BYTE pin? Use JMP pin with pin set to the BYTE GPIO. From datasheet:

JMP PIN branches on the GPIO selected by EXECCTRL_JMP_PIN, a configuration field which selects one out of the maximum
of 32 GPIO inputs visible to a state machine, independently of the state machine’s other input mapping. The branch is
taken if the GPIO is high.

(Some more thinking may be required on whether we want to invert /BYTE in hardware, as we get jmp pin, but not jmp !pin - TBC, will depend on how the precise algorithm falls out.)

On pin assignments:

• Q0-15 need to be contiguous
• Q0-7 need to be connected to the first 8 data GPIOs (any order) - as need to be stored in "low" (even) bytes in RAM
• Q8-15 need to be connected to the second 8 data GPIOs - as need to be stored in "high" (odd) bytes in RAM
  • These MUST be laid out in the same order as Q0-7 so 8-bit mode works correctly, as 8-bit mode will be applying these "upper" bytes to the "lower" byte pins.
• Address lines must be contiguous in any order, apart from Q15/A-1
• Q15/A-1 needs to be allocated both as part of the data pins (anywhere in GPIOs 8-15), and ALSO as the LSB ("right hand side") of the address lines - so it can be used as the LSB in the BYTE active case.
• BYTE may need to be in pins 0-31, so it can be addressed using JMP_PIN (which may use absolute pin numbering, although it may be relative to GPIO_BASE, not sure)
• CE/OE/BYTE need to be contiguous

This leads to be a very similar layout to One ROM 28. Data lines, then CE/OE/BYTE, then address, then D15/A-1.

There are also some requirements over which PIO blocks can be used. We have 3 on the RP2350, with 4 SMs each. GPIO_BASE can be 0 or 16, and is a block-wide config.

Hence CS and data output PIOs must be in common block(s). Address PIOs must be in another block (with GPIO_BASE set to 16. This reinforces the need for Q15/A-1 to be duplicated - it simply can't be accessed by the PIO with GPIO_BASE set to 16 if it's only (say) pin 15.

Just like existing One ROMs, bytes are mangled to match the actual pin layouts. So are addresses. However, here, originally adjacent bytes are retained as adjacent even/odd pairs - so 8 and 16 bit modes work properly. (And, as above, both even/odd - low/high - bytes must be mangled in the same way.)

[piersfinlayson]

Ah, I just noticed VCC is pin 21 on this ROM, so the 5-3.3V voltage regulator does really need to be below the RP2350B.

[piersfinlayson]

Implemented as One ROM 40.