Posted By
TLC
on 2011-02-17
06:46:19
|  Re: Plus/4 C16 diagnostics and TED partial failure modes
Some time ago I also bought a couple of 8501s from a Hungarian reseller (hqvideo.hu... I didn't know about this source even though I'm Hungarian and that I used to buy components there sometimes... it was pointed out by Pepax in this forum). They sold "old stock" chips ie. from that last production run (...I assume they kept them on stock for about 20 years... they're the sort of replacement-part resellers... small stocks, very large palette, rare-ish (...and obsolete-ish) components at a slightly expensive price). I bought a small stock for my needs and bought/sent chips to people who asked. By now it looks someone finally bought up the whole remaining stock (by the time I bought 8501 chips there for the last time, which was last summer, they still had around 20 pieces or so). I can only hope that it was someone "amongst us" and not someone with some speculative intents...
It's interesting to note that the fact that you could buy that stock from China... well... seem to suggest (...I'm not sure, but I can't find a better explanation) that our Chinese friends could somehow get hold of a number of 264 series machines. ...Should that mean, that a presumably large number of machines ended up there via these dispose/recycle programs of so-called "developed" countries?... ...I feel like the guy in the traditional joke (..."absolute ambivalent feeling" = when your mother-in-law writes off your brand new car in an accident ). ...At least, a lot of valuable chips have been salvaged...
Cartridge: although most of us "creative" people usually have more ideas than time/intent to realize them (...at least I assume so  ), so we're usually pretty flooded by ideas and don't really need others' (...what we'd need was time and effort instead  ), I'd present some ideas that you might or might not use in your design... that's up to you from now.
There's the problem of the cartridge relying on the Kernal and (more importantly, because it fails more often) the RAM.
You could probably avoid that.
The basic idea: the CS' signals are generated by the TED, the PLA, and a couple of TTLs. None of them know about the CPU -- they only know about the address bus. Even if the CPU addresses $fffc, the address bus doesn't neccessarily need to reflect that.
Second: the CPU is an NMOS device (ie. generates strong L and weak H levels). You can pull any of its outputs to low anytime, without major (physical) consequences.
Let's suppose you intentionally pull A8 low externally, when the reset mechanism starts. What happens?
The CPU first reads $fffc, then $fffd. You pulled A8 low. This doesn't harm the CPU, but as a result, the address bus reflects $fefc and $fefd, respectively -- and so will see the whole decoding logic in the machine. $fef0-$feff is reserved for the first 1551 drive TIA -- it's certainly empty space if no 1551 is connected to the machine. In short, first, the memory fetch avoids the Kernal ROM. Kernal' certainly won't be activated. Second, at this point, the fetch reads from nowhere -- but that's only one more step, to map some external ROM here. All in all, the Kernal can be avoided... it only takes some TTL logic to hold A8 low when it's needed, and map ROM to $fe00-$feff (again, when it's needed).
I would most probably use an RS flip-flop to hold the internal state. This flip-flop would be activated by Reset' (which is predictably low upon power-on reset). The active state of the flip-flop pulls A8 low through an OC output or just simply a series diode. It also activates a small extra address decoding circuit (might be a greatly simplified one) whose output ANDs with "cartridge 1 hi'", ie. enables the cartridge ROM to be active at $fe00-$feff too, but only if the RS flip-flop is set. The reset mechanism fetches then from $fefc-$fefd ie. your mapped-in cartridge ROM, your program can start in your ROM, and can also turn this little present off. (As a simplification, I'd probably reset the flip-flop by R/W' -- predictably, no writes occur before the CPU attempts to do so, and the code will sooner or later attempt to do that I'd presume --, but it could probably also be done by some decoding logic + respective CPU instruction).
With that, the need for a useable kernal rom chip + ram can be avoided... at the expense of a slightly more complex digital logic.
Edit: R/W' is probably not suitable (...alone), because the cartridge ROM needs to be mapped in, which already needs writing (...it won't be good to pull the $fe00-$feff rom slice off at the moment the sta $fddx happens... ). ...But you get the idea.
|
