6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 6:53 pm

All times are UTC




Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: GAL Address Decoder
PostPosted: Sun Apr 05, 2015 9:27 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Generally, the output of an uninitialised storage device is not defined - it will be either 0 or 1. So, if you're lucky, you might find the latch initialises to all-zero, but more likely it will come up random. It won't come up floating or in an intermediate state though.

But, I notice this part has a CLR* input: you should use that to power-on reset to all zero.
http://www.ti.com/lit/ds/scls134e/scls134e.pdf

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Sun Apr 05, 2015 10:51 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
BigEd wrote:
Generally, the output of an uninitialised storage device is not defined - it will be either 0 or 1. So, if you're lucky, you might find the latch initialises to all-zero, but more likely it will come up random. It won't come up floating or in an intermediate state though.

But, I notice this part has a CLR* input: you should use that to power-on reset to all zero.
http://www.ti.com/lit/ds/scls134e/scls134e.pdf

Cheers
Ed

Thanks Ed. I hadn't spotted that and, yes, it should work nicely with the /reset line.


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Sun Apr 05, 2015 4:05 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Incidentally, there's a 74AC version of the 74HC259. In general, 74AC logic is faster than 74HC and has stronger drive. With the way in which you are cascading logic you can use all the speed you can get.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Sun Apr 05, 2015 6:21 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
BigDumbDinosaur wrote:
Incidentally, there's a 74AC version of the 74HC259. In ge0neral, 74AC logic is faster than 74HC and has stronger drive. With the way in which you are cascading logic you can use all the speed you can get.

I did intend to buy one, but Farnell (where I get most of my components) don't seem to stock one (tried searching for 74AC259 - nothing comes up).
With regard to speed; Are you talking about for RAM bank swapping itself? I.e. having to talk through the VIA to the latch if a bank needs changing? Obviously, this would only effect changing the swap bank which is why I'm opting for a latch to hold the values.
This is my latest circuit digram with the address decode in the bottom left and the latches in the bottom right.

[EDIT] Or do you mean the logic in the GAL? If so then it should have a propagation of 15ns or less according to the datasheet.


Attachments:
65c02_b1rev0.png
65c02_b1rev0.png [ 258.85 KiB | Viewed 1180 times ]


Last edited by banedon on Sun Apr 05, 2015 7:56 pm, edited 3 times in total.
Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Sun Apr 05, 2015 7:39 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
If you want to save some VIA pins, it looks like you could make the 259's, the LCD, and the keyboard controller share data lines. As long as only one thing is selected or strobed at a time, their data lines can be shared. You could get all that, and a printer interface, and more, all on one VIA and have the other one left free for experiments.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Sun Apr 05, 2015 11:55 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
I've already read your excellent primer with regards to this and was going to tackle that at a later point (along with RS232C which I find slightly daunting lol).


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Mon Apr 06, 2015 12:53 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
I have an RS-232 primer at http://wilsonminesco.com/RS-232/RS-232primer.html . (My apologies-- if you like pictures and diagrams, well, very few of them are in the first half of the article. Hopefully you'll still find it very clear.) RS-232 was later called EIA-232 and most recently TIA-232-F (based on what organizations adopted it as a standard, and the "-F" ending is the latest revision), but if you say "RS-232," everyone knows what you mean. It's an old industry workhorse that still very good for simplicity, long cable lengths, the fact that you can make up your own connectors, it's easy to view on an oscilloscope and troubleshoot if necessary, and probably other virtues I'm forgetting at the moment.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Mon Apr 06, 2015 1:51 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
banedon wrote:
BigDumbDinosaur wrote:
Incidentally, there's a 74AC version of the 74HC259. In ge0neral, 74AC logic is faster than 74HC and has stronger drive. With the way in which you are cascading logic you can use all the speed you can get.

I did intend to buy one, but Farnell (where I get most of my components) don't seem to stock one (tried searching for 74AC259 - nothing comes up).
With regard to speed; Are you talking about for RAM bank swapping itself? I.e. having to talk through the VIA to the latch if a bank needs changing? Obviously, this would only effect changing the swap bank which is why I'm opting for a latch to hold the values.
This is my latest circuit digram with the address decode in the bottom left and the latches in the bottom right.

[EDIT] Or do you mean the logic in the GAL? If so then it should have a propagation of 15ns or less according to the datasheet.

I'm referring to the prop time through the 65C22 added to the time required for the '259 to react to whatever comes out of the 65C22. Any GAL these days will be more than fast enough.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Mon Apr 06, 2015 1:36 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi Banedon,

any reason why you connect the '259 to the VIA port, it's actually a waste of VIA pins in my opinion. I always use them as they have been used in the Apple II computer. You need a /SEL which is qualified with PHI2 and covers a range of 16 addresses. Then I connect D -> A0, S0 ->A1, S1 ->A2 and S2 -> A3. /CLR is connected to /RES so you have a clear initial state. Then a simple LDA instruction can throw any of the flip-flop in the '259.

