jgreco@csd4.milw.wisc.edu (Joe Greco) (01/21/89)
Has anyone managed to run two 1750's on a 64? Let me back up and describe a scenario: My system has a 1750 and MSD IEEE interface. I used to use the 1750 for a RAMdisk, but have since needed to use it for data storage (swapping). RAMDOS will not coexist, and there wouldn't be enough room anyways. What I want to do is to remap the 1750 someplace else in the $Dxxx range, and put another 1750 in running with RAMDOS to provide RAMdisk access. Breaking down the $D000 block isn't hard, it's just a matter of pulling thE 74LS239 and adding a second one to decode all 16 256 byte pages in the region. Then use one of the select lines to select the "swapping" 1750. 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? . JG -- 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)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (01/23/89)
> 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. 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). I would think that you're stuck with the two I/O blocks at $DE00 and $DF00. There are ways to squeeze more than one device into such a block (the BusCard II did, and I'd be glad to tell you how if you need the info). 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 1764. If not, and you haven't built a hefty supply yourself, you may be in for some trouble. 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. =========================================================================== Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | 66 Mooregate Crescent Usenet: watmath!isishq!izot | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/Geoffrey Welsh | N2M 5E6 CANADA BBS: (519) 742-8939 24h 7d 300/1200/2400bps | (519) 741-9553 =========================================================================== | "I don't need a disclaimer. No one pays any attention to what I say." | =========================================================================== -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
fred@cbmvax.UUCP (Fred Bowen) (01/24/89)
In article <503@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >Has anyone managed to run two 1750's on a 64? >Breaking down the $D000 block isn't hard, it's just a matter of >pulling thE 74LS239 and adding a second one to decode all 16 256 byte >pages in the region. Then use one of the select lines to select the >"swapping" 1750. Probably it would be easier just to select the second REU by hanging it off the IO-1 select instead of the IO-2 select. As long as you have enough power and do not "prime" the DMA's in both to respond to the $FF00 trigger option simultaneously they should work. Of course, you'd have to provide your own software, since existing software will address the REU at $DF00 only. >My system has a 1750 and MSD IEEE interface. I used to use the 1750 >for a RAMdisk, but have since needed to use it for data storage >(swapping). RAMDOS will not coexist [...] The amount of available expansion RAM aside, in the latest TC128 magazine (is it out yet?) I describe a simple patch to the RAMdisk which allows you to "partition" the REU, allocating the lower banks for the RAMdisk and leaving the upper banks available for your own application. I also provide a simple patch to BASIC-8 to make it compatible with the RAMdisk. -- -- 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
jgreco@csd4.milw.wisc.edu (Joe Greco) (01/24/89)
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)
jgreco@csd4.milw.wisc.edu (Joe Greco) (01/24/89)
In article <5760@cbmvax.UUCP> fred@cbmvax.UUCP (Fred Bowen) writes: >In article <503@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: > Probably it would be easier just to select the second REU by hanging > it off the IO-1 select instead of the IO-2 select. As long as you > have enough power and do not "prime" the DMA's in both to respond to > the $FF00 trigger option simultaneously they should work. Of course, > you'd have to provide your own software, since existing software will > address the REU at $DF00 only. That works fine 'till you have several devices demanding I/O pages. I decided that the actual work involved in pulling the 74LSxxx and doing the described modification was less than would be involved in attempting further decoding within I/O1 and I/O2. Please note that I haven't done it.... I don't HAVE the second RAM expander (but I do have plenty of space for it). Part of the problem is that my software could already use more RAM than it has access to (used to store massive amounts of data and indexes). :>My system has a 1750 and MSD IEEE interface. I used to use the 1750 :>for a RAMdisk, but have since needed to use it for data storage :>(swapping). RAMDOS will not coexist [...] > > The amount of available expansion RAM aside, in the latest TC128 > magazine (is it out yet?) I describe a simple patch to the RAMdisk > which allows you to "partition" the REU, allocating the lower banks > for the RAMdisk and leaving the upper banks available for your own > application. I also provide a simple patch to BASIC-8 to make it > compatible with the RAMdisk. Well I wish I had known that six months ago, when I had to kill the RAMdisk and use the 1750 for data storage! :-) That's exactly what I wanted back then (now I'm not sure the storage provided by a 1750 would be enough for all the stuff I need to store on a RAMdisk). All of this aside, is Commodore still producing the 1750? I have NOT seen any for sale as of late, and I'm not too anxious to hack a 1764 up to a 1750. On a similar note. I finally got my December Transactor. Has anyone tried the expand-your-64-to-256K project? It sounds reasonable. -- 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)
fred@cbmvax.UUCP (Fred Bowen) (01/25/89)
In article <532@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) asks: >All of this aside, is Commodore still producing the 1750? I have NOT >seen any for sale as of late, and I'm not too anxious to hack a 1764 The RAM expanders (1764 and 1750 at least) are still being carried- but you have to hunt for them. A shipment went out around Christmas time to dealers & distributors; I imagine they did not last long on the shelves. Apparently the problem is 256K DRAMs, used in quite a few small systems and peripherals. >On a similar note. I finally got my December Transactor. Didn't get one :-( (received some Amiga Transactors though...). -- -- 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