jgreco@csd4.milw.wisc.edu (Joe Greco) (06/01/89)
In comp.sys.cbm article <7028@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) wrote: ]in article <2451.247F6F5D@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says: ]>> From: daveh@cbmvax.UUCP (Dave Haynie) ]>> For home hacking, if it work, do it. For a commercial product, you'd ]>>better be sure it'll always work. ] ]> Like the 1700/1750 REUs, that didn't work on some C64s, eh? <grin> ] ]The 1700/1750 units are C128 products. They aren't intended for the C64, ]and in fact a 1750 has an excellent chance of turning your C64 power ]supply into a smoking pile of ash. While they _may_ work on a C64, it's ]at your own risk.... ] Gee, my supply runs three 64's with no problems.... not to mention a host of other hardware. (Turn *THAT* into a pile of ash :-) 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. Well, I explored the interface to the 64 a little. Tracing a few lines revealed that the only "special" lines the REU appears to use are BA (Bus Available), DMA (Direct Memory Access), and the I/O line which I had already dealt with. The I/O line hack definitely worked (adding a second decoder chip to decode $D5-$D7 and $D1-$D3 instead of letting phantom images reside there). Which meant that there was an "apparent" problem with either DMA or BA. I decided to play with DMA, since BA is an output signal and I could not imagine what I could try to do to it. I determined that the DMA outputs from the REU's needed to be OR'ed together, since the DMA outputs did not seem to be very tristated. I did a quick OR gate hack with small signal diodes (Radio Shack is closed at 2am), and everything seemed to work fine. But it doesn't. If you try anything "complex," it mangles it. A simple stash/fetch appears to work to either unit, but loading up something like RAMDOS fails miserably. It seems to be working ALMOST. Ideas, anyone? -- 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)
David.Johnson@f171.n221.z1.FIDONET.ORG (David Johnson) (06/02/89)
> ]at your own risk.... > ] > > Gee, my supply runs three 64's with no problems.... not > to mention a > host of other hardware. (Turn *THAT* into a pile of ash > :-) > If and when it does fail (and you are courting disaster) learn from someone with experience you may lose some ram chips and possibly a rom/pal chip! (I've lost 2 ram chips and my Fload cart due to a flaky power supply) > lines revealed that the only "special" lines the REU appears > to use > are BA (Bus Available), DMA (Direct Memory Access), and > the I/O line ... > I decided to play with DMA,... > Shack is closed at 2am), and everything seemed to work > fine. > > But it doesn't. If you try anything "complex," it mangles From the information provided in the 128 prog ref manual re: DMA access you have to be very carefull of the state of the phase clock and access the dma when the vic chip is not accessing the dma chip. There was other items re: that the dma will occur after 2 clock cycles after access. "All DMA sources must yield to the vic diring phase 0 or ba low. Maybe your problem is with phase 0 as you apparently have dealt with ba From what I've gathered by looking at the MMU map and various system maps I'm lead to believe that the C128 can access either 256/or 512 K internally. (references to bank 2/3 ram) (pla pin 27 128/256?) any ideas? Any information on the 6551 uart as was designed for use with cp/m would also be appreciated. Perhaps this is the standard that should be adopted and maybe if enough of us authors support it it may be commercially viable -- David Johnson - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!David.Johnson Internet: David.Johnson@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (06/04/89)
In comp.sys.cbm article <2482.2487586D@isishq.FIDONET.ORG>, David.Johnson@f171.n221.z1.FIDONET.ORG (David Johnson) wrote: ] > Gee, my supply runs three 64's with no problems.... not ] > to mention a ] > host of other hardware. (Turn *THAT* into a pile of ash ] > :-) ] > ] ]If and when it does fail (and you are courting disaster) learn from ]someone with experience you may lose some ram chips and possibly a ]rom/pal chip! (I've lost 2 ram chips and my Fload cart due to a flaky ]power supply) If and when it does fail, it will cost me as much to replace as the 64's.... it is kind of like putting a locomotive engine in a Volkswagen :-) I'm not talking about a flimsy regulated power supply, after all. It works, and it was more economical than buying two new bricks when two old ones went out within a day of each other. That's a typical regulated supply.... ] > lines revealed that the only "special" lines the REU appears ] > to use ] > are BA (Bus Available), DMA (Direct Memory Access), and ] > the I/O line ]... ]> I decided to play with DMA,... ] > Shack is closed at 2am), and everything seemed to work ] > fine. ] > ] > But it doesn't. If you try anything "complex," it mangles ] ]From the information provided in the 128 prog ref manual re: DMA access ]you have to be very carefull of the state of the phase clock and access ]the dma when the vic chip is not accessing the dma chip. There was ]other items re: that the dma will occur after 2 clock cycles after ]access. "All DMA sources must yield to the vic diring phase 0 or ba ]low. Maybe your problem is with phase 0 as you apparently have dealt ]with ba That could possibly be it (there is NO info out in the 64 guide, of course). So, do any geniuses have a solution? -- 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) (06/10/89)
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
jgreco@csd4.milw.wisc.edu (Joe Greco) (06/10/89)
In comp.sys.cbm article <7074@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote:
]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
The $100,000 question is: what else would you use an ML monitor
for.... heh. No, I haven't tried it. Not even interested. *MY*
software is entirely flexible in regards to REU location.
]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).
That is and yet is not the answer I wanted. You are saying that it
should work. My experience says no way Jose. :-)
I am not using that $FF00 trigger business. There may be some point
on a C128, but on a 64 it would be a half-***ed option and I can't
imagine any real use.
I cannot use IO1 because my *trusty* MSD IEEE interface resides there.
In reality, just a 6526 sitting pretty on IO1. I can reassemble my
drivers for it to work elsewhere, although it seems like unneeded
work.
Here's what I did for decoding. Electronically, I cut 1Y0 and 1Y1
(pins 4 and 5 of U15 74LS139 decoder chip for $Dxxx range) and added a
second 74LS139, duplicating the way 1Y3 goes into the second half of
the original 74LS139. 1Y0 of #1 goes to EN1 of #2, 1Y1 of #1 goes to
EN2 of #2. A8 and A9 go to both halves of #2. VIC and SID signals
are taken from 1Y0 on decoder #2 and 2Y0 on decoder #2, respectively.
Moronic Digital Electronics 101 in simplicity; I duplicated a known
solution. :-)
Electrically, I popped a socket on the motherboard. Then I took a
little prototyping board and popped three 16 pin sockets on. Decoders
in two, and a DIP ribbon cable to plug into the motherboard.
Freestyle wiring on the outboard decoder finished it off. Filter
caps, etc as needed. All very straightforward, and the 64 runs.
Remove either decoder, and it doesn't. So both are in use, and my
meter says that all the electrical seems to be cool.
So I cut off IO2 on the last slot on my 5 slot expander, and wire it
to the $D500 decoder line. Confidently, I plug in a 1750 to the 5th
slot, and a 1700 into a normal slot. I don't recall specifics, but it
didn't work. I believe it powered up, but wouldn't run a darn thing
from REU.
Then I tried the DMA line hack, as I already mentioned. It worked
*better* (I was able to mutilate data at very high speeds, but it DID
transfer!) ... then I gave up, since the only other line I saw the
REU making use of was BA ("special" lines, that is).
I cannot figure out what is the matter.
Ah well, such is life.
(Time to go check my decode circuitry, maybe?)
--
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)