VIA address decoding

[JonBrawn]

I've been staring at schematics for a while now, and I'd like something confirming (or, better still, denying).

VIC responds to addresses that match the pattern 1001_0000_xxxx_rrrr
VIA1 responds to addresses that match the pattern 1001_00xx_xxx1_rrrr
VIA2 responds to addresses that match the pattern 1001_00xx_xx1x_rrrr

So reading from $903F will actually enable all three to try to drive the data bus at the same time - a collision(*).

However, the following groups of addresses are not decoded by any device:

$910x
$914x
$918x
$91Cx
$920x
$924x
$928x
$92Cx
$930x
$934x
$938x
$93Cx

I plan to use some of these addresses for Victor features such as user writable palette and reprogramming the EEPROM (once the magic unlock sequence has been written).

Is my observation about this address decoding correct, or have I missed something?

---
*) MOS chips seem to survive this fairly well. Victor uses level shifting line drivers which are substantially more aggressive in how they drive the data bus, and so I'll only be enabling the output from the databus for addresses strictly in the range $9000-$900F, because I don't want to be responsible for blowing the snot out of somebody's VIAs.

[MCes]

VIC20 does not have fully decoded addresses for chip selection,
so some chips overlaps can be done.

The overlaps become bus conflicts if a READ cycle is executed,
but it can be used to WRITE the same value into the same register of both VIAs in the same CPU cycle,
it can be useful for "raster routines and VIAs timers" or other applications that are time critical or need to be very short....

If not necessary the simultaneous write activity on more chips into the same cycle has to be avoid for best compatibility with an eventual modded VIC20 that could use a full address decoder that resolve the overlaps enabling a single chip or no chip instead both VIAs...

[Mike]

[...] I'd like [someone] confirming [...]

You might want to recap the threads 'Aliases' and 'Writes to $9010-$901F' (the latter also being linked to from the former thread).

Please note people already have added circuitry to finer-decode I/O0 within their VIC-20. Also, the 'memory holes' have been used on occasion to probe VIC activity by the CPU (by fetching data remaining on the BD bus due to parasitic capacitances).

[JonBrawn]

Also, the 'memory holes' have been used on occasion to probe VIC activity by the CPU (by fetching data remaining on the BD bus due to parasitic capacitances).

That is unfortunate - regrettably, I need an area where I can read info back from Victor to do things like reprogram its EEPROM or fetch the current settings for the user palette. However, unless the super secret unlock pattern has been written to the appropriate registers in the range $9000-$900F then these extra locations won't be enabled.