>I'd put a 60hz clock in as well as a 50hz clock [snip]
>I'd also have the bus provide all of the different powers -- >3.3v, 5v, and 12v -- that would be needed.

For things like this, it's just a matter of 'documentation' - we can designate certain pins to be whatever we want.
As for 50/60 Hz, unless our clock generator already does it, I would think that we don't want to add hardware for this sort of feature.

>It would be nice to have a signaling protocal for what MHz >speed the bus is running at, but I think the range is too >variable. Perhaps just two pins so we could signal a 0-1 >MHz, 1-2 MHz, 2-4 MHz, and 4+ MHz bus.

Ummm... I'm not sure what a 'speed signal' would be used for...? Unless we really want to support multiple CPUs on the same bus, there is nobody 'out there' that would be able to make use of the signal. I'm thinking that *real* multi-CPU support is beyond the scope of this project.

>As far as stacking, I suppose we just need to define that >you have the connector in one corner of the board[...snip...] That'll be much better than trying to build >slots.

I'm thinking we don't have to define anything at all - since the two (or more) boards are, 'by definition', identical, they are guaranteed to plug together. Maybe you're thinking of mating it with *other* boards - but it would be easy for a future custom board to match our layout, if that was desired.

Pete

One more thing from 2.14 : I forgot to mention IRQ and NMI.

Another design note:
I see from the 65C22 spec sheet that the IRQ output is *not* an open-drain type (like the 6522 was)!!

This means that, if we have two 65C22's in the board, we can *not* tie their IRQ lines together without a little bit of logic (a 2-input AND gate would be needed). Also, we cannot tie any other interrupt signals to it - it becomes a dedicated interrupt line for a single 65C22 (bad!).

I'm thinking we should include the AND gate in the design, if possible. Either that, or one of the 65C22's should be designed as "interrupt-less", and we would not be able to tie other devices to the IRQ line. Another option is to always use 6522's instead of 65C22's, but then we are significantly increasing the power drain, and limiting the speed to 2 Mhz.

I'm assuming that NMI will be used for the UART, primarily.

I suggest we use an *open-collector* AND gate, so that other devices can also be tied to the CPU's IRQ line, thru the bus connector.
If we use the O.C. version of an LS00 NAND gate (I forget what it is), then two of the gates can be used to generate the OE and RAM-R/W signals (which we need anyway), and the other two gates will fix the 65C22 problem. Each of the four gates will need a pullup resistor also.

Pete

Hi everyone,

From what I've seen up to now, it seems that most people want specific nick-nacks that can be implemented using external circuitry. We must not forget that the original goals included "ease of building". I think we should limit THIS board (the first project of www.6502.org community) to 4 mhz max, and keep everything tidy using STANDARD chips. Sure, using pre-programmed MPUs to add "Multi-I/O ASIC"-like functionnality would reduce the board size, but at the cost of getting pre-programmed MPUs and using PLCC or similar packages which are much harder to assemble on a board. As for the memory, the cleverest idea yet is the O.C output decoder, which would make a nifty low logic-demand design. However, in terms of memory map, I think the design made by Chris Ward is by far the best, having the possibility of 32k of RAM, 8/16k of ROM, and enough left for at least 16k of I/O decoded in 256 bytes pages, which can enable the use of easy-to-make daughterboards to add stuff like IDE interface, RTC, Multi-IO boards, etc (and Chris has done some of those already). I really think this board could be helpful to a lot of people, but we must make sure that it remains simple in principles. If people with more advanced knowledge of electronics want to add higher speed components, I'm sure that the knowledge they already have enables them to do it on their own without forcing the concept on other people who prefer the good old "slow but simple" approach to home-made computer system.

Regards,

