history is hard (was: Microsoft open sources GWBASIC)

Guy Sotomayor ggs at shiresoft.com
Tue May 26 00:48:17 CDT 2020


On Mon, 2020-05-25 at 14:13 -0700, Fred Cisin via cctalk wrote:
> > I hadn't thought about IBMCACHE.SYS in *years*.  I wrote it in 
> > its entirety (there's even a patent that covers some of its
> operation). 
> > I was in an AdTech (Advanced Technology) group at the time and 
> > was looking at how to make disk operations faster in DOS at the
> time 
> > when I came up with the idea. There was a *huge* battle within IBM
> on if 
> > it should be released and in order to do so, it was fairly well 
> > hidden.
> 
> I think that I recall a mention of REFERENCE disk of PS/2?
> (NOT model 25 or 30, which didn't have extended memory)
> 
> 
> Can IBMCACHE co-exist with HIMEM.SYS?
> Or require it?
> Or the A20 support needed by Windows 3.10?
> When SMARTDRV was activated, did it disable IBMCACHE? or conflict
> with it?
> 

No, IBMCACHE was standalone.  As I recall (I wish I'd kept a copy of
the source), you could tell it how much (and starting address) of where
it would use memory > 1MB (I think there was also a mode that allowed
you to use it < 1MB as well).  That was done to allow for co-existence
with HIMEM.SYS.

When the write back cache was enabled (it would always allow write-
thru), in addition to intercepting INT 13 (and timer) it would also
intercept INT 21 so that if you did a "close" it would immediately
flush out the dirty buffers.

One of the differences between between IBMCACHE and SMARTDRV as I
recall (I really didn't spend too much time thinking about SMARTDRV)
was that IBMCACHE was block based versus SMARTDRV being track based. 
It allowed for much better caching (from my own analysis when I was
developing it).  It also allowed for caching blocks that had bad
sectors (which was one of the patents for IBMCACHE).

When IBMCACHE did a write out of dirty blocks they were always in
sorted order (the list of dirty blocks was kept in sorted order).  I
recall playing around with dual elevator algorithms (it knew where the
last read/write was) so it could do the writes that required the
fewest/shortest seeks.  It turned out now to be a huge win (for DOS)
versus the complexity, so I never released that.

I even had a version that cached floppies (but would *never* enable the
write-back cache for devices that it thought were removable).  If it
detected a disk change it would flush the cache for that drive.  

TTFN - Guy



More information about the cctalk mailing list