Posted By
TLC
on 2024-04-05
08:19:51
|  Re: New Project: Hannes-compatible 256k RAM Expansion
@SukkoPera I think the basic confusion about this matter is in the context of this "default bank" thing, I mean how this "default" word is interpreted.
It's no matter how some address bits are inverted (negated) in some particular memory addressing schema. Such thing is nothing more than a logical mapping, which makes no difference as long as all the interested parties know about the exactly same one. (See, if I'd to invert A16 or A17 in some banking logic, application level wouldn't notice that, since it'd still see a linear N-bit address space. Whether some addresses now resided on different physical memory pages than before, it'd really not care.) Some problem can only pop up from the point where the physical memory can be addressed multiple ways. This is exactly the case with Hannes / Solder's "force-default bank" thing, where it's implicitly a second way to address physical memory banks. Still, the detail that "where exactly" some difference is actually happening in the combinatorial logic, doesn't really matter either, as far as the end result is concerned. The only thing that really matters, is just how the different addressing methods "relate" to each other.
In effect, and from a purely logical (not implementation) point of view, in HLI's you get
- a usual linear bank addressing schema from bank 0 to N (N=$0f for 1M), with the "highest existing" bank set active on power-on reset (...this schema totally aligning with that of original Hannes / Solder so far).
- "bank 3" of the linear bank address range selected on "force default bank" conditions
The latter, "bank 3" thing is implemented by manipulating the P2 and P3 signals. TL;DR: this detail doesn't really matter. (The author could as well have manipulated the "force default" combinatorial logic to achieve the same result... I mean this is a mere detail of physical implementation. What only matters is how the selected bank of the basic bank addressing method relates to the selected bank by the other (force-default-bank) method. This relation can be deduced by interpreting the combinatorial logic, i.e. finding out what MA8 and /CAS is triggered by a force-default-bank condition, and then finding out, which P0-P3 values trigger the same MA8 and /CAS values. That's where actually the force-default-bank = P0=1, P1=1, P2=0, P3=0 result comes from).
That's probably all about the HLI specific bank addressing schema.
Personally I think that "well behaving" 256k/256k+ specific code is and has always been supposed to leave unused bits of $FD16 just alone. I mean the one single guaranteed thing here is, that all bits in $FD16 are initialized to "1" upon power-on reset. Logically, and that's maybe only because I had read a lot of microcontroller / other embedded system related application notes in my life  , that default would have to be respected for any bits not needed / not "known about" by the code (--> mask them and keep them "1" all time), and from that point on, things would-should just work fine on any Hannes / Solder derivatives of any size. (Note, that that simple rule is messed up by the HLI address hack for any 256k+ Hannes / Solder derivatives, if implemented.) That method would work for any Hannes / Solder / Csory combinations up to 1M, and for up to 4M pure Hannes / Solder derivatives (where P4 and P5 also play as bank address bits).
As said, considering that people could and likely have arbitrarily set the P2-P5 bits in their legacy 256k specific prods, from the point P2-P3(-P5) have effect, I think there's little chance that one-single 256k+ schema could fit all the existing cases in one. I guess this is an inherent limitation.
(I think, for bad-behaving 256k code, the best options are probably a revert-to-256k hw mode first - that is, a hw option (either activated by config bits or a physical switch), where bank select bits from P2 and above are void of any effect on memory addressing. That'd plausibly make all the affected legacy prods work "in one step", albeit with manual intervention needed. Patching problematic code as time goes (so that they would "behave"), could then make these prods run on "regular" expanded memory setups of any expansion sizes just out of the box,... that is, no longer requiring manual intervention.)
|
