Path: utzoo!utgpu!watserv1!maytag!xenitec!zswamp!root
From: root@zswamp.uucp (Geoffrey Welsh)
Newsgroups: comp.sys.cbm
Subject: Re: QuickSilver 128
Message-ID: <50.282E8E8B@zswamp.uucp>
Date: Mon, 13 May 91 00:21:59 EST
Organization: Izot's Swamp BBS (FidoNet), Kitchener, Ontario

 >From: neusoft@vax1.mankato.msus.edu

 >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...

> [my description of the BusCard II's hardware operation deleted]

 >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.

   That *would* make sense, but the PRG labels it "-ROMH: 8K decoded RAM/ROM 
block @ $E000", suggesting to me that it does *not* take into account the 
state of the HIRAM signal.

 >Also, why would it only be asserted at certain times???

   You mean, the -GAME line?  If you want to replace the whole 8K Kernal ROM, 
you can feed the -ROMH output back into the -GAME input, but why bother 
putting a whole 2764 on the board when you can get away with a 2716 
overwriting only 2K of the Kernal ROM?  Remember that the thing was designed 
in the days when 64 kbit EPROMs were significantly more expensive.

 >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.

   You're missing the whole point here: the idea is to remain *invisible* and 
*compatible*.  In order to do that, you've got to wedge into existing serial 
bus routines, and that's simply not possible to do without overwriting the 
Kernal ROM.

   In addition, the BusCard uses only the space that it absolutely must at the 
top of the I/O 2 space ($DF00), and (I believe) doesn't pass the I/O2 signal 
through if the BusCard devices are addressed (i.e. it fully decodes the 
address).  This should permit other devices which use the $DF00 block to use 
it as long as the device doesn't need the whole page.  (Lots of devices 
*appear* to fill the page by not fully decoding their addresses; most of the 
space is taken by 'images' of the devices, which are not necessary and should 
not be addressed directly).

 >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.

   (in case you missed this point from the above paragraphs)

 ... but what causes that code to be executed?

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

   Your C128 ROM control ideas are interesting.  I've never tried 128 
cartridge port hardware, so I have no idea if your plan would work.
 

--  
Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171)
root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root
602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553
"He who claims to know everything can't possibly know much" -me