Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!gacvx2.gac.edu!vax1.mankato.msus.edu!neusoft
From: neusoft@vax1.mankato.msus.edu
Newsgroups: comp.sys.cbm
Subject: Re: QuickSilver 128
Message-ID: <1991May9.213134.550@vax1.mankato.msus.edu>
Date: 10 May 91 03:31:34 GMT
References: <14.2824F701@zswamp.uucp>
Organization: Mankato State University
Lines: 71

Well, I'll give it a shot...I don't have a IEEE interface, but I do know a fair
amount about the signals at expansion port...

>    The C64 wedge works by "replacing" the internal C64 Kernal ROM - or, at 
> least, part of it, with an external ROM which knows how to access the IEEE 
> I/O ports.  In order to do this, the external cartridge decodes the address 
> lines and, if it decides that the CPU is talking to the ROM, it will assert 
> the -GAME line on the cartridge port, reconfiguring the 64 as a MAX machine 
> (in which mode, the 8K at $E000-$FFFF is replaced by an external ROM).  This 
> permits an external cartridge to override the Kernal ROM whenever it wants to 
> by switching into and out of MAX mode.
>
>    This is all fine & dandy, but there's a hitch: the cartridge asserts the 
> GAME line based on the values of the address lines only; it doesn't know 
> whather it's overriding the Kernal ROM or the RAM underneath it (which is 
> banked in by the HIROM line, conmtrolled by the I/O port on the 6510).  This 
> is a real problem for software which uses that upper 8K of RAM, such as 
> PaperClip, because suddenly there's a "hole" in the RAM where the external 
> cartridge overrides what it thinks is Kernal ROM.
> 
>    The clip is meant to be attached to the 6510 CPU or 82100 PLA and feed the 
> HIRAM signal out to the cartridge; a low on that line would indicate 
> that RAM is banked in and prevent the cartridge from overriding it.
> 

This whole operation seems a bit silly...yes, I agree that it would have to
assert the GAME line, but your meathod seems a bit strange (but I'm not saying
your wrong...it just seems alot more complicated than it has to be).  First, if
the GAME line is pulled low (by some external device), there is allready a chip
select line available at the port (labled RAMHI).  I guess I'm not real sure,
but I would think this would take into account the condition of the 6510's
HIROM signal.  Also, why would it only be asserted at certain times???  If
thats is whats going on, a more likely solution is to have a small section of 
the ROM is mapped into the I/O space at $DE00-DFFF.  The I/O vectors point to
this area so than when an I/O operation is decoded, the routines here decide
weather  or not the IEEE needs to be used, and at this point, assert the GAME
and make the approprate jump.

>    That explains why we need the clip for C64 mode, but it doesn't explain 
> why we don't for C128 mode... to tell you the truth, I'm not sure why it 
> wouldn't be needed (RTC's IEEE 128 adapter for its C64-Link II actually has 
> *more* clips...) but I suspect that the cartridge could program the MMU 
> however it pleases so that it doesn't have to pull stunts like the C64 
> cartridge does...
> 
>    Matt (who's on the phone as I type) also agrees that a well-designed 128 
> cartridge should be able to program its way through, rather than use the
> brute force.

This is true, in fact, the 128 has a much better meathod of addressing external
ROMS.  Rather than asserting signals at the back of the port, the C128 goes
through a 'poling' process at power up.  Because the MMU has enough address
space, the C128 also assumes that the ROMS are always present, and in fact a
total of four 32K ROMS can be accessed--two from the interal "empty socets" and
another two from the expansion port.  More than likely, the ROM on the C128
IEEE port maps itself into bank 8 (or 9) at either $8000-$BFFF or $C000-$FFFF. 
Again, the ROM can be selected by the ROMLO or ROMHI lines respectively.  The
poling process mensioned above looks at each of these spaces for a special code
(similar to the 64's autostart signature), assignes a priority (to resolve
confilicts) an begins to execute the program in ROM after reset if it is an
autostart device.  Now, the same procecdure for an IEEE device access can be
used for the C64 with very little modification (in fact, the same 32K ROM could
hold both the 128 and 64 code!).  If an I/O function is called, the external
ROMS are called first, and if the operation is a serial device, the standard
ROMS are used, otherwise, the modified IEEE roms are used.

There.  I feel much better knowing that I lossed a few people, but it had to be
done :) .

-Mike
neusoft@vax1.mankato.msus.edu