6502.org • View topic - MARC-2 project

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Hardware

All times are UTC

MARC-2 project

Page 1 of 3

[ 31 posts ]

Go to page 1, 2, 3 Next

Previous topic | Next topic

Author

Message

lordbubsy

Post subject: MARC-2 project

Posted: Sat Dec 07, 2013 2:27 pm

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

MARC-2 project

With a lot of help I figured out how to replace glue logic with a CPLD. At first I bought a couple of XC9572XL PC44 CPLD’s which are 3.3V. After some struggle I can report that they work quite well with NMOS / TTL logic. However MARC-2 will be CMOS and I want to use 5V. So I ordered some chips from eBay.

Using up and until webpack version ISE 10.1, I can use the homemade Xilinx parallel Cable III and use ABEL. I tried to get into Verilog, but I haven’t got the feeling for it.

XC9572-7PC84C $4,00
XC9572-10PC44C $5,00
XC95108-7PC84C $10,00
http://www.ebay.co.uk/itm/XC9572-7PC84C ... 5651395ccf
http://www.ebay.co.uk/itm/XC9572-10PC44 ... 56513a9f9a
http://www.ebay.co.uk/itm/XC95108-7PC84 ... 589aeab55b

I didn’t receive them yet...

So far MARC-2 is planned with the following IC’s:

• CPU W65C816S PDIP-40
• RAM AS6C4008-55 Alliance Memory SRAM 512K x 8 PDIP-32
• ROM AT28C256-15PU Atmel EEPROM 32K x 8 PDIP-32
• GPIO W65C22S VIA PDIP-40
• GPIO W65C22S VIA PDIP-40
• RS232 SC26C92C DUART PLCC-44
• 65SPI XC95108 PLCC-84 / XC9572 PLCC-84 / XC9572 PLCC-44
• GLUE XC95108 PLCC-84 / XC9572 PLCC-84 / XC9572 PLCC-44
• VGA XC95108 PLCC-84 / XC9572 PLCC-84 / XC9572 PLCC-44
• SOUND ??? *nervous*

Because of the programmable logic, I could make it as simple or difficult as I want / can. But I have some things already in mind:

Depending on the extend of I/O pins and used macro cells 65SPI, GLUE and VGA will be spread over CPLD’s
Firmware will be loaded from EEPROM to RAM during reset.
If 512kB SRAM shouldn’t be enough, I could stack them on each other! So I leave some pins reserved for that.
My search results regarding VIDEO:

http://www.ulrichradig.de/home/index.ph ... it_c_graka
http://www.lucidscience.com/pro-vga%20v ... or-14.aspx
http://www.pyroelectro.com/tutorials/fp ... istor_dac/
http://elm-chan.org/works/crtc/report.html
http://sbc.rictor.org/sbc/info3.html
http://www.xess.com/static/media/appnot ... vgagen.pdf
http://www.xess.com/static/media/appnotes/vga.pdf
http://excamera.com/sphinx/gameduino/porting.html

There are so many possibilities,

• CPLD
• FPGA
• VDC VIC VICII Yamaha 99xx

interface with:

• bitmapped
• a bunch of video registers
• SPI

On MARC-1, I have the gameduino going. It’s interfaced with 65SPI.
After a reset, the gameduino normally comes with that stupid startup screen, it can be prevented by clearing it’s memory right after reset. By not clearing everything, you can leave the charset and use it for displaying text.

For MARC-2 I’d like to consider video with the CPLD’s. I’d choose for VGA 256(X) x 240(Y) x 256(colors), those 60kB somewhere mapped in the SRAM. A charset would also be loaded from EEPROM to RAM during reset.

Some doubt remains regarding the VPA and VDA issue BDD addresses.
viewtopic.php?p=29748#p29748
The only thing I’m concerned about is that I also will choose for the SC26C92C and W65C816S. However, connecting VPA and VDA to the CPLD would solve any upcoming problem.

_________________
Marco

Top

GARTHWILSON

Post subject: Re: MARC-2 project

Posted: Sat Dec 07, 2013 4:16 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California

Quote:

