My son bought this kit from a yard sale... but there is no manual.? I read on the internet that you might have the manual for this kit? It is the 75 in 1 made by Tandy for Radio Shack.
?
Thanks so much for any help.
?
Wayne
>
> You don't want to use a PC HD drive, Commodore disks are 40 track (OK, well, 35 track, but still), the narrower head of the 80 track PC drive will cause problems if you want to write.
Well, about 80% of the games sold for the C64 were in fact written on
industrial grade PC drives with Trace machines. Many titles use 80 track
mechanics and heads. It in fact works when the drive is well aligned and
you make sure the disk is empty, e.g. degaussed, before you do this,
otherwise you would risk keeping garbage for disks that were previously
formatted in a 40 track drive with wider heads.
All games that do stepping tricks with so called fat tracks or half
tracks can't be written with 40 track drives at all.
>
> An HD PC floppy drive will *NOT* read commodore 1541 disks.not a
> chance in hell. PC drives are MFM, commodore are not. totally
> incompatible.
You are totally wrong. The drive will happily read the disk, but you
need a controller that can make use of GRC coding and the special
encoding tricks used by copy protections. As the 1541 is a separate
computer, there is much freedom here.
> I've heard of people using catweasel with 1541 drives, mounted in
> their PC's also.
Really? Afaik the 80 track drives with 40 track wide heads were custom
made for Commodore and don't have a Shugart connector.
> those are very different from commodore disks,someone already
> mentioned commodore have up to 40 tracks,what about half-tracks, and
> copy-protected disks? will they read v-max disks?commodore software
> got heavily into copy protection,like rapidlok, and worse in the later
> days
Indeed. These will cause trouble when read with a 1541 for various
reasons. Some protections work by using the index while recording (which
the 1541 does not have...), later read a specific track and then step
ahead to find some special data when reading a few tracks later. You
can't write such protections with a standard 1541 as it lacks the index
to aling your data to.
Other protections vary bit cell density, which is ok for reading, but
can't be written with an unmodified 1541, some make tracks so long and
write them in one pass, so you need more ram in a 1541 and some will
even trick the sync detection which is not very reliable in the 1541.
What makes things worse is that the format used for storing such data,
g64, is very badly implemented in most of the emulators out there. To
our knowledge all emulators are working with a fixed track size of 7928
bytes per track, which will give trouble for e.g. V-MAX! style disk, at
least everything before V3.
We are working with Pete Rittwage (author of Nibtools) to find out if we
can help enhance e.g. Vice to support properly imaged disks that have
demanding protections. Currently some g64s need tampering with, some
even need cracking the game, because the format can't properly store the
protection (see e.g. Pirates! for fun invloved). See:
http://c64preservation.com/dp.php?pg=bangui6
If anyone wants to take a look... we do have V-MAX disk images of
Defender Of The Crown that are definitely beyond what emulators will
accept at the moment. Let me know...
> I'd say zoomfloppy, simply because of nibtools, which is the most
> feature-rich for commodore disks I've found.especially where
> copy-protection is involved. And, the fact it can write images back to
> disk gives it a distinct advantage. this is only for commodore style
> disks, other platforms would have their preferred tool(s). Dan.
I would agree, at least if writing is important to the person using it.
KryoFlux currently does not write g64 files, so it's for reading only
(at the moment). We do have a preliminary STREAM to g64 converter, which
spits out files that are correct in regard to what's on the disk
(leaving out e.g. varying density in a track, which can't be stored by
the file format itself), but fail in emulators, because, as written
above, all of them work with a fixed track size and so forth. Some
protections will fail if the track size is wrong.
If you are going for an estimated 85% of things out there, can live with
losing index information, don't fear messing with images, having e.g.
three to four separate g64s for one game for different emulators, want
to start tweaking the drive to alter rotation speed (therefore creating
e.g. longer tracks at the cost of slightly wrong recording coercivity),
and need a cheap solution, ZoomFloppy with a 1541 and Nibtools will work
ok. I also have one for testing, it's very well executed and Jim Brain
delivers quality. If you want to go beyond, KryoFlux might come handy.
E.g. a 1541 will never show you recording tricks like varied bitcell
width, "killer tracks" full of syncs etc. But it's work in progress, and
won't be fully ready tomorrow.
Modifying a drive to make it read flippy disks in one pass, like at the
recording stage, is a pain. Just for the record.
Enjoy.
Chris
not going to be an issue in my case. Still cant get it open...if by screws the poster meant the hexagonal lugs or whatever in back then i guess its april 1 after all...
------------------------------
On Sun, Apr 1, 2012 4:16 PM EDT Tony Duell wrote:
>>
>> VR201? Remove screw under cover in the centre of the rear panel between
>> plug and pots. Lower adjustment leg to fully out.=20
>>
>> Screen blue spot?=20
>>
>> a) Run a hot wire (Styrofoam cutter) between the outer screen and the fro=
>> nt
>> of the tube.
>>
>> Or =20
>>
>> b) (only for CRT familiar persons) Remove the tube completely. Place in
>> something to support it at the face end. Don goggles and gloves. Chip awa=
>> y
>> the outer faceplate bit by bit. Peel off the soft plastic. Polish up the
>> tube front, rebuild the monitor and put spacers at the four corners then
>> replace casing. Does wonders for the brightness as well.
>
>Look, I know what day it is, but practical jokes are supposed to be
>funny, and not endager innocent bystnaders at som random future time.
>
>CRT implosions are not common, I agree. But they must be serious enough
>tat even in the less safety-concious times of 50 years ago all TV sets
>had some kind of implosion protection.
>
>Unless you have definiete infroamtion to the contrary, I will go by what
>every CRT data sheet I've looked at says. That the twin-panel faceplate
>acts like a laminated windscreen and supports te screen i nthe even of an
>implosion, preventing the user from being showeed in fragments of glass.
>Most CRT datasheets also say that no attempy must be made to remvoe the
>outer layer, but I think it's popsible to do this safely _provided you
>then re-bond the layers together properly_. LEaving off the outer layer,
>or not bonding it to the frotn of the envelope is not acceptable IMHO.
>
>You don't know when the CRT could implode, or who might be in front of it
>at the time.
>
>-tony
> From: Dave McGuire <mcguire at neurotica.com>
>
>
>
> Well, I just timed it: Clean slate to running VMS system with a tape
> image mounted on an emulated drive, under simh. 26 minutes.
>
That's because you know what you are doing.
> But suit yourself. ;)
>
>
>>> I don't know your level of expertise with VMS or simh, so please don't
>>> take this the wrong way, but...if you want to do that and would like
>>> some help, I'd be happy to help you out. I can put together a "canned"
>>> simh VMS installation for something like this in a very short time.
>>>
>>>
>> I got simh to teach my kids some machine language programming on the
>> PDP-11.
>> (We had a class last Sunday.)
>>
>
> Nice!! How old are they? (if you don't mind my asking, I am just
> curious)
>
Range from 12 to 22.
>
> Sweet!!
>
>
Yeah, back in 1986 or so, this was a totally awesome system! Fooling
around with
these tape images on disk shows me (again) how far computers have come.
I can scan
a 30 MB file in a fraction of a second! I'm sure that would have taken
10 minutes or
so on the KA-630.
> Jon Elson wrote :
>> If all else fails, I suppose I could go that way, but this vmsbackup
>> program
>> seems to try to work, it probably needs a little tweak. It detects the
>> 80 byte
>> header records and stops. All the VMS Backup tapes I've checked so far
>> have two 80 byte headers, this program seems to want one 256-byte header.
>>
>
> That doesn't sound too tough to deal with. Good luck!
>
I've finally established contact with the last guy who worked on the
vmsbackup program,
he suggested removing the offending tape headers with xxd, but if you
cut the top lines
off the file, it uses the address column on the left and you end up with
zeros in their
place. Anybody know a way to edit a tape container file to remove a few
tape blocks
>from the beginning?
I know I could write a program that does this exactly, and my just do so
tonight.
Basically, it would extract the backup files verbatim from the tape image.
Jon
At 11:16 AM 4/3/2012, Rob wrote:
>getting to grips with simh, locating images and and working out how to
>install it all etc. A ready-to-roll VM type thing would definitely
>get a download off me, though! Please consider it..
I bit of googling showed a few people on the SimH mailing list
were thinking about a virtual appliance version. I don't know if
they did it. They were talking about a stripped-down Linux.
So how would we connect a glass terminal or a DECwriter to it?
- John
I WAS LOOKING FOR A SMALL SOFTWARE PROJECT TO DO ON VINTAGE HARDWARE.
THE HUNT DIDN'T GO ON LONG BEFORE IT HIT ME. ONLY ONE THING COULD
POSSIBLY DO: CALCULATE PRIME NUMBERS ON MY TRUSTY PR1ME 5340
MINICOMPUTER.
THE 5340 IS A SOPHISTICATED MACHINE, CMOS BASED, AND UTILIZING CUSTOM
HIGH DENSITY GATE ARRAYS TO REDUCE THE PHYSICAL SIZE OF THE CPU AND
MAIN MEMORY (16 MB) TO WELL UNDER 225 SQUARE INCHES. POWER
CONSUMPTION IS WELL UNDER 10A, TOO, AND THE MACHINE CAN RUN WITHOUT
HEAVY AIR CONDITIONING. JUST A COUPLE OF YEARS AGO, EVEN A HIGH END
ECL DESIGN COULD NOT PROVIDE THE SAME LEVEL OF PERFORMANCE IN SEVEN
TIMES THE BOARD SPACE, AND IT STILL WOULD HAVE REQUIRED 30A TO 50A OF
WALL POWER, PLUS SEVERAL THOUSAND BTU OF CHILLING.
SINCE THE PR1ME ARCHITECTURE IS TARGETED AT SCIENTIFIC USERS, AN
ARBITRARY PRECISION NUMBER PACKAGE IS NOT READILY AVAILABLE. AFTER A
FEW TESTS, I CONCLUDED THAT THE HARDWARE QUAD PRECISION FLOATING POINT
SUPPORT WAS A POOR CHOICE DUE TO THE SCALE OF THE ROUNDING ERRORS I
WAS SEEING. THE PR1ME FLOATING POINT IMPLEMENTATION IS QUITE GOOD,
BUT WHEN ALL OF THE SIGNIFICANT DIGITS ARE TO THE LEFT OF THE DECIMAL
POINT, THERE IS VERY LITTLE IT CAN DO.
BUT ALL WAS NOT LOST, AS HAS NO DOUBT BECOME OBVIOUS BY THE POSTING OF
THIS MESSAGE. THE ARCHITECTURE ALSO SUPPORTS PACKED AND UNPACKED
DECIMAL ARITHMETIC, WHICH CERTAINLY DOESN'T SUFFER FROM ROUNDING
ERRORS. IT CAN EVEN STORE NUMBERS AS LARGE AS 63 DIGITS IN LENGTH.
PERFECT!
I WAS NOT WILLING TO SIMPLY CODE UP SOME MATHEMATICIAN'S DUBIOUS
ALGORITHM -- I WANTED TO BE SURE NOT TO MISS ANY VALID PRIMES.
INSTEAD, I CAREFULLY DESIGNED MY OWN, AND VALIDATED IT USING A LARGE
CORPUS OF TEST DATA (ALL INTEGERS BETWEEN 1 AND 100). THE CODE USES A
NUMBER OF ADVANCED TECHNIQUES FOR ACCURACY AND HIGH PERFORMANCE,
INCLUDING:
* SEQUENTIAL SEARCH FOR POSSIBLE FACTORS.
* CYCLING TO THE NEXT POTENTIAL PRIME IMMEDIATELY UPON DISCOVERING AN
INTEGRAL FACTOR, INSTEAD OF CONTINUING TO TEST ALL REMAINING POSSIBLE
FACTORS.
* TESTING ONLY FACTORS LESS THAN HALF OF THE CANDIDATE PRIME.
* NOT TESTING FOR DIVISIBLENESS BY 1.
* TESTING ONLY ODD CANDIDATE PRIMES.
* HAND-CODED IN PR1ME ASSEMBLER.
USING THESE METHODS, I WAS ABLE TO ACHIEVE REMARKABLE PERFORMANCE. IN
TESTING, THE PROGRAM EXECUTED ABOUT 3,086,913,596 DECIMAL DIVISION
OPERATIONS IN 11 HOURS AND 17 MINUTES, FINDING THE FIRST 10544 PRIME
NUMBERS, AT A RATE OF ABOUT 75994 DIVISIONS PER SECOND, AND NEARLY 935
PRIMES PER HOUR. TRY _THAT_ IN BASIC ON YOUR IBM 5150!
THE SOURCE PROGRAM, AND AN OUTPUT FILE WITH START AND END DATE STAMPS
AND THE FOUND PRIMES, ARE AVAILABLE FOR PERUSAL AT
http://yagi.h-net.msu.edu/primenumbers/.
SUGGESTIONS FOR ENHANCEMENT OR CORRECTION OF THE PROGRAM WILL BE
GRATEFULLY RECEIVED BY THE AUTHOR.
DE
Honestly guys. This conversation sounds very bitchy. If it wasn't Bill
Gates who dominated the OS area in the 1980s and 1990s someone of the same
ilk would of.
Regardless what you think of them survival in business is always the
survival of the fittest. Gates was at the top of that game for a while.
Anyone who gets beats off the competition at that level has got to be
ruthless and clever. I don't condone it, but its a fact.
At least he IS doing something good with his money.
Let's move on from the constant Microsoft bashing, please!
Tez
On Tue, Apr 3, 2012 at 2:09 PM, Dennis Boone <drb at msu.edu> wrote:
> > Very true; as this isn't a merit-based society. He was a damn good
> > programmer "back in the day", though; pity he didn't stick to that.
>
> Some of the things I've heard about the early basic interpreter make me
> wonder if he was really a good programmer.
>
> De
>
Im making this big carload of TRS-80 magazines/owners manuals free to
someone who will take the time, scan it and put it online.
Its free for pickup at my home in Flushing MI
Now that I have read in a few archival tapes and unpacked the simple
ones (ANSI-D) I am looking at extracting files from VMS BACKUP
tapes. I found a program vmsbackup originally by John Carey at
Monash University in AU. It actually seems to understand my
tape container format, maybe because it is practically identical
to some other formats. But, it is complaining that my tape
has 80-byte header records, and it wants 256. My tapes start
out with VOL1, HDR1 and HDR2 80-byte records, then a tape mark and
then the backup save set follows. I get the message :
Invalid header block size: expected 256 got 80
So, does anyone know whether there is a version of this program that
will handle a backup tape with 80-byte header records, or is there
another program for extracting files from a VMS backup tape or
save set that will run on Linux?
Thanks,
Jon
