6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Nov 15, 2024 5:46 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 2 of 2
  [ 24 posts ]  Go to page Previous  1, 2
  Previous topic | Next topic 
Author Message
rwiker
PostPosted: Sat Nov 03, 2012 9:11 am 
Offline

Joined: Thu Mar 03, 2011 5:56 pm
Posts: 284
Another option would be Daryl Rictor's pre-programmed PAL decoder: http://sbc.rictor.org/parts/decoder.html
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sat Nov 03, 2012 10:45 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8541
Location: Southern California
Yes, that one is referenced in the primer page I linked to earlier (http://wilsonminesco.com/6502primer/addr_decoding.html), but I was thinking I ought to make it more obvious. It kind of gets lost in 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  
BigDumbDinosaur
PostPosted: Sat Nov 03, 2012 1:11 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8487
Location: Midwestern USA
Dajgoro wrote:
An xc9536 or xc9572 cpld can be used as a memory mapper, since they are cheap and run on 5V.

Good suggestion. You could also use equivalents from other manufacturers beside Xilinx. My POC V2 will be using an Atmel 1508AS, which is a 5 volt device with considerable resources.

In fact, you could make a pretty decent MMU out of a 22V10 GAL if your needs aren't too extensive (see above reference to Daryl's unit). In this day and age of CPLDs and FPGAs, it's easy to forget that GALs are still pretty capable devices, especially when their relatively modest footprint is considered. Many of us aren't trying to build servers out of 65C02s and 65C816s, so smaller PLDs are still viable. :D Also, don't forget the time-honored technique of using an EPROM as an MMU. The first version of the Lt. Kernal hard disk subsystem for the C-64 used EPROM logic to map the host adapter in and out of MPU space (later versions used PLDs).

I think the point to be understood is to look at how currently-produced devices can be adapted, rather than overpaying for old silicon that went out of production years ago.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Dajgoro
PostPosted: Sat Nov 03, 2012 3:27 pm 
Offline
User avatar

Joined: Mon Aug 08, 2011 2:48 pm
Posts: 808
Location: Croatia
Noooooo Palasm :D .
I had a lab with it, its kinda tedious, but once you figure it out, it is not so scary anymore :mrgreen: .

If a bigger cpld is used, you can implement the little internal ram that stores the memory map, like in the 74ls612.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Nov 03, 2012 4:37 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8487
Location: Midwestern USA
Dajgoro wrote:
Noooooo Palasm :D .
I had a lab with it, its kinda tedious, but once you figure it out, it is not so scary anymore :mrgreen: .

PALASM??? Yer living 25 years in the past. :roll:

Quote:
If a bigger cpld is used, you can implement the little internal ram that stores the memory map, like in the 74ls612.

You could, but since the logic equations are/should be tailored to the particular architecture you want, why waste P-terms and MCs in that fashion? If you want to incorporate selectable memory maps, you can set up some virtual registers that use bit patterns stored within to expose different combinations of RAM, ROM and I/O, in a fashion similar to what was done in the MMU in the Commodore 128. The average CPLD is many times more powerful than was the C-128's MMU, which was more powerful than the 'LS612. So why would you treat the CPLD as an overgrown 'LS612?

Again, the idea is to use current thinking with current devices. Attaching 25 year old methodology to contemporary hardware is retrogressive, don't you think? Just a curmudgeonly opinion.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Dajgoro
PostPosted: Sun Nov 04, 2012 5:44 am 
Offline
User avatar

Joined: Mon Aug 08, 2011 2:48 pm
Posts: 808
Location: Croatia
BigDumbDinosaur wrote:
PALASM??? Yer living 25 years in the past. :roll:

Ha, that is what i had to work with last year in lab, we only had Palasm for programming the gal devices on the development boards. So it seems my collage is living in the past :D.

As for using more modern technology, i agree, and i am going to use cpld-s on my next sbc projects. I always kinda want to try to thinker with all kind of stuff, old and new. :D

Ill have to reprogram all the cpld-s every 20 years, i just hope that ill have a pc around :mrgreen: .
Top
 Profile  
Reply with quote  
HCF
PostPosted: Sun Nov 04, 2012 3:37 pm 
Offline

