TunerPro RT crash after changing XDF base offset

[jsiddall]

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?

[robertisaar]

why exactly are you messing with the offset?

the BIN stacker and splitter does wonders.

[jsiddall]

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]

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]

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]

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]

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]

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

[jsiddall]

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]

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

[jsiddall]

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]

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

[jsiddall]

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]

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

[Mangus]

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.

[jsiddall]

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.

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.

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.

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.

[Mangus]

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.

[jsiddall]

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.