cheers

Peter


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Mon Apr 06, 2015 10:31 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
cbscpe wrote:
Hi Banedon,

any reason why you connect the '259 to the VIA port, it's actually a waste of VIA pins in my opinion. I always use them as they have been used in the Apple II computer. You need a /SEL which is qualified with PHI2 and covers a range of 16 addresses. Then I connect D -> A0, S0 ->A1, S1 ->A2 and S2 -> A3. /CLR is connected to /RES so you have a clear initial state. Then a simple LDA instruction can throw any of the flip-flop in the '259.

cheers

Peter

Hi Peter
It's mostly because I want to keep things off the 6502 address and data buses as much as possible. That way if I really need to put something on them then I don't have to worry about having already overloaded them.

But going with your idea, is this what you're suggesting? The only part I'm a bit uncertain of is where /SEL comes from. I assume a VIA pin as in my circuit diagram (please ignore it saying PA0- it should say PB0)?
If so, then surely then you have a disjunction between the right address being on the address bus and /SEL (/LE) going low.
Attachment:
latch_from_addrbus.png
latch_from_addrbus.png [ 14.55 KiB | Viewed 1140 times ]


[EDIT] ...or would use use the decoder to intercept a certain range (as small as possible) and then enable the latch select (/LE) pin? I'd have to introduce mode address pins if I did that to avoid wasting massive amounts of address space.


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Tue Apr 07, 2015 5:01 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi banedon,

yes except something is odd with our 74HC259, pin 14 is the latch enable and should be the /LATCH_SEL signal and not +5V, the LATCH_SEL has no pin number. Have a look at it. Of course I would have the GAL decode a small (minimum 16-byte) range and only this range enables LE of the '259. I would add a 74ACT138 between the IO_SEL pin and the IO devices.
As for the load, a 74HCT259 is neglectable. I have 65C816 working with about 15 CMOS devices connected to the address bus without any problem.

cheers

Peter


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Tue Apr 07, 2015 6:37 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
cbscpe wrote:
Hi banedon,

yes except something is odd with our 74HC259, pin 14 is the latch enable and should be the /LATCH_SEL signal and not +5V, the LATCH_SEL has no pin number. Have a look at it. Of course I would have the GAL decode a small (minimum 16-byte) range and only this range enables LE of the '259. I would add a 74ACT138 between the IO_SEL pin and the IO devices.
As for the load, a 74HCT259 is neglectable. I have 65C816 working with about 15 CMOS devices connected to the address bus without any problem.

cheers

Peter

Sorry, that's my fault. I used a generic '259 device from Eagle CADs library and added on the /LE (/LATCH_SEL) manually.
I'll see if I can get a proper TI one.

My concern about adding the '259 in the way that you're suggesting is that I will have to either sacrifice a large amount of address space or lose more pins on the GAL to decode a 16 byte range. I think that would mean I would have to decode A15-A4 (12 pins worth) as opposed to A15-A12 (4 pins) that I'm using at the moment.

With regard to the I/O; I'm using one address decode pin out of the GAL which connects to /CS2 of all of the VIA's and then A4 to CS1 of VIA#1 and A5 to CS1 of VIA#2.


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Tue Apr 07, 2015 7:30 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
banedon wrote:
It's mostly because I want to keep things off the 6502 address and data buses as much as possible. That way if I really need to put something on them then I don't have to worry about having already overloaded them.

At viewtopic.php?t=1908, Daryl says he put my 4Mx8 SRAM module on his SBC-4 and ran it at 12MHz with no problem. The SRAM module has 8 512Kx8 SRAM ICs on it, and he had other things on the buses as well, with no transceivers. WDC's pin drivers seem to be much stronger than the data sheets let on. Keep in mind of course that a CMOS input offers no DC load. The only load is a few pF of capacitance. That's not to say you don't still have to pay attention to inductance and transmission-line effects of traces and connectors though. No amount of drive strength can overcome problems there.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Tue Apr 07, 2015 8:07 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi banedon,

I then suggest that you "export" some functions from your GAL to a more appropriate device. E.g. add a AND gate for the IRQs (e.g. 74HCT21, this part of your computer is not time critical at all), or you could add a 74ACT138 to decode the IO range (this however is time-critical so you need a fast version).

cheers

Peter


Top
 Profile  
Reply with quote  
 Post subject: Re: GAL Address Decoder
PostPosted: Tue Apr 07, 2015 8:29 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Ok you've both convinced me :). I'm going by what I've read elsewhere that you shouldn't over burden the buses - and I have no experience as to when this might happen.

What about having a couple of GALs in parallel? One intercepts the I/O and ROM and latch, the other does the RAM?
At least until I look at using PLCCs.

I.e.:
Attachment:
two_pals.PNG
two_pals.PNG [ 25.92 KiB | Viewed 1108 times ]


Or perhaps:
Attachment:
two_pals2.PNG
two_pals2.PNG [ 26.2 KiB | Viewed 1108 times ]


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: