OneROM

[jxx]

Gee thats a blast from the past, I recon I made that image 17 years ago

It's still a good reference point
About the only image i can find to point where to tap into lol


I tried to reverse engineer my picture from about that era, but the potato that took that photo just wasn't hi res enough.
How times have changed, from buying most of the components and pcb from jaycar and hacking a cable off a mouse to this onerom that gets made in china and shipped to your door.

max232.jpg

[Muncie]

Ive just bought 2 to play with, will try one in a Ecotec v6 flash PCM See how it goes.

[Muncie]

I've received two Fire 32 B2 boards. Official OneROM detects them correctly as fire-32-b RP2350 and supports 27C010. I've checked your onerom_emu_27C010_DIS image and can see it is compiled specifically for fire-32-a.

Current upstream OneROM lists both Fire 32A and Fire 32B2 as verified RP2350B/RP2354B 32-pin boards, with B2 mainly adding RGB. Would you be able to rebuild the 27C010 DIS/Ostrich firmware for the fire-32-b target?

I have a VX/VY $060A PCM with the original AT29C010 removed and pads cleaned, ready for bench testing.

Happy to test any experimental B2 build and report back with bench results.

Thanks
Dave

[jxx]

Here's the source code for the onerom system plugin, fair warning it's possibly a mess as I've just zipped the entire directory, I was planning on stripping and separating the 2 projects and this is all in one built layer on layer.
I cheat and use build.sh & build32.sh, all switches should be documented.
It's built on the onerom usb plugin, usb_ostrich and usb_uart are the main points of interest, pretty sure there were modifications to some of the original files as well (memory might be playing tricks on me though).

Code: Select all

one-rom/plugins/system/"usb_emu_Switchable_UART"

