OneROM

[themr.m]

what tunerpro calls data tracing? I've also heard it called bubble tracing. Usually that's in tunerpro, but the XDF and the ADX together need to be set up for it (and each other), and you need to turn it on here.

I dig up info in moates web and found they explaining it.. maybe it on Tunerpro side.. because cobrartp motronix also not supported these address tracker function, until they add hardware support to Tunepro side.

https://shop.moates.net/pages/about-the ... -emulators

5.00.9290.00 (General Release) (02/25/21)

Added mousewheel support for zooming in 3D table graphs
Added data address vlidation to XDF editor. If the address of any cell in the X, Y, or Z axes of a table, or the address of any data contained in a scalar, flag, or patch falls outside the size of the bin specified in the XDF header, you'll see a warning when you apply changes to the table's XDF definition.
Added support for CobraRTP emulation hardware
Fixed crash when equation variables resolved to very large or very small values

[jxx]

https://github.com/mstrand/ostrich2
https://raw.githubusercontent.com/mstra ... /README.md

https://raw.githubusercontent.com/mstra ... _init__.py

Code: Select all

def version(self):
    self.write(b'VV')
    device_type = self.read_byte()   # byte 1
    version = self.read_byte()        # byte 2
    device_id = chr(self.read_byte()) # byte 3 - must be a character
    return (device_type, version, device_id)

The 3rd byte is device_id, not part of the version.
TunerPro combines them into "v20.9.O" for display.


Okay with a lot of further reading and research, it won't work with the onerom and the firmware as it is now.
I have not implemented anything to track where the ECU/PCM is accessing the data in the rom address space, this is just a simple rom emulator with a plugin to read/write the rom image.

[jxx]

Attempted to implement Data Tracing/Address Tracking, let me know if it works.
It might be pushing the limits.

It's on the edge of failing, especially with faster ecu access times.
The underlying SDRR (Software Defined Retro ROM) One Rom system only allocates so much ram for the system plugin, stacking the features like i'm doing has basically exceeding this allocation now and had to make compromises like cutting buffer sizes for the DT feature.

I think trying to make a fully featured compatible replacement would be moving outside the grey areas of the ostrich compatible protocol emulator, it's also starting to move outside the bounds of the cheap open source one rom project if i've pushed the limits to this point.

onerom-emu-flashtool_0.1.6-alpha-fix.zip

Code: Select all

Valid options with DT toggle:

All ALDL DT		27C256/27C512
DISABLED DT		27C256/27C512
NORMAL DT		27C256/27C512
HTS/OSTRICH_Z DT	27C256

EDIT:
****FOUND_BUG_REMOVED****onerom-emu-flashtool_0.1.6-alpha.zip
Uploaded new version

[themr.m]

Attempted to implement Data Tracing/Address Tracking, let me know if it works.
It might be pushing the limits.

EDIT:
****FOUND_BUG_REMOVED****onerom-emu-flashtool_0.1.6-alpha.zip
Uploaded new version

I just try 0.1.6 fix version, It still grey button for Address tracker, but good new the Bank selection now not locked. Bank 0 selection for 28pin operation. like mention in moates web.

https://shop.moates.net/pages/troubleshooting-ostrich

[jxx]

Ahh the bank selection i found was picky for some reason, sometimes it didn't show up the first time, but connect a 2nd time it was available.
I did chase that bug a while ago and never found the cause, was just as easy to hit connect a 2nd time.
But i thought that was only for 128K/27C010, wasn't needed on a 32K/64K bin....
The way i had it write just used address info in the datastream, no need to select a bank. Looks like i broke something if it's able to be selected now.

[themr.m]

Code: Select all

def version(self):
    self.write(b'VV')
    device_type = self.read_byte()   # byte 1   - "HEX BYTE = 14" @ "DEC = 20"
    version = self.read_byte()        # byte 2      - "HEX BYTE = 09" @ "DEC = 9"
    device_id = chr(self.read_byte()) # byte 3  - must be a character "HEX BYTE 4F" @ ASCii "O"
    return (device_type, version, device_id)

The 3rd byte is device_id, not part of the version.
TunerPro combines them into "v20.9.O" for display.

Ostrich 2.0 Command :
Description: Request version.
Command Send: 'V'+'V'
Receive: x+y+A (ex. 10+07+'O')

