6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 3:06 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Sun Jan 05, 2020 5:50 pm 
Offline

Joined: Thu Jan 02, 2020 11:32 am
Posts: 19
Location: Nottingham, England
Many hours of work and browsing this forum have lead to the design of my first computer!
These are the specifications:

16k ROM
~48k RAM SPACE (Not all allocated yet)
256b I/O

I have included the schematic:

Attachment:
output-onlinepngtools (1).png
output-onlinepngtools (1).png [ 84.61 KiB | Viewed 1609 times ]


Are there any final changes that i should make for my design?

Thank you all for the help that you have given me along the way!

NOTE: I have removed some glue logic, which may be an area of some problems

_________________
Nice Little Community This Isn't It


Last edited by BigLadWhillis on Tue Jan 07, 2020 8:21 pm, edited 6 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jan 05, 2020 7:05 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1485
Location: Scotland
BigLadWhillis wrote:

Are there any final changes that i should make for my design?

Thank you all for the help that you have given me along the way!


The only thing I'd add (and I may have missed it) is to use one decoupling capacitor per IC - I think you only have one for the 4 TTL chips in there.

Wiring the 65C02 pins (Rdy, etc.) to Vcc is OK but it might stem from my old school thinking with TTL and NMOS chips to use a 3.3K resistor than a direct pull. It's probably OK though. (Probably also OK to leave them unconnected too, given an earlier comment by Chromatix too)

Good luck!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Sun Jan 05, 2020 8:46 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
I have a suggestion or two, BigLadWhillis, although I've not spent much time with the drawing. Speaking of drawings, in future please consider posting in monochrome if possible. :)

A reminder about RAM chips. If it saves you any trouble -- and it might! -- feel free to exchange any address line on the RAM chip with any other address line on the RAM chip. Likewise it's alright to exchange any data line with any other data line. Yes this'll scramble what gets written, but the reverse effect occurs upon readback. This freedom to swap pins can be helpful in a physical sense, when it's time to actually make those connections.

Probably the glue logic could be collapsed somewhat, resulting in better speed potential and perhaps fewer IC's. (IDK if those are priorities for you.) Example: you have 4 gates and an inverter between A10 and RAMENABLE. That results in a lot of delay! One possible option is to design using 3- or 4-input AND gates, and thus have less need to cascade one gate after another.

Drogon's right about the decoupling capacitors, of course. Likewise re pullups -- the simple answer is yes, use 'em, and 3.3K is fine (although you could double or halve that value and still be OK).

If you're sure an input will never be used, it's OK to tie directly to Vcc. The only exception is the RDY input on a WDC CPU, where a pullup is desirable as protection in case a WAI is accidentally invoked.

Edit: remove erroneous reference to "bus hold."

Pins such as NMI and SO are edge-triggered, and if unused may be permanently pulled either high or low; it doesn't matter which. Unless a transition is present, these inputs won't react. Other pins such as BE are level-sensitive, not edge-sensitive, and if unused you do need to heed which way they go.

Have fun, and keep us posted! :)
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Last edited by Dr Jefyll on Sun Jan 05, 2020 10:26 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jan 05, 2020 9:07 pm 
Offline

Joined: Thu Jan 02, 2020 11:32 am
Posts: 19
Location: Nottingham, England
Dr Jefyll wrote:
I have a suggestion or two, BigLadWhillis, although I've not spent much time with the drawing. Speaking of drawings, in future please consider posting in monochrome if possible. :)

A reminder about RAM chips. If it saves you any trouble -- and it might! -- feel free to exchange any address line on the RAM chip with any other address line on the RAM chip. Likewise it's alright to exchange any data line with any other data line. Yes this'll scramble what gets written, but the reverse effect occurs upon readback. This freedom to swap pins can be helpful in a physical sense, when it's time to actually make those connections.

Probably the glue logic could be collapsed somewhat, resulting in better speed potential and perhaps fewer IC's. (IDK if those are priorities for you.) Example: there are 4 gates and an inverter between A10 and RAMENABLE. One possible option is to design using 3- or 4-input AND gates, and thus have less need to cascade one gate after another.

Drogon's right about the decoupling capacitors, of course. As for pullups, the simple answer is yes, use 'em, and 3.3K is fine (although you could more than double or halve that value and still be OK).

If you're sure an input will never be used, it's OK to tie directly to Vcc. The only exception is the RDY input on a WDC CPU, where a pullup is desirable as protection in case a WAI is accidentally invoked.

