Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!fred
From: fred@cbmvax.UUCP (Fred Bowen)
Newsgroups: comp.sys.cbm
Subject: Re: REU Hacking.
Message-ID: <7074@cbmvax.UUCP>
Date: 9 Jun 89 21:30:14 GMT
References: <2451.247F6F5D@isishq.FIDONET.ORG> <7028@cbmvax.UUCP> <2720@csd4.milw.wisc.edu>
Reply-To: fred@cbmvax.UUCP (Fred Bowen)
Organization: Commodore Technology, West Chester, PA
Lines: 25

In article <2720@csd4.milw.wisc.edu> Joe Greco writes:
> A few months ago I had been discussing the feasibility of hooking up
> two REU's to a single machine (64) by remapping one unit to another I/O
> location (and not $DE00, since I need that as well).  I built the
> needed decoder to decode the entire $Dxxx region into pages, and
> hooked in a 1700 at $D500 (1750 at standard address).  It didn't work,
> it strangled any data stored or fetched.  Not only that, but it was
> nasty about it.   [...]   A simple stash/fetch appears to work to either
> unit, but loading up something like RAMDOS fails miserably.

It is possible (meaning, I have done it) to modify an REU by moving its
select from IO2 to IO1 (simple cut and jumper).  It works fine as you indicate,
even works with the RAMDOS after I re-assemble the RAMDOS to change the REU's
DMA controller address (an option you obviously could not attempt :-).  I have
not modified the REU to work with *two* drives though.  Of course, you cannot
preconfigure both REU's to trigger when $FF00 is addressed, simultaneously.  I
think this is probably what happened to you, otherwise I don't see what the
problem is (assuming your decode circuitry is correct).
--
-- 
Fred Bowen			uucp:	{uunet|rutgers|pyramid}!cbmvax!fred
				arpa:	cbmvax!fred@uunet.uu.net
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380