[comp.sys.cbm] 6551 interfacing

bowen@cs.Buffalo.EDU (Devon E Bowen) (05/19/89)

I'm currently working on a board for the expansion bus that will give the
64 a 6551 UART for much higher baud rates. I finished the wiring last night,
plugged it in and it almost works. I've got the chip set up so it takes
over the I/O expansion area number 1 from 6E00 to 6EFF by running the
chip select directly to the IO1 pin on the bus. The problem I'm having is
that sometimes it takes more than one write to actually get the data to
the chip and sometimes reading multiple times from a chip register that
should be constant gives different results.

It was suggested to me that I might have some contention between chips
which is very possible considering the area I'm working in can be used for
I/O, RAM or character ROM. But the default memory configuration has I/O
in this area, and I didn't touch the configuration, so I assume it should
work ok. The one thought I had was that maybe I have to do something
with either the GAME line or the EXROM line. These lines aren't described
very well in the book and on the schematics the logic gets lost in the
PLA. Anyone know if I need to tug on one of these?

Any other suggests would be appreciated, too. Maybe I should just stick to
software...  8-)


Devon Bowen (KA2NRC)		FAX:	   (716) 636-3464
University at Buffalo		BITNET:    bowen@sunybcs.BITNET
				Internet:  bowen@cs.Buffalo.EDU
UUCP: ...!{watmath,boulder,decvax,rutgers}!sunybcs!bowen

daveh@cbmvax.UUCP (Dave Haynie) (05/19/89)

in article <5944@cs.Buffalo.EDU>, bowen@cs.Buffalo.EDU (Devon E Bowen) says:
> 
> I'm currently working on a board for the expansion bus that will give the
> 64 a 6551 UART for much higher baud rates. I finished the wiring last night,
> plugged it in and it almost works. I've got the chip set up so it takes
> over the I/O expansion area number 1 from 6E00 to 6EFF by running the
> chip select directly to the IO1 pin on the bus. 

I admit it's been awhile, but aren't the I/O spaces at DExx and DFxx?  In
any case, if you're basing your chip select on the IO1* pin, you won't get
any contention -- the mapping hardware will only generate a chip select
if the I/O space is mapped in.

> The problem I'm having is that sometimes it takes more than one write to 
> actually get the data to the chip and sometimes reading multiple times 
> from a chip register that should be constant gives different results.

I suspect that you're having setup time problems.  Basically, you can't
just hook a 6526 up to the expansion bus and expect it to work OK.  The
chip select and addresses must be valid at least 90ns before the PHI2
clock goes high.  Like I said, it's been a long time, but I think we used
to use something like this for the 6551A and similar chips:

	            +--------+
 		    |        O 4
		    |	+---------+
	            | 2 |   PR*   |5
	 PHI2_C64 --+---+D       Q+-----  PHI2_6551
	              3 |         |6
 	      DOT ------+CK     Q*|O----
		        |   CL*   |
	                +---------+
	                   1 O   74LS74
	                     |
	                     o +5V

The idea is to delay PHI2 going into the 6551 until the addresses and
chip select are valid.

> Devon Bowen (KA2NRC)		FAX:	   (716) 636-3464
> University at Buffalo		BITNET:    bowen@sunybcs.BITNET
> 				Internet:  bowen@cs.Buffalo.EDU
> UUCP: ...!{watmath,boulder,decvax,rutgers}!sunybcs!bowen
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession

po87553@tut.fi (Ojala Pasi Juhani) (05/19/89)

In article <5944@cs.Buffalo.EDU> bowen@cs.Buffalo.EDU (Devon E Bowen) writes:
>I'm currently working on a board for the expansion bus that will give the
>64 a 6551 UART for much higher baud rates. I finished the wiring last night,
>plugged it in and it almost works. I've got the chip set up so it takes
>over the I/O expansion area number 1 from 6E00 to 6EFF by running the
                                           ^^^^^^^^^^^^
I think it should be de00-deff?

You should try to use bigger condensators, I had the same trouble with
my SRAM-application. The values 100nF and up are fine (??)..
Where did you find that recipie? I have a Finnnish C64-magazine, which
has the same chip and plugs in DE00-DEFF (i/o1).
-- 
   /////////////////////               \\\\\\\\\\\\\\\\\\\\\\\\\\\\\
  //  Pasi Ojala     //   Pasbox v2.6   \\ The hardest thing doing \\
 // po87553@tut.fi  //    C64 forever    \\  a job is beginning it. \\