In another thread,
Chromatix wrote:
The W65C02S has "bus holding devices" on most of its pins. They'll hold an input line at a proper CMOS logic level, as long as the CPU is powered - either VCC or GND. But if you want it to settle at a *particular* logic level, then you have to drive it externally

In case you're wondering, you don't need any particular logic level if NMI is unused, or SO. IOW it's OK to hold it permanently high (or allow it to hold itself permanently high), and likewise permanently low is also OK. Unless a transition is present, these inputs won't trigger. Thus the W65C02S's internal bus holding devices are all you need. Other pins such as BE are level-sensitive, not edge-sensitive, and if unused you need to heed which way they go. IOW, don't leave them unconnected and just rely on the bus holding devices.

Have fun, and keep us posted! :)
Jeff


I have updated the schematic with the criticisms posed fixed, thanks for the advice (apart from the logic, which i will fix soon, i have also modified the 3k3 to be 1k as that is probably more useful and already used for the rst button)

_________________
Nice Little Community This Isn't It


Top
 Profile  
Reply with quote  
PostPosted: Sun Jan 05, 2020 9:33 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
(Just to note, what we generally see here on 6502.org for projects, even long-running ones, is a single thread which broadly alternates between updates and queries. If you do start new threads, please link back to previous ones. Otherwise you'll either end up with context-free responses, or you'll have people searching back for which threads relate to the one project.)


Top
 Profile  
Reply with quote  
PostPosted: Sun Jan 05, 2020 11:07 pm 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
It seems your connections to the RAM IC /OE and /WE pins may be reversed. Also, we usually qualify the RAM /WE signal with the Ф2 clock signal.

Not to detract from your thread but I'd love to share an idea using a 74HC688 "8-bit Identity Comparator" IC to insert/inject/map an I/O block into the address space. A clever jumper block arrangement provides a somewhat intuitive method for configuration. Basically, you install jumpers from right to left on the bottom "size" rows for the I/O block size. The address columns left over are used to select the start address of the I/O block. Install a jumper across the 'address' rows in an address column for a '1' and omit a jumper for a '0'. Please check out the examples...

Cheerful regards, Mike

Attachment:
74HC688 Decoder Notes.png
74HC688 Decoder Notes.png [ 312.86 KiB | Viewed 1732 times ]


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 06, 2020 12:59 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
BigLadWhillis wrote:
Many hours of work and browsing this forum have lead to the design of my first computer!
These are the specifications:

32k ROM
~32k RAM
256b I/O

I have included the schematic:

Attachment:
The attachment output-onlinepngtools.png is no longer available

Are there any final changes that i should make for my design?

Thank you all for the help that you have given me along the way!