Joined: Thu Nov 01, 2012 5:21 pm
Posts: 6
BigDumbDinosaur wrote:
As you can see, the MPU's A8, A9 and A10 lines drive A0, A1 and A2 on the decoder. A8 is equal to 2^8, A9 is equal to 2^9 and A10 is equal to 2^10. 2^8=256, so that's where the one page increment comes from. The final hint involves the A11 line, which you don't see anywhere in the circuit... :D There are only three inputs to the decoder, so you should be able figure it out from here.


Thanks, It appears that I would want to connect the lines as follows:

Code:
 
(BUS) -> (74AC138)
 A9 -> A0
A10 -> A1
A11 -> A2



BigDumbDinosaur wrote:
BTW, any particular reason for partitioning the I/O block in two page chunks? You're not gaining anything by doing so, as the 74AC138 only has 8 outputs. I use one page increments because it opens the door to adding another decoder to fill the range $D800-$DFFF, allowing up to 16 devices, if the need arises.


I see your point. I was thinking about future expansion with the bus design. I had originally wanted to include 8 expansion points on the SBC. The first Two or so would be taken by on-board devices (6551's, RTC, MMU if I get lucky), leaving 5 or 6 for expansion. I had lofty long term goals of a video or extension ram device, and thought it would be nice to have a single page available to write to, that was separate from the first page. The first page would include registers and such.

BigDumbDinosaur wrote:
Using the WDC part is a wise choice, as it is the definitive version, plus it can be run at any speed you might care to try (up to 20 MHz at 5 volts). Be sure to pull up unused inputs to Vcc to avoid unpleasant surprises.


I'll make a note of that.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sun Nov 04, 2012 5:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8487
Location: Midwestern USA
HCF wrote:
It appears that I would want to connect the lines as follows:
Code:
 
(BUS) -> (74AC138)
 A9 -> A0
A10 -> A1
A11 -> A2

You got it right.

Quote:
BigDumbDinosaur wrote:
BTW, any particular reason for partitioning the I/O block in two page chunks? You're not gaining anything by doing so, as the 74AC138 only has 8 outputs. I use one page increments because it opens the door to adding another decoder to fill the range $D800-$DFFF, allowing up to 16 devices, if the need arises.

I see your point. I was thinking about future expansion with the bus design. I had originally wanted to include 8 expansion points on the SBC. The first Two or so would be taken by on-board devices (6551's, RTC, MMU if I get lucky), leaving 5 or 6 for expansion. I had lofty long term goals of a video or extension ram device, and thought it would be nice to have a single page available to write to, that was separate from the first page. The first page would include registers and such.

A caveat that we have often offered to someone building a first design is to keep it as simple as it can be. Too much creeping featurism all too often ends up killing the project because the complexity gets out of hand. In other words, circle the airport a few times while flying a Piper Cub before you take off for Japan at the controls of a 747.

I suggest that for a first effort you keep the I/O hardware to a reasonable minimum so you don't get hit with too many simultaneous problems if it doesn't work right on the first try (a not-uncommon occurrence). Once you've gotten it to where it is stable and can compute, then go ahead and add more hardware. Of course, construction methods will dictate how much you can add and how easily. Also, you'll have to keep fanout and distributed capacitance issues in mind. Garth covers quite a bit on those items in his primer, plus there's plenty of discussion on these matters scattered about in the forums. This is an area where use of the 74AC logic helps.

Incidentally, use of an "MMU" (in whatever form you may conceive) implicitly dictates a different design than your first effort. The effect of an MMU is usually to produce a "translated" address bus that fools the MPU into seeing things that it normally wouldn't be able to see in a 64KB address space. However, once you decide to take that route it would be prudent to look at the 65C816.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sun Nov 04, 2012 8:50 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8541
Location: Southern California
The primer page on expansion buses (and the surprising amount you can do today without expansion buses) is at http://wilsonminesco.com/6502primer/ExpBusIntrfc.html

_________________
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  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 2
  [ 24 posts ]  Go to page Previous  1, 2

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 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:  
6502.org is an ongoing project by Mike Naberezny and contributors.