Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!husc6!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: Re: Ambitious RAM Expansion Hacking
Message-ID: <531@csd4.milw.wisc.edu>
Date: 23 Jan 89 17:21:11 GMT
References: <1287.23DA03C5@isishq.FIDONET.ORG>
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: UW-Milwaukee Home for Out-of-date 8 bit Hackers
Lines: 73

In article <1287.23DA03C5@isishq.FIDONET.ORG> izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) writes:
>
> > My question is this:  Has anyone done it?  The REU uses some system
> > control lines that I have relatively little experience with (DMA, for
> > instance) and I don't know whether or not they would coexist
> > peacefully.  I don't see why not, but has anyone done it?
> 
>   REU DMA shuts down the CPU and reads/writes absolute addresses set in its 
>registers. Where in C64 memory the REU controller is mapped shouldn't have any 
>effect on the DMA.

Except that I don't know what the effect of having multiple DMA
devices online at once might be!

>   Your main problem may be driving conflicts with existing internal I/O 
>devices. The C64 PRG, for instance, says that $D500 - $D7FF contain SID 
>images; if you map the REU controller there, you'll end up generating 
>conflicts between the drivers on those two devices when reading that address 
>range. The PRG doesn't mention if the VIC-II has the same imaging at 
>$D100-$D3FF, but I suspect it would. (Fred, this would be a good time to 
>reveal the truth table for the address decoder PLA, please).

The PLA has nothing to do with it... the PLA decodes the signal to the
$D000-$DFFF region and that's the extent of PLA decoding.  From that
point, as I explained in original post, it is broken down by a 74LSxxx
chip.  One half breaks it down into four 1K regions, and the other
half breaks down the last 1K region ($DC00-$DFFF) into four 256 byte regions.

PLA ---- +-----------+ ---- $D000 (VIC)
A10 ---- |1/2 74LSxxx| ---- $D400 (SID)
A11 ---- |decoder    | ---- $D800 (Video Color RAM)
	 +-----------+ ---\
			   \
			    \--- +-----------+ ---- $DC00 (CIA #1)
			 A8 ---- |1/2 74LSxxx| ---- $DD00 (CIA #2)
			 A9 ---- |decoder    | ---- $DE00 (I/O exp 1)
				 +-----------+ ---- $DF00 (I/O exp 2)

So the idea is that the first one breaks down a 4K chunk, and the
second one breaks down a broken down 1K chunk into 256 byte chunks.
This has been done from memory (I'm at school), so please forgive any
errors and assume I know what I'm talking about.

What I propose is to add another 74LSxxx decoder, and cut the first
two outputs of the first 74LSxxx.  So I would route the $D000 and
$D400 signals into a 74LSxxx, split each of those 1K regions into 256
byte regions, and I would gain I/O blocks (OPEN) at $D100, $D200,
$D300, $D500, $D600, and $D700.

This is what my original article said, in short.

>   Your other worry is power. Since you're using 1750's, I can only hope that 
>you got the "C128-power-supply-with-a-C64-connector-on-it" that comes with the 

Me?  Use that piece of junk?

>1764. If not, and you haven't built a hefty supply yourself, you may be in for 
>some trouble.

My supply drives four C64's.  Easily. ('nuff said)

>   While looking through the REU DMAC specs, I noticed that there's a byte to 
>control which bank of 64K the DMAC moves the data to/from. I wonder if some 
>sort of external latch for bit 3 could be used to enable/disable complementary 
>1750's and thus give an effective 1 megabyte REU.

Very messy sounding.

--
jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
	West Allis, WI  53227-3329	"These aren't anybody's opinions."
Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)