segmented memory models

[Jim Brain]

Sridhar Ayengar wrote:
> Jim Brain wrote:
>> Tony Duell wrote:
>>> And IMHO one common expression of 'brain damage' is when the design 
>>> omitted to ccosider soemthing that later became a major issue.
>>>   
>> Do you design for a living?  If so, then my hat is off to you for 
>> thinking of *EVERY POSSIBLE* use of the design you have made.  I 
>> design for a living, and I think you're asking way too much of a 
>> designer.  The best designers plan for the stated requirements and 
>> try to consider the long term, but they are not prophets.
>
> I do design for a living, and, although your point regarding being 
> unable to predict the future with perfect accuracy rings true, I would 
> argue that prototypes really help with getting the really big 
> screw-ups out of your designs.
>
> Peace...  Sridhar
I can't argue that.  Are you stating, though, that the 8080 or 8086 
design did not go through a prototype stage?

I would rebut (only slightly) that I find it is getting harder to do a 
"prototype" design.  Customers want it right the first time, there's no 
time or budget for a "prototype", and it cna be hard to simulate a new 
design to the degree needed to ensure all of the issues are resolved.  
Luckily, new designs ararely break a ton of new ground, and costs of raw 
materials are much less now, so it's easier to hedge your bets by 
designing in some backup plans for a worst case scenario.

To keep things on topic, I find the CBM 1351 mouse design serves as a 
good example of my point.  Long after the C64 had been introduced, it 
was still a good seller, and Berkely Softworks had managed to put a GUI 
on it in the name of GEOS.  A clever chunk of code, no matter your 
impression of GUIs in general.  While I never found the tool all that 
exciting from a user point of view, the developer in me marveled at the 
functionality they crammed into 64kB and 320x200 and 170kB disks.

Still, a UI needs a mouse, and the C64 was not designed for one.  If we 
take Tony's perspective, we know that Xerox was doing GUI and 
mouse-driven UI work ong before the 64 came out, so some might argue 
that the 64 design should have included a mouse port (heck, we coudl 
argue that for all PCs, but I digress).  I don't take that view.

Still, CBM engineers looked at their options for adding a mouse to the 
64.  The obvious candidates were the soft 1200 bps uart on the user 
port, but that would preclude telecomm apps.  An expansion card option 
with a proper uart was another path, but multi-slot expansion cards were 
not the norm then, and GEOS already effectively needed the expansion 
slot for the RAM expansion unit (REU).  The cassette port could work, 
but the engineers no doubt kept coming back to the joystick port, as 
they is the normal location for non-KB input device installation.  Hmmm, 
5 IO pins and 2 8-bit ADCs are all they had to work with.  Other designs 
used the analog pins for absolute positioning, but that made pixel-level 
positioning impossible.  Clearly, some relative positioning approach was 
needed, and the design should minimize the use of the digital IO, since 
the joystick port IO was shared with the KB (one port are the low 5 bits 
of the KB columns, the other is the 5 low bits of the KB rows).

In order to satisfy all of the business requirements (use no other 
ports, > 8 bit positioning, minimize digital IO usage), they came up 
with a clever (in my opinion) approach.

They designed an IC that kept two digital counters (X and Y) and then 
translated the low 6 bits of the counters on the two POT lines.  Instead 
of trying to generate a variable resistance (that would require tuning 
and other such things), they took advantage of the known properties of 
the SID POT lines.  The lines work by counting the discharge of a cap to 
a preset reference value over a 256 cycle period.  Further, then end the 
cycle by clamping the POT line to ground for 256 cycles.  So, the design 
implemented was:

Watch the POT line for the line to drop to ground.
Wait 256 cycles
wait another 256 - (low 6 bits of internal counter)*2
bring line high for (low 6 bits of internal counter)*2 cycles
repeat

This process ensured the line was always high at the end of the 512 
cycle period in order to see the next clamp to ground event.  The *2 
took care of the inherent jitter of the design (PAL 64s ran a bit slower 
than 1MHz, NTSC a bit above, the ASIC in the mouse ran at 1MHz exactly, 
so the low bit of the SID POT line would jitter.  Thus, the programmer 
would take the low 7 bits, lsr, and then have the counter value modulo 
64.  A bit of additional work on the programmer's side and overflow 
could be handled as well.  The top bit was left off because the design 
relied on a small resistance on the ADC line to allow the ASIC to drive 
the line high but still see the low clamp event.  Thus, there was no way 
to reach above 250 or so on the scale, and the design was much simpler 
if just 6 effective bits were used.

Now, looking at it one way, the design is awful, as it abuses so many 
things.  On the other hand, I find it an elegant solution to the problem 
at hand.  Many 1351 mice were sold because they were easy to understand, 
reliable, and easy to install/remove.

Jim