luce@aurs01.UUCP (J. Luce) (04/30/91)
I just purchased a used SFD1001 and a Quicksiver 128 IEEE interface. Can
anyone tell me what the dipswitch settings are on the 4-switch DIP? All
I know is that as it now sits, the SFD1001 is seen as Device 8.
Also, there is 1 barnacle underneath and the a wired 'clip' to one of
the pins at the female end of the cartridge port extender. What is that
for and does it affect the 64 or 128 usage?
I also understand that there was software that came with it originally.
Anyone got the disk?
Thanks.
-------------------------------------------------------------------
John Luce | Life is the leading cause of death
Alcatel Network Systems | -----------------------------------------
Raleigh, NC | Standard Disclaimer Applies
919-850-6787 | Mail? Here? Try aurs01!aurw46!luce@mcnc.org
| or ...!mcnc!aurgate!luce
-------------------------------- or John.Luce@f130.n151.z1.fidonet.org desimone@cse.uta.edu (David Desimone) (05/01/91)
In article <59771@aurs01.UUCP> luce@aurw46.UUCP (J. Luce) writes: >I just purchased a used SFD1001 and a Quicksiver 128 IEEE interface. Can >anyone tell me what the dipswitch settings are on the 4-switch DIP? All >I know is that as it now sits, the SFD1001 is seen as Device 8. My information comes from using the IEEE Flash! from Skyles, but there are many similarities between them. The first switch is an on/off switch. When the switch is off, the entire interface board is disabled. You must turn it on to access the IEEE bus at all. On the C64, this controls whether the new Kernal ROM is switched in, but the C128 adds its own ROM, so this switch may have no effect in C128 mode. The other three switches change which references to drive numbers are channelled through the serial bus, and which are channelled through the IEEE bus. Such as: Switch 2: ON, device 8 is IEEE, OFF, device 8 is SERIAL. Switch 3: ON, devices 9 and 10 are IEEE, OFF, devices 9 and 10 are SERIAL. Switch 4: On, device 4 is IEEE, OFF, device 4 is SERIAL. (Printer!) I may have some of these switches in the wrong order, but a little experimenting should sort it out. I believe the interface board causes references above device 12 to ALWAYS be on the IEEE bus, but that doesn't happen very often anyway. >Also, there is 1 barnacle underneath and the a wired 'clip' to one of >the pins at the female end of the cartridge port extender. What is that >for and does it affect the 64 or 128 usage? The clip is required in order to swap the internal ROM with the C64 ROM. It does not affect C128 usage as far as I know, since that ROM is already in the machine at all times. It also prevents you from easily unplugging the thing, which is annoying. >I also understand that there was software that came with it originally. >Anyone got the disk? My IEEE Flash! came with no software, just the board and instructions. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
treesh@vangogh.helios.nd.edu (05/01/91)
The quick Silver IEEE has 4 switches on it. The frist switch is for directing the device 8 data flow, either to IEEE bus or serial bus. The 2nd switch is for device 9 and 10, they are ganged together. The last switch is for device 4 (for an IEEE printer?). ctfm
luce@aurs01.UUCP (J. Luce) (05/02/91)
In article <1991May1.050128.26834@cse.uta.edu> desimone@cse.uta.edu (David Desimone) writes: -In article <59771@aurs01.UUCP> luce@aurw46.UUCP (J. Luce) writes: ->I just purchased a used SFD1001 and a Quicksiver 128 IEEE interface. Can ->Also, there is 1 barnacle underneath and the a wired 'clip' to one of ->the pins at the female end of the cartridge port extender. What is that ->for and does it affect the 64 or 128 usage? - -The clip is required in order to swap the internal ROM with the C64 ROM. -It does not affect C128 usage as far as I know, since that ROM is -already in the machine at all times. It also prevents you from easily -unplugging the thing, which is annoying. - --- -David DeSimone, aka "Fuzzy Fox" on some networks. /!/! -INET: an207@cleveland.freenet.edu / .. -Q-Link: Fuzzy Fox / --* -Quote: "Foxes are people too! And vice versa." / --- Bzzzzz!Timeout! What do you mean by the 'ROM is already in the machine'? I got no ROM with this (how does one get into the little black box surrounding the midsection of the QS128?)... do I need to call Sykes? If so, what's their phone number? Thanks... ------------------------------------------------------------------- John Luce | Life is the leading cause of death Alcatel Network Systems | ----------------------------------------- Raleigh, NC | Standard Disclaimer Applies 919-850-6787 | Mail? Here? Try aurs01!aurw46!luce@mcnc.org | or ...!mcnc!aurgate!luce -------------------------------- or John.Luce@f130.n151.z1.fidonet.org
desimone@cse.uta.edu (Fuzzy Fox) (05/02/91)
In article <59780@aurs01.UUCP> luce@aurw46.UUCP (J. Luce) writes: >Bzzzzz!Timeout! What do you mean by the 'ROM is already in the machine'? > >I got no ROM with this (how does one get into the little black box >surrounding the midsection of the QS128?)... do I need to call Sykes? If >so, what's their phone number? As I said, my information is somewhat guesswork, since I don't have the 128 version of this hardware, only the 64 version. I had heard somewhere that the Quicksilver comes with a ROM which plugs into the extra ROM socket on the 128. This could be wrong though. If you plug in your SFD and are able to access it in C128 mode with no trouble, then by all means, ignore me. :) -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
root@zswamp.uucp (Geoffrey Welsh) (05/03/91)
In a letter to All, J. Luce (luce@aurs01.UUCP ) wrote: >-The clip is required in order to swap the internal ROM with >the C64 ROM. >-It does not affect C128 usage as far as I know, since that >ROM is >-already in the machine at all times. >Bzzzzz!Timeout! What do you mean by the 'ROM is already in >the machine'? >I got no ROM with this (how does one get into the little >black box >surrounding the midsection of the QS128?)... do I need to >call Sykes? If >so, what's their phone number? Perhaps I should explain why the wire is needed for the 64 in the first place. 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. 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. -- 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
neusoft@vax1.mankato.msus.edu (05/10/91)
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
root@zswamp.uucp (Geoffrey Welsh) (05/13/91)
>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
treesh@vangogh.helios.nd.edu (05/18/91)
The QS 128 comes with a ROM chip, but the IEEE FLASH does not (for the 128). Both products are the same, they both contain a 6522 CIA buss controller, some other small chip I think, and a IEEE FLASH ROM for the C64, or C128 in 64 mode. If you have the QS128 product, it comes with an extra ROM chip that plugs into your C128 computer. It does not go into the extra sockette, but rather replaces the kernal rom that is already in there, so you need to pull it out and put this new one in. This new rom allows for the 128 mode to see and use the IEEE buss. The frist swtich on the unit has no effect at all in C128 mode, and there really is no way to "disable" the unit, however I have found that in 128 mode there really is no reason to at all. Unlike FLASH mode of 64, the QS128 driver software sits WAY-UP in rom memory, way out of the way of anything else that might be going on in the computers memory (At least in my expirence) Switching off the DEVICE 8 and DEVICE 9&10 switches to all serial mode acutal just like a device disable for 128 mode. It so compatable that I even think you can still use your cassette drive in 128 mode with the think active in IEEE mode. (God only knows why anyone would want to?) The clip has no real pourpose in 128 mode, but it still is a good idea to install it onto that one pin of the PLA chip. This is so that 64 mode can maintain its sort-of-compatablity with the IEEE buss rom (FLASH). I have found ZERO conflits in 128 mode, but, in 64 mode, the IEEE FLASH has cause a lot of trouble wiith most ternialal software. ctfm