Vic-20/C-64 serial ports
The Arch-Deviant
on a swipe-card reader this morning, and started thinking about how much of my
youth was spent reading those same words while waiting for Vic-20 programs to
load off tape. This got me thinking about how, by the time we had a C-128 (but
still no disk drive), things had advanced to "Invader Load", a hectic version
of space invaders you could play while the tape rolled.
The reason they could do this was that tape I/O was interrupt-driven, and to
finally get to the point of this post I'm struck by the irony of a system that
has interrupt-driven code for tape but software polling for disk I/O.
My question is, why did Commodore implement the serial protocol in software?
Both the 6522 and 6526 had hardware shift registers and associated interrupt
capability, but until the 128's fast serial mode these were never used. Does
anyone know why not?
TIA...
Simon Brady "I've been an awful woman all my life
University of Otago A dreadful daughter and a hopeless wife
Dunedin, New Zealand Well I've had my eyes on that carving knife
simon...@stonebow.otago.ac.nz Oh you've been lucky, so far..."
- Kirsty MacColl, 'Bad'
Lonnie McClure
|
| My question is, why did Commodore implement the
| serial protocol in software? Both the 6522 and 6526
| had hardware shift registers and associated interrupt
| capability, but until the 128's fast serial mode these
| were never used. Does anyone know why not?
|
|
Commodore Trivia series answers, as I recall).
In summation, the use of the 6522's serial shift register was planned, but
there was a bug the chip that prevented this from working properly. Rather
than hold-up the release of the VIC-20, they went with the software bit-banger
implementation that we all so love to hate.
Of course, the 64's 6526's shift register worked fine, but Commodore had an
existing stock of 1540 drives that would be useless for the 64 if they
implemented use of the 6526's shift register (and a new drive using a 6526
instead of a 6522 would need to be engineering and put in production), and
with Commodore (wrongly) expecting most owners to use cassette storage,
cost won out over speed.
--
LMCC...@delphi.com
Little Rock, AR
marcus durham
simon...@stonebow.otago.ac.nz "The Arch-Deviant" writes:
> Isn't it scary what you remember? I was staring at the "please wait..." message
> on a swipe-card reader this morning, and started thinking about how much of my
> youth was spent reading those same words while waiting for Vic-20 programs to
> load off tape. This got me thinking about how, by the time we had a C-128 (but
> still no disk drive), things had advanced to "Invader Load", a hectic version
> of space invaders you could play while the tape rolled.
Im sorry I had to delurk at the mention of that game.
Goodness. Invaderload, I remember that ( still have it somewhere ). That
music and the brillientness of it all. And half the time Invaderload
was better than the game you where loading. I remember stopping
the tape after Invaderload had loaded on more than one occasion just
to play Invaiderload.
> The reason they could do this was that tape I/O was interrupt-driven, and to
> finally get to the point of this post I'm struck by the irony of a system that
> has interrupt-driven code for tape but software polling for disk I/O.
>
> My question is, why did Commodore implement the serial protocol in software?
> Both the 6522 and 6526 had hardware shift registers and associated interrupt
> capability, but until the 128's fast serial mode these were never used. Does
> anyone know why not?
>
> TIA...
>
> Simon Brady "I've been an awful woman all my life
> University of Otago A dreadful daughter and a hopeless wife
> Dunedin, New Zealand Well I've had my eyes on that carving knife
> simon...@stonebow.otago.ac.nz Oh you've been lucky, so far..."
> - Kirsty MacColl, 'Bad'
>
--
-=- Marcus Durham -=-
Circular logic will only make you dizzy
Eldrad must live
Graham Penny
marcus durham <mar...@zenn.demon.co.uk> wrote:
>In article <4cn3ba$i...@celebrian.otago.ac.nz>
> simon...@stonebow.otago.ac.nz "The Arch-Deviant" writes:
>Im sorry I had to delurk at the mention of that game.
>Goodness. Invaderload, I remember that ( still have it somewhere ).
That
>music and the brillientness of it all. And half the time Invaderload
>was better than the game you where loading. I remember stopping
>the tape after Invaderload had loaded on more than one occasion just
>to play Invaiderload.
>
Yup, I did that... quite often in fact. Invaders still rules after all
these years!! :)
GP (Humming the Invaderload choon.. God, I can still remember it!!)
_________________________________________________________________
/ \ \
/ ___\ Graham Penny \
| /\ \ \
| |__| | |
\__/_____| a.k.a. Targaff the Faerie Dragon (Can someone change my |
| wings back... please?) |
| a.k.a. Manticore (A dangerous incarnation, avoid at all costs)|
|----------------------------------------------------------------|
| ' "Go wipe yourself," he said. ' |
| -Rome Haul, Walter (middle letter). Edmonds |
____ / /
\__/_________________________________________________________________/
James Chamblin
>In article <4cn3ba$i...@celebrian.otago.ac.nz>
> simon...@stonebow.otago.ac.nz "The Arch-Deviant" writes:
>
>> The reason they could do this was that tape I/O was
interrupt-driven, and to
>> finally get to the point of this post I'm struck by the irony of a
system that
>> has interrupt-driven code for tape but software polling for disk
I/O.
>>
>> My question is, why did Commodore implement the serial protocol in
software?
>> Both the 6522 and 6526 had hardware shift registers and associated
interrupt
>> capability, but until the 128's fast serial mode these were never
used. Does
>> anyone know why not?
>>
>> TIA...
>>
The reason was that after commodore did some testing, they found that
the hardware serial on the 6522 was unreliable. So they decided to use
a software method instead. The problem was fixed in the 6526 but
commodore decided that compatability was more important than speed
(after all alot of people were upgrading from VIC-20 to C64).
Christopher Wiles
> My question is, why did Commodore implement the serial protocol in software?
> Both the 6522 and 6526 had hardware shift registers and associated interrupt
> capability, but until the 128's fast serial mode these were never used. Does
> anyone know why not?
'Cause they were insane. Remember, these were the folks that opted to
not fully decode the $D000-$DFFF region, so that all of the memory-mapped
devices (VIC-II, SID, both CIAs) were shadowed every 4k ...
Seriously, hooking a UART to the user port would probably obviated using
the port for non-RS232 devices. Things were *much* more flexible with
the CIA (CIA2? It's been a while).
Anyone know why the RS232-emulation kernel code was so inefficient?
Slipshod design, or what?
-- Chris (wil...@moscow.com) -- PGP public key available from keyservers
http://www.eecs.wsu.edu/~cwiles/
Chip Pieroni
In article <4cpl92$72c...@salford.ac.uk>, Graham Penny (MLH...@news.salford.ac.uk) writes:
>In article <821025...@zenn.demon.co.uk>,
> marcus durham <mar...@zenn.demon.co.uk> wrote:
>> simon...@stonebow.otago.ac.nz "The Arch-Deviant" writes:
>
>>Goodness. Invaderload, I remember that ( still have it somewhere ).
>That
>>music and the brillientness of it all. And half the time Invaderload
>>was better than the game you where loading. I remember stopping
>>the tape after Invaderload had loaded on more than one occasion just
>>to play Invaiderload.
>>
>Yup, I did that... quite often in fact. Invaders still rules after all
>these years!! :)
>
>GP (Humming the Invaderload choon.. God, I can still remember it!!)
>
Ahhh, I remember. Ghostbusters had Invada-Load, two great
games on the one tape, eh ?
Cheers !
Chip Pieroni..
--
Chip Pieroni Vintage Systems Finder..
(United Kingdom..)
Jim Brain
In article <4cn3ba$i...@celebrian.otago.ac.nz>,
simon...@stonebow.otago.ac.nz (The Arch-Deviant) wrote:
>Isn't it scary what you remember? I was staring at the "please wait..." message
>on a swipe-card reader this morning, and started thinking about how much of my
>youth was spent reading those same words while waiting for Vic-20 programs to
>load off tape. This got me thinking about how, by the time we had a C-128 (but
>still no disk drive), things had advanced to "Invader Load", a hectic version
>of space invaders you could play while the tape rolled.
>
>The reason they could do this was that tape I/O was interrupt-driven, and to
>finally get to the point of this post I'm struck by the irony of a system that
>has interrupt-driven code for tape but software polling for disk I/O.
>
>My question is, why did Commodore implement the serial protocol in software?
>Both the 6522 and 6526 had hardware shift registers and associated interrupt
>capability, but until the 128's fast serial mode these were never used. Does
>anyone know why not?
>
>TIA...
>
>Simon Brady "I've been an awful woman all my life
>University of Otago A dreadful daughter and a hopeless wife
>Dunedin, New Zealand Well I've had my eyes on that carving knife
>simon...@stonebow.otago.ac.nz Oh you've been lucky, so far..."
> - Kirsty MacColl, 'Bad'
From the trivia:
Q $07B) When the VIC-20 was designed, the serial port throughput was roughly
equivalent to the throughput of the IEEE-488 bus? Why isn't it
very fast in production VICs?
A $07B) Let's go back to question $04F:
<begin insert>
Q $04F) What was the primary reason Commodore went to a serial bus
with the introduction of the VIC-20?
A $04F) Jim Butterfield supplied me with this one:
As you know, the first Commodore computers used the IEEE bus
to connect to peripherals such as disk and printer. I
understand that these were available only from one source:
Belden cables. A couple of years into Commodore's computer
career, Belden went out of stock on such cables (military
contract? who knows?). In any case, Commodore were in quite
a fix: they made computers and disk drives, but couldn't
hook 'em together! So Tramiel issued the order: "On our next
computer, get off that bus. Make it a cable anyone can
manufacture". And so, starting with the VIC-20 the serial
bus was born. It was intended to be just as fast as the
IEEE-488 it replaced.
<end insert>
And here is what Jim Butterfield followed up with:
"Technically, the idea was sound: the 6522 VIA chip has a "shift
register" circuit that, if tickled with the right signals (data and
clock) will cheerfully collect 8 bits of data without any help from
the CPU. At that time, it would signal that it had a byte to be
collected, and the processor would do so, using an automatic
handshake built into the 6522 to trigger the next incoming byte.
Things worked in a similar way outgoing from the computer, too.
We early PET/CBM freaks knew, from playing music, that there was
something wrong with the 6522's shift register: it interfered with
other functions. The rule was: turn off the music before you start
the tape! (The shift register was a popular sound generator). But
the Commodore engineers, who only made the chip, didn't know this.
Until they got into final checkout of the VIC-20.
By this time, the VIC-20 board was in manufacture. A new chip could
be designed in a few months (yes, the silicon guys had application
notes about the problem, long since), but it was TOO LATE!
A major software rewrite had to take place that changed the VIC-20
into a "bit-catcher" rather than a "character-catcher". It called for
eight times as much work on the part of the CPU; and unlike the shift
register plan, there was no timing/handshake slack time. The whole
thing slowed down by a factor of approximately 5 to 6.
When the 64 came out, the problem VIA 6522 chip had been
replaced by the CIA 6526. This did not have the shift register
problem which had caused trouble on the VIC-20, and at that time it
would have been possible to restore plan 1, a fast serial bus. Note
that this would have called for a redesign of the 1540 disk drive,
which also used a VIA. As best I can estimate - and an article in
the IEEE Spectrum magazine supports this - the matter was discussed
within Commodore, and it was decided that VIC-20 compatibility was
more important than disk speed. Perhaps the prospect of a 1541
redesign was an important part of the decision, since current
inventories needed to be taken into account. But to keep the
Commodore 64 as a "bit-banger", a new problem arose.
The higher-resolution screen of the 64 (as compared to the VIC-20)
could not be supported without stopping the CPU every once in a while.
To be exact: Every 8 screen raster lines (each line of text), the CPU
had to be put into a WAIT condition for 42 microseconds, so as to
allow the next line of screen text and color nybbles to be swept into
the chip.(More time would be needed if sprites were being used).
But the bits were coming in on the serial bus faster than that:
a bit would come in about every 20 microseconds! So the poor CPU,
frozen for longer than that, would miss some serial bits completely!
Commodore's solution was to slow down the serial bus even more.
That's why the VIC-20 has a faster serial bus than the 64, even though
the 64 was capable, technically, of running many times faster.
Fast disk finally came into its own with the Commodore 128."
--Jim
Q $07C) On Commodore computers, how much RAM is set aside as a tape buffer?
A $07C) 192 bytes is used as a tape buffer. Blocks of data on tape are 192
bytes long.
Q $07D) On Commodore computers, most every peripheral has a device number.
What is the device number of the screen?
A $07D) #3
Q $07E) What is the device number of the keyboard?
A $07E) #0
Q $07F) Commodore computers use 2's-complement notation to represent integers.
What is the 2's-complement hex representation of the signle byte -1?
A $07F) (This was not a Commodore specific question) Commodore computers
use this notation to represent integer quantities. In 2's complement
notation, a -1 looks like 11111111(binary) or $FF(hex).
End of Commodore Trivia Edition #8!
Jim Brain
br...@mail.msen.com
2306 B Hartland Road
Hartland, MI 48353
(810) 737-7300 x8528
--
Jim Brain, Embedded Systems Designer, Brain Innovations, Inc. (BII)
br...@mail.msen.com "Above views DO reflect my employer, since I'm my employer"
Dabbling in WWW, Embedded Systems, VR, Old CBM computers, and Good Times! -Me-
<a href=http://www.msen.com/~brain/>BII, VR, CBM, and personal info</a>
DoN. Nichols
Matthias Urlichs <sm...@work.smurf.noris.de> wrote:
[ ... ]
>wrote your own file system, and after you found the one (out of five) BASIC
>compilers which could process a nontrivial piece of software, you were able
>to run a _decent_ BBS on the thing, as compared to the trillions (well, it
>felt like that at the time) who didn't have a clue.
[ ... ]
>Those were the days. Now, if I wanted to, I'd redo the whole thing in HTTP
>and CGI scripts, and wouldn't offer a textual login at all. Well, OK, for
>new user registration ("Hello. This is The Foobar System. If you want in,
>configure your system for PPP, tell it to accept the IP number we assign to
>you, call again, and point your browser to http://10.20.30.40/newuser.
>
>If you don't know how to do that, ask your computer dealer; they should
>know about this stuff by now.
What about systems like my Sun SPARCstations? They already have
perfectly good IP (and properly assigned) addresses of their own, and might
not like being told that they have to route some packets to the IP address
*your* system assigns them. (Of course, if you had a *real* net connection,
and allowed access via that, the problem would go away.
--
Email: <dnic...@d-and-d.com> | ...!uunet!ceilidh!dnichols
Donald Nichols (DoN.) | Voice Days: (703) 704-2280 Eves: (703) 938-4564
My Concertina web page: http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
Jim Brain
In article <4d563t$r...@whidbey.whidbey.com>,
"Douglas Beattie Jr." <beat...@svc.ctc.edu> wrote:
>simon...@stonebow.otago.ac.nz (The Arch-Deviant) wrote:
> (snip!)
>>...tape I/O was interrupt-driven, and to
>>finally get to the point of this post I'm struck by the irony of a system that
>>has interrupt-driven code for tape but software polling for disk I/O.
>>
>>My question is, why did Commodore implement the serial protocol in software?
>>Both the 6522 and 6526 had hardware shift registers and associated interrupt
>>capability, but until the 128's fast serial mode these were never used. Does
>>anyone know why not?
>>
>
>Commodore wanted to use the 6551 ACIA in their original VIC-20 design,
>but MOS Technology could not supply the part on time for the VIC-20's
>first production. The intention was to add the 6551 to a later VIC
>design; with minor modifications, the Kernel was to be portable.
>
>Therefore they used EMULATION. All of that "bit-banging" code is a
>6551 emulator which has VIRTUAL REGISTERS at absolute offsets from a
>base address. I think the C64 was made in the likeness of the VIC-20
>and used a similar method...
Areyou sure about this. No one has ever confirmed the real reason, but
I was told the most probable reason was simply MONEY. CBM didn't think the
VIC would need fast RS232 or DISK, so those two parts were skimped on in the
end.
JIm
>
>--
>Douglas Beattie Jr. http://www.whidbey.net/~beattidp
Jim Butterfield
: In article <4d563t$r...@whidbey.whidbey.com>,
: "Douglas Beattie Jr." <beat...@svc.ctc.edu> wrote:
: >simon...@stonebow.otago.ac.nz (The Arch-Deviant) wrote:
: > (snip!)
: >>...tape I/O was interrupt-driven, and to
: >>finally get to the point of this post I'm struck by the irony of a system
: >>that has interrupt-driven code for tape but software polling for
: >> disk I/O.
The original PET design was for an "intelligent" drive which would
exchange data with the computer by means of a standard interface bus:
the IEEE-488 (or Hewlett-Packard GPIB, same thing).
This worked well and reasonably fast, for the times. In fact, a number
of commercial users hooked in special purpose instruments which came equipped
with that interface. The interface was reasonably fast for that era,
although the cables (by Belden) were costly and clumsy.
: >>My question is, why did Commodore implement the serial protocol in software?
: >>Both the 6522 and 6526 had hardware shift registers and associated interrupt
: >>capability, but until the 128's fast serial mode these were never used. Does
: >>anyone know why not?
: >>
First part of your question: why change from the parallel IEEE-488
interface to the serial bus? Credible legends tell us that Commodore was
vulnerable to cable shortages, and made to switch to serial for that
reason; they believed when they made the decision that there would be
little if any loss in speed. Most old timers clearly recall the
desperate days when the Belden cables could NOT be obtained, even by
Commodore.
: >Commodore wanted to use the 6551 ACIA in their original VIC-20 design,
: >but MOS Technology could not supply the part on time for the VIC-20's
: >first production. The intention was to add the 6551 to a later VIC
: >design; with minor modifications, the Kernel was to be portable.
: >
: >Therefore they used EMULATION. All of that "bit-banging" code is a
: >6551 emulator which has VIRTUAL REGISTERS at absolute offsets from a
: >base address. I think the C64 was made in the likeness of the VIC-20
: >and used a similar method...
This could be. I had heard the story as: Commodore thought the 6522
VIA chip for the job. It seemed to have all the requirements: a serial
register that could be hooked into the interrupt system. But the 6522
didn't work right in this operation (heck, we users knew that .. when you
used that serial register to generate sound, you had to disable other
features). And the "slowing down" of the VIC-20 bus was a result of
having to slap in "bit bang" coding at the last production-line moment.
: Areyou sure about this. No one has ever confirmed the real reason, but
: I was told the most probable reason was simply MONEY. CBM didn't think the
: VIC would need fast RS232 or DISK, so those two parts were skimped on in the
: end.
I suspect that the VIC-20 business was almost purely technical ..
the just couldn't get the fast bus working to meet production schedules.
(A production line is a wondrous thing to see .. all those tens of
thousands of components flowing into the production area, and you GOTTA
keep that line moving). Of course, if you want to look at it from
another direction, the need to keep production on schedule is also a
financial factor.
The switch to the 64 was perhaps the tragic part. By that time,
the 6522 was out of the design, and the original bus speed could have
been restored. But it appears to have been a marketing decision that
compatibility with VIC-20 peripherals must not be lost. So, in fact, the
bus had to be slowed even more! This matter was discussed in a copy of
the IEEE Spectrum about 10 years ago, so it has more credibility that
most apocryphical stories.
-- (the other) Jim
: JIm