OneROM

[Muncie]

Made a vt version can confirm that tunerpro talks to it.

I just need a VT to plug it into to test or build a bench loom, I have enough parts to make a bench loom but a bit cooked for today. road tuned my VY today live its awesome.

[Muncie]

Close up unpowered so you can see how nice it fits.

Jumpers dont fit anymore but everything else does even the blue cap

[antus]

[Muncie]

@antus if you want to borrow it let me know? Im going to get a stock of FIRE 32 Oneroms for here in NZ theres no point fitting 27C010's anymore. The only car i can test this on is currently full of electrical gremlins.

[antus]

Thanks but I've already got some oneroms on my bench. Too many toys! Spending my time on pcm hammer development and my gemini at the moment. But thanks! viewtopic.php?p=139896#p139896

[Muncie]

spent most of today getting a OneROM Fire 32B working as a live emulator on a VT V6 PCM, using the original OneROM firmware rather than the earlier experimental emulator firmware.
Hardware is a VT V6 PCM running a 27C010 128K EPROM, with The1's $A5G Enhanced v1.1 calibration.
I’ll add some more detail separately about physically mounting the OneROM in the MEMCAL because that turned into a project of its own.
First step — get the PCM reliably booting
Before doing anything with emulation I made sure the PCM would boot normally from the OneROM.
Current working OneROM setup:
OneROM Fire 32B
Official firmware v0.7.1
ROM type: 27C010
One ROM USB system plugin
The1 VT_V6_AUTO_$A5G_Enhanced_v1.1.bin
With that setup the PCM boots normally and OSE identifies it as:
Found Enhanced Factory RT A5GE 1.1 VTV6 A PCM
Version: delcohacking.net
So the basic OneROM replacement for the factory EPROM is working.
TunerPro/Ostrich bridge
The next problem was getting TunerPro to treat the OneROM like normal emulation hardware.
Rather than modifying OneROM firmware, I wrote a small PC-side bridge that:
TunerPro
↓
Moates Ostrich II protocol
↓
Virtual COM pair
↓
Python bridge
↓
Official OneROM CLI
↓
Fire 32B
↓
VT PCM
I’m using an HHD virtual serial pair:
COM20 ↔ COM21
TunerPro sees COM20, while the bridge opens COM21.
The actual ALDL lead stays completely separate on COM6.
The bridge impersonates an Ostrich II v20.9, which TunerPro detects normally.
Ostrich memory mapping
One important discovery was the address mapping.
TunerPro/Ostrich gives us a 512K address space:
00000–7FFFF
The VT's 128K 27C010 image is placed at the top of that space:
Ostrich: 60000–7FFFF
OneROM: 00000–1FFFF
So for example:
Ostrich 653E6
maps to:
OneROM 053E6
Mock testing first
Before letting the bridge touch the real OneROM I ran the whole thing against a mock backend.
TunerPro successfully:
detected an Ostrich II v20.9
entered emulation mode
uploaded the complete 128K BIN
sent realtime single-byte edits
restored those edits again
A full TunerPro upload comes through in 4K blocks:
ZW phys=60000 size=1000 logical=00000
ZW phys=61000 size=1000 logical=01000
...
ZW phys=7F000 size=1000 logical=1F000
The bridge buffers all 32 blocks and only commits the complete 128K image once the entire upload has arrived.
That was deliberate so the running PCM never gets presented with a half-old/half-new ROM image.
Realtime write format
We also decoded TunerPro's realtime single-byte write.
For example:
57 01 53 E6 3C ...
becomes:
W
length = 1
address = 53E6
data = 3C
Once TunerPro has selected bank 06:
BR set -> 06
the bridge translates it as:
bank=06
addr=53E6
phys=653E6
logical=053E6
and writes logical address 0x53E6 in the live OneROM image.
One trap we found
Initially I tried making a realtime edit without doing TunerPro's full emulator upload first.
TunerPro selected:
BR set -> 01
and attempted:
phys=153E6
which is outside the VT 27C010 window.
The bridge safety check caught it and treated it as shadow-only, so the real OneROM was not touched.
Repeating the test in mock mode showed what was happening.
After using:
Upload Current Bin to Emulator
TunerPro uploads the 128K image into:
60000–7FFFF
and subsequent realtime edits correctly select:
BR set -> 06
So the required TunerPro sequence appears to be:
Initialize emulator
↓
Upload current BIN
↓
Realtime emulation edits
Testing against the real Fire32B
Once the mock path was proven I changed the bridge to use the actual OneROM CLI.
I’m using OneROM CLI v0.3.0.
It supports:
onerom peek --address ... --length ... --output ...
and:
onerom poke --address ... --input ...
I first added a read-only mode to the bridge.
On startup it successfully:
Checked OneROM
Read the complete live 128K image
Mapped 60000–7FFFF to 00000–1FFFF
Started the Ostrich interface
TunerPro then detected:
Hardware: Ostrich II v20.9
with the real Fire32B sitting behind the bridge.
No writes were permitted during that test.
Real full BIN upload
The final test today was enabling live writes and doing a genuine TunerPro emulator upload.
TunerPro sent the complete 128K image in the expected blocks:
ZW phys=60000 ...
...
ZW phys=7F000 ...
The bridge then issued:
onerom.exe poke --address 0x0 --input <128K temp file>
and reported:
Full 128K upload complete
Most importantly, the VT PCM remained alive afterward.
OSE immediately continued communicating with it and still identified it as the Enhanced $A5GE 1.1 PCM.
So at this point the following path is working for real:
TunerPro
→ Ostrich II emulation protocol
→ PC bridge
→ official OneROM CLI
→ Fire 32B
→ VT V6 PCM
including a complete 128K live emulator upload while the PCM is powered.
Where it is currently at
I stopped there for the day.
The next test is simply to do one known realtime scalar edit after the full upload and independently verify the byte using OneROM peek, then restore it.
We already proved that exact incremental-write path in mock mode, and we’ve also manually proven previously that the Fire32B can have individual live ROM bytes changed while the VT PCM continues running.
So there doesn’t appear to be much left between where it is now and normal TunerPro realtime calibration editing.
The nice part is that this is still using the official Fire32B firmware, rather than needing a special OneROM firmware build.
If this continues working reliably, the end result should basically be a modern replacement for the old VT/VY EPROM emulation hardware: fit the OneROM in place of the 27C010 and use TunerPro for live calibration changes.

[Muncie]

I used Chat GPT to help out with a summary there as i got absolutely balls deep and bloody determined to make it work.

The mounting of the onerom to the carrier for the PCM absolutely has to be soldered! Even on the bench bumping anything would crash it just after testing all pins with meter it was diagnostics hell.

After soldering its rock solid so just be prepared if you dont solder expect your car to die first bump you get.

I even dremmelled a slot to hold down as per normal but still access the usb c.

[jxx]

Down the rabbit hole.....

I find using narrow pins on the onerom and a dip socket makes a good connection, then it's still removable.
Worst case you can then drop an eprom back in if you no longer want to use the onerom in the memcal.

https://www.aliexpress.com/item/1005007 ... 1802S8gUz8

pins.jpg

[jxx]

A 32 pin wide dip socket shouldn't be hard to source.

2.54mm Double Row Straight Female 2-40P Pin Header Socket Connector
https://www.aliexpress.com/item/1005008 ... 1802S8gUz8

32_pin_board.jpg

Gerber and Drill files to get the board fabbed (I use jlcpcb)

FAB_32_Pin_Dip_Adapter.zip

I have been meaning to sit down with a vernier caliper and redesign this board to duplicate the dimensions of a VS/VT memcal and have edges routed in fab so the blue cover clips back on (or a 3D printed replica).
I also use this board with pins on both top and bottom as an adapter for memcals (VN-VT) to plug into an eprom burner, it's just a quick dirty universal adapter.

Cheats way:
The stock VS/VT memcal is 18 x 2, 36 pins in total, only 32 are used.
Pull the extra unused pins at the end out, this way when it solders in the extra plastic width lines up better in the VS/VT memcal socket so it can't be put in on the wrong pins.
You could get even more creative and order a longer length and file the ends so the memcal can't be put in backwards and match the original... but that sounds like way to much work.


This is similar to what i did with the VN-VR memcal boards i fabbed.

01.jpg

02.jpg

04.jpg

Most recent revision, had to make some changes to dimensions that i stuffed up, waiting on these to arrive to confirm they are right then i'll post the fab files (gerber, bom and position for the board and smd resistors, sockets and header will still need to be manually soldered on)
Positions to add limp resnet socket and knock board added to this one.

memcal.jpg

[Muncie]

Looks awesome! i bumbled my way through using Kicad and made up the interposer board so have those on way for the flash PCM. that has been working faultlessly since i put it in have tuned shit out of car live so can say that works.

The VT version is simpler to install but i struggled to get the fire 32B Working as easily ive got the work around but its clunky. Ive got a VT to test it in but with caveat it has a major electrical gremlin i have to fix first for owner before i can even start car with it

Ive got a few more Fire 32's on way to fit out a few more flash PCM's here in cars im currently tuning in NZ mainly to make my life far easier no slow coms is bliss!