[comp.sys.m6809] Caching

rph@chp.UUCP (08/12/87)

In article <5047@milano.UUCP> baxter@milano.UUCP writes:
>In article <1109@wlbr.EATON.COM>, pete@wlbr.EATON.COM (Pete Lyall) writes:
>> ... The DMC
>> controller is allegedly also barking up that tree, but with
>> considerably smaller cache area (~8K).
>SDOS has always had a cache of 2-4Kb.  It works reasonably well,
>but isn't anywhere the performance of the big cache we have been talking
>about.

I run OS9 on a SuperPET and wrote up a caching system that uses 26k
of non-OS9 memory. It caches both reads and writes, because by patching
the disk driver routines I found that some horrible inefficiencies
occur when writing. Cached write-modified blocks are removed by a daemon
that writes out the oldest modified block every 5 seconds or so,
or they just get pushed out of the cache by aging. Not a great algorithm
but it was easy to do... what it really should do is flush out those blocks
that are near where the head physically is at any moment (seeks are
the big killer, even with 5ms seeks like I have here).

>> How do you time stamp your LRU/MRU sectors?? Do you keep a separate
>> data structure aside for disk/LSN/TIME, and update with a 6 byte time
>> packet? Do you keep this list sorted?
>TIME STAMP? That's crazy. All you need is a relative time ordering,
>which a linked list does beautifully.

Ya a time stamp is useless; mine are just sorted in a doubly linked
list by order of least-recent-use. But this too can be improved a lot.

Anyway, with this cache running it takes some .3s to search my whole
execution directory (which has 116 files in it) and 4 minutes to
compile small C programs. That's pretty good since the filesystems are
actually maintained as 1-meg relative files under CBM DOS(!).
---
Pontus Hedman		{utzoo|utgpu}!chp!rph

vodall@hpfcdq.HP.COM (Bill Vodall) (08/18/87)

> I'm running around now trying to find R.S. stores that still have a
> RS232 pak or two lying around.  I want to get 2-3 more!

The RS232 pak on a coco II with a ram disc makes a "real" system.  I liked
it so much that I did go out and get another RS232 pak.  But, the killer
is that only 1 pak at a time will work as an interrupt driven device.  This
is because the 6809 int line doesn't go to the multipak.  The pseudo int
line from the multipak goes to one of the control inputs on a 6821.  The
RS232 driver recognizes the int from the 6821 when the rs232 pak changes
the state of the control line.  The multipak hardware selects one of the
4 paks interrupt lines to connect to the 6821 so only one device at a
time can be active.  I shorted the int line on both slots 0 and 1 but that
still didn't work.  One RS232 causes an interrupt but the other is checked
and the system hangs solid.

There are some workarounds:

  Use the virtual interrupt driver supplied by Tandy. This gives you 300 baud
  and doesn't work much better than the bit-banger port.

  I've used the second pak just by writing a basic routine to check the state
  of the ready bit.  It works at 1200 baud but it's not near the solution I
  want for an OS9 system.

  My future plans for the second port consist of furthering my modification to
  the hardware by running the int lines of paks 0 and 1 on the multipak to the
  real interrupt line inside the coco.  Then I'll finish modifying the
  acia driver to use the real interrupt instead of messing with the 6821.
  In addition to 2 real RS232 ports I'll now be able to use the multipak
  interrupt for the speech pak.  With the additional two 6850 acia's I've
  added this'll give me 4 serial ports on the coco.

  I plan to use the coco on the modem, packet radio tnc, real 80x24 terminal
  (Heath Z89) and laptop simultaneously.  The only problem is that I can't
  put the cover on anymore.  Too many wires sticking out.


Bill Vodall

jonh@tekgen.TEK.COM (Jon Howell) (08/21/87)

In article <300004@hpfcdq.HP.COM> vodall@hpfcdq.HP.COM (Bill Vodall) writes:
>  I plan to use the coco on the modem, packet radio tnc, real 80x24 terminal
>  (Heath Z89) and laptop simultaneously.  The only problem is that I can't
Is this a CoCo 1/2 or CoCo 3?  How could you stand using a terminal when the
cc3 has such powerful (go ahead and argue, brains that be, but I am 'new' to
computing [I've only used computers for 4 yrs] and I'm impressed by the windows
and the 106 columns!) windowing capabilities?

Jon
-- 
___ __ ,  __  __   _   ,   , __  ,   , ___ __
 |  |_ |  |_ /    / \  |\ /| |_\ |   |  |  |_  |  -- It's good for your
 |  |_ |_ |_ \__  \_/  | V | |    \_/   |  |_  *     health!

vodall@hpfcdq.UUCP (08/24/87)

>>  I plan to use the coco on the modem, packet radio tnc, real 80x24 terminal
>>  (Heath Z89) and laptop simultaneously.  The only problem is that I can't
>Is this a CoCo 1/2 or CoCo 3?  How could you stand using a terminal when the
>cc3 has such powerful (go ahead and argue, brains that be, but I am 'new' to
>computing [I've only used computers for 4 yrs] and I'm impressed by the windows
>and the 106 columns!) windowing capabilities?

It's a CoCo 2...  A CoCo 3 would be nice but I'm not going to be upgrading
in that direction.  The cost is just too high.  I'd have to buy a CoCo 3
($200), 512k memory expansion ($75??),  OS9/LII ($80), color monitor ($200)
for a total of better then $550.  It would be a neat system but still just an
8 bit cpu with memory management (6809+Gime == 8088 == clogged arteries).
And this doesn't even fix the halting of the cpu when the disk is in use
or the marginal quality keyboard.

I'd really like a machine like the Coco 3 but with a 68008 instead of the
6809+Gime.  The hardware cost would be lower and a whole megabyte of
consecutive memory is available.  I'm upgrading my personal system, a
Smoke Signal Chieftain, by adding a 68008 as a third microprocessor.
(The 2nd was a Z80.)  Then I'll have the full megabyte, lots of I/O
slots and buffered disk access's.  It'll be a fairly good performer for
a minimal additional investment.

> windowing capabilities...

While I've never seen or used the windows on the CoCo 3 I do use them daily
at work.  Right now I have five 80x24 retained, overlapping, text windows on
the screen and I can create more of any size font/dimentions that I want.
It's really handy to display the equivalent of a page of paper before making
a hardcopy.  Being in the group developing software for windows on
Hewlett-Packard's HP-UX (a port of AT&T's UNIX) I do appreciate what can be
done with windows.  But, since windows are generally expensive in terms of cpu
cycles, I still prefer separate displays.  Especially on smaller processors
that have less cycles to spare.  Can the Coco 3 run 19.2Kbaud in it's windows?
My Coco II does to the remote terminal...

Bill Vodall