Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco From: jgreco@csd4.milw.wisc.edu (Joe Greco) Newsgroups: comp.sys.cbm Subject: 1750 topics Message-ID: <830@csd4.milw.wisc.edu> Date: 9 Feb 89 00:39:06 GMT References: <5900@cbmvax.UUCP> <794@csd4.milw.wisc.edu> <5912@cbmvax.UUCP> <806@csd4.milw.wisc.edu> <5918@cbmvax.UUCP> Sender: news@csd4.milw.wisc.edu Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco) Organization: Starbase 74 - Starfleet Operational Support Services Lines: 52 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)