Upon examining your schematic there are some things that caught my attention. This list isn't exhaustive.

  1. Ø2 clock generation. Are we looking at a can oscillator or a crystal circuit? It's not entirely clear to me.

  2. Read/write. As noted by Michael, writes to the SRAM should be qualified with Ø2 so they only occur when the clock is high. During Ø2 low, the address bus and other MPU outputs are in a state of transition. RWB, according the 65C02 timing diagram, reflects the nature of the next operation (read or write) about the same time the address bus is being set up. If writing is enabled during this time there is a window of opportunity for the RAM to be exposed to a wild write before the address bus settles, which will corrupt data.

    Attachment:
    File comment: Asynchronous Device Read/Write Logic
    x86_read_write.gif
    x86_read_write.gif [ 19.73 KiB | Viewed 1724 times ]

    The above circuit will work with almost any asynchronous hardware (that is, hardware that doesn't understand the 65xx bus cycle), including your RAM and ROM. Do not use it to control any 65xx peripherals.

    Incidentally, the ROM's /OE should be gated by /RD in the above circuit, instead of being tied to Vcc. Most ROM manufacturers state in their data sheets that using /CE only to control the ROM, as you are doing, causes a reduction in performance.

  3. Memory map. Why? You won't use 32KB of ROM and probably can get by with 8KB or 12KB (I used 8KB in my POC units, and they had a full BIOS, as well as a machine language monitor in ROM). If you adapt Garth's circuit in his primer, you will have use of the entire 32KB of RAM, plus space to add more I/O once you get it going. As a bonus, you won't need so many gates.

    Further to this, with a change in the memory map, you could easily expose 48KB of RAM to the MPU (using a different SRAM), plus have ample space for I/O and ROM—and have no more than two gates between the address bus and any device's chip enable input. As we used to say back in the days of minicomputers with bit-sliced MPUs, memory is like money: there's no such thing as too much.

  4. Ø2 clock rate. I don't want to sound discouraging, but I think your unit will be unstable at 8 MHz on account of all the cascading logic. As Jeff noted, you need to go on a logic diet. :D

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 06, 2020 8:21 am 
Offline
User avatar

Joined: Wed Feb 13, 2013 1:38 pm
Posts: 589
Location: Michigan, USA
I'm not sure I'd criticize the memory map. Everyone has their own preference. However, if you need the flexibility, you could probably have adjustable ROM mapping, too.

Attachment:
74HC688 Decoder Notes 2.png
74HC688 Decoder Notes 2.png [ 345.77 KiB | Viewed 1703 times ]


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 06, 2020 5:36 pm 
Offline

Joined: Thu Jan 02, 2020 11:32 am
Posts: 19
Location: Nottingham, England
BigDumbDinosaur wrote:
BigLadWhillis wrote:
Many hours of work and browsing this forum have lead to the design of my first computer!
These are the specifications:

32k ROM
~32k RAM
256b I/O

I have included the schematic:

Attachment:
output-onlinepngtools.png

Are there any final changes that i should make for my design?

Thank you all for the help that you have given me along the way!

Upon examining your schematic there are some things that caught my attention. This list isn't exhaustive.

  1. Ø2 clock generation. Are we looking at a can oscillator or a crystal circuit? It's not entirely clear to me.

  2. Read/write. As noted by Michael, writes to the SRAM should be qualified with Ø2 so they only occur when the clock is high. During Ø2 low, the address bus and other MPU outputs are in a state of transition. RWB, according the 65C02 timing diagram, reflects the nature of the next operation (read or write) about the same time the address bus is being set up. If writing is enabled during this time there is a window of opportunity for the RAM to be exposed to a wild write before the address bus settles, which will corrupt data.

    Attachment:
    x86_read_write.gif

    The above circuit will work with almost any asynchronous hardware (that is, hardware that doesn't understand the 65xx bus cycle), including your RAM and ROM. Do not use it to control any 65xx peripherals.

    Incidentally, the ROM's /OE should be gated by /RD in the above circuit, instead of being tied to Vcc. Most ROM manufacturers state in their data sheets that using /CE only to control the ROM, as you are doing, causes a reduction in performance.

  3. Memory map. Why? You won't use 32KB of ROM and probably can get by with 8KB or 12KB (I used 8KB in my POC units, and they had a full BIOS, as well as a machine language monitor in ROM). If you adapt Garth's circuit in his primer, you will have use of the entire 32KB of RAM, plus space to add more I/O once you get it going. As a bonus, you won't need so many gates.

    Further to this, with a change in the memory map, you could easily expose 48KB of RAM to the MPU (using a different SRAM), plus have ample space for I/O and ROM—and have no more than two gates between the address bus and any device's chip enable input. As we used to say back in the days of minicomputers with bit-sliced MPUs, memory is like money: there's no such thing as too much.

  4. Ø2 clock rate. I don't want to sound discouraging, but I think your unit will be unstable at 8 MHz on account of all the cascading logic. As Jeff noted, you need to go on a logic diet. :D


thank you for the changes, i wasn't too fussed about the clock speed and didn't expect to be able to use 8mhz, would you say that 4mhz would be better suited?

i think i will modify the memory map to have around 16k ROM, as i'd like to have a few small programs on the ROM and am not too certain about how to efficiently program for the 6502, and therefore and allotting myself enough for some inefficiencies. Thank you for the changes!

also it's a can oscillator for the main clock

_________________
Nice Little Community This Isn't It


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 06, 2020 8:38 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
BigLadWhillis wrote:
i wasn't too fussed about the clock speed and didn't expect to be able to use 8mhz, would you say that 4mhz would be better suited?

4 MHz should be within reach.

If you change to 16KB of ROM you should be able to reduce the amount of cascaded logic, giving you more timing headroom and support for higher clock rates.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 06, 2020 8:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
Michael wrote:
I'm not sure I'd criticize the memory map.

I wasn't criticizing, just questioning. Convoluted memory maps tend to result in convoluted—and slow—glue logic.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 06, 2020 10:44 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
As for decoding and producing qualified read and write signals, as as well as other logic duties, you might want to give GALs a look at some stage. You can do some pretty complex stuff, get very fast response (as quick a 7ns in DIP packages) and reduce chip count. Most programmers available cheap on eBay can handle them. WinCUPL is available free to create the fuse patterns and the chips (Lattice) are available cheap on eBay. Usually NOS, but used ones come up even cheaper from tine to time.

_________________
Bill


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 0 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: