TunerPro RT crash after changing XDF base offset

Report bugs found in TunerPro. Please be sure to include as much info as possible, including system specs, OS, repro steps and TunerPro version number.

Moderators: Mangus, robertisaar, dex

Post Reply
jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

TunerPro RT crash after changing XDF base offset

Post by jsiddall » Mon May 10, 2010 12:29 pm

I have been using TunerPro RT (registered) with XDF ECM_1F for a while with no issues. Recently I built a bank switcher and now I need a new non-zero offset.

I went into XDF->View/Edit XDF Header Info and changed the base offset from 0000 to F000, then saved the new XDF as a new name. However, whenever I try to open any constants/scalars/flags/switches/tables/functions in a bin with the new XDF it crashes.

If only use the updated XDF (with F000 base offset) to upload everything works fine so I am pretty sure the size and offset are good.

Any ideas how I can get tuning to work with a non-zero offset?
Last edited by jsiddall on Tue May 11, 2010 4:36 am, edited 1 time in total.

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Mon May 10, 2010 1:25 pm

why exactly are you messing with the offset?

the BIN stacker and splitter does wonders.

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Tue May 11, 2010 4:27 am

robertisaar wrote:why exactly are you messing with the offset?

the BIN stacker and splitter does wonders.
I want to do RT tuning which, as far as I know, can only be done with an offset. Is there another way?

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Tue May 11, 2010 5:52 am

in that case, yes your only option might be to have a different XDF specifically for that...

you MAY need to adjust BIN size at the same time to get the crash to stop.

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Tue May 11, 2010 6:01 am

robertisaar wrote:in that case, yes your only option might be to have a different XDF specifically for that...

you MAY need to adjust BIN size at the same time to get the crash to stop.
OK. The BIN size is in the XDF currently 0x1000 which seems correct for a 32K bin. All the BIN files are of size 4096 bytes.

What should I change it to?

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Tue May 11, 2010 6:23 am

1000 in hex does come out to 4096 in decimal.

as a test, i would set the BIN size to $2000 and change the offset to $1000... i really can't understand why you're trying to offset it so far. unless your bank switcher will only work in 64KB increments.

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Tue May 11, 2010 7:25 am

robertisaar wrote:1000 in hex does come out to 4096 in decimal.

as a test, i would set the BIN size to $2000 and change the offset to $1000... i really can't understand why you're trying to offset it so far. unless your bank switcher will only work in 64KB increments.
I tried making the changing you suggested and those did not crash the app. In fact I could leave the size as 0x1000 and change the offset to 0x1000 or 0x2000 but anything higher than that causes a crash.

However, when I accessed the tables from a saved BIN file using the changed offset the tables were either empty or had bad data. Does the BIN file need to be stacked in the same format as the emulator?

The actual offsets are just the way the bank switcher works. It uses the MSB as a toggle with all other bits high, so the BINs I am using actually start at the 8th and 16th position.

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Tue May 11, 2010 7:27 am

well, if you offset the BIN, then you MUST have it stacked correctly or you will get bad data in the XDF.

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Tue May 11, 2010 7:39 am

robertisaar wrote:well, if you offset the BIN, then you MUST have it stacked correctly or you will get bad data in the XDF.
Well, yes of course. But what is unclear is how the emulator is used vs. the saved file. If I open a saved file and upload to the emulator using 0xF000 as an offset in the XDF it works. So this looks like a logic error where the upload code looks at files with no offset and the emulator is accessed _with_ an offset, but the table editing seems to always use an offset for both file and emulator.

If I stack the BINs into a file that mimics the emulator I am worried that the upload will try to use offset 0x0000 in the file even though the tables have all been editing offset 0xF000.

What I am saying is that no matter which way I do it I think something will be wrong (either the data in the emulator or the data in the file).

Does that make sense?

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Tue May 11, 2010 7:43 am

uhh...... someone with an emulator will have to help you at this point, because you just lost me.

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Tue May 11, 2010 9:16 am

robertisaar wrote:uhh...... someone with an emulator will have to help you at this point, because you just lost me.
OK, hopefully someone can help with the emulation thing, but maybe you can help me get the file part right.

I went ahead and created a stacked bin with two bins, one in position 0 (offset $F000 within chip) and one at position 8 (offset $7000 within chip). The rest of the positions were filled with bins containing all zeros.

Then I opened the stacked bin and set the XDF to offset 0xF000. The good news is I could see the tables correctly. The bad news is if I made a change and said "save" I got an error: "Error - One or more checksums could not be updated. Check checksum addressing, etc, for validity."

Any ideas on getting around that?

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Tue May 11, 2010 9:22 am

assuming you opened it as a normal BIN, then you would have to adjust checksum addressing as well.

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Tue May 11, 2010 10:18 am

robertisaar wrote:assuming you opened it as a normal BIN, then you would have to adjust checksum addressing as well.
Yes I opened it as a normal BIN.

The original XDF had these checksum settings:

Data Start: 0002
Data End: 0FFF
Store Address: 0000

I assume everything else stays the same anyway so I won't list those.

On my 0xF000 base offset XDF I tried changing the settings as follows (by adding 0xF000 to everything):

Data Start: F002
Data End: FFFF
Store Address: F000

But still I get the same checksum error.

Any other thoughts?

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar » Tue May 11, 2010 10:21 am

that should be correct... mark may have better answers now since this is getting out of my league.

User avatar
Mangus
TunerPro Author
Posts: 1828
Joined: Wed Mar 19, 2003 1:49 pm

Post by Mangus » Wed May 12, 2010 7:56 am

Sorry, I only glanced through, but I think the desired outcome is to have a stacked bin, and be able to tune each bin in the stack individually.

If so, here's a for-instance (using fake numbers).

4x 4KB tunes, stacked in a 16KB bin.
Tune 1 is 0-FFF, Tune 2 is 1000-1FFF, Tune 3 is 2000-2FFF, and Tune 4 is 3000-3FFF.

Great, so now what?

Create 4 copies of your base XDF. Each one will have a different base offset. For tune 1, the base offset is 0 (naturally). Tune 2's base offset will be 1000 (meaning 0x1000 is added to every referenced address in the XDF), tune 3 is 0x2000, etc.

Now, when it comes to updating the emulator, you're in a bit of a pickle. TunerPro knows the size of the entire bin (in this case, the size of the stacked bin containing all 4 tunes). When you choose to upload the entire bin, it will load the entire 16KB bin to the emulator.

Most hardware switches work by "partitioning" emulation memory. This could be a problem for doing such updates. The ostrich 2.0, though, can use the 4Mbit mode. In this sense, everything is presented to the emulation port, and you can do incremental updates across the entire bin in this case. If this is the way you work, then you should be fine. If your emulator doesn't work this way, then you probably won't be able to emulate using your hardware switch.
***************************************
TunerPro Author
1989 Trans Am

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Fri May 14, 2010 10:25 am

Mangus wrote:Sorry, I only glanced through, but I think the desired outcome is to have a stacked bin, and be able to tune each bin in the stack individually.
Yes. More specifically, I want to be able to RT tune a single bin in a stack.
Mangus wrote:If so, here's a for-instance (using fake numbers).

4x 4KB tunes, stacked in a 16KB bin.
Tune 1 is 0-FFF, Tune 2 is 1000-1FFF, Tune 3 is 2000-2FFF, and Tune 4 is 3000-3FFF.

Great, so now what?

Create 4 copies of your base XDF. Each one will have a different base offset. For tune 1, the base offset is 0 (naturally). Tune 2's base offset will be 1000 (meaning 0x1000 is added to every referenced address in the XDF), tune 3 is 0x2000, etc.
Yes, I follow what you are saying but I am having issues with even this part. I have the various XDFs for each bin, and I have a stacked bin file. Even before I connect the emulator if I try to edit the stacked bin with the desired XDF and save it I get the error "Error - One or more checksums could not be updated. Check checksum addressing, etc, for validity."

Any ideas? See some previous posts for details on this.
Mangus wrote:Now, when it comes to updating the emulator, you're in a bit of a pickle. TunerPro knows the size of the entire bin (in this case, the size of the stacked bin containing all 4 tunes). When you choose to upload the entire bin, it will load the entire 16KB bin to the emulator.
OK. In my case I have an Ostrich v1 which is set to 28 pin mode I have 16 stacked 32k bins to come up with one 512Kbit bin. I was able to upload that bin with TunerPro and it seemed to work fine.
Mangus wrote:Most hardware switches work by "partitioning" emulation memory. This could be a problem for doing such updates. The ostrich 2.0, though, can use the 4Mbit mode. In this sense, everything is presented to the emulation port, and you can do incremental updates across the entire bin in this case. If this is the way you work, then you should be fine. If your emulator doesn't work this way, then you probably won't be able to emulate using your hardware switch.
My ECM is a 24 pin 32K PROM type. My switcher simply fiddles the upper 4 bits of the 28 pin Ostrich socket to select the desired 32K bin. I assume that's what you mean by "partitioning". The Ostrich however has no way to even know there is a switcher present. It simply thinks it is emulating a 512Kbit chip. All I am trying to do is use TunerPro RT to real-time update individual 32Kbit portions of the Ostrich's 512Kbit address space. Is there some reason I can't do incremental updates like that with an Ostrich v1? I can't see any obvious technical problems with it.

Thanks for your help getting this worked out.

User avatar
Mangus
TunerPro Author
Posts: 1828
Joined: Wed Mar 19, 2003 1:49 pm

Post by Mangus » Fri May 14, 2010 10:51 am

Let's work through the checksum issue first. Please email me all of the files you're using - all XDFs (for each position), and all bins (including the stack). And include instructions to repro.

mark at tunerpro dotnet.
***************************************
TunerPro Author
1989 Trans Am

jsiddall
Posts: 12
Joined: Mon May 10, 2010 12:20 pm

Post by jsiddall » Sat May 15, 2010 5:25 pm

Mark got things resolved.

Turns out that the trick is to set the XDF bin size to be the size of the entire stack, not the size of each bin in the stack.

In my case I had 16 32Kbit bins in a 512Kbit stack, so the bin size needed to be set to 0x10000 (64Kbyte). No changes were necessary to the original XDF checksums.

Post Reply