Ostrich 2.0 and Nistune handling

[RomChip200]

Matt,

There're still some troubles regarding the Ostrich 2.0 management by Nistune.
Here is the context:
I have 8 maps of 32KB (Z32) in the Ostrich from 0x0 to 0x40000 or 0x40000 to 0x80000 (Ostrich handles 512KB max.), I tried both configurations but the "Nistune effect" occurs in both cases. I use EmUtility to burn the 0x40000 concatenated bin.
http://www.tunerpro.net/downloadUtils.htm
I have rotary know to select one map from the 8 available. I know all the maps are burnt and selected correctly b/c I use an ECU ID different for each map.
I used this to access one given map in Nistune:
EMULATOR_OFFSET=&H0000
#EMULATOR_OFFSET=&H8000
#EMULATOR_OFFSET=&H10000
(...)

Ostrich mapping:
0x0 ECU_ID0 (rotary knob position 1)
0x8000 ECU_ID1
0x10000 ECU_ID2
0x18000 ECU_ID3
0x20000 ECU_ID4
0x28000 ECU_ID5
0x30000 ECU_ID6
0x38000 ECU_ID7 (rotary knob position 8 )

The read is performed successfully, I mean I read the right bin according to the offset.
But each time, the read by Nistune scrambled the Ostrich completely and I get this when selecting a map with the knob afterwards:
0x0 ECU_ID0 (rotary knob position 1)
0x8000 ECU_ID1
0x10000 ECU_ID0
0x18000 ECU_ID1
0x20000 ECU_ID0
0x28000 ECU_ID1
0x30000 ECU_ID0
0x38000 ECU_ID1 (rotary knob position 8 )

When writing these lines, I'm realizing I should have tested the read per offset with EmUtility, I will do it tonight.

This topic may be useful for multi-maps tuners though.

[Matt]

Nistune only supports upto 64KB with the emulator officially

I have got code in there to write the MMSB (top byte) but I dont think that works with the address file settings

We treat those address file entries as a WORD (16 bits) so anything higher and the top gets ignored as per your email below

What roms are you uploading that big? How come you are using Nistune for those?

[RomChip200]

27C040 or equivalent, but in fact my Ostrich stays most of the time in the car.
I need 8 maps b/c I use different fuel types (unleaded, ethanol ...)
I use Nistune for logging, incl. AFRs ..... for one map at a time of course.

I understand your position but the root problem is Nistune scrambles the location of the mapS (then the content ...) in the Ostrich !

0x0 ECU_ID0
0x8000 ECU_ID1
0x10000 ECU_ID2
0x18000 ECU_ID3
0x20000 ECU_ID4
0x28000 ECU_ID5
0x30000 ECU_ID6
0x38000 ECU_ID7
becomes
0x0 ECU_ID0
0x8000 ECU_ID1
0x10000 ECU_ID0
0x18000 ECU_ID1
0x20000 ECU_ID0
0x28000 ECU_ID1
0x30000 ECU_ID0
0x38000 ECU_ID1
just after an emulator READ (aka download) with Nistune, not a write.

[Matt]

What we do is put the ostrich into the lower emulation banks, which is why you see what you see

Ostrich has the options inside Nistune to:
Select Read Write Bank = moates_bank
Select Emulation Bank = moates_bank
Select Persistent Emulation Bank = persistent_emulation_bank

moates_bank can be set with the XX in emulator offset XXYYYY where XX will be 0 - 7 to select the bank

persistent_emulation_bank was set to -1 (which is invalid). That should not have been set. This is a bug so I have fixed that part to make persistent_emulation_bank = 0 ... or can make that the same as the address file perhaps?

Reason why I set the bank is so we are not reading/writing a different bank that the vehicle is using (otherwise it gets too confusing)

[RomChip200]

But in my case (8 maps available), Nistune can't never know the 0x8000 map really selected (by the external rotary knob)
Then, I play with EMULATOR_OFFSET

Remember people don't really play with EMULATOR_OFFSET variable (except me).
Then, if EMULATOR_OFFSET is not set, apply -1 to persistent_emulation_bank, if you assume that makes the things safer.

As you put 0 to persistent_emulation_bank, no more scrambling should occur and I should access the right file according to EMULATOR_OFFSET now.