6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 5:12 pm

All times are UTC




Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Tue Dec 29, 2020 8:18 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
BigEd wrote:
jfoucher wrote:
BigEd wrote:
the RAM and ROM could be onboard with the CPU... it's not necessarily desirable

What are the cons of doing it that way ?

It might mostly come down to a matter of taste. Some thoughts, if the CPU board is just a CPU board:
- looks a bit more historically authentic, with ROM board, RAM board, peripheral board
- allows for one or two small RAM boards or a large paged RAM board
- allows different model of CPU, reusing all other boards
- might allow dual CPUs
- allows boot ROM swap by swapping a board


Yes, but the 100mm board size requirements limits the computer to 6 boards, and that's with little space to spare for taller components. So CPU, RAM and ROM would already be three boards, reducing the expansion capacity. But maybe having the RAM and CPU on one board and the ROM on another would be a good comprise and still allow boot ROM swap by swapping a board (I really like that idea) and maybe clock stretching when the ROM is selected to allow for higher CPU speeds when doing RAM operations.

BigEd wrote:
I would say follow your muse. You might find one or two people could be collaborators on your project - perhaps more likely, if you make the thing, someone might design a board for it.


Yes that would be great! That's why I want to make sure that the base design is sound.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 29, 2020 8:28 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
BTW, I like the INH signal!


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 29, 2020 9:05 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
It's inspired by the Apple II expansion bus pinout, although in the Apple II's case the INH/ signal only inhibits the ROM. My reasoning for having it disable both the RAM and the ROM was that the expansion board can have logic that would toggle the INH/ signal on or off depending on whether the RAM or ROM is being accessed.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 30, 2020 6:55 pm 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
jfoucher wrote:
Maybe you are aware of the RC2014, an extensible Z80 based computer ? Well maybe I didn't search properly, but I could not find something similar but based on our favorite CPU.

I guess you missed the RC6502 system, which also is designed to fit within the JLCPCB 10×10 footprint. (That's not my design, but I use it, and I wrote the bus documentation.)

That said, your project seems to be going in a somewhat different direction, so while I'd encourage you to have a look at the RC6502 stuff, there's no reason not to continue with your own.

Quote:
...I decided to go the backplane route, even if that goes against the advice of some of our most distinguished members.

Yeah, I wouldn't get too uptight about following such advice, so long as you're willing to to take care and deal with any extra debugging that may be involved. Members of this forum are running 20 MHz systems on breadboards, so clearly what you're trying to do is far from impossible.

Quote:
...the expansion slots use geographic addressing from a GAL chip on the backplane. This means the expansion cards do not generally need to include their own decoding logic, which in my mind greatly simplifies the design and creation of extension cards by third parties.

That's certainly one way to go, though I wouldn't say it solves problems as much as replaces them with different problems. :-P For example, without decoding on the cards I/O ports now move around as you move cards between slots, and drivers need to take this into account, either auto-configuring or providing a way to manually configure them. You may want at least to think about providing some bus support to help with auto-configuration, though unless you've got a particularly clever way of doing this it adds either extra complexity or ends up putting more circuitry back on expansion boards. (The Apple II dealt with this by having ROM on boards with the drivers, so that they could be essentially self-identifying.)

It is possible to do a combination of bus-based and slot-based deocding, which has already been happening with RC6502 in a similar way to the way it's often done with the USER pins on RC2014. RC6502 has four essentially unused pins (35/TX, 36/RX, 38/EX1 and 39/EX2). The SBC/CPU card (more on this below) is already decoding every 4K block from $8000 to $F000 as a byproduct of the decoding for its onboard RAM, ROM and PIA, and one of the RC6502 users has already soldered a couple of jumper wires on to his board to bring the $A000, $B000 and $C000 signals out to the TX, RX and EXT1 pins.

I'm planning to do almost the same, except probably with two 8 KB and two 4 KB ranges, $8000/$9000, $A000/$B000, $C000 and $D000. (Though I've got to say, using one of those for an inhibit line like yours is tempting.) Then my boards themselves will be able to further decode those into smaller ranges: with a single 74'138 you can easily have an expansion card select for itself a 512 byte subsegment of one of the 4K blocks above and then generate separate selects for each 64-byte range within that subsegment. Add jumpers to configure which bus select signal is used and how the high address lines within that range are routed to the '138 (which has two negative and one positive select) and other chips and you've got quite a bit of flexibility for configuring your I/O space at minimal extra decoding cost.

