Page 3 of 3

Re: Flash ROM idea - sanity check

Posted: Wed Dec 24, 2025 5:42 pm
by GARTHWILSON
cjs wrote:
Do you have any references for where I could learn more about this?
I have a lot of good links about it at the end of the AC performance page of the 6502 primer, at http://wilsonminesco.com/6502primer/construction.html .  There are some excellent videos there.

Re: Flash ROM idea - sanity check

Posted: Wed Dec 24, 2025 7:44 pm
by BigDumbDinosaur
cjs wrote:
Do you have any references for where I could learn more about this?
There is this sticky topic that is a collection of wisdom nuggets on designing stable, high-speed units.

Garth also mentions it on his website:

Quote:
#3: An actual custom PC board is best, preferably a multilayer with a ground plane. (And no, pours & fills don't qualify—they're pretty worthless for this kind of work, unless they supplement real planes and are done correctly. If they're not done correctly, they can actually make things worse).
In DC and audio work, filled planes (“pours”) are usually harmless and, in fact, I use them as ground paths in devices that are DC-only and are fabricated on two-layer PCBs.  As filled planes add unpredictable amounts of parasitic capacitance, they are best avoided in high-speed digital work, “high-speed” in this case referring to the very rapid voltage transitions that occur as logic outputs change state.

In my POC units, the only places in which I have filled planes are around external connections.  The purpose of doing so is to try to keep a lid on RF radiation.  See attached for an example.

POC V1.2 PCB Illustration
POC V1.2 PCB Illustration

The above unit is POC V1.2, which is stable at 20 MHz.

Re: Flash ROM idea - sanity check

Posted: Sat Feb 07, 2026 4:08 pm
by Michael
Your design looks very nice. Thank you for sharing.

May I ask what IDE you're using for the '4809 code, please? If MPLABX, which version? The code is very interesting but swapping banks in and out of the $C000..$FFFF ROM address space for Flash write operations seems like a PITA.

Have you considered using the '4809 as a selectable 1, 2, 4, or 8 MHz CPU clock source? You'd basically turn off the clock output and set it low after enableFlashControl(). Memory read and write operations would involve setting the CPU address lines, setting the Flash F16-F14 address lines, setting the RWB line, then manually toggling the clock line high and low. Set the clock output back to 1, 2, 4, or 8 MHz before switching back to 6502 "run" mode. Perhaps connect an SMD or HC49S crystal or a can oscillator to the '4809 instead of using the '4809 internal oscillator.

Have fun... Cheerful regards.

Re: Flash ROM idea - sanity check

Posted: Sun Feb 08, 2026 8:30 am
by speculatrix
Michael wrote:

May I ask what IDE you're using for the '4809 code, please? If MPLABX, which version? The code is very interesting but swapping banks in and out of the $C000..$FFFF ROM address space for Flash write operations seems like a PITA
I use VS Code for coding and avrdude to flash the MCU. Changing addresses for Flash write (and, for that matter, read) operations is simply a matter of setting three address lines, so simplicity itself, especially at you don’t do it very often.

Re: Flash ROM idea - sanity check

Posted: Fri Feb 13, 2026 9:42 am
by Michael
I will look into VS code and the Microchip add-ons. Thank you.

I recently came across a 128K I2C EEPROM ($1.27 single quantity @ Mouser) that looks interesting. It might be a nice fit for a ROM Emulator type system where you Load and Run programs or test iterative code in RAM and save to the ROM 'image store' as needed. I believe you can read and write 6502 I/O devices using the uC "WDC Bus Enable Interface" method just as you can with the uC "Blind Interface" method.
SPEX 3.png
Just for fun... I wonder if a full-blown 8-MHz "6502 VIA Lab" could be squeezed onto an Arduino Uno 'shield' plugged into a $5 Uno R3 clone using the "Blind Interface" method?
6502 SBC Shield R1.png