/////////////////////                     \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (05/19/89)

 > From: bowen@cs.Buffalo.EDU (Devon E Bowen)
 > Message-ID: <5944@cs.Buffalo.EDU>
 
 > I've got the chip set up so it takes
 > over the I/O expansion area number 1 from 6E00 to 6EFF by running the
 > chip select directly to the IO1 pin on the bus.
 
   That should put the chip at $DE00, not $6E00.
 
 > It was suggested to me that I might have some contention between chips
 
   If you used IO1 and don't have any other cartridges that also use the IO1 
slot (e.g. C64-Link), then I wouldn't think that's the problem. The IO1 signal 
is only enabled if the correct bank AND address are selected (one of the 
functions of the 82S100 PLA), so you're not going to be in contention with RAM 
or the character generator.
 
   It might be that other chip select lines aren't properly selected (might 
they be floating, or connected to other lines?)...
 
 > The one thought I had was that maybe I have to do something
 > with either the GAME line or the EXROM line. These lines aren't described
 > very well in the book and on the schematics the logic gets lost in the
 > PLA. Anyone know if I need to tug on one of these?
 
   No, leave them floating (or pull them high). You only need these if you're 
going to be imposing ROM in the C64 memory map.
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG

bowen@cs.Buffalo.EDU (Devon E Bowen) (05/20/89)

In article <6925@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>I admit it's been awhile, but aren't the I/O spaces at DExx and DFxx?

Yep. That was a typo.

>I suspect that you're having setup time problems.  Basically, you can't
>just hook a 6526 up to the expansion bus and expect it to work OK.  The
>chip select and addresses must be valid at least 90ns before the PHI2
>clock goes high.

That could be it. I'm still pretty new to all this hardware stuff, and
I'm still overlooking things like timing. Live and learn. Thanks for the
suggestion. I'll give it a try this weekend.

Devon

rcwlobe@klipper.cs.vu.nl (Reg Lobee) (05/22/89)

In article <6925@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> I suspect that you're having setup time problems.  Basically, you can't
> just hook a 6526 up to the expansion bus and expect it to work OK.  The
> chip select and addresses must be valid at least 90ns before the PHI2
> clock goes high.

I have connected an 6526 directly to my computer and it works like
a charm. I use it as an I/O cartridge without any problems so far.

|^^\   | Reg Lobee        |==================================|
|__/   | rcwlobe@cs.vu.nl | Disclaimer:                      |
|\     | V.U. University  | Sorry folks no disclaimer today. |
| \ eg | The Netherlands  |==================================|

bowen@cs.Buffalo.EDU (Devon E Bowen) (05/23/89)

Well thanks for all the help. The problem was with the timing of the clock.
I had to use the latch cicuit that was posted to delay the clock enough to
get it to work. Actually, I needed two of the latches in series to get a
long enough delay. But now everything's working fine. Thanks again and happy
hacking...


Devon Bowen (KA2NRC)		FAX:	   (716) 636-3464
University at Buffalo		BITNET:    bowen@sunybcs.BITNET
				Internet:  bowen@cs.Buffalo.EDU
UUCP: ...!{watmath,boulder,decvax,rutgers}!sunybcs!bowen

daveh@cbmvax.UUCP (Dave Haynie) (05/25/89)

in article <2284@botter.cs.vu.nl>, rcwlobe@klipper.cs.vu.nl (Reg Lobee) says:

> In article <6925@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
>> I suspect that you're having setup time problems.  Basically, you can't
>> just hook a 6526 up to the expansion bus and expect it to work OK.  

Whoops, that's supposed to say 6551, not 6526.  The 6551 has an address to 
PHI setup requirement of 90ns.  The timing on the 6526 is much easier to
deal with, meaning that even if it's not quite correct, it'll usually work
just hooked up directly.  I don't recall the exact setup time for the
6526...

> I have connected an 6526 directly to my computer and it works like
> a charm. I use it as an I/O cartridge without any problems so far.

It's important to know that just because something works in one given
situation, it's not necessaily going to always work.  The 90ns setup
for the 6551, for example, is a worst-case figure.  Some parts may only
require 75ns, or even less.  However, if you give it 90ns, every single
part will work.  For home hacking, if it work, do it.  For a commercial
product, you'd better be sure it'll always work.

> |^^\   | Reg Lobee        |==================================|
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession

izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (05/25/89)

 > From: daveh@cbmvax.UUCP (Dave Haynie)
 > Newsgroups: comp.sys.cbm
 
 > For home hacking, if it work, do it.  For a commercial
 > product, you'd better be sure it'll always work.
 
   Like the 1700/1750 REUs, that didn't work on some C64s, eh? <grin>
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG

daveh@cbmvax.UUCP (Dave Haynie) (06/01/89)

in article <2451.247F6F5D@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says:
>> From: daveh@cbmvax.UUCP (Dave Haynie)
>> For home hacking, if it work, do it.  For a commercial product, you'd 
>>better be sure it'll always work.

>    Like the 1700/1750 REUs, that didn't work on some C64s, eh? <grin>

The 1700/1750 units are C128 products.  They aren't intended for the C64,
and in fact a 1750 has an excellent chance of turning your C64 power
supply into a smoking pile of ash.  While they _may_ work on a C64, it's
at your own risk....

>  Geoffrey Welsh - via FidoNet node 1:221/162
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession

izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (06/02/89)

 > From: daveh@cbmvax.UUCP (Dave Haynie)
 > The 1700/1750 units are C128 products.  They aren't intended for the C64,
 > and in fact a 1750 has an excellent chance of turning your C64 power
 > supply into a smoking pile of ash.  While they _may_ work on a C64, it's
 > at your own risk....
 
   My comments about the 1700 & 1750 working on the C64 may have been flippant 
and rather presumptuous about the interchangeability of accessories for the 
C128, but now that you mention it, I do know an appropriate application of 
your rule that things released commercially better work reliably: the C64 
power supply.
 
   You see, many of us who would be adventurous enough to plug a 1750 into a 
C64 threw out our C= issue power supply long ago (assuming that it was still 
working!) and replaced it (in my case with a boat-anchor device ugly as heck 
but built with devices so over-rated that it easily handled TWO C64s with 
cartridges and didn't even get hot).
 
   I know that nothing lasts forever and I do not expect power supplies to be 
immune to this, but the C64 supply is a great example of bad public relations. 
While working at the computer department of Eaton's (a Canadian department 
store, in fact the place the PETs first sold in Canada), Jay Winick (author of 
the Dircon BBS software) saw literally HUNDREDS of C64 power supplies 
returned, with their outer plastic cases MELTED. To Commodore's credit, they 
didn't seem to pose a fire hazard even in that condition, but it must not be 
confidence-inspiring to have your computer die on you and then find that the 
power supply had overheated so much that it had softened the plastic of the 
case.
 
   It would appear that the transformers in the C64 power supply were 
custom-wound, or at least sought out carefully; given the effort involved in 
that I wonder why an oversized (and difficult to find) high-current 7805-type 
device was used in stead of the much hardier (and easier to find!) LM323? In 
retrospect, several companies made (and continue to make) small fortunes 
selling C64 replacement power supplies.
 
   Please, Commodore, don't allow marginal engineering like this to happen 
again. Most of Commodore's engineering shortcomings in the past have been the 
result of assumptions that certain things would NOT be done with a particular 
computer model. I am sure that the C64 design team has been surprised again 
and again with what their toy has been made to do.
 
   Geoff
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG

daveh@cbmvax.UUCP (Dave Haynie) (06/12/89)

in article <2483.24875872@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says:

>    My comments about the 1700 & 1750 working on the C64 may have been flippant 
> and rather presumptuous about the interchangeability of accessories for the 
> C128, but now that you mention it, I do know an appropriate application of 
> your rule that things released commercially better work reliably: the C64 
> power supply. ...

Point taken.  C64 power supplies were not a marvel of technology, even in their
time.  If nothing else, I should point out that all the folks responsible for
that device were long gone even by the time we made the C128 (and it's 
respective power supply).  I was around for the 128, and I wrote the spec for
the supply, at least to the point of how much juice it can crank out.  I hope
that was a little better.

I leave as an exercise to the reader the task of figuring out where the C64
people are today....

>    Geoff

-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession

Geoffrey.Welsh@p0.f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (06/12/89)

 > From: daveh@cbmvax.UUCP (Dave Haynie)
 > Message-ID: <7085@cbmvax.UUCP>
 
 > I was around for the 128, and I wrote the spec for
 > the supply, at least to the point of how much juice it
 > can crank out.  I hope that was a little better.
 
   'Twas a marvel. I don't know of any problems caused by a C128 drawing too 
much power from its supply. I never saw a C128 ps fail, but I have read 
somewhere that at least one has (which, I suppose, was inevitable). Of course, 
the switching power supply was a completely different approach (and probably 
significantly more expensive).



--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171.0!Geoffrey.Welsh
 Internet: Geoffrey.Welsh@p0.f171.n221.z1.FIDONET.ORG