|
Post by gsteemso on Nov 14, 2016 13:45:26 GMT
As far as I can tell, there's supposed to be a kind of navigation bar that stays in fixed position at the top of the page no matter where you scroll down to, but I have found it very temperamental and unreliable. It only seems to work properly on a handful of browsers, and not always even for those.
|
|
|
Post by gsteemso on Nov 14, 2016 13:40:30 GMT
Oh, I know that it would be a very small savings in the end, but recall they were using mask-programmed parts rather than electronically writable ones. Even with the chip foundry nominally part of the same company, that would have to be a minor logistical nuiance. Of course, from what you say about them using only the one ROM regardless of how much VRAM was present shows they actually took the even more tightfisted route of simply not bothering at all. I wish I could say that surprised me, I really do…
|
|
|
Post by gsteemso on Nov 14, 2016 13:32:35 GMT
Agreed, that is very straightforward. For some reason "programmable logic" automatically meant "FPGA" to my brain; I'm sure that would be massive overkill even with 1980s parts! A PLD makes a lot more sense.
|
|
|
Post by gsteemso on Nov 12, 2016 19:40:53 GMT
I didn't have time today to read back over this whole thread, so this may have been covered already, but I had previously understood the "brown fix" was straightforward to implement in either of two ways — (1) use a couple of simple logic gates to substitute the correct value when the Dark Yellow RGBI code is presented, or (2) use a different arithmetic weight for the Intensity input signal than for the RGB ones, such that the resultant analogue RGB signals are each specified by three-bit values instead of two-bit ones. Obviously, that one produces a different colour palette than the usual method (to my eyes a less satisfactory one, but if you were originally exposed to that one and so had different preconceptions, there's nothing actually wrong with it), but it requires no special-case logic at all.
I ran across the second method several years ago in an article on CGA video, and have not been able to find it again since, but I wasn't looking very hard either.
Anyway, with this being so simple either way, isn't it kind of massive overkill to use actual programmable logic to do it? Not trying to be snide in asking this — I'm genuinely curious as to the reasoning.
|
|
|
Post by gsteemso on Nov 12, 2016 19:21:03 GMT
I periodically toy with the idea of a vastly improved ROMset for my 128s, which would remove as many flaws and annoyances as possible without altering software compatibility (of course, programs which ignore all sanity and jump directly to random locations in ROM are, as always, out of luck). One big item on the list of requirements for such a thing is a test for how much VRAM is physically present before setting that register appropriately.
I never could figure out why that test was left out in the first place, or at least the second place; you'd think that being able to use the same physical part whether assembling a 128 or 128D would have been a gain in production efficiency. Or was the 64KiB model produced only after the others had been discontinued?
|
|
|
Post by gsteemso on Jul 17, 2016 4:52:31 GMT
Unless Commodore made a special effort to duplicate the functionality in an entirely separate I/O port on another chip elsewhere in the system, it is impossible that the Z80 could ever access a cassette drive directly. Without actually looking up the details, I am certain that over half of the control and sense lines used to interface to the tape connector are only available from specific bits in the 8502’s onboard I/O port. Thus, for the Z80 to access the cassette drive at all, it would HAVE to do so indirectly via an 8502-mode subroutine.
|
|
|
Post by gsteemso on Jul 1, 2016 17:11:10 GMT
Erk! I was thinking solely of this specific announcement, which as you point out appears to have no evidence of actual existence beyond that single article you mentioned — no commentary on your own well-documented projects was intended. Indeed, it would be quite hypocritical of me to sneer about the slow pace of anyone else's work when none of my own works' progress has advanced AT ALL in at least a year. In other words, I sympathize with people who are committed but experiencing serious delays; I am, on the other hand, merely irritated by those who announce unrealized dreams as though they were imminently to be available for purchase.
|
|
|
Post by gsteemso on Jun 30, 2016 21:12:50 GMT
While I hadn’t been aware of that project until I saw this thread just now, the bit where it claims to be a C128-compatible EasyFlash work alike immediately grabbed my attention.
The last commentary I encountered on that particular subject stated fairly authoratively that (due to the very different low-level electrical characteristics of each model's system bus) implementing it would require an entirely new approach if it were even possible at all, so if these people have actually figured out a way to do so, I am EXTREMELY interested. Really hope this turns out to not be vaporware!
|
|
|
Post by gsteemso on Jun 26, 2016 6:42:45 GMT
Broken link!
|
|
|
Post by gsteemso on May 20, 2016 4:33:24 GMT
As posed, this question is difficult to answer. What assumptions are you making about the hardware environment? Your mention of reserving values under 128 (i.e., a 7-bit-wide value) to indicate internal memory is… a bit unexpected, shall we say. The original Commodore 128 concept allowed for up to 16, 64KiB banks of native RAM (totalling 1 MiB of capacity and needing 4 bits to encode), of which two banks are physically present and four are allowed for in the we'll-fill-the-rest-in-later firmware that was cobbled together to get it out the door on time. The 16 pre-defined RAM-plus-extras configurations that BASIC 7 calls "banks" would, if extended to account for the other 12 banks of physical RAM, presumably number somewhere around 64, which would eat six bits to encode. So far so good.
This whole scheme was obsoleted mid-development by the invention of the REU, which could (if its design were fully realized) hold up to 256, 64KiB banks. That value needs a full byte to encode, so referencing both maxed-out internal RAM and maxed-out REU RAM cannot be done in a single octet.
Making matters even more annoying, there are numerous other flavours of RAM in "common" use (insofar as the term can be said to apply to a platform with a residual userbase of at most a few thousand or so worldwide), such as RAMLink and GeoRAM. All of these matters were very elegantly dealt with in the 1990s by a fellow named Craig Bruce, whose text-mode ACE operating system which makes use of the method he devised is still available from his website. (I think the current version has been release 16 for roughly 20 years.) In short, he uses a 4-byte pointer model: one byte each for the type of RAM, bank number, page number within that bank, and byte number within that page. The details are freely available in a clearly linked-to file on his page.
As an aside, I observed a few years ago that the 4-byte universal pointer model can be extended by adding a fifth byte to indicate which of the CPUs available locally on the Commodore Serial Bus (or IEEE-488 bus, if present) is in charge of the memory pointed to by the other four bytes. Obviously, this extension would only be useful in a custom-programmed CSB-based cluster computer… That said, you can make one of those using only a single Commodore computer plus whatever programmable disk drives you have plugged into it. More than one person has written degree theses concerning exactly that type of bargain-basement multiprocessor system.
|
|