jgreco@csd4.milw.wisc.edu (Joe Greco) (02/09/89)
In comp.sys.cbm article <5918@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote:
]In article <806@csd4.milw.wisc.edu> (Joe Greco) writes:
]>In comp.sys.cbm article <5912@cbmvax.UUCP> (Fred Bowen) wrote:
]>]In an article in the latest Twin Cities 128 (issue #23) I do just that- tell
]>]you how to partition the RAMdisk.
]>
]>Help us who don't get TC128 [...]. Ditto with Q-Link.
]
]I believe in giving these people a fair chance at attracting subscribers,
]which they would not have if I simply copied the material to you fine folks
]mooching info from free (to you) networks. :-)
I don't "mooch." But at the same time, I also don't like hacking into
other peoples' programs. RAMDOS looks a little too formidable for me.
:-)
]But capitalism has its limits, and after they have had their fair chance I
]will share the information with you.
Sounds reasonable (even if it WILL drive me to drink).
]>Does RAMDOS64 4.2 work with the 1750?
]
]Certainly. Maybe you have a bum copy. I assume the 1750 works on your C64
]otherwise, power supply and plug-in gee-whiz cartridges not withstanding.
Tried it on a standard 64... no go.
It [1750] serves really nicely. Also worked marginally well with RAMDOS 3.2
(?), but that RAMDOS had some problems (I just loved that "FILE
EXSISTS" error.... directory wasn't formatted quite right and caused
minor problems... etc etc)
Good time to mention a minor problem I've encountered once in a great
while. My 1750 is used for index tables and to maintain a copy of my
BBS's message header files. For each message read, approximately 2000
REU accesses are performed (scanning 16 byte indexes) and a 256 byte
record is read. I've had a somewhat rare problem where data in the
REU is corrupted. The 256 byte records are checksummed, and I have
gotten occasional errors where entire records would be mangled
(obviously the correct record, but certain bits returned bad for many
bytes in a row). I don't believe it's the power supply (it has a
hefty "filter" cap, and causes no other problems)... does the REU
object to many, many sequential accesses or anything unusual?
The information on the disk is correct.... just the RAM saved copy is bad.
--
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) (02/10/89)
In <830@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >In article <5918@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote: >>But capitalism has its limits, and after they have had their fair chance I >>will share the information with you. >Sounds reasonable (even if it WILL drive me to drink). :-) Sounds like fun. Gimme a call and I'll join you. >>>Does RAMDOS64 4.2 work with the 1750? >>Certainly. Maybe you have a bum copy. I assume the 1750 works on your C64 >>otherwise, power supply and plug-in gee-whiz cartridges not withstanding. >Tried it on a standard 64... no go. >Good time to mention a minor problem I've encountered once in a great >while. [...] I've had a somewhat rare problem where data in the >REU is corrupted. The 256 byte records are checksummed, and I have >gotten occasional errors where entire records would be mangled >(obviously the correct record, but certain bits returned bad for many >bytes in a row). I don't believe it's the power supply (it has a >hefty "filter" cap, and causes no other problems)... does the REU >object to many, many sequential accesses or anything unusual? What I was implying was: you are using a 1750 (C128 peripheral) on a C64. I know many folks do this without adding the resistor at R4 and say they have no problems. Have you added this resistor (390 ohm)??? The problem you are describing sounds like you haven't. This resistor shifts the dot clock timing slightly to compensate for small (TTL delays) differences between the C64 and C128 timing at the expansion port. -- -- 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) (02/10/89)
In comp.sys.cbm article <5942@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote: ]What I was implying was: you are using a 1750 (C128 peripheral) on a C64. I ]know many folks do this without adding the resistor at R4 and say they have ]no problems. Have you added this resistor (390 ohm)??? The problem you are ]describing sounds like you haven't. This resistor shifts the dot clock timing ]slightly to compensate for small (TTL delays) differences between the C64 and ]C128 timing at the expansion port. There is a *factory installed* R4 on the pcb. The machine in question is located in an odd spot and I can't quite make out the color codes.... Ah well. Perhaps a patch or two and I can get a little more debugging info. -- 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) (02/11/89)
In <853@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >In article <5942@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) wrote: >]What I was implying was: you are using a 1750 (C128 peripheral) on a C64. >There is a *factory installed* R4 on the pcb. Sorry- right idea but it didn't come out right. An REU used on a C64 should NOT have a resistor at R4. An REU used on a C128 SHOULD have a resistor at R4. If you are using a 1750 on a C64, remove the resistor at R4 (leave it open). -- -- 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