I mentioned an "SBC" above: this is my favourite board of the whole system. The first RC6502 system had separate boards for CPU, clock/reset, RAM, ROM, and so on, but the SBC combines all of those and serial I/O (via a PIA talking to a microcontroller emulating the Apple 1 video and keyboard circuitry, in this particular case) so that the board can run standalone, which is great for carrying around to demos and whatnot. But plug it in to the bus and you've got access to whatever expansion cards you want. (The current RC6502 system has a wide range, including video and so on.) There are jumpers on the SBC to disable the RAM, ROM and serial I/O so that you can replace those with off-board devices if you like. You might want to consider doing your system this way so that you could run the simplest version as an SBC, and put your video and whatnot on additional boards.

I also have a few comments on your repo organization and so on:

1. I strongly suggest you put all of your work in one repo, with a subdirectory for each project. This provides some very tangible development benefits, such as ensuring that changes are co-ordinated between boards and reducing duplication (for example by having one library for things like bus symbols and footprints used by all projects). It also makes it easer to get and update copies of your work, since there's only one repo to clone or fetch.

2. Once you're at the point where you're inviting folks to look at your work, it helps if you commit a PDF of the schematic, as well as the `.sch` file. This lets people view it on-line, rather than having to download the files or clone the repo. (And install KiCAD, if they've not done so already.) You do need to remember to regenerate and commit the PDF in every commit that changes the `.sch` file, but I'm hoping to look soon at some way of automating that a bit.

3. You seem to have committed your backup files as well (*-bak); it's probably best to remove these and then add that pattern to the .gitignore. (You do want to keep committing the *-cache* files, though, since they ensure someone without the same libraries as you can still read the schematics and PCB design.)

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 30, 2020 10:04 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
First of all cjs, thanks for the detailed reply.

cjs wrote:
jfoucher wrote:
Maybe you are aware of the RC2014, an extensible Z80 based computer ? Well maybe I didn't search properly, but I could not find something similar but based on our favorite CPU.

I guess you missed the RC6502 system, which also is designed to fit within the JLCPCB 10×10 footprint. (That's not my design, but I use it, and I wrote the bus documentation.)


Yes definitely never saw that one, very interesting! I will have to take a look at their github repo in more detail.

cjs wrote:
jfoucher wrote:
...the expansion slots use geographic addressing from a GAL chip on the backplane. This means the expansion cards do not generally need to include their own decoding logic, which in my mind greatly simplifies the design and creation of extension cards by third parties.

That's certainly one way to go, though I wouldn't say it solves problems as much as replaces them with different problems. :-P For example, without decoding on the cards I/O ports now move around as you move cards between slots, and drivers need to take this into account, either auto-configuring or providing a way to manually configure them. You may want at least to think about providing some bus support to help with auto-configuration, though unless you've got a particularly clever way of doing this it adds either extra complexity or ends up putting more circuitry back on expansion boards. (The Apple II dealt with this by having ROM on boards with the drivers, so that they could be essentially self-identifying.)


Would reprogramming the PAL to map a specific address range to another port count as autoconfiguration ? :D But at least it is possible to move cards around without modifying the drivers, although you do have to pull the PAL and reprogram it. Having ROM on the cards is good move I think to allow third parties to integrate drivers in the system. However I feel it's overkill for this project.

cjs wrote:
It is possible to do a combination of bus-based and slot-based deocding, which has already been happening with RC6502 in a similar way to the way it's often done with the USER pins on RC2014. RC6502 has four essentially unused pins (35/TX, 36/RX, 38/EX1 and 39/EX2). The SBC/CPU card (more on this below) is already decoding every 4K block from $8000 to $F000 as a byproduct of the decoding for its onboard RAM, ROM and PIA, and one of the RC6502 users has already soldered a couple of jumper wires on to his board to bring the $A000, $B000 and $C000 signals out to the TX, RX and EXT1 pins.


Hmm, that gives me an idea. By having a transceiver between the select lines coming out of the PAL and the bus itself, an extension card could take control of the activation and deactivation of the expansion slots in a way similar to what you suggest. Maybe there are other, better ways though, but it is an intriguing possibility for sure.

cjs wrote:
I mentioned an "SBC" above: this is my favourite board of the whole system. ... You might want to consider doing your system this way so that you could run the simplest version as an SBC, and put your video and whatnot on additional boards.

That's actually a great idea! I think I could get something close by adding a serial chip and a connector for a USB to serial adapter to the CPU board (which already has RAM and ROM) Or maybe make them two separate card so that you could choose which one you want to build.

cjs wrote:
1. I strongly suggest you put all of your work in one repo, with a subdirectory for each project.

It was on my mind as well, will do it ASAP.

cjs wrote:
2. ... it helps if you commit a PDF of the schematic ... You do need to remember to regenerate and commit the PDF in every commit that changes the `.sch` file, but I'm hoping to look soon at some way of automating that a bit.

Yes, do let me know if you manage to find a way to do that! Automatic 3D view generation for the boards would be great as well!

cjs wrote:
3. You seem to have committed your backup files as well (*-bak); it's probably best to remove these and then add that pattern to the .gitignore. (You do want to keep committing the *-cache* files, though, since they ensure someone without the same libraries as you can still read the schematics and PCB design.)


Will do, thanks for the info.

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 31, 2020 1:01 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
jfoucher wrote:
By having a transceiver between the select lines coming out of the PAL and the bus itself, an extension card could take control of the activation and deactivation of the expansion slots
Instead of a transceiver, consider using an octal FET switch instead. Example: 74CBT3245 (PDF below) even has the same pinout as a normal '245.

These FET Switch devices add virtually no propagation delay as a signal passes through -- except for a few ohms of resistance, it's as if the signal were passing through the contacts of an electromechanical relay. And as with a relay the signal can be bidirectional (!). The only minor caveat: as with a relay, there *is* some real delay in turning the thing on and off. Nothing extreme, just a gate delay.

There's some introductory material at the start of the Selection Guide (PDF below). On page 10 they discuss 5-volt devices.

The products are also offered in bus exchange and mux / demux configurations. Example of the latter: a 74_257 equivalent that's virtually-zero delay (also bidirectional). :shock: Such a part (or a pair of 'CBT3245's) would be ideal for letting an extension card take control of the activation and deactivation of the expansion slots.
Attachment:
Bus Switch Functions.png
Bus Switch Functions.png [ 37.15 KiB | Viewed 1406 times ]
Attachment:
bus switch selection scdb006a.pdf [719.31 KiB]
Downloaded 53 times
Attachment:
74cbt3245c.pdf [893.93 KiB]
Downloaded 50 times

-- Jeff

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 31, 2020 6:09 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
Oh, one more issue with slot-based addressing that I forgot to mention: it also then limits the number of (decoded) expansion slots you have to the number you have on-board decoding for.

jfoucher wrote:
Would reprogramming the PAL to map a specific address range to another port count as autoconfiguration ? :D

Well, so long as you're reprogramming the PAL on the fly while the system is operating! :-)

Come to think of it, something like that might not be so difficult. Using a parallel ROM for decoding is a tried and true technique, as seen in systems like the Fujitsu FM-7. You could use an EEPROM for decoding, wire it to be in-system programmable, and then reprogram it on the fly as the system is running. (I'll leave it to you to decide how serious I am about that proposal. :-))

Quote:
Having ROM on the cards is good move I think to allow third parties to integrate drivers in the system. However I feel it's overkill for this project.

Also, having ROM on the cards also seems to undermine the point of having a dedicated select line per slot, which is to reduce the number of components one needs to put on a card, no? Or am I misunderstanding what you like about the bus-based select system?

I'm kind of feeling now that bus-based select can be good when you have a nailed-down system design, but when your system design is in flux the constraints of a particular decoding scheme would probably hurt more than they would help. But:

Quote:
Hmm, that gives me an idea. By having a transceiver between the select lines coming out of the PAL and the bus itself, an extension card could take control of the activation and deactivation of the expansion slots in a way similar to what you suggest.

Ah ha! This idea could be used to allow for arbitrary experimentation again. How about removing all the address decoding from the backplane and putting it on a separate card that plugs into a special slot on the bus? This card would have access to all the control signals and all but perhaps the very lowest address lines, as well as a pin for the enable for each other slot. Then you can go wild consing up different ideas for the decoding circuitry without having to replace your backplane every time, and if it's not working out you can still use your backplane in the traditional way with all decoding on the card or partial decoding with a very simple separate decoding card asserting a line for the "I/O block."

Quote:
That [SBC is] actually a great idea! I think I could get something close by adding a serial chip and a connector for a USB to serial adapter to the CPU board (which already has RAM and ROM) Or maybe make them two separate card so that you could choose which one you want to build.

Yes, that's more or less how the RC6502 system works: you can build the separate CPU, RAM, ROM, etc. boards or just use the SBC board to replace the core set of boards (or of course use the SBC board stand-alone).

To run the SBC board stand-alone, you'll need clock, reset and a bit of address decoding on it too of course. I think that the RC6502 SBC is a very good model of this. The only things I'm intending to change from that when I do my own 6800 board are to add a disable jumper for the CPU as well (so the board can be used for any individual function or combination of functions: RAM, ROM, I/O and clock already all have disable jumpers) and add some configuration ability to choose what I/O select signals come out on to what bus pins.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 01, 2021 9:18 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
cjs wrote:
Oh, one more issue with slot-based addressing that I forgot to mention: it also then limits the number of (decoded) expansion slots you have to the number you have on-board decoding for.


That does not matter much since there are a fixed number of expansion slots on the board. I am not really planning of daisy chaining backplanes, although I understand it has been done.


cjs wrote:
jfoucher wrote:
Having ROM on the cards is good move I think to allow third parties to integrate drivers in the system. However I feel it's overkill for this project.

Also, having ROM on the cards also seems to undermine the point of having a dedicated select line per slot, which is to reduce the number of components one needs to put on a card, no? Or am I misunderstanding what you like about the bus-based select system?

Yes I like that it simplifies the card hardware and that it makes it easier to build cards, but I think having drivers on the card was a good move for the Apple II in that it simplifies driver integration in the overall system. I'm wondering how the card drivers can be included otherwise without having the user reprogram the main ROM. Any suggestions are more than welcome.


cjs wrote:
How about removing all the address decoding from the backplane and putting it on a separate card that plugs into a special slot on the bus?

Yep, a separate address decoding card could be used, all you have to do is remove the GAL22V10 from it's socket ;)


cjs wrote:
To run the SBC board stand-alone, you'll need clock, reset and a bit of address decoding on it too of course
.
The CPU card is already full as is, and I rather like the aesthetics of having all the expansion boards the same height, but maybe I can make all of them higher!

cjs wrote:
The only things I'm intending to change from that when I do my own 6800 board are to add a disable jumper for the CPU as well (so the board can be used for any individual function or combination of functions: RAM, ROM, I/O and clock already all have disable jumpers) and add some configuration ability to choose what I/O select signals come out on to what bus pins.


My humble suggestion regarding this would be to look at the feasibility of enabling / disabling specific features from software. Maybe a "master" CPU on the bus could disable the SBC's clock and CPU? Not sure if that's possible in your setup though. (I'm not the biggest fan of jumpers as you can see ;) )

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 01, 2021 9:46 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
BigEd wrote:
Another thing which commonly happens is that at least one peripheral needs to run at some slower clock than the CPU, so it would be good to hear what the plan is there: RDY, or clock stretching, or something else. (And if the clock isn't regular, is there any provision for fixed-frequency timer/counters?)

Just to enlarge on this a little: Acorn's BBC Micro provides a usually-2MHz CPU clock, which can be switched to a free-running 1MHz clock, used for the VIA timers. That switching to slow clock takes one or two phases depending on which phase of the 2MHz clock triggered the switch. See here for a diagram. On the other hand, their later machine, the Master, uses RDY to stall the CPU, making slower accesses as required. In both cases, the decision that the current cycle needs to be a slow cycle has to made pretty quickly, driven of course by decoding the address bus.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 01, 2021 9:51 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
jfoucher wrote:
cjs wrote:
To run the SBC board stand-alone, you'll need clock, reset and a bit of address decoding on it too of course
.
The CPU card is already full as is, and I rather like the aesthetics of having all the expansion boards the same height, but maybe I can make all of them higher!

You can put parts on both sides, to get more on a board, even with thru-hole! :D You can also put narrow ICs under wide ones on the same side, with the wide ones in sockets to get the needed vertical room.

_________________
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  
PostPosted: Fri Jan 01, 2021 9:54 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
BigEd wrote:
Just to enlarge on this a little: Acorn's BBC Micro provides a usually-2MHz CPU clock, which can be switched to a free-running 1MHz clock, used for the VIA timers. That switching to slow clock takes one or two phases depending on which phase of the 2MHz clock triggered the switch. See here for a diagram. On the other hand, their later machine, the Master, uses RDY to stall the CPU, making slower accesses as required. In both cases, the decision that the current cycle needs to be a slow cycle has to made pretty quickly, driven of course by decoding the address bus.

Funny, I just posted a question on this subject here.
Of course VIA timers go out the window with this method, but it could be useful if possible. My long term plan anyway is to copy the ROM to RAM on boot and run from RAM.

For the BBC Micro I'm not sure I understand how VIA timers are handled when switching clock speeds... Would you mind clarifying BigEd?

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Last edited by jfoucher on Fri Jan 01, 2021 10:01 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 01, 2021 9:59 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
GARTHWILSON wrote:
You can put parts on both sides, to get more on a board, even with thru-hole! :D

I've put through hole parts on both sides before, but only for simple boards. For complex boards, wouldn't the limiting factor be the number of traces that have to be run all over ? I'd rather limit the boards to 2 layers if at all possible.

GARTHWILSON wrote:
You can also put narrow ICs under wide ones on the same side, with the wide ones in sockets to get the needed vertical room.

Yes I saw incredible examples on your website, but Kicad complains even I put a surface mount cap under a socket :/ I should probably tweak the design rules so it stops bothering me about that...

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 01, 2021 10:26 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
jfoucher wrote:
BigEd wrote:
Just to enlarge on this a little: Acorn's BBC Micro provides a usually-2MHz CPU clock, which can be switched to a free-running 1MHz clock, used for the VIA timers. That switching to slow clock takes one or two phases depending on which phase of the 2MHz clock triggered the switch. See here for a diagram. On the other hand, their later machine, the Master, uses RDY to stall the CPU, making slower accesses as required. In both cases, the decision that the current cycle needs to be a slow cycle has to made pretty quickly, driven of course by decoding the address bus.

Funny, I just posted a question on this subject here.
Of course VIA timers go out the window with this method, but it could be useful if possible. My long term plan anyway is to copy the ROM to RAM on boot and run from RAM.

For the BBC Micro I'm not sure I understand how VIA timers are handled when switching clock speeds... Would you mind clarifying BigEd?

Well, first thing is that VIA timers remain reliable: the VIAs both get a steady 1MHz clock tick, all the time.

The VIAs, and anything else which needs to see 1MHz accesses, will only ever see 1MHz accesses, because in the cycles that they are selected, the CPU is held up to wait for the end of the next 1MHz cycle, before continuing at its usual 2MHz.

So, the VIAs operate in a 1MHz world, and the CPU operates 99% of the time in a 2MHz world. Dave (@hoglet) has extended this to a CPU running at 100MHz (in FPGA) slowing down to 2MHz or 1MHz as it needs to access resources on the motherboard. Revaldinho has extended it to an '816 CPU daughterboard running at 14MHz and up to 20MHz on a similar basis. (In both cases, fast local RAM is needed to get any work done at high speed.) So, these two tactics, of RDY or clock-stretching, have proved to be quite general and robust.

(RDY is more applicable with CMOS parts, as NMOS CPUs don't recognise RDY during a write cycle, making it harder to use it for this purpose. That's probably the reason why Acorn's earlier machine used the clock-stretching approach.)


Last edited by BigEd on Fri Jan 01, 2021 10:33 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Jan 01, 2021 10:28 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
jfoucher wrote:
GARTHWILSON wrote:
You can put parts on both sides, to get more on a board, even with thru-hole! :D

I've put through hole parts on both sides before, but only for simple boards. For complex boards, wouldn't the limiting factor be the number of traces that have to be run all over ? I'd rather limit the boards to 2 layers if at all possible.
Routing is always the challenge with high density. I think all board houses today can do .006" trace & space though before they start charging extra or losing reliability; and you can get up to four traces between pads of a a thru-hole IC with them. This is with pads .045"x.055" and .006"/.006" trace/space:
Attachment:
4tracesThruDIP.gif
4tracesThruDIP.gif [ 8.68 KiB | Viewed 1345 times ]

Quote:
GARTHWILSON wrote:
You can also put narrow ICs under wide ones on the same side, with the wide ones in sockets to get the needed vertical room.

Yes I saw incredible examples on your website, but Kicad complains even I put a surface mount cap under a socket :/ I should probably tweak the design rules so it stops bothering me about that...

I quit paying attention to my DRC many years ago, as it doesn't understand what I'm trying to do. At my last place of work, we had OrCAD, and it was much worse. At least with my old Easy-PC Pro I can still elect to ignore the DRC and do what I want. OrCAD was always trying to second-guess me and tell me I couldn't do one thing or another, and it wouldn't let me.

Nice idea on the VIAs & clock-speed switching, Ed.

_________________
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  
PostPosted: Fri Jan 01, 2021 11:21 pm 
Offline
User avatar

Joined: Sun Dec 27, 2020 11:12 pm
Posts: 94
Location: France
BigEd wrote:
jfoucher wrote:
For the BBC Micro I'm not sure I understand how VIA timers are handled when switching clock speeds... Would you mind clarifying BigEd?

Well, first thing is that VIA timers remain reliable: the VIAs both get a steady 1MHz clock tick, all the time.

The VIAs, and anything else which needs to see 1MHz accesses, will only ever see 1MHz accesses, because in the cycles that they are selected, the CPU is held up to wait for the end of the next 1MHz cycle, before continuing at its usual 2MHz.

Ok, I think I get it. The VIAs get a single clock at 1MHz all the time. The CPU gets another clock at (say) 2MHz all the time except when the VIAs are selected so that it can communicate with them.

In my case, (and please tell me if I get something wrong) it would be possible to have a slow clock and a fast clock on the bus. The expansion slots would listen to the slow clock all the time. The CPU board would listen to the fast clock all the time except when an expansion slot (or it's onboard ROM) is selected. The only drawback I see with this scheme is that fast devices (say RAM expansion) on the bus would be forced to use the slow clock. Unless I can think of a way to let the CPU know which expansion board uses which clock... Or have some "fast slots" and some "slow slots"...

Anyway, thanks for the clarification BigEd

GARTHWILSON wrote:
jfoucher wrote:
GARTHWILSON wrote:
You can put parts on both sides, to get more on a board, even with thru-hole! :D

I've put through hole parts on both sides before, but only for simple boards. For complex boards, wouldn't the limiting factor be the number of traces that have to be run all over ? I'd rather limit the boards to 2 layers if at all possible.
Routing is always the challenge with high density. I think all board houses today can do .006" trace & space though before they start charging extra or losing reliability; and you can get up to four traces between pads of a a thru-hole IC with them. This is with pads .045"x.055" and .006"/.006" trace/space:



I have to admit I haven't dared go to the limit of what the board house can do. I'm currently setup for 10mil/10mil trace/space. It appears JLCPCB at least can do 5mil/5mil ( https://jlcpcb.com/capabilities/Capabilities ). I'll have to get a test board fabricated at those specifications to see if the reliability is there before I'm confident though ;) Getting 4 traces between pads sound reeeally appealing :D

_________________
Jonathan Foucher

Take a look at the Planck 6502 computer.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

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