_________________
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?

I agree that putting both fast (and possibly variable) clock as well as slow (and fixed frequency) clocks on the bus looks like a step forward. You already have RDY on the bus, which is just a little like a bus acknowledge. One tiny issue: RDY is an input, so maybe this needs to be open-collector?

If you don't use RDY to stall the CPU for slow peripherals, then it does seem the CPU card needs an input signal coming from slow peripheral cards: again, a shared input, so open-collector or something.

Or, as I think is where you are thinking presently, the CPU card is hard-wired to know which cards need slow accesses - maybe all of them - and how slow they are. This simplifies the bus, but does nail down the access speed of each slot, or card.

If you don't like open-collector inputs, you could daisy-chain OR or AND gates or something, so any card can signal a low (or a high) as appropriate. But this adds logic delays to larger systems, and that's troublesome when you need to adjust clocks.

Or, if you have the free connector pins, put the OR or AND gate on the CPU card, and provide N inputs, one from each 'slow' slot.

Modularizing a mixed-speed design may not be so easy. Maybe it's enough to provide just one or two slow slots?

Well, I don't see how a clock can be enabled/disabled from software, since you need the clock working before the software can run.

It sounds as if you're looking to have the bus have enough "intelligence" to automatically select the right clock source, but that would be a nightmare for my purposes. My aim is to have a backplane/board system that's as flexible as possible, since I'm hooking up all sorts of stuff to it. For example, the "CPU board" might be a Commodore 64 wired to an RC6502 bus interface card so that the C64 can use peripherals I build. If there were clock-selection logic on the bus and cards, then the C64 interface board also needs to have extra circuitry to participate in that clock selection and ensure that it always supplies the clock, since the C64 can't (without significant hardware hacking) have its internal clock disabled.

I'm not sure what your objection to jumpers is: for flexible situations like this (such as wanting to use the RAM or ROM on an SBC board as a peripheral to another processor), jumpers seem like the simplest way to achieve this: just jumper to "off" all the parts on the SBC you don't want to be part of the other computer system.

It seems apparent that you're looking more for a system that interfaces only with stuff specifically designed for your bus, so you're going quite a different direction there. I was going to suggest that it might make sense to use RC6502 bus and expand it with another row of pins for your additional functions, but I now wouldn't suggest going that way with what's becoming apparent of the goals of your design.


Or having the option of building a larger backplane, as I can see now. In my case, there may not even be a backplane. This is not just when running an SBC board standalone, but also is reasonably likely when using one microcomputer bus interface card and one peripheral: I'm planning to add a "slot" connector to such boards so that a peripheral board could plug directly into the interface board in those cases where I don't need more than one peripheral.

In fact, you can see another form of this in the reconfigurable RAM/ROM board I'm currently working on. (The current development version as of this writing can be found here, though that link will be out of date when the development branch disappears, in which case look for the hw/ subdir on the master branch in that repo.) There, as well as the standard RC6502 bus interface, I have a 50-pin "microcomputer bus" header which can be wired directly to the external bus connector of your microcomputer of choice. So I can, e.g., plug it in to my JR-200 to program an EEPROM, and then unplug that and plug the board into a backplane with a CPU to have the CPU boot from that EEPROM.



Well, the only thing that comes to mind is to put ROM on the peripheral cards, which kinda breaks the "simple to build" thing, though it certainly does make life simpler for end-users who just want to drop a pre-built peripheral card into the backplane, which seems to be more what you're aiming for.


Not quite: you still need a bus slot that has access to all of the peripheral slots' individual select pins. Otherwise how does it drive those?


Well, yeah. Your CPU card is full only becuase you chose to make it smaller than the full 10×10 cm available for the cheapest price. But it's sounding to me as if the backplane is such an integral part of your system, providing significant amounts of its functionality (clock and at least some of the address decoding) that it doesn't make sense to try to set things up to give yourself the option to have CPU boards work also as SBCs.

_________________
Curt J. Sampson - github.com/0cjs

