alex.burger@canremote.uucp (ALEX BURGER) (06/14/89)
Has anyone firgured out how to use the 1750 REU, and lets say FASTLOAD! at the same time? If they can hook up two REUs at the same time, then I imagine that this is possible. Alex Burger --- * Via ProDoor 2.9a
jgreco@csd4.milw.wisc.edu (Joe Greco) (06/21/89)
In comp.sys.cbm article <89061907384920@masnet.uucp>, alex.burger@canremote.uucp (ALEX BURGER) wrote: ] ]Has anyone firgured out how to use the 1750 REU, and lets say FASTLOAD! ]at the same time? ] ]If they can hook up two REUs at the same time, then I imagine that this ]is possible. WHO'S figured out how to hook up two REU's at the same time? SOMEONE PLEASE TELL ME! :-) -- 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/21/89)
In article <3028@csd4.milw.wisc.edu> (Joe Greco) writes: >In comp.sys.cbm article <89061907384920@masnet.uucp>, (ALEX BURGER) wrote: >] >]Has anyone firgured out how to use the 1750 REU, and lets say FASTLOAD! >]at the same time? >] >]If they can hook up two REUs at the same time, then I imagine that this >]is possible. > >WHO'S figured out how to hook up two REU's at the same time? SOMEONE >PLEASE TELL ME! :-) Sorry, I thought I did tell you :-) While your special decoding looks fine to me (what do I know- I'm not a hardware type), my simple modification of the chip select (from IO2 to IO1) works. I don't believe there is anything particularly unique about the IO1/IO2 timing. If I had the time, I would duplicate your decoder hardware and try it. The only other difference between your setup and mine is the computer- I use a C128, you use a C64. I trust you have modified the 1700/1750 C128-compatible REUs to work properly on your C64. If your software is so flexible that it works wherever the REU is located, I trust your software for the MSD cartridge is too- move it to your newly decoded region :-) Perhaps the additional TTL delay you introduced is the culprit. The scheme I used has worked for others. One word of warning- the power supply is a real issue, so folks who have not beefed up their power supply as Joe has should not attempt this, particularly on a C64. -- -- 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/22/89)
In comp.sys.cbm article <7107@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote:
]In article <3028@csd4.milw.wisc.edu> (Joe Greco) writes:
[...]
]>WHO'S figured out how to hook up two REU's at the same time? SOMEONE
]>PLEASE TELL ME! :-)
]
]Sorry, I thought I did tell you :-) While your special decoding looks fine
]to me (what do I know- I'm not a hardware type), my simple modification of
]the chip select (from IO2 to IO1) works. I don't believe there is anything
]particularly unique about the IO1/IO2 timing. If I had the time, I would
]duplicate your decoder hardware and try it. The only other difference
]between your setup and mine is the computer- I use a C128, you use a C64.
]I trust you have modified the 1700/1750 C128-compatible REUs to work properly
]on your C64.
I've never HAD any problems running 128 REU's on my machines. You
know the saying, if it isn't broke- don't fix it!
There's nothing abnormal about IO block timing that I am aware of
(more in a minute on that).
]If your software is so flexible that it works wherever the REU is located,
]I trust your software for the MSD cartridge is too- move it to your newly
]decoded region :-) Perhaps the additional TTL delay you introduced is the
]culprit.
"My" software for the MSD is actually a rehash of MSD's own code (the
darn thing's EPROM blew up one day). Still, it wouldn't be hard to
relocate. But: There *IS* no additional TTL delay, if you understand how
my decoding works. IO1 and IO2 go through two 74LS139 decoders, my
new IO blocks also do. The circuitry and timing are identical, with
the possible exception of a one foot ribbon cable I introduced into
the works. That isn't it, as ONE REU works all by itself.
Actually, I designed my software to work with "several" REU's if need
be, each type of data I am working with can be made to run off of a
different REU address. Assemblers make the world go 'round.... That
was easy. The tri-byte arithmetic was a little more painful and
memory consuming. (Joe begins to appreciate 16-bit processors :-)
]The scheme I used has worked for others. One word of warning- the power
]supply is a real issue, so folks who have not beefed up their power supply
]as Joe has should not attempt this, particularly on a C64.
But, still, did you run two REU's or were you just relocating ONE?
That is the $1,000,000.00 question.
And yes, children, don't try this at home unless you have a power
supply rated at SEVERAL amps (even the 1764's might be stressed by
these kind of shenanigans) :-) :-) :-) :-) :-)
******
**********
************
** ** **
** (FOOM!)
* ** *
***********
+---------+
! Ye Olde ! Don't let this happen to everyone's favorite
! C64 ! brick power supply. hehe
! Supply !
+---------+
--
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/22/89)
In article <3041@csd4.milw.wisc.edu> Joe Greco writes: >In comp.sys.cbm article <7107@cbmvax.UUCP> Fred Bowen wrote: > >] I trust you have modified the 1700/1750 C128-compatible REUs to work properly >] on your C64. > >I've never HAD any problems running 128 REU's on my machines. You >know the saying, if it isn't broke- don't fix it! This is not a will work / won't work thing- there are really close timing factors involved. It also depends upon the vintage of your C64. > [...] But: There *IS* no additional TTL delay, if you understand how >my decoding works. IO1 and IO2 go through two 74LS139 decoders, my >new IO blocks also do. The circuitry and timing are identical, with >the possible exception of a one foot ribbon cable I introduced into >the works. That isn't it, as ONE REU works all by itself. Right you are- I apologize for not looking more closely. The ribbon cable is still a bad idea timing-wise. Although I'm sure what the situation is, you have not made things clear: When both REUs are connected, do they both fail to work? If not, which one works? When only one REU is connected to the ribbon cable, does it work? Just for the heck of it, try 'em without the ribbon cable, and without the resistor at R4. >But, still, did you run two REU's or were you just relocating ONE? >That is the $1,000,000.00 question. Gee, the price keeps going up :-) Okay- I have both REUs connected and functioning properly (pay up :-). Perhaps your C64 is old enough that you are hosed. Perhaps there is some loading problem hanging all that stuff off the dot clock. Perhaps I'm out of ideas. I suggest we continue this discussion via email. -- 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/24/89)
In comp.sys.cbm article <7116@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote:
]In article <3041@csd4.milw.wisc.edu> Joe Greco writes:
]>I've never HAD any problems running 128 REU's on my machines. You
]>know the saying, if it isn't broke- don't fix it!
]
] This is not a will work / won't work thing- there are
] really close timing factors involved. It also depends
] upon the vintage of your C64.
So, what is the "fix" and what versions of the REU and C64 require it?
I have a C1700 REU Assy 311751 Fab 311753 with an older DIP style 8725 (R1).
C1750 REU Assy 312533 Fab 312535 with a newer "square" 8726 (R1).
Not sure if that first one is an 8725 or 8726...?
The C64 is (C)1984 Assy 250425 with an (R8) VIC and (R1) PAL chip.
Hope that's enough to indicate just how vintage it is or isn't.
]> [...] But: There *IS* no additional TTL delay, if you understand how
]>my decoding works. IO1 and IO2 go through two 74LS139 decoders, my
]>new IO blocks also do. The circuitry and timing are identical, with
]>the possible exception of a one foot ribbon cable I introduced into
]>the works. That isn't it, as ONE REU works all by itself.
]
] Right you are- I apologize for not looking more closely.
] The ribbon cable is still a bad idea timing-wise. Although
] I'm sure what the situation is, you have not made things
It was the easiest way to interface the "daughterboard" decoder. I
could probably get it to sit right ON the 64 motherboard, though.
] clear: When both REUs are connected, do they both fail to work?
Both fail to work. At least, my observation was that the relocated
1700 at $D500 mutilated data, and a copy of RAMDOS that usually worked
fine wouldn't load into the 1750 at $DF00. I didn't bother to see
what the one at $DF00 was doing - it seemed apparent enough that
neither was working too swiftly.
] If not, which one works? When only one REU is connected to the
] ribbon cable, does it work? Just for the heck of it, try 'em
] without the ribbon cable, and without the resistor at R4.
The 1750 at $DF00 is working like a charm, with the entire decoder in
place. What is the "the resistor at R4" supposed to mean? The C64's
R4 is in the cassette circuitry, and I don't see a marked R4 on the
1700 (one unmarked resistor could be it, though).
]>But, still, did you run two REU's or were you just relocating ONE?
]>That is the $1,000,000.00 question.
]
] Gee, the price keeps going up :-) Okay- I have both REUs
] connected and functioning properly (pay up :-). Perhaps your
] C64 is old enough that you are hosed. Perhaps there is some
] loading problem hanging all that stuff off the dot clock.
Ah he**, I don't have the equipment or experience to mess with loading
problems and anything else less-than-obvious.
] Perhaps I'm out of ideas. I suggest we continue this discussion
] via email.
Okay, I think I'll take my wonderful BBS down and mess with it some
more tonight. If you have got it working, that leaves some hope - and
that was the answer I wanted, that SOMEBODY had got it to work!
Thanks for your time and trouble in this, I will scream and moan after
I try some other things and they don't work. :-)
--
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/30/89)
In article <3085@csd4.milw.wisc.edu> Joe Greco writes: >In comp.sys.cbm article <7116@cbmvax.UUCP> Fred Bowen wrote: > >I have a C1700 REU Assy 311751 Fab 311753 with an older DIP style 8725 (R1). > C1750 REU Assy 312533 Fab 312535 with a newer "square" 8726 (R1). >Not sure if that first one is an 8725 or 8726...? Both are 8726, and they function identically. >Ah he**, I don't have the equipment or experience to mess with loading >problems and anything else less-than-obvious. I suspect the *DMA line is the problem. I buffered it with a 7407: pin 1 connects to REU#1 *DMA pin pin 2 connects to expansion port pin 13 pin 3 connects to REU#2 *DMA pin pin 4 connects to expansion port pin 13 pin 7 ground pin 14 +5 In article <3129@csd4.milw.wisc.edu> Joe Greco writes: >In comp.sys.cbm article <382@hal.UUCP> Howard Hermann wrote: > >]Joe, If you finally get those two cartridges up and running, I am certain >]a lot of us less technically minded, but otherwise willing souls would like >]to hear from you as to "how-to-do-it". > >*MY* experience has been no-go. I was unable to get a 1700/1750 to >work, and I also experimented with a 1750/1750. Same damn results. > >Now if fred@cbmvax would share his "partitioning" hacks to RAMDOS, I >do believe I could live. Try the above, it works for me. If it works for you, I'd like to hear about it. I'll take all the credit I can get, but I won't be responsible for anything bad resulting from this information :-). As for partitioning, I described that in TC128 issue #23. I hope Loren does not mind if I "share" it with you now. This is only part of the article, which includes a RAMDOS install program which does the partitioning. Enjoy. Partitioning the RAMdisk If you can live with a few limitations, it is possible to fool the RAMdisk into believing it has fewer 64K RAM banks than it actually has. When the RAMdisk is installed, one of the very first things it does is "sniff" the REU to determine how big it is. A simple patch to this routine allows you to specify the number of banks the "sniff" routine "discovers". Any memory banks above this number are then free to use for non-RAMdisk purposes. I have re-written the RAMDOS.BAS program which installs the RAMdisk. This version will ask if you want to partition the RAMdisk, and it works on either C128 or C64 systems using RAMDOS version 4.x. 10 REM F$="RAMDOS.BAS":OPEN1,8,15,"S0:"+F$:CLOSE1:SAVEF$,8 20 IF P THEN 100 30 PRINT"<clr>"; 40 PRINT"----------------------------------- 50 PRINT"| RAM DISK INSTALLATION - V112188 | 60 PRINT"-----------------------------------":PRINT 70 : 100 U=9: GOSUB 9000: IF R THEN 440 110 INPUT "INSTALL RAM DISK AS UNIT 9<3 cursor lefts>";U 120 : U=INT(U): IF U<4 OR U>30 THEN 110 130 PRINT "RAM DISK INTERFACE PAGE IS ";P;LEFT$("<6 cursor lefts>",L);: INPUT A 140 : IF F=0 AND (A<2 OR A>207) THEN 130 150 : IF F=1 AND (A<2 OR A>32) THEN 130 160 : P=A 170 IF NB=0 THEN 230 180 : A$="Y": INPUT "PARTITION RAM EXPANDER Y<3 cursor lefts>";A$ 190 : IF LEFT$(A$,1)<>"Y" THEN 230 200 : PB=INT(NB/2):PRINT" NUMBER OF BANKS FOR DISK ";PB;"<4 lefts>";:INPUTPB 210 : IF PB>NB OR PB<1 THEN 200 220 : IF F=0 THEN POKESN+3,PB: POKESN+4,76: POKESN+5,134: POKESN+6,126 225 : IF F=1 THEN POKESN+3,PB: POKESN+4,76: POKESN+5,184: POKESN+6,62 230 A$="Y": INPUT "INITIALIZE RAM DISK Y<3 cursor lefts>";A$ 240 : M=3: IF LEFT$(A$,1)="Y" THEN M=0 250 : 260 IF (F=0 AND P=207) OR (F=1 AND P=14) OR (F=1 AND P=8) THEN 290 270 : A$="N": INPUT "<down>CHECK INTERFACE PAGE: ARE YOU SURE N<3 lefts>";A$ 280 : IF LEFT$(A$,1)<>"Y" THEN 30 290 : 300 REM C128 C64 WHAT IT DO 310 REM $2300 $6300 --> INSTALL RAM DISK 320 REM 3 3 --> RE-INSTALL RAM DISK 330 REM 6 6 --> INSTALL RAM DISK W/ ARG: UNIT=.A PAGE=.X 340 REM 9 9 --> RE-INSTALL RAM DISK W/ ARG: UNIT=.A PAGE=.X 350 REM C C --> DISPLAY COPYRIGHT NOTICE 360 : 370 : 390 POKE RE,U: POKE RE+1,P :REM LDA UNIT: LDX PAGE 400 SYS ML+6+M :REM (RE)INSTALL RAMDISK, USING UNIT# & PAGE 410 : 420 IF F=1 THEN PRINT: DIRECTORY U(U): GRAPHICCLR 430 PRINT 440 PRINT "<down>PRESS ANY KEY TO RETURN TO MENU" 450 GETA$:IFA$=""THEN450 460 LOAD "STARTUP.*",8 :REM GOODBYE 470 : 9000 REM VERIFY PRESENCE OF RAM CARD 9010 : 9015 IF P THEN 9180 9020 R=57088 9030 FORI=2TO5:POKER+I,I:NEXT 9040 FORI=2TO5:IFPEEK(R+I)<>ITHEN9060 9050 NEXT: R=0 9060 IF R>0 THEN PRINT "<down><rvs> RAM EXPANDER NOT PRESENT ": RETURN 9070 : 9080 REM DETERMINE IF C64 OR C128 9090 : 9100 SYS65418 :REM RESTORE SYSTEM VECTORS 9110 F=ABS(PEEK(65533)=255) :REM F=0 IF C64, F=1 IF C128 9120 IF F THEN BANK 15 :REM SELECT 128 SYSTEM BANK 9130 IF F=0 THEN P=207: L=6: ML=25344: RE=780: F$="RAMDOS64.BIN*" 9140 IF F=1 THEN P=14: L=5: ML=8960: RE=6: F$="RAMDOS128.BIN*" 9150 IF F=0 THEN LOAD F$,8,1 9160 IF F=1 THEN GRAPHIC1,1: BLOAD (F$): IF PEEK(DEC("D7"))=0 THEN GRAPHIC0 9170 : 9180 REM VERIFY SIZE OF RAM CARD 9190 : 9200 NB=0 :REM #BANKS=0 IF CANNOT PARTITION 9210 IF F=0 THEN SN=32317: B=24837: V=25741 :REM SNIFF ROUTINE, SIZE, VERSION 9220 IF F=1 THEN SN=15983: B=8453: V=9357 9230 : FORI=0TO2:V$=V$+CHR$(PEEK(V+I)):NEXT 9240 : PRINT"RAMDISK VERSION "V$" LOADED": SYSML+12: PRINT 9250 : IF LEFT$(V$,2)="4." THEN SYS SN: NB=PEEK(B) 9260 : 9270 RETURN 9280 : 9999 REM F.BOWEN 11/21/88 Replace your current version of RAMDOS.BAS with this version. Simple enough? This new version will patch the RAMdisk only if you answer Yes to the partition query, otherwise it won't change a thing. I suggest you contact TC128 about a subscription if you like this sort of information (shameless plug). The full article describes a simple hack to BASIC-8 (C128 graphics extensions) which makes it work with RAMDOS, partitioned or not. -- -- 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