Skip to content

Latest commit

 

History

History
50 lines (46 loc) · 5.04 KB

0025-2020-06-04.md

File metadata and controls

50 lines (46 loc) · 5.04 KB

4 Jun 2020

For the sheer fun of it, but also better learning and better testing of JLC's services (inc. PCB assembly), this is what I think I need to do now with electronics:

  • Look back into the NES/STM32 project.
  • Design a smaller, better NES Dev board:
    • Matching size of other NES/Famicom adapter boards.
    • Have a template for plug-in boards that use the middle peg. Don't forget size of pin header socket/buffer. Can the template also have a breakaway region for escaping the cart shell (i.e. edge test slot), and mousebites for doing a possible drop-board pass-thru?
    • Pads for TXS0108EPWR chips, including a couple of spares that can be done with bodge wires. Use keying on such boards to prevent accidental insertion of a 3.3V-only plugin card (e.g. FPGA) into a 5V-only adapter.
    • On-board 3.3V LDO; saves having to put one on every plug-in card. What other things can be moved to the adapter board as a one-off instead of having to repeat on every plug-in?
      • Oscillator (50MHz? 20MHz? 16MHz? Or a dot-clock/USART multiple?) with a counter chip, tapped out for various lower speed options?
      • Power-on reset circuit.
      • NES reset detector circuit (e.g. when reading from $FFFC or whatever).
      • H/V mirror jumper
      • Extra pins on internal headers for more features inc. the 3V3 line, etc.
      • Maybe some extra debug pins, LEDs, or even 7-segs, latches, etc?
      • Placeholder for ESP-01, ESP-12E/F, NodeMCU, or bare ESP8266? That way, we don't have to populate it, but if we do it can be used universally. Only possible issue is whether the NES metal will shield it if it's on the NES Dev board.
      • USB? Good for power and programming of plug-in boards.
    • NOTE: Better to put header socket on the adapter, and header pins on the plug-in?
    • How important is the "swizzle"? Must it match the Famicom? Do we a separate swizzle board or even do it as a break-away-and-overlay adapter?
    • Consider possible CPLD/FPGA requirements.
  • Work out what's going on with AVRCICZZ mode select logic. Can it just be hard-coded, instead, to use a specific region? What about a pin to tie it to a specific region?
  • Design a plug-in board that uses the STM32:
    • Consider using STM32G431:
      • It's fast (170MHz?), has a lot of I/O, is relatively cheap, and has (probably) enough 5V-tolerant lines.
      • NOT available at JLCPCB?
      • Might need code to be redesigned: It's an ARM Cortex-M4F, probably with a different memory map and some different peripherals, too.
    • STM32F103 is available in lots of variants from JLCPCB for their assembly service.
      • This is also quite a familiar part; consider cloning the Blue Pill on my own plug-in board. What are the Blue Pill's schematics? Why does it have so many components??
      • NOTE: With our own design, we could try pushing it past 128MHz to see what happens. Blue Pill by default has an 8MHz crystal, which can be clocked up to 16 × 8MHz => 128MHz. If we had the adapter board with a tapped counter on 50MHz XO (configured as "HSE", i.e. High Speed External in STM32 language), we could shoot for:
        XO Counter STM32 PLL Core clock Notes
        50MHz ÷2 ×3 75MHz Safely close enough to rated 72MHz, but probably too slow
        50MHz ÷2 ×4 100MHz Safer than 128MHz, but is it too slow still?
        50MHz ÷4 ×9 ~112MHz Also safer than 128MHz; too slow?
        50MHz ÷2 ×5 125MHz About the same as 128MHz
        50MHz ÷4 ×11 ~137MHz I'd wager this will work. 128MHz + 7%
        50MHz ÷2 ×6 150MHz Great speed, if it works. 128MHz + 17%
        50MHz ÷4 ×13 ~162MHz Probably the fastest we could go. Might not work always. 128MHz + 27%
    • Instead of cloning the Blue Pill, using a discrete STM32F103 IC in my own design, maybe just design for an actual Blue Pill? It's ubiquitous, cheap, standardised, and verified to work. Not certain it will always have the same quality, though, or always be able to reach the 128MHz overclocking reliably.

Some suggested goals:

  • Design an STM32F103-based board that can take 48-pin STM32F103C* (~A$2.80), 64-pin STM32F103R* (~A$3.80), and 100-pin STM32F103V* (~A$4.40) parts all on the same board.
    • Test out the idea using "Where we're going we don't need dev boards" approach.
    • Design for JLC assembly.
    • Make sure the variable footprint doesn't conflict with JLC's assembly requirements.
    • Any other changes over a standard Blue Pill? Ext. clock source option, for one.
    • Think about USB.
  • Design new NES Dev board adapter with extra features. Again, design for assembly. Include edge connector and ENIG, this time.