Value read from bankswitching location?

[eshu]

Hi,

 

When I read from a bankswitching location eg LDA $1FF8 in $F8 bankswitching it reads #$FF into the accumulator, does anyone know if this behaviour is the same on real hardware, on both the harmony/melody and normal cartridge boards?

 

Thanks

[Kroko]

Hi,

 

When I read from a bankswitching location eg LDA $1FF8 in $F8 bankswitching it reads #$FF into the accumulator, does anyone know if this behaviour is the same on real hardware, on both the harmony/melody and normal cartridge boards?

 

Thanks

 

You are reading the value from $1FF8. If the bankswitching is very slow, then you read from the old bank, if it is quick you read from the new bank.

To always get $FF, you should put $FF at location $1FF8 in both banks. If you need a different value, just put that value at $1FF8 in both banks.

[eshu]

Hi,

 

When I read from a bankswitching location eg LDA $1FF8 in $F8 bankswitching it reads #$FF into the accumulator, does anyone know if this behaviour is the same on real hardware, on both the harmony/melody and normal cartridge boards?

 

Thanks

 

You are reading the value from $1FF8. If the bankswitching is very slow, then you read from the old bank, if it is quick you read from the new bank.

To always get $FF, you should put $FF at location $1FF8 in both banks. If you need a different value, just put that value at $1FF8 in both banks.

 

Thanks, makes sense - I think dasm fills unused bytes with #$ff - I had a bit of a mental block because the address obvioussly serves the function of bankswitching, but i guess that's handled by a different part of the circuit and the memory is still there to read....

[+batari]

In general, I think it's a bad practice to rely on values read at hotspot locations.

 

Putting the same value in all banks at hotspot locations will usually work, but if the hardware happens to be changing addresses during the time the value is read, this is undefined behavior and there is no guarantee the data will be valid.

 

What's worse, some hardware may not drive the bus at all when a hotspot is hit leading to unpredictable values.

[Nukey Shay]

I think dasm fills unused bytes with #$ff

By default. You can instruct it to fill memory with any byte (or group of bytes) that you choose though.

 

ex:

ORG $FF00,0 fills memory below the address specified with zeros. I believe that it's been said it's better/quicker to fill unused portions with $FF for binaries you intend to burn to eprom.

[Kroko]

What's worse, some hardware may not drive the bus at all when a hotspot is hit leading to unpredictable values.

 

I think you can rely on the value if it is the same on both banks. The original F8 devices do drive the bus

and I guess if new boards want to be compatible they should do this as well. Do you know of any boards/devices

that do not drive the bus when A12 is '1' ? That would be interesting ...

[+batari]

What's worse, some hardware may not drive the bus at all when a hotspot is hit leading to unpredictable values.

 

I think you can rely on the value if it is the same on both banks. The original F8 devices do drive the bus

and I guess if new boards want to be compatible they should do this as well. Do you know of any boards/devices

that do not drive the bus when A12 is '1' ? That would be interesting ...

Usually that is true, but recently I was working on an 8k board running a 4k game, and A12 was (mistakenly) floating. Even though both 4k banks had the same data, the game did not work until I connected the line high or low. This suggests that address lines must be at proper logic levels during the read. If reading an EPROM at the same time the address is changing, this might result in incorrect data. Even if this occurs one in a thousand reads, that is enough.

 

Devices with RAM do not drive the bus in some addresses with A12=1. There are some new schemes for Harmony/Melody that currently don't bother driving the bus during hotspots.