Thank you for all your suggestions Ed, really great food for thought!
I'll have to get back to my design and look at what is possible to implement. At the moment I'm experimenting some ideas on my protoboard SBC to see what works and what doesn't. But what a mess of wires to solder through when I have to change anything . And so far not much works with slow ROM, I got fed up and hardwired everything to the ACIA clock to at least get a basic prompt




Oh sorry I guess I misunderstood your goal, but I imagined maybe the system could start on the slow clock by default and then get switched to the fast clock by software.


Haha me neither to be honest, I think maybe because I've been a software guy for 15 years, I'm used to doing everything in software!


Yes, I guess that's one way to say it. I think what I really want is to have a system where you can plug in any card designed for the system and it "just works", similar to C64 cartridges (although It would probably be ok to reprogram the ROM depending on which cards are installed in the system, unless I find a better solution than having ROM on each card.)


A larger backplane could be designed, I guess, but the limit would be the number of pins on the address decoding chip. But of course the larger backplane could include a different address decoding chip to allow for addressing all the slots. But as you say I'm not really thinking about that right now.

Yes I like this idea. Maybe you could do that also with a "micro" backplane that is just one female socket on each side


Oh wow yeah, I'm amazed that would even be possible!



Oops haha yes you are perfectly right of course and I feel really silly now!



Yes I understand what you mean. I still like the SBC idea but it's probably not applicable to the system as it stands now. I'll have to see how it evolves from all the comments you're all kindly providing and find the best compromise for what I imagine my "perfect" system to be.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

If you've been lurking for more than three years then you might hold the record.



People have put 6502 on RC2014 bus. However, the memory maps don't match. So, unless 6502 is used with incompatible RAM/ROM, some of the upper address lines must be inverted. Also, I presume that full peripheral compatibility requires a 6502 I/O hole to be mapped to Z80's IOREQ using 74x688. This chip is notoriously slow and may be incompatible with your target of 10MHz. Indeed, if you can sidestep this, 14MHz should be attainable.

Anyhow, I have some advice. Feel free to apply pieces of it according to your preferences and judgement.

Firstly, I've already stated that I'd like an ITX board with 65SIB. This also applies to Mini-ITX or smaller, such as 100mm*100mm. Therefore, whatever you devise, I'd like to make an initial purchase of two units and more to follow. I trust your instincts with design choices.

Secondly, now that you've de-lurked, you'll have to ignore the whingers. For every permutation of hardware or software, someone will disagree. A minority of them will have the decency to publish an outline specification prior to disagreement but I suspect that some of them contrarians or wish to impede the progress of others. If they don't like your design decisions, they are free to make their own variants.

Thirdly, I totally get the hard limit of a 100mm*100mm board. Prototyping board exceeding 300mm*100mm used to be commonplace. However, with increased scale of integration, it is now common to obtain a microcontroller with serial ROM and WiFi or an accelerometer which is 40mm*30 or significantly smaller. With competitive pressure on circuit board prototyping services, a credit card circuit board gets expensive and the smallest 160mm*100mm EuroCard prohibitively so. I also wonder about the budget of some hobbyists given that 1/3 of people in US cannot raise USD400 in an emergency. In other countries, USD50 is a significant commitment.

Fourthly, you have conflicting constraints, and especially so when you have a hard limit on board size (and the helpful contributions of the peanut gallery). However, I strongly suggest placing speed ahead of need. Specifically, all high speed, parallel hardware should be adjacent to the processor. That's ROM, RAM and video. All else is secondary. Indeed, I may persuade you that a bus expansion connector may not be required or that it is relegated to a miscellaneous, we-hadn't-thought-of-it connector likely to be used by zero or one cards.

You may have seen recent discussion regarding processor stacking and RAM stacking. While I am a keen advocate of processor stacking, a design with FPGA may benefit more from using the alternate clock phase for video, DMA and/or a soft-core with custom instructions, such as hardware multiply. Other uses may include decompression hardware, a polygon engine or an alternate processor architecture, such as 6809 or Z80. Anyhow, I strongly recommend against DIP 65C02 and instead use a smaller package. This should save about 1/16 of the board area.

