28 May
2010
28 May
'10
8:43 p.m.
Can a C1541 or C1571 attached to a C64 read floppies from other
Commodore computers such as the VIC-20 or C16? Since the floppy
drive is basically a computer attached to the C64 by a serial cable,
I tend to think it can, but I don't believe I've ever seen anything
on this, and I know I've never tried. I've never had a floppy drive
attached to any of my VIC-20's, back when it was my only computer, I
only had a cassette drive.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
28 May
28 May
9:07 p.m.
On Fri, 28 May 2010, Zane H. Healy wrote:
Can a C1541 or C1571 attached to a C64 read floppies
from other Commodore
computers such as the VIC-20 or C16? Since the floppy drive is basically a
computer attached to the C64 by a serial cable, I tend to think it can, but I
don't believe I've ever seen anything on this, and I know I've never tried.
I've never had a floppy drive attached to any of my VIC-20's, back when it
was my only computer, I only had a cassette drive.
Zane, the short answer is yes. The long answer is yes, because the brains
of the drive and the DOS are IN the drive itself, not the computer. :)
The only difficulty you might run into is trying to read a double sided
1571 disk in a single sided 1541.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
9:37 p.m.
At 9:07 PM -0700 5/28/10, Gene Buckle wrote:
On Fri, 28 May 2010, Zane H. Healy wrote:
I thought this was the case, but just couldn't believe Commodore
could have done anything so logical. :-)
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Can a C1541 or C1571 attached to a C64 read
floppies from other
Commodore computers such as the VIC-20 or C16? Since the floppy
drive is basically a computer attached to the C64 by a serial
cable, I tend to think it can, but I don't believe I've ever seen
anything on this, and I know I've never tried. I've never had a
floppy drive attached to any of my VIC-20's, back when it was my
only computer, I only had a cassette drive.
Zane, the short answer is yes. The long answer is yes, because the
brains of the drive and the DOS are IN the drive itself, not the
computer. :)
The only difficulty you might run into is trying to read a double
sided 1571 disk in a single sided 1541.
9:43 p.m.
On Fri, 28 May 2010, Zane H. Healy wrote:
At 9:07 PM -0700 5/28/10, Gene Buckle wrote:
There's a couple of folks that have hooked 1541 drives to their ZX-81
computers. Anything that will talk the IEC serial protocol can use the
drives.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
On Fri, 28 May 2010, Zane H. Healy wrote:
I thought this was the case, but just couldn't believe Commodore could have
done anything so logical. :-)
Can a C1541 or C1571 attached to a C64 read
floppies from other Commodore
computers such as the VIC-20 or C16? Since the floppy drive is basically
a computer attached to the C64 by a serial cable, I tend to think it can,
but I don't believe I've ever seen anything on this, and I know I've never
tried. I've never had a floppy drive attached to any of my VIC-20's, back
when it was my only computer, I only had a cassette drive.
Zane, the short answer is yes. The long answer is yes, because the brains
of the drive and the DOS are IN the drive itself, not the computer. :)
The only difficulty you might run into is trying to read a double sided
1571 disk in a single sided 1541. 
10:24 p.m.
At 12:17 AM -0500 5/29/10, Jason T wrote:
On Fri, May 28, 2010 at 11:43 PM, Gene Buckle <geneb
at deltasoft.com> wrote:
http://www.trikaliotis.net/xu1541
No, I don't have one. I use my old Twinhead 386sx/16 laptop to drive
a C1541 drive. Though now I guess I'll simply use an SD card, and
the C-64 itself.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
There's a couple of folks that have hooked
1541 drives to their ZX-81
computers. Anything that will talk the IEC serial protocol can use the
drives.
So is there a USB interface for it yet? ;)
30 May
30 May
11 a.m.
On Sat, 29 May 2010, Jason T wrote:
On Fri, May 28, 2010 at 11:43 PM, Gene Buckle
<geneb at deltasoft.com> wrote:
I think someone is working on it. I think it's called the XU1541 adapter.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
There's a couple of folks that have hooked
1541 drives to their ZX-81
computers. ?Anything that will talk the IEC serial protocol can use the
drives.
So is there a USB interface for it yet? ;)
6:08 p.m.
On Sat, May 29, 2010 at 12:43 AM, Gene Buckle <geneb at deltasoft.com> wrote:
There's a couple of folks that have hooked 1541
drives to their ZX-81
computers. ?Anything that will talk the IEC serial protocol can use the
drives.
The instructions and associated software to hang a 1541 off of a
Syntertek SYM-1 (a functional, but not component-for-component, clone
of the KIM-1) are floating around as well, though I haven't tried it.
-ethan
28 May
28 May
9:08 p.m.
Can a C1541 or C1571 attached to a C64 read floppies
from other
Commodore computers such as the VIC-20 or C16? Since the floppy
drive is basically a computer attached to the C64 by a serial cable,
I tend to think it can, but I don't believe I've ever seen anything
on this, and I know I've never tried. I've never had a floppy drive
attached to any of my VIC-20's, back when it was my only computer, I
only had a cassette drive.
Yup. No problem.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- BOND THEME NOW PLAYING: "Nobody Does It Better" from "The Spy Who Loved
Me"
9:29 p.m.
Cameron Kaiser wrote:
Indeed, though I do remember there being problems with using the very
early 1540 drive from the VIC with later models, as the timing was not
compatible with the C64. I believe that the only real difference between
the 1540 and 1541 drives was slightly different firmware, cirtainly the
drives look identical inside. I also believe that the 1540 can be
upgraded by replacing the firmware with that from the 1541.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
Can a C1541 or
C1571 attached to a C64 read floppies from other
Commodore computers such as the VIC-20 or C16? Since the floppy
drive is basically a computer attached to the C64 by a serial cable,
I tend to think it can, but I don't believe I've ever seen anything
on this, and I know I've never tried. I've never had a floppy drive
attached to any of my VIC-20's, back when it was my only computer, I
only had a cassette drive.
Yup. No problem.
9:41 p.m.
On Sat, 29 May 2010, Phill Harvey-Smith wrote:
identical inside. I also believe that the 1540 can be
upgraded by replacing
the firmware with that from the 1541.
...and thereby utterly destroying the collectability of the 1540 drive. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
29 May
29 May
2:01 a.m.
cctalk-bounces at classiccmp.org wrote:
But you can keep a copy of the original firmware so it's a reversible
change, no?
Antonio
identical
inside. I also believe that the 1540 can be upgraded by
replacing the firmware with that from the 1541.
...and thereby utterly destroying the collectability of the 1540
drive. :)
30 May
30 May
11:02 a.m.
On Sat, 29 May 2010, arcarlini at iee.org wrote:
cctalk-bounces at classiccmp.org wrote:
But you can keep a copy of the original firmware so it's a reversible
change, no?
Yes, but with the current glut of 1541 drives, it would still be a hanging
offense. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
identical
inside. I also believe that the 1540 can be upgraded by
replacing the firmware with that from the 1541.
...and thereby utterly destroying the collectability of the 1540
drive. :)
29 May
29 May
6:39 a.m.
On 29/05/2010 05:41, Gene Buckle wrote:
On Sat, 29 May 2010, Phill Harvey-Smith wrote:
Which is why when I repaired the one I have and found it had a duff rom,
I replaced it with an eprom copy of the original ROM, as I guess my
chances of sourcing the actual ROM are pretty close to 0.
Cheers.
Phill.
identical inside. I also believe that the 1540
can be upgraded by
replacing the firmware with that from the 1541.
...and thereby utterly destroying the collectability of the 1540 drive. :) 
17 Jul
17 Jul
11:17 a.m.
On Saturday 29 May 2010 09:39:29 am Phill Harvey-Smith wrote:
On 29/05/2010 05:41, Gene Buckle wrote:
I have a fair amount of c= parts, some salvage, some NOS from when I worked on that
stuff extensively. Feel free to contact me offlist if you want any of it...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
On Sat, 29 May 2010, Phill Harvey-Smith wrote:
Which is why when I repaired the one I have and found it had a duff rom,
I replaced it with an eprom copy of the original ROM, as I guess my
chances of sourcing the actual ROM are pretty close to 0. identical inside. I also believe that the 1540
can be upgraded by
replacing the firmware with that from the 1541.
...and thereby utterly destroying the collectability of the 1540 drive. :) 
29 May
29 May
2:01 a.m.
Phill Harvey-Smith wrote:
Indeed, though I do remember there being problems with
using the very
early 1540 drive from the VIC with later models, as the timing was not
compatible with the C64. I believe that the only real difference
between the 1540 and 1541 drives was slightly different firmware,
cirtainly the drives look identical inside. I also believe that the
1540 can be upgraded by replacing the firmware with that from the 1541.
There was
also a command or sequence of commands that could be sent to a
1540 that changed its timing to meet the C64 requirements, until the
next time the 1540 was power-cycled or otherwise reset. When I got my
first C64 in 1982, it came with that information, but I no longer have it.
I am of the impression that on a VIC one would get slightly higher
performance out of a 1540 than a 1541, but I don't know for sure. And I
don't know whether there is a corresponding command or sequence that can
be sent to a 1541 to switch it to 1540 timing.
Eric
2:47 a.m.
I wrote:
There was also a command or sequence of commands that
could be sent to
a 1540 that changed its timing to meet the C64 requirements, until the
next time the 1540 was power-cycled or otherwise reset. When I got my
first C64 in 1982, it came with that information, but I no longer have
it.
I am of the impression that on a VIC one would get slightly higher
performance out of a 1540 than a 1541, but I don't know for sure. And
I don't know whether there is a corresponding command or sequence that
can be sent to a 1541 to switch it to 1540 timing.
Found it. The "UI+"
command will slow down a 1540 for use on a C64, and
"UI-" will speed it up again. Apparently when they wrote the 1540
firmware they anticipated that the bus might have to be slowed down for
use with some future computer.
Although the 1541 defaults to slow mode, the same commands work, so when
using a 1541 on a VIC-20 you might want to give the "UI-" command.
Example: OPEN 15,8,15,"UI-":CLOSE 15
Eric
9:37 a.m.
At 2:47 AM -0700 5/29/10, Eric Smith wrote:
Found it. The "UI+" command will slow down a
1540 for use on a C64,
and "UI-" will speed it up again. Apparently when they wrote the
1540 firmware they anticipated that the bus might have to be slowed
down for use with some future computer.
Although the 1541 defaults to slow mode, the same commands work, so
when using a 1541 on a VIC-20 you might want to give the "UI-"
command.
Example: OPEN 15,8,15,"UI-":CLOSE 15
Eric
Eric,
Am I reading correctly that the 1540 sends data faster than the 1541?
This brings up the obvious question, can you 'downgrade' a 1541 to a
1540! :-) I have multiple working 1541's, but only have 1 or 2
1540's in questionable condition (I believe one is literally in
pieces).
I'm still trying to organize and sort out the stuff I got in the two
loads, and have barely looked at the hardware itself. I dug through
a couple boxes of software, doc's and magazines last night. Some
very interesting stuff.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
10:09 a.m.
On 5/29/2010 11:37 AM, Zane H. Healy wrote:
At 2:47 AM -0700 5/29/10, Eric Smith wrote:
If you have a long board 1541, you can swap out the ROM with a 1540 ROM
image
Found it. The "UI+" command will slow
down a 1540 for use on a C64,
and "UI-" will speed it up again. Apparently when they wrote the
1540 firmware they anticipated that the bus might have to be slowed
down for use with some future computer.
Although the 1541 defaults to slow mode, the same commands work, so
when using a 1541 on a VIC-20 you might want to give the "UI-" command.
Example: OPEN 15,8,15,"UI-":CLOSE 15
Eric
Eric,
Am I reading correctly that the 1540 sends data faster than the 1541?
This brings up the obvious question, can you 'downgrade' a 1541 to a
1540! :-) I have multiple working 1541's, but only have 1 or 2 1540's
in questionable condition (I believe one is literally in pieces).
I'm still trying to organize and sort out the stuff I got in the two
loads, and have barely looked at the hardware itself. I dug through a
couple boxes of software, doc's and magazines last night. Some very
interesting stuff.
12:49 p.m.
Zane H. Healy wrote:
Am I reading correctly that the 1540 sends data faster
than the 1541?
By default, yes. Either drive can do serial bus transfers at either
speed.
This brings up the obvious question, can you
'downgrade' a 1541 to a
1540! :-)
Yes, either temporarily by using the "UI-" command, or
permanently by
replacing the ROM. Other than the ROM contents, the hardware is
functionally identical.
Eric
1:44 p.m.
At 12:49 PM -0700 5/29/10, Eric Smith wrote:
Zane H. Healy wrote:
>This brings up the obvious question, can you 'downgrade' a 1541 to
>a 1540! :-)
Yes, either temporarily by using the "UI-"
command, or permanently
by replacing the ROM. Other than the ROM contents, the hardware is
functionally identical.
Nice! Thanks for clarifying that.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
10:28 a.m.
On 5/29/2010 4:47 AM, Eric Smith wrote:
Found it. The "UI+" command will slow down
a 1540 for use on a C64,
and "UI-" will speed it up again. Apparently when they wrote the 1540
firmware they anticipated that the bus might have to be slowed down
for use with some future computer.
The UI- command does not exist in the 1540 ROM. Commodore did not
think that far ahead.
The story goes that Tramiel was unhappy with the price and availability
of the IEEE-488 cables on the PET line, and told the VIC designers to
"get off that bus!". They looked at the VIA 6522 and designed a serial
protocol around the use of the shift register. Late in the game,
software developers became aware of the 6522 Shift Register "bug", and
so had to retreat back to bit banging the bus. So, for that bug, the
serial speed went from CLK/32 to transfer a byte down to CLK/320 or so.
Then, when the C64 was in development, they improved the VIC-I to do 40
columns. By the time they got done, the VIC-II had to "steal" cycles in
order to do it's work. This corrupted disk transfers because the
"steal" took away more time that the cycle time of the IEC protocol.
So, the IEC protocol was slowed from 20uS to 60uS on the 154X->C64
direction. The 1540 ROM had to be updated to slow down the transfer,
and thus UI+/- was introduced.
Jim
--
Jim Brain, Brain Innovations (X)
brain at jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com
1:42 p.m.
Jim Brain wrote:
The UI- command does not exist in the 1540 ROM. Commodore did not
think that far ahead.
Hmmm... You must be right. Looking at a disassembly of the
1540 ROM, I
can't even figure out how UI+ would have worked properly on it either.
Unlike the 1541 ROM, the UI vector never checks for a + or -, doesn't
set the value of zero-page location $23 (which is never used), and jumps
into the reset code. Must be something strange and very non-obvious
going on in there.
Eric
1:56 p.m.
Jim Brain wrote:
>
> The UI- command does not exist in the 1540 ROM. Commodore did not
> think that far ahead.
I wrote:
Hmmm... You must be right. Looking at a disassembly
of the 1540 ROM,
I can't even figure out how UI+ would have worked properly on it
either. Unlike the 1541 ROM, the UI vector never checks for a + or -,
doesn't set the value of zero-page location $23 (which is never used),
and jumps into the reset code. Must be something strange and very
non-obvious going on in there.
The more I look at it, the more convinced I am that
the sheet of paper I
got with my C64 and 1540 back in 1982, explaining how to use the 1540
with the C64, must have suggested something other than the UI command.
Maybe it said to turn off the C64 display when reading from the disk? I
can't remember now. Or maybe my 1540 already contained a 1541 ROM, and
the paper was explaining how to use the UI- command to use it with a
VIC-20. That's starting to seem like the most likely explanation. Darn
this unreliable memory!
Eric
3:22 p.m.
The more I look at it, the more convinced I am that
the sheet of paper I
got with my C64 and 1540 back in 1982, explaining how to use the 1540
with the C64, must have suggested something other than the UI command.
Maybe it said to turn off the C64 display when reading from the disk?
Yes. Something like POKE 53265,11 would do it.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- There's always free cheddar in a mousetrap, baby. -- Tom Waits -------------
30 May
30 May
6:15 p.m.
On Sat, May 29, 2010 at 1:28 PM, Jim Brain <brain at jbrain.com> wrote:
The story goes that Tramiel was unhappy with the price
and availability of
the IEEE-488 cables on the PET line, and told the VIC designers to "get off
that bus!". ?They looked at the VIA 6522 and designed a serial protocol
around the use of the shift register. ?Late in the game, software developers
became aware of the 6522 Shift Register "bug", and so had to retreat back to
bit banging the bus.
Were there any versions of the 6522 (65C22?) that had the shift
register bug fixed? Does the 6526 preserve the bug? With all the
Speed DOS products that were out there, I can't imagine it would be
worth trying to (re)create the originally envisioned
hardware-implemented bit-serial interface, but once I heard the story
about the shift register bug, I'd always wondered what it would have
been like to have used a drive that wasn't so glacially slow.
So, for that bug, the serial speed went from CLK/32
to
transfer a byte down to CLK/320 or so.
I hadn't realized it was that much slower. Wow.
My first C-64 (S/N P00002007, a development machine sent from
Commodore to my first employer) came with a 1540 and some extra
operational instructions - I think it was to disable VIC-II DMA, like
the KERNEL already does during a tape load.
-ethan
6:43 p.m.
On 5/30/2010 8:15 PM, Ethan Dicks wrote:
Well, I'm sure anal pedantic folks might quibble over the values, but
here was my calculations:
6522/6526 shift register operates at CLK/4 top speed. So, 8 bits take ~
CLK/32
On the VIC-20, the CLK is 20uS per half cycle. That CLK/40 per bit, or
CLK/320 for the byte.
Both calculations ignore TURN and other protocol nuances.
The C64, due to the DMA needs, reduced the 1541-C64 speed to CLK/60 per
half clock cycle. So, a byte takes CLK/960, or ~ 1000 bytes/sec. In
reality, my numbers are off, since most references acknowledge a top
speed of 300 bytes/sec for the 1541, though some of that is probably due
to sector latency and the protocol overhead.
Were there any versions of the 6522 (65C22?) that had the shift
register bug fixed? Does the 6526 preserve the bug? With all the
The 6526 fixed the bug, though it has a bug (bugs) of its own.
Jim Butterfield noted in a post long ago that the hardware guys knew
about the 6522 shift register bug long before the VIC-20 was in
development, but due to "right hand, left hand" stuff, that information
never got communicated.
The story continues that when the C64 was in development, the switch to
the 6526 would allow a return to the shift register usage. The
designers added the requisite lines to the PCB design, but during the
cost reductions/final design work done in Japan, the extra lines were
removed. When the PCBs came back from the initial run, the PCB designer
in the US was apalled to find his extra lines had been removed.
So, for that
bug, the serial speed went from CLK/32 to
transfer a byte down to CLK/320 or so.
I hadn't realized it was that much slower. Wow.
My first C-64 (S/N P00002007, a development machine
sent from
Commodore to my first employer) came with a 1540 and some extra
operational instructions - I think it was to disable VIC-II DMA, like
the KERNEL already does during a tape load.
Yes, disabling the VIC-20 will allow VIC-20 speeds. Some fastloaders
did this to allow ignoring the DMA issues.
Jim
7:30 p.m.
Ethan Dicks wrote:
Were there any versions of the 6522 (65C22?) that had
the shift
register bug fixed?
Yes. Some, but not all, of the CMOS variants fixed the issue. You
can't count on a part marked 65C22 as having the fix; you have to check
the datasheet for the specific manufacturer and part number.
Note that the issue isn't really a bug in the strict sense. According
to Synertek application note AN5, the problem occurs when the rising
edge of CB1 occurs less than 100 nanoseconds before the falling edge of
Phi2. If you look at the NMOS 6522 datasheet (eg, Rockwell R6522), the
AC specifications give a parameter tSR3, "External Shift Clock (CB1)
Setup Time Relative to Phi2 Trailing Edge" with a minimum of 100 ns.
This is illustrated in Figure 31g "Timing for Shift in with Internal or
External Shift Clocking". Thus the problem only occurs when the
specifications for the part are violated.
Another "bug" people claim that the 6522 had was that registers could be
corrupted if the register select inputs changed while Phi2 was active,
even if the chip was not selected. This caused problems with using the
6522 in 68000 systems. Changing the register select lines with Phi2
active violates the tACR, tCAR, tACW and tCAW specs of the part, so it's
not a true bug.
Eric
7:45 p.m.
On Sun, May 30, 2010 at 10:30 PM, Eric Smith <eric at brouhaha.com> wrote:
Ethan Dicks wrote:
Good to know (but not unsurprising).
Were there any versions of the 6522 (65C22?) that had the shift
register bug fixed?
Yes. ?Some, but not all, of the CMOS variants fixed the issue. ?You can't
count on a part marked 65C22 as having the fix; you have to check the
datasheet for the specific manufacturer and part number. Note that the issue isn't really a bug in the
strict sense. ?According to
Synertek application note AN5, the problem occurs when the rising edge of
CB1 occurs less than 100 nanoseconds before the falling edge of Phi2...
OK. I can accept is isn't strictly a bug, but what is it about the
VIC-20 design that violates the 6522 specs? Did they cost-reduce too
many corners? Is there a similar issue with the PET design?
I thought there was also a problem (verifiable with PETs) where
certain aspects of the chip act funny if you are using the shift
register - the symptoms I remember is that if you are using CB2
"music" (free-running shift register), the tape drive doesn't work.
You have to "disable the sound" before you can save your work (as we
used to view it when we were hacking PETs). Is this the same/a
related bug or something else?
Another "bug" people claim... caused
problems with using the 6522 in
68000 systems.
Did Apple do something tricky with the original Mac design?
http://farm3.static.flickr.com/2365/2391525329_af71ed4f8d.jpg
(one of the few times I've seen a 6522 hung off of a 68K - for an
embedded product I worked on in the 1980s, we had Z8350 SIO chips and
6821 PIO chips, but not 6522s).
-ethan
31 May
31 May
12:25 a.m.
Ethan Dicks wrote:
I seem to recall that they did, but it's been so long since I looked at
the schematics and the reverse-engineered PAL equations that I don't recall.
Eric
OK. I can accept is isn't strictly a bug, but
what is it about the
VIC-20 design that violates the 6522 specs? Did they cost-reduce too
many corners? Is there a similar issue with the PET design?
The issue with using the shift register for the Commodore serial bus is
that if you feed the clock directly into CB1, it can violate the timing
specs. If you add an external synchronizer, that would fix it.
However, instead they went the cost-reduction path of bit-banging it.
Another
"bug" people claim... caused problems with using the 6522 in
68000 systems.
Did Apple do something tricky with the original Mac design?
5038
days inactive
5087
days old
29 comments
10 participants
participants (10)
-
afra＠aurigae.demon.co.uk -
arcarlini＠iee.org -
brain＠jbrain.com -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
geneb＠deltasoft.com -
healyzh＠aracnet.com -
rtellason＠verizon.net -
silent700＠gmail.com -
spectre＠floodgap.com