Flash ROM idea - sanity check

[Michael]

speculatrix wrote:

Michael wrote:

a $2 Arduino Nano clone to form the essence of a custom ROM Emulator & Programmer on the SBC.

I did consider using an MCU as a ROM emulator, and it's something I might still explore just for fun. Your work provides many useful points of departure - thanks.

I used to really enjoy the articles on your blog. It's sad to see them behind a paywall now.

[speculatrix]

Michael wrote:

I used to really enjoy the articles on your blog. It's sad to see them behind a paywall now.

It’s how I pay for stuff like food.

[Michael]

speculatrix wrote:

Michael wrote:

I used to really enjoy the articles on your blog. It's sad to see them behind a paywall now.

It’s how I pay for stuff like food.

I understand and please accept my best wishes. I signed up on your site several years ago and enjoyed your articles and the effort and creativity that went into building the Zolatron project. I'd love to find a way to continue to cheer you on and follow your progress.

BTW, the "blind interface" method mentioned earlier could be used with other microcontrollers and CPU's like the Z80 and 6809, too. I used a PIC uC on a CDP1802 design (below) with a Pi Zero used as a video terminal and it works quite well. I'd like to try something like this for the 6502 (same form factor) but use the Pi Zero as both the Linux Host PC and Terminal via serial and as full-blown ROM Emulator using the minimal "blind interface" connection.

Cheerful regards.

[speculatrix]

In case anyone was at all curious, I got this idea to work.

I reworked the CPU board of my computer (it's a backplane design) replacing the EEPROM with an SST39SF010 flash chip and an ATmega4809 MCU. Now, when I want to update the ROM code, I simply push it from my dev machine over serial to the MCU which writes it to the flash and then resets the machine.

The dev machine has a Python script to do this which in turn can be included in build scripts. My Bash build script assembles the 6502 assembly code, writes a binary file & invokes the Python script, so everything is effectively done with one command. From typing that command to a reset machine running the new ROM code takes a little under 14.5 seconds and, more importantly, I don't need to be anywhere near the 6502 machine to do it. I can do everything remotely via SSH, which means a lot more time on the sofa.

I love it when a plan comes together.

[cjs]

speculatrix wrote:

The dev machine has a Python script to do this which in turn can be included in build scripts.

Excellent! I wish more developers would spend just a little bit of thought on making what they build usable as components in other systems.

(I have a similar build/test/load-to-device system for my development.)

[PaulaM]

FWIW, I recently got a couple of PicoROMs (one for my 6502 and one for my partner), works a treat and super quick to upload.
https://www.tindie.com/products/epromfo ... -emulator/

[BigDumbDinosaur]

PaulaM wrote:

FWIW, I recently got a couple of PicoROMs (one for my 6502 and one for my partner), works a treat and super quick to upload.
https://www.tindie.com/products/epromfo ... -emulator/

Interesting gadget.  Shame they don’t make a version that will fit a PLCC32 socket.

[barnacle]

Been a couple of interesting videos recently explaining some of the development: chap called Piers Rocks https://www.youtube.com/channel/UC4d_tO ... c9O3x-5Gew

Neil

[Michael]

speculatrix wrote:

In case anyone was at all curious, I got this idea to work.

I reworked the CPU board of my computer (it's a backplane design) replacing the EEPROM with an SST39SF010 flash chip and an ATmega4809 MCU. Now, when I want to update the ROM code, I simply push it from my dev machine over serial to the MCU which writes it to the flash and then resets the machine.

The dev machine has a Python script to do this which in turn can be included in build scripts. My Bash build script assembles the 6502 assembly code, writes a binary file & invokes the Python script, so everything is effectively done with one command. From typing that command to a reset machine running the new ROM code takes a little under 14.5 seconds and, more importantly, I don't need to be anywhere near the 6502 machine to do it. I can do everything remotely via SSH, which means a lot more time on the sofa.

I love it when a plan comes together.

Congrats' on getting it working. How did the new CPU board turn out (picture)?

Cheerful regards. Happy Holidays.

[speculatrix]

Well, I may have been a bit previous. It works for certain values of 'work'. I can upload a new ROM image fine. An the 6502 machine reboots and appears to run. But certain programs are now crashing.

Some short user programs run without issues. Others crash, and always at the same point. Yet the exact same ROM and user code runs fine on the copy of the machine with an EEPROM.

So that's my Xmas project.

Pic attached.

[BigDumbDinosaur]

speculatrix wrote:

So that's my Xmas project.

Pic attached.

Board looks nice.  I did POC V1.2 in red, like what you did, and as soon as I went to populate it, I regretted the color choice.  For some reason, the red glared under the magnifier light and I had trouble discerning pads from the background while soldering.  I was amazed when the thing worked on the first try, as I was sure I had made a mess of soldering it.

BTW, filled planes, aka “pours,” such as you have on your unit, are not a good idea.  They are not a substitute for the ground and power layers in a four-layer board.  About all filled planes will do is mess with signal quality due to the extra parasitic capacitance they add.  At 1 MHz, that is probably not an issue, but when the day comes to crank up the clock. it might be a different story.

A distinct advantage gained with a four-layer board is not having to allow space for running ground and power traces.  This means you can make a smaller and denser layout, which will perform better at elevated clock rates.  Also, the inner power and ground layers suppress crosstalk between the signal layers, which can significantly improve noise immunity.  The layers themselves tend to act as a large decoupling capacitor, further suppressing noise.

Something for you to consider with your next design.

[speculatrix]

Something for you to consider with your next design.quote]

Thanks for the info. It is, in fact, a 4-layer board. And the size is fixed because this is a backplane design. The boards all have mounting holes in the same places so I can use standoffs to provide rigidity. (Pix attached.) There are four holes but I use only one. The boards also rest on a bar in the chassis.

The problems I'm having are driving me nuts because there could be all kinds of sources, including firmware on the MCU, a bug in the board design or a bug in the overall computer design that has resulted in marginal timing issues that, for some reason, I've been getting away with until now.

I'm currently gathering data - scope captures, logic analyser - in the hope that something stands out. Once I've got things marshalled in a way that will let me ask sensible questions I'm likely to be back!

[Michael]

That CPU-2 board looks very nice. Looking forward to seeing the schematic. Gosh, that ATMega4809 is a monster. May I ask if the signal assignments in the following drawing are correct, please?

Happy Holidays...

[speculatrix]

Michael wrote:

Looking forward to seeing the schematic.

Be careful what you wish for.

Schematics attached. And yes, I've redone the decoding part to stop people yelling at me.

Also yes, the 4809 is indeed a beast. 20MHz by default, loads of GPIO, single pin programming (UPDI). It's available in 40-pin DIP, albeit at the cost of about 8 GPIOs. Because I knew I wanted to play with the QFP version on breadboard prototypes, I designed a breakout board that converts it to a 48-pin DIP.

[EDIT] I should probably have pointed out that there is an error in these schematics. In the flash ROM section, for the UPDI programming headers there's a resistor where a Schottky diode should have been. I had to fix this when the board arrived, as well as providing a pullup resistor on the UPDI line. You live and learn. Mostly.

[cjs]

BigDumbDinosaur wrote:

BTW, filled planes, aka “pours,” such as you have on your unit, are not a good idea.  They are not a substitute for the ground and power layers in a four-layer board.  About all filled planes will do is mess with signal quality due to the extra parasitic capacitance they add. 

Do you have any references for where I could learn more about this? I'm quite familiar with the fact that ground pours are very much not ground planes, but it hadn't occurred to me to think about the parasitic capacitance they might add. I was thinking of them more as a, "you might get lucky and get a better return path on some of the signal lines" kind of thing. (Whether that's worth the effort of doing the ground pours has always seemed to me an open question.)