74x138 allows eight RAM to be stacked. If 74x138 is itself stacked, it is quite easy to make a stack of 24 (or more) RAM chips. Therefore, using 128KB static RAM, it is possible to place 2MB or more in one socket directly adjacent to the processor. Given that ROM and RAM (of different form factors) often have similar pin-out, it is possible to place one surface mount EEPROM at the bottom of one optional ROM socket/RAM stack and place one surface mount RAM at the bottom of another optional stack. Fly leads determine address decode and read/write functionality. A further tip that I've seen (from BigDumbDinosaur or drogon?) is to never solder a relatively expensive ZIF socket. Instead, it is possible to insert a ZIF socket into a DIP socket during development and then remove the unsoldered ZIF socket when complete. This elevated arrangement may also require less space around a ROM socket for ZIF handle. Anyhow, this requires approximately 1/4 of your board but it practically eliminates the requirement for a RAM expansion card.

A video connector of any type plus FPGA, power regulation, boot ROM and boot ROM programming socket requires a minimum of 3/16 of the board area. Optional video DRAM may require another 3/16. Therefore, it may be highly preferable to omit video DRAM restrict display to character tile data sourced from static RAM. Regardless, FPGA is likely to perform unrelated functions. The standard technique for FPGA systems is to hold the processor in a reset state until the FPGA configuration is loaded from serial ROM and initialization is complete. During this period, an FPGA may populate static RAM with debug software. FPGA can also be used for clock division and address decode. Some FPGA provide PCI Express. I am not suggesting that you choose such a unit but your design is likely to be upward compatible with PCI Express and therefore a future iteration may have a bridge to SCSI, SATA and Ethernet. Dual port RAM in FPGA is suitable to implement a cell network hardware suitable for a near universal tape/disk/keyboard/mouse/PAN/LAN/WAN interface. In the trivial case, eight bi-directional FPGA UARTs (without hardware handshake) can be wired to four PS/2 connectors which may also provide power to peripherals. Four PS/2 connectors require approximately 1/16 of your board area.

To aid bootstrap, it may be preferable to connect keyboard in a manner which bypasses FPGA. (I've previously suggested this with W65C265 microcontroller.) While a dual 6522 configuration would obtain much goodwill, this may not be compatible with your desire to avoid clock stretching and similar techniques. Instead, it is possible to use one or more 74x574 latches and one or more 74x244 (or 74x245) buffers to obtain a switch matrix interface up to 16*16. This can be connected to any cheap keyboard after its PS/2 or USB controller is removed. After further development, the interface may be re-purposed as GPIO. Indeed, I suggest that the parallel port approximates the conventions of 26 pin or 40 pin Raspberry Pi connector. This would provide compatibility with a subset of existing peripherals.

65SIB is quite obviously intended to use 74x138 for decode. In a minor case of chip stacking, it is possible to obtain 16 or more multiplexed channels. Seven of these may be allocated to a primary 65SIB connector. Another seven may be allocated to an optional secondary 65SIB connector. The remainder may be allocated to internal use (RTC, config EEPROM, thermometer, status lights) or the Raspberry Pi connector.

With VGA, ROM socket, RAM stack, eight unclocked serial channels, 24 clocked serial channels, Raspberry Pi GPIO connector and possible future expansion with PCI Express, I am not sure that a dedicated bus expansion connector is the best use of space. Indeed, such expansion can be bodged from RAM socket. The missing signal lines can be provided from an adjacent socket with known placement and configuration. Without loss of generality, this uses considerably less space on the main board and you do not have to worry about the reliability of this bodge. I believe that BigDumbDinosaur implemented an expansion board in a similar manner prior to the probable world record for 65816 + SCSI uptime exceeding 300 days.

Regarding clock speed, 80MHz oscillator provides a suitable video dot clock for 1280*720 and FPGA can divide by 5-20 for 65C02. Future iterations of the design could use 150MHz oscillator suitable for 2K video (1920*1080) although, without space for video DRAM, this may be limited to tiles of some description. In all cases, FPGA for video is a hedged bet which allows you to follow any advances made by ElEctric_EyE, Radical Brad or others. I am not fussed by the details of FPGA. I believe that anything with 10000 LUTs would be more than sufficient to implement a VIPER and a VIC-II. Prior to a self-hosted system, the least constrained development environment may be an advantage. In particular, any FPGA partially supported by open source tools may draw more interest. However, the preferences of idiots like me with full stack of vaporware are secondary to people making practical advances with FPGA video.

At the risk of minor blasphemy, it is possible to save approximately 1/16 of the board area by eliminating 65C02 and rely upon one or more soft-cores. I have been recently alerted to BigEd's work in this field.

Here's a quick board area budget where the limit is approximately 16 square inches:

• 1 square inch for board fixing holes.
• 1 square inch for four pin Molex power connector and power regulation.
• 0.5 square inches for oscillator.
• 1 square inch for 65C02.
• 3-8 square inches for ROM/RAM/expansion.
• 3-6 square inches for video and miscellaneous tasks.
• 4 square inches for parallel port.
• 1 square inch for UART/cell networking.
• 1 square inch for 65SIB.

To minimize cost, I believe that a two layer board is possible. If you are lucky, you might get three ROM/RAM sockets on the first iteration but this may not continue to future iterations. Indeed, pressure of space allocation may reduce sockets to a boot ROM hidden under one RAM stack.

Anyhow, pick through my message for useful ideas. In the case that you reject all of them, I still wish to purchase multiple units from you because it is preferable for us to have economies of scale and a common development platform.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Right; in my case it's not about different clock speeds, it's about having more than one hardware clock source in whatever system I've cobbled together (because multiple boards and/or a microcomputer provide and possibly consume clock) and deciding which one to use.

I see now how this confusion came about: it seems that for both of our systems we had some of our own internal assumptions about the goals that we never made explicit. This conversation has been very useful for bringing that out!

So my current understanding is that you are intending to make a fairly "closed" system in the sense that it was for use only with boards designed for that system, whereas I am aimed more at a platform that allows me to glue together, as best I can, arbitrary things that I have lying around. A consequence of my design decision is that I expect the need to understand the low-level hardware and software details of each part, and reconfigure the hardware of all the various bits in order to make any particular configuration work. On the other hand I think now that you're looking for a "plug and play" system for the end user, where so long as a board is designed for your system, the user plugs it in wherever he likes and it Just Works, as you say explicitly later in your post.


That really sounds to me the way to go with this, though of course you'll then need to deal with the software interfaces and that sort of thing. Even if you don't add ROM to the cards in your initial versions, perhaps it's worth designing-in the facility for this?


Hmm! While initially attractive, that involves either a straight-through connector with one board flipped "upside down," or a cross-over connector that sounds very messy to build. And I'm kinda feeling that I'm sure to make errors plugging things in if I have too many ways to do it. So tentatively, I think I'm going to stick with either using a backplane or, for particular instances, having a single female connector in parallel with the male one on certain boards (essentially, a "built-in one-slot backplane"). But I'm going to continue to think on this, so thanks.


Right. So my suggestion was really oriented more at making it easy to prototype and play with many versions of your backplane circuitry: you could simply unplug one you're unhappy with and substitute a new one, or play with different versions, without having to spin and solder a new backplane. This you might do only during the initial stages, and later, once things have been nailed down in practice, move the circuitry on to the backplane itself. But you may or may not need that.


From this I'm not sure that you're clear on the reasoning behind the 100×100 mm limit. It's the same for this project as for RC6502: JLCPCB has a special price ($2 for a set of five) for two-layer circuit boards of that size or smaller. (It actually seems to be up to 102×102 mm.) If you go to that form I linked and increase one of the dimensions to 103 mm you'll note that the price quadruples, to $8.

It's not actually quite so dramatic as that for a single board, of course, because the shipping cost is still around $10 or so I guess, depending on your country. For me, with shipping, the prices work out to ¥1134 vs. ¥1762, about a 50% difference. Still, that's not insignificant: for a system with four boards and a backplane, averaging two spins of each (because I will certainly mess up the first and perhaps even second go at some designs), that's around a $70 saving during development for each board done individually. And if you're in small-scale production, the special price is good up to ten boards ($1728 including shipping, as opposed to ¥2484 for ten 100×105 mm).

_________________
Curt J. Sampson - github.com/0cjs

_________________
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?

(Try: OT: stacked (DIP) chips)

_________________
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?

Thanks, there is quite a lot in your message, I will have to take some time to digest it all!
However there are a few things that maybe you can clarify:


Ok for RAM and video, but the only parallel ROM I could find that was not outrageously expensive was 150ns, so why couldn't it be at the other end of the bus ?


Yep, will do. I am not planning to sell the boards, they already have an open hardware license (CERN specifically) so you can just grab the gerbers and order them. Of course since the minimum order is generally for 5 boards I'll be happy to send you a couple for the cost of postage.


Yes, the Osborne one is hard to believe. I don't think I'm ready for that!

Yes, I understand now, thank you. It's an interesting concept for sure.


An update on the project: I'm still trying to find a way of having a slower clock for slower peripherals, I've been experimenting on my SBC and not really getting the results I want using the ATF22V10, so I will go back up thread and try some more options that have been proposed.
On the bright I have forth running like a charm via serial. It was my first time trying forth and the elegance is something else. What a pleasure discovering this.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

Ok, here is what I have so far on the clock stretching front:
I have used the clock stretching with counter method presented here. Here is the schematic for the clock part (bit of a messy draft, sorry).

If a base clock of 24MHz is provided, the normal clock will be at 12 MHz and the slow clock about 3MHz if my calculations are correct.
SLOW0 to SLOW5 are individual signals that the expansion cards can send to request a slower clock speed. Each expansion slot has it's own SLOW signal. For example, the CPU board's ROM select is also tied to it's SLOW pin which slows down the clock when the ROM is selected.

I am a bit worried about the time between address setup and the next positive clock edge. From WDC's datasheet it appears the address setup time is 30 ns, but a half period at 12 MHz is 41.6 ns. Even 74AC logic has a propagation delay of about 5ns and the 74AC161 requires I think 8 ns of setup time, giving a total of 43 ns, so it would appear that this scheme would only barely run at 12 MHz. Please do correct me if these calculations are wrong.

The 74AC11 datasheet gives quite a wide range of propagation delays from a min of 1.5 ns to a max of 8ns.
Am i correct to think that depending on the specific chips I get, different speeds will be attainable?
Can I get your feedback on the design of this clock circuit ?
Thanks

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

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

Hi BDD,
Yes, a minimum performance requirement for all cards sounds like a good idea. And if they cannot meet it then they have access to the RDY pin on the expansion bus to stall the CPU the required amount of time.

I have actually tried the counter method of clock stretching on my prototype board computer, but could not get it to run stably at 10MHz even. I thought I didn't have any JK flip flops in my box, but I actually do have a few 74HC76 (I inverted the clock and the ROM select signal in the 22V10 to let them behave like a 74HC109). This seems to run ok at 12 MHz.

On the scope it appears the address setup time is much lower that what WDC claims (I get a valid ROM select 20 ns after the negative clock edge, minus let's say 5ns from the 22V10, that's 15ns Tads). Is that to be relied on?

Regarding the 74ACT1130, first of all thanks for letting me know about this chip. I was looking for a 74AC30 which does not seem to exist? Would there be a J-K flip flop with non inverting K input and positive clock edge trigger? This combination seems like it would work pretty well.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.

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

Great, thanks for the info, I need to have a think about all this.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.