Posted By
TLC
on 2022-11-04
11:24:23
|  Re: New Project: Hannes-compatible 256k RAM Expansion
@SukkoPera addendum (re: Csory memory expansion); as said whether someone feels enthusiastic about the Hannes / Solder / Csory memory expansion schema isn't really my business (...I know I definitely used to be  ), yet, maybe it's worth writing down why "I" am already not.
In a nutshell, the Csory schema lets the programmer select one of four 16K windows of the CPU's 64K address space for paging. Then, 16K pages of the 256K expanded memory can be selected to appear in the selected address space window. The thing works transparent to the Hannes/Solder memory expansion. (That is, everything under Hannes/Solder remains as-is, except for the 16K window selected under the Csory expansion schema.) Also, the enable bits of the extension logic are in the Hannes/Solder control / page register i.e. $FD16.
At first sight, the "16K page in a selectable 16K window" approach is IMHO definitely much more elegant for the job than how the Hannes/Solder is doing it. Still...
My loss of enthusiasm started from the point where I realized the obvious, i.e., that there's no Csory expansion without a Hannes/Solder part implemented first. That is, what I have to judge is in fact not the Csory expansion itself, but inherently the combined bunch of the two in one. From that on, things IMHO take a bit different route, especially if resources are scarce (...which they are, as long as no modern PLDs are in the picture). First and most of all, from the point of adding the Csory extension, the basic function (i.e. memory paging) is literally implemented "twice"; that is, our thing is redundant, which is (by definition) a waste of resources. I'm just referring to my prototype above - the Csory extension AFAIR required four or five extra TTL gates to be added, which is a comparable number to the overall chip count of my previous (Hannes/Solder) controller prototype. Not only is the thing redundant, but (due to the alternative functions) the two need to be multiplexed together, which has also nothing to do with basic functionality (i.e. memory paging).
(When I think over what could have been implemented in roughly the same complexity of the Hannes/Solder memory controller's (let alone Hannes/Solder/Csory), I also find that the existing construct is suboptimal. The Hannes/Solder already has too many "control bits", "modes", "exceptions", if you please (implementing these exceptions takes resources comparable to that of basic paging functionality). I mean these "modes" IMO merely attempt to patch a conceptually flawed design (--> the design choice of paging ram in 64K long pages), and the implementation of the exceptions takes resources that don't serve basic i.e. memory paging functionality. ...Let alone Hannes/Solder/Csory, where just activating the Csory schema part starts off with wasting 2 potential address bits from the Hannes/Solder page register. If someone had said instead, hey, let's just start over from scratch, create two page registers of 4...8 bits each, assign them to the $4000-$7FFF and $8000-$BFFF address windows respectively, and let them both page in 16K pages of a 256K... theoretically up to 4M expanded memory space, the task would have been solved with practically no "function control" bits and corresponding overhead (all of them waste) at all. That is, we'd just have memory paging functionality superior to that of either Hannes/Solder, Csory, or both (...hey, we'd have two, clean, symmetric and completely independent page reigsters and pages!), in roughly equal (or even less) controller complexity. (*Reset for the page registers could have been somewhat tricky, but that's all.))
At that point, the Csory expansion could still have had some historical value (Csory has been a talented and very prolific guy IMHO), but when I started to look around finding releases for testing my prototype card, I found out that there were almost none. Most of the 256K specific programs, as previously said, speak Hannes/Solder. The rest, although not documented yet (my bad), mostly turned out to be HX-256 specific. I could find exactly two Csory specific programs. The first one is the Bard's Tale III Csory 256K release, which turned out to be buggy (...traced the culprit down to a small code snippet in the loader, no doubt it would never run on a true 256K capable config). The second is Csory's infamous 256K Macro Assembler, which I happened to have from someone. That stuff exclusively runs off a 32K ROM, which is fine, but it also requires committing the extra ROM hack loosely described in Solder's ROM expansion schematics, which is/was IMHO not. By then I was less than enthusiastic about raising my stakes, so I just didn't.
That's probably all about "my" story. Being a TTL junkie (and, when not, still very much preferring contemporary components with regards to old gear), I thought I'd just drop this from my next prototype (especially given that I might, as said, probably just get away with using two 22V10's, given I'd only implement the Hannes/Solder schema). No doubt there could be other considerations.
|