This is where I got to with the Fire 32A (The Fire 28 code should be functional and untouched but I can't promise anything)

usb_emu_Switchable_UART.zip

Some python scripts i used for debugging:

python.zip

[Muncie]

I can work with that, Just waiting on a new soldering setup then i'm into it! to be fair i'll be happy to just not have to flash over ALDL anything extra is a bonus.

Do you remember which OneROM upstream version/commit this directory was based on? My boards are fire-32-b RP2350 and I’m initially aiming for 27C010 + standard Ostrich/TunerPro with UART disabled.

Also, has anyone already tried building this system plugin against the Fire 32B target? From the code it looks like the ROM pin mapping comes from the OneROM firmware itself, so I’m hoping the main Fire32A-specific part is the optional UART GPIO setup.

Happy to test and feed back anything we get working on the B2 hardware.

Thanks
Muncie (Dave)

[jxx]

Well that was a mistake, just cloned the most recent upstream to make sure it all still worked.
At a quick glance, 0.7.0 is where changes were made, 0.6 was what i built this on, "sdrr" being moved/renamed to "firmware" is one problem.

Fairly sure Fire 32B was not released.

Lack of free time to put more effort into this project is the reason i've released the source code, the bones are there to expand and port for anyone to do.

[jxx]

Here are all the prebuilt system plugins from the old code.

Fire 28 are the plain .bin.
Base firmware, metadata and plugins for the 32A (_32.bin).
DT were the last experimental data trace attempts (_DT.bin).

These are baked into the flashtool and what all the options are.
I don't know if simply using one of the Fire 32A plugins with the standard 32B base firmware will work.

assets.zip

[Muncie]

Got it running on the Fire 32B.

Quick summary of what we did:

* Started with an official **OneROM v0.6.13 Fire 32B / RP2350 / 27C010** custom image.
* The 32B base firmware and your old 32A build both appear to be from the same **v0.6.13 / 2d96a8a** generation, which made this look promising.
* Left the **Fire32B base firmware, metadata and 27C010 ROM mapping completely untouched**.
* Replaced only the 64KB system-plugin region at **0x10000–0x1FFFF** with your:
`usb_emu_system_plugin_DISABLED_32.bin`
* Padded the remainder of the plugin slot with FF.
* Used the **UART-disabled / standard Ostrich** version initially, as I already use a separate ALDL interface for logging.

The resulting image boots normally on my Fire 32B.

OneROM Web reports:

* Firmware good / running
* v0.6.13
* RP2350
* `fire-32-b`
* 27C010 calibration still present and active

The RGB scrolling changed to a single red LED with your plugin installed, but otherwise the board is happy.

The really good bit: **TunerPro RT found it immediately and identified/initialised it as a Moates OSTRICH II.**

So it looks like your existing Ostrich system plugin can indeed run on the standard Fire32B base without needing the ROM pin mapping rewritten.

I’ve stopped there for now before getting too excited. Next tests will be USB-only first:

1. full 128K BIN upload
2. verify/readback
3. incremental table/scalar update

Then once those pass I’ll connect it to the VX/VY $060A PCM and test actual 27C010 emulation.

Massive thanks for releasing the source/plugins — looks like the bones were definitely there. I’ll keep feeding results back as we go.

Dave

[jxx]

That's a great start.
The big test is to write a bin with tunerpro (will probably take 2 writes as the image is large the first time and isn't skipping identical blocks, like the good old days of over burning an eprom to make sure it wrote)
Verify, power cycle and re-verify to confirm write persists thru power cycle.
Then dump/verify the image in an eprom programmer to make sure the rom image is served on the physical pins correctly.

I use a gq 4x, make sure your eprom burner doesn't output over 5v on pins for read/verify as some do and will kill the onerom

This is where the fire 32 a port tested my patience, there was a lot of debugging to get that working and it was 1 step at a time, i'd get it to write, it'd fail persist, i'd get persist working and it'd be serving a mangled image instead of converting it... i'd get the image serving but it'd only be part of it and looping...
This is why it's functional and writes multiple identical mangled images.
There is a lot more work to get this working and enabling bank switching for the 128K images instead of it just being functional.
Unless like me you're happy with 1 image that is quick and easy to edit and upload in a couple of seconds.

There is a small bit of code that makes the led blink if the usb emu plugin is corrupt, similar to what a stock onerom does if it can't boot, i've never seen it kick in and never manually forced it.
There is a checksum calculated on compile in my releases, if this failed on hardware it'd still function but would blink the LED, unless it was to corrupt to run.


Looking into updating the code to work with 0.7.0 onwards, it might be more complicated than I thought, functions of usb_rom.c are now handled by firmware api along with other path name changes at a glance.

[Muncie]

Pretty huge day on the Fire 32B side, so I think we are allowed to put their feet up for a bit.

Quick summary of where we got to today with the VX/VY $060A / 27C010 project:

. Started with an official **OneROM v0.6.13 Fire 32B / RP2350 / 27C010** image.
. Kept the **Fire32B base firmware, metadata and 27C010 ROM mapping untouched**.
. Replaced only the 64KB system-plugin region with jxx's:
`usb_emu_system_plugin_DISABLED_32.bin`
. Board booted happily as `fire-32-b`, firmware good/running, with the 27C010 calibration still recognised.
. Plugged it into TunerPro RT and it was immediately detected and initialised as a "Moates OSTRICH II"

For the 128KB image TunerPro needed **bank 8** selected. Once that was set:

. Pulled the complete 128KB calibration from the Fire into TunerPro.
. Compared that readback against the known-good $060A R28 BIN:
**131,072 / 131,072 bytes identical.**
. Made calibration changes in TunerPro and committed them normally from the table dialogs.
. Incremental Ostrich writes work — no need to save/re-upload the whole BIN for each change.
. Read the modified calibration back successfully.
. Restored the original R28 values.
. Completely power-cycled the Fire.
.Read it back again after power-up:
**byte-for-byte identical to the original R28 image.**

So we have now confirmed:

Fire32B + jxx Ostrich plugin

. TunerPro detection
. 128KB 27C010 logical read
. incremental live writes
. full write/readback
. persistence through complete power loss

We then started jxx's suggested physical-pin test with my XGecu T48.

Before connecting the OneROM I checked the T48's 27C010 READ voltages:

.VCC: ~5.11V
. VPP/A9/PGM/CE/OE all remained around 3.5V during read
. no 12/13V programming voltage appeared

The Fire doesn't have its DIP pins soldered on yet, so I tried sitting it on the supplied loose pin strips in the T48. That made reliable contact pretty difficult.

We got three physical dumps though, and they were very informative. Every corruption pattern could be reproduced exactly by specific address/data pins simply not making contact. By the third attempt there were no stuck data bits at all; the entire mismatch was explained by four open address contacts.

So there is currently "no unexplained mangling/corruption showing up from the Fire32B implementation". I stopped there rather than keep skewing the loose pin strips and risk damaging the board.

Once the soldering gear arrives we'll make a proper connection and repeat the T48 physical read for the definitive byte-for-byte test.

Meanwhile I'm also mapping the VX/VY flash PCM's U11 AT29C010 footprint back to the J4 header. Most of the ROM bus appears to be available there directly, so the eventual PCM installation may be a straight ribbon from J4 plus only a few fly leads from U11.

Next major milestone after the clean physical dump is:

Fire32B → VX/VY $060A PCM → bench boot → ALDL → actual live TunerPro test.

Considering this morning we didn't even know whether the old Fire32A Ostrich plugin would run on a Fire32B, I'm pretty bloody happy with where it ended up.

Massive thanks again to jxx for releasing the source/plugins, Antus for all the Holden groundwork, and everyone else who's contributed to OneROM and the PCM side of this over the years.

Dave