Tennessee Carmel-Veilleux
(veilleux@ameth.org

>As for the memory, the cleverest idea yet is the O.C output >decoder, which would make a nifty low logic-demand design. >However, in terms of memory map, I think the design made by >Chris Ward is by far the best, having the possibility of 32k >of RAM, 8/16k of ROM, and enough left for at least 16k of >I/O decoded in 256 bytes pages

I looked briefly at Chris' address decoding scheme.
Chris' design has the advantage of many decoded blocks, because of using an LS154 to break one 4K block into 16 pieces. The disadvantage is (perhaps) that the bottom 32K is always a single block (for RAM). He has some random logic gates, but I forget what they are for. The '154 is a 24-pin device, so is a little bulky (do we care?).

My suggestion (from a few notes back) is a little simpler (a total of two 16-pin chips plus a few resistors); has 8 fewer decoded blocks, but is more flexible about where things go in the memory map, and about how big each of the 'blocks' is.

I will support either one (or something else that is similar).
With either design, folks who don't need so much flexibility can leave out a chip or two: in Chris' design, I think the LS154 could be optional; and in mine, the LS138 could be left off the board.

Pete

Okay, the way I see it (and I haven't seen any of the prototype designs), there
are a number of things that need to be considered. First, we need to consider the base 65c02 board that will be produced first. Second, we need to consider the structures that need to be in place for the base 65c02 board to be replaced later on by a 65816 or other nifty board for bigger projects. And then later, the nifty 65816 designs can be built.

But we might as well designate the bus and 65c22 pinouts so that we can support the designs later. And just figure out which pins need be tied down or up on the 6502 design.

Also note.. Some of us who'd love to goof with the design don't have a programmer. Which means that there shouldn't be any GAL/PAL/FPGA/etc circuts in the design. And you might as well make any EPROMs that are going to be included in the design available with the board itself.

Although, one page I found on the net had an extremely simple ROM programmer that ran off of the serial port that looked pretty easy to deal with. Dono...

>Also note.. Some of us who'd love to goof with the design >don't have a programmer. Which means that there shouldn't be >any GAL/PAL/FPGA/etc circuts in the design. And you might as >well make any EPROMs that are going to be included in the >design available with the board itself.

I think it's pretty certain that there won't be any 'hi-tech' devices like PALs on the board. There's no need for them in a general-purpose CPU design like this.

For the PROMs, I plan to use EEPROM devices - either 2K or 8K. They don't require special hardware for blasting or erasing - just write the desired data, with an appropriate time delay between each byte. That's it.
I have 2 or 3 platforms that I can plug a EEPROM device into for programming.
If you don't have *any* existing hardware for blasting a PROM, then I'm sure one or more of us could help out.

Pete

50/60Hz you definitely want to have when adjusting busy-wait timing,
or nice task switching in software when you don't know the CPU speed.
50Hz gives a nice _external_ time base, that is very convenient
for OS or software development.

Andre

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I have to say that I am impressed by the recent volume of messages. I've invited a few others onboard and hopefully their names will start showing up in the discussions also. I feel we're really making some progress with this project.

Pete, you've made an important discovery about the 65C22, something I wasn't aware of. I haven't used the part because I have so many extra NMOS 6522s laying around. I think that the need for compatibility with the CMOS version is a given. I've made a note of your suggestion and we can revisit it when we start drawing the schematic.

Ken, you're brought up some good points. One I like is your suggestion for the bus specification, leaving pins marked as "reserved for 65816 signal xx". We should consider this when figuring out the bus pinouts, but for the time being is there a need to be concerned with it? As Pete said, we have 80 pins to play with going under the assumption we are going to use the two 40-pin headers. Are we definitely going with this idea? If we vote yes then the next step is to start defining them. Remember, we don't have to figure them all out now. "Reserved for future expansion"

About using PAL/GAL or other programmable logic, that's out of the question. No beginner has access to these programmers and we want everyone to enjoy the board.

As for the E(E)PROM: Once we write the software, I will make it available with the boards.

Tennessee, I looked into Chris' decoding scheme and it is nice, but look at Pete's solution. I think right now it is the best suggested. Here's why: Pete's scheme is small, the 74154 is a big chip (24-pins) which will really beef up the size of our board. As I see it, the only advantage that Chris' scheme offers over Pete's is more decoded I/O selects. We already have a few extra I/O selects. If that user needs that extra decoding for so many chips he/she is going to be building a substancial expansion card anyway, I say throw the extra bit of decoding on that board (since all of the CPU signals will be available at the bus connector anyway). We do you guys think?

Finally, Andre has brought up something many of us have overlooked. Having a 50/60 Hz clock signal is extremely useful, especially for writing real time clocks in longer delay loops. I think we should consider if we want to generate such a signal on the board as an option, and how to go about it. I'd like to have it myself.

I think that's it. Keep up the good work guys.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

I know we haven't had any official votes yet, but since everyone seems to be on about the same track, I've updated the current specifications of the board:

http://www.6502.org/pcb.htm

Please check it for accuracy and give any further comments or suggestions.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Here's one idea for how to make a 60 Hz signal:
Years ago I built a freq. counter from scratch, and so I needed an accurate 1 Hz time base. I used an MM5369 (?), which runs with a 3.579 Mhz (TV colorburst) crystal, and it outputs 60 Hz. If desired, the CPU could be run from a 3.579 crystal, then just use the CPU clock to drive the MM5369.

I don't know if that chip is still available... it's an 8-pin DIP.
Do those real-time clock modules (like from Dallas Semi.) put out 50/60 Hz??

Old computers (like the VIC-20) use a counter in a 6522 to make a 60 Hz interrupt rate. We could do that too, if necessary.

Pete

Hello,

<<<Quote follows:
Years ago I built a freq. counter from scratch, and so I needed an accurate 1 Hz time base. I used an MM5369 (?), which
runs with a 3.579 Mhz (TV colorburst) crystal, and it outputs 60 Hz. If desired, the CPU could be run from a 3.579
crystal, then just use the CPU clock to drive the MM5369.

END of quote>>>
That's an idea BUT, the thing is that running the board with such a "weird" clock rate will give you the following problems to deal with:

1- The 6522 timers are in CYCLES. If you want 1024ms of timing with a 6522, it's easy to calculate the constant with 1,2 or 4 mhz. However, with 3.59mhz, how many people know how much one cycle translates in "real" timing ?

2- 4Mhz parts are MUCH harder to find than their 1 and 2 MHZ counterparts, and the 2mhz part will NOT work with 3.59 (overclocking isn't that good on NMOS !). If we divide 3.59mhz to provide clock rates for the slower chips, we will get even MORE weird clock rates

3- The chip you mention might not be the best suited for that purpose and the added crystal+circuitry might add more cost than is needed.

The solution I thought about involves only 2 chips: Either we use an RTC module that can generate 60hz (I don't know of any) on an external pin, OR, we get the cheapest off-the-shelf part that does the job and use a simple astable to generate the 60 hz with very little "drift" using discrete components (60hz doesn't need to be precise to 0.001us . So a 555 with a Schottky Silicon rectifier aranged in monostable multivibrator mode will give you a perfect 50/50 square wave at TTL levels when using 5V (I've tested a design I found elsewhere using my scope and it seems pretty good).

Regards,

Tennessee Carmel-Veilleux
(veilleux@ameth.org

Hello,

<<< Begin Quote
Tennessee, I looked into Chris' decoding scheme and it is nice, but look at Pete's solution. I think right now it is the best
suggested. Here's why: Pete's scheme is small, the 74154 is a big chip (24-pins) which will really beef up the size of our
board. As I see it, the only advantage that Chris' scheme offers over Pete's is more decoded I/O selects. We already have
a few extra I/O selects. If that user needs that extra decoding for so many chips he/she is going to be building a substancial
expansion card anyway, I say throw the extra bit of decoding on that board (since all of the CPU signals will be available
at the bus connector anyway). We do you guys think?

End of quote >>

I do not want to be pushy of the option I mentionned, but I do feel that having 2x 40 pins header will make for a LOT of trouble when making your own card. We should make sure that all "optional" signals are on one header while the other has the CPU lines so that we don't NEED the 2 headers on every expansion card. Also, I think that, even though the 154 is big, it should be mapped to one of the 8k blocks of Pete's decoder to provide for "small I/O" (Most chips require 2 or 3 address lines. The 154 decoding would make 16x 8 lines blocks, which is more than enough) which would make external "test boards" design much easier, due to the fact that no more decoding will be needed. It will also allow something which I find very cool, which is an LCD connector (14 pins header, 2x7 pins rows) ON-board, and it can provide all the decoding for all the chips of the board which require any. I'm sure we won't decode the UART in a full 8k block, nor the 6522. The '154 is good for that: taking all the necessary decoding and translating it from a combination of gates to single, easy-to-use, inverted enable signals. The '154 won't crowd the traces too much, and it can provide decoding for the UART, the 6522, the RTC, and leave the rest of the decode lines for external devices. I don't know what you guys think, but I'm sure this is the most flexible way around. We should discuss it further IMHO.

Regards,

Tennessee Carmel-Veilleux
(veilleux@ameth.org

Tennessee wrote:
>OR, we get the cheapest off-the-shelf part that does the job and use a simple astable to >generate the 60 hz with very little "drift" using discrete components (60hz doesn't need to >be precise to 0.001us .

Yes, for many applications, the difference between 60.0 and 60.1 is not significant. BUT,

it will probably not be very accurate for any 'clock' type of applications, where the
error becomes cumulative. Any R-C oscillator will be sensitive to temperature, *especially*
at low frequencies, which require large-value caps. Yes, there are low temperature coefficient caps (NP0 types, for example), but they are not nearly as stable as a crystal,
and are generally not available in large values.
Besides, using something like an MM5369 and a 3.579 crystal (separate from the CPU
crystal, so that the CPU could run at 1 Mhz or whatever) would have *less* components than any decent discrete oscillator.
With the MM device, changing to a European-type TV crystal will give you 50 Hz, instead of 60 (3.579 Mhz is NTSC standard, so that crystal is very common in the U.S.).

>I do not want to be pushy of the option I mentionned, but I do feel that having 2x 40 pins >header will make for a LOT of trouble when making your own card. We should make >sure that all "optional" signals are on one header while the other has the CPU lines so that >we don't NEED the 2 headers on every expansion card.

That's a good idea. 40 pins should be just about enough for all the 'basic' signals.
Folks that don't need the other signals can leave the 2nd connector off the board.

>Also, I think that, even though the 154 is big, it should be mapped to one of the 8k blocks >of Pete's decoder to provide for "small I/O" (Most chips require 2 or 3 address lines. The >154 decoding would make 16x 8 lines blocks, which is more than enough) which would >make external "test boards" design much easier, due to the fact that no more decoding >will be needed.

I don't quite follow you here. With either 8K-->8 or 8K-->16, there are plenty of decoded blocks to work with. With my suggested scheme, I see the use of 'decodes'
being *something* like this:
- There are 8 blocks of 8K each, provided by the LS145 with
O.C. outputs. Of those, one is for PROM, one is for the
LS138, four are for RAM, and two are unused.
- Of the LS138 outputs (1K each), two are for 6522s, one is
for the UART, and five are unused.
That means a total of 7 decoded blocks (or up to 10 if you have only 8K or RAM).
That sounds like plenty to me! No more decoding is needed to use any one of them -
it doesn't matter that (for example) you connect a 1-address-line LCD module up
to an 8K decoded block - it's a little wasteful, but it works the same. In reality, you
would probably use the five 1K blocks for accessories like an LCD display, and
perhaps use the two 8K blocks for extra RAM/EEPROM.

>It will also allow something which I find very cool, which is an LCD connector (14 pins >header, 2x7 pins rows) ON-board, and it can provide all the decoding for all the chips of >the board which require any. I'm sure we won't decode the UART in a full 8k block, nor >the 6522. The '154 is good for that: taking all the necessary decoding and translating it >from a combination of gates to single, easy-to-use, inverted enable signals.

Remember, the 154 doesn't do anything different from the 145 or 138 - it just decodes
one extra address line, making the decoded blocks half as big. With a 138, we will end
up with 1K blocks; with a 154, we will have 0.5K blocks - there's no other difference.
[BTW, the 145 is really a BCD 1-of-10 decoder, but in this case we would be using
it just like a 138, but with O.C. outputs.]

>The '154 won't crowd the traces too much, and it can provide decoding for the UART, >the 6522, the RTC, and leave the rest of the decode lines for external devices.

The only extra thing there is an RTC - there would still be a minimum of 6 decodes
unused. As Mike suggested/hinted, more 'accessories' than that and we are talking
about a *big system*...

Pete

Tennessee brings up an excellent point about the arrangement of the bus signals on the headers. By allowing simpler cards to be connected by only one header, construction of expansion cards can be much smaller and simpler. I've added this note to the expansion connectors description on the project page.

I'm still confused about why adding the '154 to the address decoding scheme on the main board is beneficial, considering the large amount of real estate it will take up and it's limited usefulness for most people. I still think if you need that much extra decoding that your expansion card is going to be big enough where throwing on a '154 or other decoder isn't going to make a difference.

An onboard LCD connector would be neat, the EPE Microlab has one. Is it worth the board space and extra header, or is it better left to an expansion card?

Pete, I had the same thought as you about the using the MM chip and a colorburst crystal, but I didn't make the suggestion myself because it is kind it's sort of a hard to get part, and we're trying to stray away from those. The Commodore SX-64 used this arrangement to get it's 60 Hz output to the 6526 CIA's TOD input.

If we do want a fifty or sixty Hz timebase onboard, Tennessee's suggestion of the 555 circuit sounds pretty good to me because it's available everywhere and you can just vary the RC values for your choice of 50 or 60 Hz and this circuit could be combined with the reset generator inside a 556 (dual 555) to use less board space. The only drawback of this idea is that it would be adding more resistors and capacitors to our circuit than I'd like.

This is assuming that we want the 50/60 Hz signal at all. Do we? I'd like one myself, or at least have it as an installable option.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Hello

<<< Begin Quote

Tennessee brings up an excellent point about the arrangement of the bus signals on the headers. By allowing
simpler cards to be connected by only one header, construction of expansion cards can be much smaller and
simpler. I've added this note to the expansion connectors description on the project page.

I'm still confused about why adding the '154 to the address decoding scheme on the main board is beneficial,
considering the large amount of real estate it will take up and it's limited usefulness for most people. I still think if
you need that much extra decoding that your expansion card is going to be big enough where throwing on a '154 or
other decoder isn't going to make a difference.

An onboard LCD connector would be neat, the EPE Microlab has one. Is it worth the board space and extra header,
or is it better left to an expansion card?

End of Quote >>>
You have a point there... The 154 might be a little too much:) Making an expansion card with all the additionnal elements wanted (LCD connector, more 6522) should be very easy, and the decoding of a 1k block by a 154 on that card would make for a lot of expandability. So the thing is: we could design a seperate "option" board (of which the PCB would not be designed right now) for people who want to expand the design later on.

As for the 40 pins header, I think that one of the headers should contain the strict minimum of signals, but 40 pins means we'll have to cut somewhere (mostly in the upper address lines) if easy expandability is wanted... The basic connector should have at least the following:

D0..D7

A0..A15

/NMI

/IRQ

R/W

Phi 0

Phi 2

I/O decodes 1 to 8 (From one of the 8k I/O ports)

50/60hz clock.

That makes 32 lines. If we want more specific lines added, we have space for 8 more, and worst case scenario is that we cut 3 or 6 upper address lines and use only the decoded I/O lines.

As for the 60hz, A useable frequency of 61hz could be gotten from dividing the main 4mhz crystal by 2^16, but not divider that I know can do both the 2^16 and the divide-by-two or four needed by the CPU. So we either have to use a 555, or make use of much clever crystal manipulations with additionnal chips. Even if it adds a little discrete component part, the 555 alternative takes less board space than having multiple crystals and chips just to generate the 60hz. Another possibility is that we also add an EXTERNAL 50/60hz input which could generate the frequency from the AC power line through the power supply (but since we do not include a PS on the board, that would be VERY optional).

Also note that I own a commercial-grade EPROM programmer so I could provide the firmware (if one is made) to anyone who wants it for a very small amount of money (perhaps postage+chip cost). However, it should be noted that Chris Ward has made an extremely easy-to-build EEPROM programmer design which can be built by pretty much everyone (I built one, but bought a commercial programmer afterwards) and use to program the firmware for their 6502 board. The 2864 EEPROMs are relatively easy to find compared to 28256 models.

Regards,
Tennessee Carmel-Veilleux
veilleux@ameth.org