If 512kB SRAM shouldn’t be enough, I could stack them on each other!

or just use my 4Mx8 5V 10ns SRAM module: http://wilsonminesco.com/
There's forum discussion on it at viewtopic.php?f=4&t=1908

_________________
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

BigDumbDinosaur

Post subject: Re: MARC-2 project

Posted: Sat Dec 07, 2013 7:42 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

lordbubsy wrote:

MARC-2 project...

• CPU W65C816S PDIP-40
• RAM AS6C4008-55 Alliance Memory SRAM 512K x 8 PDIP-32
• ROM AT28C256-15PU Atmel EEPROM 32K x 8 PDIP-32
• GPIO W65C22S VIA PDIP-40
• GPIO W65C22S VIA PDIP-40
• RS232 SC26C92C DUART PLCC-44
• 65SPI XC95108 PLCC-84 / XC9572 PLCC-84 / XC9572 PLCC-44
• GLUE XC95108 PLCC-84 / XC9572 PLCC-84 / XC9572 PLCC-44
• VGA XC95108 PLCC-84 / XC9572 PLCC-84 / XC9572 PLCC-44
• SOUND ??? *nervous*

Why use the DIP40 version of the '816 and 65C22? You're already committed to the PLCC package for your CPLD and DUART, so you might as well go with PLCC as much as possible and reduce the total footprint of your machine. The PLCC44 versions of the '816 and 65C22 use about 60 percent of the board real estate of the DIP40 packages. During my design of the POC V1.0 unit, I conclusively determined that I could build a more compact and tighter layout with PLCC packages than with DIPs, and only used DIPs for the glue logic and the MAX238. POC V1.1 has the SOIC verion of the MAX238, which is physically about half the size of the DIP24.

POC V2 will use SOIC for the bus drivers and the clock generator flop, completely eliminating through hole components (although the PLCC parts will be in sockets). Speaking of the MAX238, I don't see any mention of that device or similar in your BoM.

GARTHWILSON wrote:

Quote:

If 512kB SRAM shouldn’t be enough, I could stack them on each other!

or just use my 4Mx8 5V 10ns SRAM module: http://wilsonminesco.com/
There's forum discussion on it at viewtopic.php?f=4&t=1908

My recommendation as well. Your CPLD will have enough outputs to drive the eight chip selects of Garth's DIMM, giving you an address range of $000000-$3FFFFF. A decoding map would be as follows:

Code:

   Address Range             /CEn   A21  A20  A19
—————————————————————————————————————————————————
$000000 - $07FFFF  (512KB)   /CE0    0    0    0
$080000 - $0FFFFF (1024KB)   /CE1    0    0    1
$100000 - $17FFFF (1536KB)   /CE2    0    1    0
$180000 - $1FFFFF (2048KB)   /CE3    0    1    1
$200000 - $27FFFF (2560KB)   /CE4    1    0    0
$280000 - $2FFFFF (3072KB)   /CE5    1    0    1
$300000 - $37FFFF (3584KB)   /CE6    1    1    0
$380000 - $3FFFFF (4096KB)   /CE7    1    1    1
—————————————————————————————————————————————————

The A0-A15 DIMM inputs would be driven by the corresponding MPU address bus lines, and the A16-A18 DIMM inputs driven by outputs from the glue logic CPLD that latches the A16-A23 address bits during the Ø2 low part of a valid memory cycle (that is, when VDA | VPA is true). So your address logic would be "artificially" generating A16-A21 to drive the 4MB DIMM. The DIMM chip selects are generated by an analog to the ubiquitous 74xx138 3-8 decoder, using the A19-A21 address bits as "inputs."

I discuss the use of Garth's DIMM in a post in my POC V2 topic.

Incidentally, have you given any consideration to the potential bus loading that all that hardware is going to create?

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

Top

lordbubsy

Post subject: Re: MARC-2 project

Posted: Sun Dec 08, 2013 12:59 pm

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

As always, a lot of information, great!

Quote:

Why use the DIP40 version of the '816 and 65C22?

mainly a matter of availability and costs. Some IC’s I already have.

I just saw Jameco has the '816 available in PLCC. OTOH DIP40 is breadboard friendly...

On MARC-1 I didn’t use a RS232 level converter, which I now miss. So it has to be included on MARC-2. I’ll also include a 78S05 with the surrounding caps etc.

Garth, your SRAM module is superb! It’s definitely on the consideration list.

Obviously MARC-2 will be very similar to Daryl’s SBC-3, but not an exact copy of it. So regarding busload, I trust the design of SBC-3. After all it doesn’t have to be a speed demon.

Quote:

eight separate CE\ pins, so you can get faster selects by
handling the computer's entire address-decoding scheme with
a CPLD

I’m glad that I now have the opportunity to use CPLD’s although being a complete rooky. Especially that it can be changed after the computer has been build!

_________________
Marco

Last edited by lordbubsy on Sun Dec 08, 2013 5:27 pm, edited 1 time in total.

Top

GARTHWILSON

Post subject: Re: MARC-2 project

Posted: Sun Dec 08, 2013 4:03 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California

lordbubsy wrote:

Quote:

Why use the DIP40 version of the '816 and 65C22?

mainly a matter of availability and costs. Some IC’s I already have.

I just saw Jameco has the '816 available in PLCC. OTOH DIP40 is breadboard friendly...

There are PLCC sockets, both soldertail type and WW, that go into standard perfboards (although the WW ones are very expensive). I do hope you don't mean solderless breadboard though-- those are the worst of all worlds for digital.

Quote:

Garth, you SRAM module is superb! It’s definitely on the consideration list.

Thanks. I tried other approaches (like stacking the SRAM ICs and putting the stack on a DIP header, but it just was not practical.

_________________
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

nyef

Post subject: Re: MARC-2 project

Posted: Sun Dec 08, 2013 5:02 pm

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235

GARTHWILSON wrote:

lordbubsy wrote:

Quote:

Why use the DIP40 version of the '816 and 65C22?

mainly a matter of availability and costs. Some IC’s I already have.

I just saw Jameco has the '816 available in PLCC. OTOH DIP40 is breadboard friendly...

Or there's the approach of using a soldertail PLCC socket and just sticking it into wire-wrap pin headers. Probably a bit worse than a straight-up wire-wrap header in a few ways, but should be a lot more easily available. It's what I'm planning to go with for the few chips I have in PLCC.

GARTHWILSON wrote:

Quote:

Garth, you SRAM module is superb! It’s definitely on the consideration list.

Thanks. I tried other approaches (like stacking the SRAM ICs and putting the stack on a DIP header, but it just was not practical.

My current design for '816 decoding has provision for this SRAM module, but I don't want to order one until I've demonstrated to myself that I can build a system without irreparably screwing up the design or construction. After that, though, it's definitely going on my shopping list.

Top

lordbubsy

Post subject: Re: MARC-2 project

Posted: Sun Dec 08, 2013 6:02 pm

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

Quote:

I do hope you don't mean solderless breadboard though-- those are the worst of all worlds for digital.

True and true, especially with CPLD’s I found out the hard way. That’s also a reason I made MARC-1, to get rid of the whole computer on a breadboard. While replacing glue logic and adding 65SPI, things simply didn’t work until I placed a lot of bypass caps. Without help, I was clueless.

nyef wrote:

Or there's the approach of using a soldertail PLCC socket and just sticking it into wire-wrap pin headers.

I did something like that. The first approach was an adapter from PLCC to DIL.

Attachment:

adapter.jpg [ 81.53 KiB | Viewed 3420 times ]

The second approach was an adapter using pinheads (I believe that’s how they are called)

Attachment:

Test Gameduino.jpg [ 484.16 KiB | Viewed 3420 times ]

_________________
Marco

Top

BigDumbDinosaur

Post subject: Re: MARC-2 project

Posted: Sun Dec 08, 2013 7:46 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

lordbubsy wrote:

I’m glad that I now have the opportunity to use CPLD’s although being a complete rooky. Especially that it can be changed after the computer has been build!

I'm no expert when it comes to CPLDs, so don't feel inadequate in that regard. The key is having the ability to describe your logic requirements within a language.

As I'm using an Atmel 1508as CPLD in POC V2, I've started writing my logic in WinCUPL, which is a "universal" logic description language. The Atmel WinCUPL package also includes a fitter to generate the JEDEC fuse map, so it's not nearly as onerous a process as it was back when these devices first started to appear on the scene (that was when ABEL was in widespread use). In any case, the language description is relatively intuitive once the syntactical requirements have been mastered. For example, here's an excerpt of what I've written to decode Garth's 4MB DIMM:

Code:

/* 
* * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * *
* *                                   * *
* * MEMORY ADDRESS  TRANSLATION LOGIC * *
* *                                   * *
* * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * *

   System memory consists of 1 to 4 Wilson Mines 4MB dual inline memory modules
   (DIMM), for a maximum of 16MB.  Assuming a single DIMM has been installed, the
   memory map would appear as follows:

                         +--------------------------+ $3FFFFF
                         |                          |
                         |  Extended RAM (3968 KB)  | extram
                         |                          |
      +------------------|--------------------------| $010000
      |                  |                          |
      | High ROM (8 KB)  |  Upper RAM Block (8 KB)  | hiram
      |                  |                          |
      +------------------|--------------------------| $00E000
                         | Hardware Management Unit |
      +------------------|--------------------------| $00DF00
      |                  |                          |
      | Unassigned       |                          |
      |                  |                          |
      +------------------|. . . . . . . . . . . . . | $00D800
      |                  |                          |
      | I/O Block (2 KB) |                          | ioblock
      |                  |                          |
      +------------------|. . . . . . . . . . . . . | $00D000
      |                  |                          |
      | Low ROM (4 KB)   |                          | lorom
      |                  |                          |
      *------------------|. . . . . . . . . . . . . | $00C000
                         |                          |
                         |     Base RAM (55 KB)     | baseram
                         |                          |
                         +--------------------------+ $000000

   At power-on or reset, the default memory map is as follows:

                         +--------------------------+ $3FFFFF
                         |                          |
                         |  Extended RAM (3968 KB)  |
                         |                          |
                         |--------------------------| $010000
                         |      High ROM (8 KB)     |
                         |--------------------------| $00E000
                         | Hardware Management Unit |
                         |--------------------------| $00DF00
                         |        Unassigned        |
                         |--------------------------| $00D800
                         |      I/O Block (2 KB)    |
                         |--------------------------| $00D000
                         |                          |
                         |     Base RAM (55 KB)     |
                         |                          |
                         +--------------------------+ $000000

   Note that the HMU appears in all memory maps.

   The DIMM consists of 8 SRAMs of 512KB each, with a separate /CEx input to enable
   individual SRAMs, where x is 0-7.  Hence to enable the 1st 512KB /CE0 would be
   asserted.  /CE1 would be asserted to enable the 2nd 512KB, and so on.  As each
   SRAM on the DIMM is 512KB, the DIMM's address inputs are A0-A18, which means
   only address bits A19-A21 must be decoded into an SRAM chip select:

      BANK    A21  A20  A19   /CE7  /CE6  /CE5  /CE4  /CE3  /CE2  /CE1  /CE0
      ----------------------------------------------------------------------
      00-07    0    0    0      0     0     0     0     0     0     0     1
      08-0F    0    0    1      0     0     0     0     0     0     1     0
      10-17    0    1    0      0     0     0     0     0     1     0     0
      18-1F    0    1    1      0     0     0     0     1     0     0     0
      20-27    1    0    0      0     0     0     1     0     0     0     0
      28-2F    1    0    1      0     0     1     0     0     0     0     0
      30-37    1    1    0      0     1     0     0     0     0     0     0
      38-3F    1    1    1      1     0     0     0     0     0     0     0
      ----------------------------------------------------------------------

   In studying the above, it can be seen that a 3-to-8 decoder can be made to prod-
   uce the required chip selects.
*/

   /* register resets... */

$REPEAT i = [0..7]
    dffa{i+16}.ar   = !RESET;
    hmu_mcfg{i}.ar  = !RESET;
    hmu_idbnk{i}.ar = !RESET;
    hmu_ipbnk{i}.ar = !RESET;
    hmu_pisr{i}.ar  = !RESET;
    hmu_sbnk{i}.ar  = !RESET;
    hmu_udbnk{i}.ar = !RESET;
    hmu_upbnk{i}.ar = !RESET;
    dffa{i+16}.ap   = 'b'0;
    hmu_mcfg{i}.ap  = 'b'0;
    hmu_idbnk{i}.ap = 'b'0;
    hmu_ipbnk{i}.ap = 'b'0;
    hmu_pisr{i}.ap  = 'b'0;
    hmu_sbnk{i}.ap  = 'b'0;
    hmu_udbnk{i}.ap = 'b'0;
    hmu_upbnk{i}.ap = 'b'0;
$REPEND
$REPEAT i = [6..7]
    hmu_stat{i}.ar = !RESET;
    hmu_stat{i}.ap = 'b'0;
$REPEND

   /* bank latching logic... */

$REPEAT i = [0..7]
   dffa{i+16}.ck = vbus & phi1;
$REPEND
$REPEAT i = [0..7]
   dffa{i+16}.d  = vbus & phi1 & D{i};
$REPEND

bank0     = extaddr:0;                            /* true if bank = $00 */

   /* memory map... */

c_mem     = bank0 & a15_a12:'b'1100;              /* true if address is $00C000-$00CFFF */
d_mem     = bank0 & a15_a12:'b'1101;              /* true if address is $00D000-$00DFFF */
e_mem     = bank0 & a15_a12:'b'1110;              /* true if address is $00E000-$00EFFF */
f_mem     = bank0 & a15_a12:'b'1111;              /* true if address is $00F000-$00FFFF */
h_mem     = e_mem # f_mem;                        /* true if address is $00E000-$00FFFF */

lorom     = c_mem;                                /* low ROM             4 KB */
hirom     = e_mem;                                /* high ROM            8 KB */
ioblklo   = d_mem & a11_a8:'b'0000;               /* I/O devices         2 KB */
ioblkhi   = d_mem & a11_a8:'b'1000;               /* unused                   */

hmu       = d_mem & a11_a8:'b'1111;               /* true if addresss is $00DF00-$00DFFF */

There's quite a bit more to it, but it's enough (in theory) to get it working.

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

Top

lordbubsy

Post subject: Re: MARC-2 project

Posted: Sun Dec 08, 2013 11:16 pm

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

Having a google at WinCUPL, I found the Atmel WinCUPL Users Manual. I have to say they have nice manuals.
http://ecee.colorado.edu/~mcclurel/Atme ... oc0737.pdf

However the online ABEL Reference Guide is unbeatable!
http://www.xilinx.com/itp/xilinx10/help ... /whnjs.htm

And here is a nice ABEL primer:
http://mazsola.iit.uni-miskolc.hu/cae/docs/xabel.html

Googling for Verilog references / tutorials / primers is overwhelming and gives so much info that it’s hard to choose.

_________________
Marco

Top

BigDumbDinosaur

Post subject: Re: MARC-2 project

Posted: Mon Dec 09, 2013 5:08 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

lordbubsy wrote:

"Googling" is an unsafe thing to do. It's much safer for your privacy and your computer's health to use search engines like Ixquick, which don't maintain detailed data of your whereabouts on the Internet and don't plant cookies for later use in pushing advertising.

Atmel provides other documentation as well, some specific to their CPLDs. As for programming CPLDs, ABEL is passé these days, as most new development is in VHDL or Verilog.

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

Top

lordbubsy

Post subject: Re: MARC-2 project

Posted: Mon Dec 09, 2013 1:37 pm

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

Quote:

It's much safer for your privacy and your computer's health to use search engines like Ixquick

that seems to work quite well,
even "something site:http://forum.6502.org/" works. Thanks!

Quote:

ABEL is passé these days

I realize that, but I’m hooked to ABEL, it feels so logical and intuitive to me.

Verilog looks more like the programming language C, which I’m rather bad at. I learned to crawl my way through Atmel Studio in the past year, and that was my first contact with C.

I got a CHOCHI F board, and had some help from MichaelM to get a feel on Verilog. When the time has come, I’ll try my hands on CHOCHI using Verilog. Just changing, and perhaps later adding some stuff.

_________________
Marco

Top

lordbubsy

Post subject: Re: MARC-2 project

Posted: Thu Apr 10, 2014 8:46 am

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

For MARC-2 I’m using an XC95288XL 144 pin CPLD. It’s a 3,3V part with 5V tolerant I/O’s. The DUART that I’m using, the SC26C92, needs 0,8 x 5V = 4V at the clock input. I want the CPLD to deliver that clock and level-shift it to 5V. I could use a resister to pull-up to 5V and tri-state the I/O line for HIGH. This is a method Xilinx suggests. I’d rather use a transistor like this:

Attachment:

2.jpg [ 32.65 KiB | Viewed 3117 times ]

Would this suffice for the needed 3,36864MHz? I’d rather not use a 74XXX14 or 74XXX74.

_________________
Marco

Last edited by lordbubsy on Fri Apr 11, 2014 4:04 pm, edited 1 time in total.

Top

BigDumbDinosaur

Post subject: Re: MARC-2 project

Posted: Thu Apr 10, 2014 4:34 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

lordbubsy wrote:

Either way, the output waveform will be sloppy. Rate of rise will depend on how quickly R17 can charge the parasitic capacitance of the clock circuit. So the clock high phase will be something less than the ideal rectangular waveform. A totem-pole arrangement would be better, as both clock phases will be driven. An alternative would be to use the lowest value for R17 that is consistent with the rating and gain characteristics of T1.

That said, you'd be better served by using a can oscillator to generate the 26C92 clock. That clock is asynchronous to the 65xx bus cycle, so there's nothing gained by making the CPLD act as the clock generator. All you're accomplishing is wasting product terms and I/O pins.

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

Top

lordbubsy

Post subject: Re: MARC-2 project

Posted: Fri Apr 11, 2014 4:00 pm

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands

Quote:

A totem-pole arrangement would be better, as both clock phases will be driven.

Could you elaborate?

Quote:

That said, you'd be better served by using a can oscillator to generate the 26C92 clock.

I don’t have (easy) access to a 3.6864MHz can oscillator.
What about a 3.6864MHz crystal?

I’m also considering using a 74AC74 like this.

Attachment:

111.jpg [ 78.04 KiB | Viewed 3120 times ]

So to summarize, I’m considering three options: the transistor, a crystal or a 74AC74. What would be the preferable of those?

Quote:

All you're accomplishing is wasting product terms and I/O pins.

OK, that’s true, the CPLD I’m using already has so few I/O pins.

_________________
Marco

Top

Aslak3

Post subject: Re: MARC-2 project

Posted: Sat Apr 12, 2014 7:14 am

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK

Quote:

A totem-pole arrangement would be better, as both clock phases will be driven.

Could you elaborate?

See: http://en.wikipedia.org/wiki/Push%E2%80%93pull_output

Quote:

What about a 3.6864MHz crystal?

This would seem like the simplest arrangement.

I know many people dismiss discrete crystals with a pair of caps as clock sources. I personally have never had any issues with them in my 8bit computers, either handmade or not. They might suffer temperature variance issues, but on the plus side they are simple and cheap and easy to get hold of.

But like BBD said, the clocking of your [D]UART is asynchronous with regard to the rest of the circuit, so you are free to treat it as a separate problem to solve in the way you think is appropriate.

(FWIW I will be using a simple 3.6864MHz crystal in my 88C681 DUART setup. I don't anticipate any issues bearing in mind I've had the same circuit rigged on breadboad for months. I used rates up to and including 115K2.)

_________________
8 bit fun and games: https://www.aslak.net/

Top

Page 1 of 3

[ 31 posts ]

Go to page 1, 2, 3 Next

Board index » 6502.org Users Forum » Hardware

All times are UTC

Who is online

Users browsing this forum: No registered users and 35 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