Notes:
x = is typically 10/20 for Ostrich, 5 for BURN1, and 2 for AutoProm.
Y = will vary with firmware revision.
A = will be an alphanumeric, and will be A for APU1, O for Ostrich, and B for BURN1 typically. Can vary with older firmware.


When you mention it, I realize Tunerpro RT only detect "Hardware : v20.9 " look like missing devices_id. But understand now. The Onerom fimware is fixed and no capability to change via command. Do device_id # byte 3 can be re-program? But wait, I tried send command VV to onerom with realterm, and got reply 14 09 4F which "20 9 O" so it not firmware problem.



EVO123BIN
https://www.mediafire.com/file/zvatlcfi ... L.bin/file

EVO123XDF
https://www.mediafire.com/file/03b7ys6t ... L.xdf/file

[jxx]

You have a .bin and XDF
Do you have the corresponding ADX file?
As mentioned above, pretty sure you need all 3 for data tracing.

https://www.tunerpro.net/WebHelp/source/datracing.htm
https://forum.tunerpro.net/viewtopic.php?t=2674

It would be responding with the correct version and id, i can't answer why it's only showing v20.9 instead of v20.9.O
I've seen both in tunerpro while i was making this and even using earler versions that i remeber not showing the O during testing now show it.... I just close my eyes and ignore that, essentially if it doesn't reply with the correct 3 byte response to VV it won't connect.

Even your pic above showing v0.1.5 flashtool is only showing v20.9 now instead of your earlier images with v20.9.O, i don't think it's an issue, just tunerpro playing funny games.

[themr.m]

You have a .bin and XDF
Do you have the corresponding ADX file?
As mentioned above, pretty sure you need all 3 for data tracing.

https://www.tunerpro.net/WebHelp/source/datracing.htm
https://forum.tunerpro.net/viewtopic.php?t=2674

It would be responding with the correct version and id, i can't answer why it's only showing v20.9 instead of v20.9.O
I've seen both in tunerpro while i was making this and even using earler versions that i remeber not showing the O during testing now show it.... I just close my eyes and ignore that, essentially if it doesn't reply with the correct 3 byte response to VV it won't connect.

Even your pic above showing v0.1.5 flashtool is only showing v20.9 now instead of your earlier images with v20.9.O, i don't think it's an issue, just tunerpro playing funny games.

Yeah you right, it wont work.. not cause software not recognize by hardware name. It more how software interact with onerom. Event successfully recognize with tunerpro rt and un-grey the Address tracking button, still it wont work since onerom firmware cannot respond to any change when Trace serial command is send right? Thank you for your great and excellent work, also share with us these OneROM-emu Flashtool.

Yes, since these bin and xdf is for evo1-2-3, it should support adx by kaxlon, can be download from TR website.. but never try it. I will try aldl cable and see if it work.

https://www.tunerpro.net/download/datas ... DX_v1a.zip

[jxx]

DT mode should respond to these commands

Code: Select all

Host sends:  'T' + x1 + x2 + x3 + y1 + y2 + sMMSB + sMSB + sLSB + eMMSB + eMSB + eLSB + CS
Device sends: 'O' + [addresses] + 'O'

Matching the moates v19 protocol.

Unfortunately i don't have a bench setup to attempt further testing these more advanced modes.
All the work i've done is based on what i've found online.
And the memory limitations aren't helping, I really don't want to strip out things that are making it stable and reliable which is about the only option.

[themr.m]

DT mode should respond to these commands

Code: Select all

Host sends:  'T' + x1 + x2 + x3 + y1 + y2 + sMMSB + sMSB + sLSB + eMMSB + eMSB + eLSB + CS
Device sends: 'O' + [addresses] + 'O'

Matching the moates v19 protocol.

Unfortunately i don't have a bench setup to attempt further testing these more advanced modes.
All the work i've done is based on what i've found online.
And the memory limitations aren't helping, I really don't want to strip out things that are making it stable and reliable which is about the only option.

I just test it with serial splitter monitor the data return from onerom, 4F 00 00 00 00 00 00 00 00 00 00 00 00 4F equal to 'O' + [addresses] + 'O'. I will get ostrich and compare the serial data. Maybe get some clue what difference.

About the memory, on onerom fire 28 there circuit for external memori, original buy from Piers, there no external memory include. What if we add W25Q16JVSS to the circuit? Is these give extra memory needed?