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

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

I used a set of jumpers to select between 28C256 and 39SFxxx devices on my Flash Programmer Shield but I took care of the the A14/A15 conflict on pin 3 in software. A slightly more complex jumper scheme might allow support for a variety of RAM and ROM devices (see below).

Good luck on your project. Cheerful regards, Mike

Are you sure both A15 and A16 need to be at the same logic level?

I interpreted the "unconnected pins" designation as meaning they weren't connected rather than they shouldn't be connected. If it had said "do not connect", I would have interpreted it the other way. However, I'll concede I may have misinterpreted it and it doesn't cost anything to use a bridgeable link or do what Garth said and cut the pin off.

That's how I interpreted this table:



It says "address lines AMS to A15 can be VIL or VIH, but no other level". Which is a very odd statement. I interpreted that as meaning they either have to be all low or all high. Although there are other possible interpretations. You could interpret it as "they all have to be either high or low, independently", but surely that is no constraint? Other than that they can't be left floating or connected to a voltage which doesn't represent a valid logic level, which I would have though goes without saying. The statement could also be interpreted as saying those pins have to be held at exactly VIL or VIH, but that makes even less sense.

From the fact you've used this chip before, I'm guessing you didn't have them at the same level while issuing command codes, and it still worked?

Sorry about the length; I kinda let this thread go a while before starting to read it and now there's lots to reply to.


For what it's worth, the "standard" RC6502 backplane board is 24 mm centre-to-centre. (This is the maximum spacing you can get for five slots on the JLCPCB 10 cm × 10 cm minimum-price board around which the entire RC6502 system was designed.) The attached photo shows my Apple I clone SBC inserted into the backplane; you'll note it leaves enough room for the Arduino Nano which is not socketed but is a small board on 0.1" headers.


For spacing the bus headers further apart, have you thought about moving some of your devices between the headers? I would think that RAM and ROM, in particular, might fit in there fairly well since most of their signals are coming off the bus anyway. I'm not so sure about the PIA.

I'd also consider adding pads for a right-angle header right at the edge of the board so it could plug into a stand-alone backplane, like the SBC does.


Well, my feeling on that is that I'd consider carefully using the Wilson design or even a NAND or two over more decoding (like the '138 on the SBC) if you're focusing on making this fairly expandable. (Which, with three slots on your board, it looks like you are.) Garth's approach is pretty darn clever and gives massive savings on logic, but has the usual trade-off of eating a fair amount of address space for a relatively limited number of devices. It also has a lot of aliasing of multiple devices together, which is fine if you know what you're doing but not so great if beginners might be using your boards, I'm thinking. The '138 does have the disadvantage of being slower, but particularly high speeds might also be bad for beginners if they're glomming their own stuff on the bus, too.

The advantage of the '138 method is that it does a "medium" amount of non-overlapping decoding and, if you bring some of these I/O lines out to the bus as is discussed in the other thread (and as I plan to do for my SBC, and as others have done for theirs) it means you can use another '138 on a peripheral board to do another "medium" amount of decoding, giving you "medium²," which is a fair amount. (Typically, first '138 decoding top 32K into 8×4K blocks and second '138 decoding one of those into 8×512 byte blocks. It's easy to change this to be 2K/256 byte or 1K/128 byte chunks if you are building a high-memory system with 48K or 56K always mapped as RAM.) More on all this in the bus thread, of course.

BTW, this is not to say that the Wilson method is bad in any way; it's just (to my mind) best for something like a single system where one experienced guy is in designing and building everything on it, and speed and reducing logic is more important than being more modular. (Which happens exactly to describe Garth's bench computer.)

All that said, I must admit that for personal reasons I prefer you do the Wilson decoding system since bringing in such a different decoding design at an early stage will help make the bus design better. :-)

For what follows, I'm not sure if it's all worked out or not but I'll just post it without doing too much analysis of the previous posts because it's getting near the end of a long day. :-/


Is it not? At first glance it looks as if it is to me. Remember, when more pins are added, the pins on the right side "slide" so that the "bottom" pins (furthest from pin 0 and the highest pin) continue to match. This means that e.g. /OE should be pin 20 on a 24-pin device, pin 22 on a 28-pin device, and pin 24 on a 32-pin device. I drew up this diagram to help with matching the JEDEC pinouts for various device sizes (this is RAM/EEPROM, not EPROM):


(In case that's not rendering well in your browser, I've attached below a screenshot taken in urxvt.)

There are definitely some pins that need jumpers based on device size (Vcc being the most obvious one), but if you need not support the old really small devices, I think this is relatively few.


Yeah, that's using JEDEC ROM pinout instead of RAM/EEPROM pinout, IIRC, but even there there are not a lot of pins to change with jumpers or solder/cut pads.

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

Appreciate all the folks sharing schematics for making the ROM slot more configurable (And explaining the logic behind the JEDEC layout a little bit).



I am indeed using the Wilson linear-ish decoding scheme. I'm making the /IOEN signal (which decodes 4000-7FFF range) easily assigned to the bus, but I do think your idea on the other thread of permanently assigning this to Bus Pin #39 is a fine idea. A 138 can still be used within that range with /IOEN as the G1 signal. If you're using more than 10 cards with parallel interfaces, well... that would be a pretty cool computer .

Ultimately tho, this build just needs to be address compatible with the BE software. So I might try around to see what I can come up with that still decodes 6000-600F but has less of the potentially risky address duplication.


That's the "original" backplane? The [link url=https://rc2014.co.uk/backplanes/backplane-5/]Backplane-5[/link] from RC2014 official shop is much smaller, with pins on 13mm-ish centers.

Components between the headers is interesting. If I do smoosh this board down to 100x100 (dropping pin 40), I may give that a try.



The boards (SC SBC and RC2014 Mini) both use Right Angle headers to pass through to a standalone backplane. I do see photos of z50 Bus devices that have larger pads with a straight header soldered directly on. hmm.

_________________
https://github.com/Individual-Solid/

Yes, it works. A15 and A16 do not need to be at the same level...

No need to drop pin 40 at 100×100: you can just leave a pad somewhere and hand solder a jumper wire from the pin that sticks off the edge to that pad. As I mentioned, on my backplane I didn't trim the 40-pin female headers down to 39 and so I still have that one pin sticking off the edge of the board for every slot, ready to have a wire soldered to connect them all together.

Sure, it's a bit "bodgy," but then again, so is the whole idea of using a single-row .1" pin header in the first place. There are much better solutions out there if you're not going for "cheap and cheerful."


Right. You've linked the original RC2014 backplane; I was talking about the original RC6502 backplane, which is what you're trying to be compatible with. Though honestly, I'm guessing that making your spacing a bit smaller is not likely to be a huge issue. FWIW, my RC6502 memory board has a ZIF socket on it that when loaded needs 18 mm of clearance above the board. (The socket's handle sticks up over the top so it will clear another 10 cm board in the next slot.)


Right. In case I wasn't clear, I was talking about doing this on your SBC. (In the current designs you've shown, the pads closest to the edge don't look close enough for the standard RC2014 connector, at least to my eyes.) This is what I was talking about:

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

If you use JLCPCB, the maximum size pc board for their economical 100mmX100mm pcb is actually 102mmX102mm, so you in fact can have full 40 pin RC2014 connector and still get their economical pricing. SeeedStudio, on the other hand, is indeed 100mmX100mm and no bigger.
Bill

I'll admit that hardware compatibility with the RC2014 backplane families is more interesting to me (than compatibility with any particular RC6502 design), given that there are more designs available for purchase today.

Ah yes, I keep shuffling these things apart. I wanted to bring attention to this style, which I might choose to adopt

saving the need for a RA header.

The BOM on the current board is $46 with the CPU/RAM/ROM/VIA included, and $13 without, so I'll definitely be investigating the flash to replace the EEPROM.


Oh, that's fabulous news! I'll work on a revision that incorporates the flash, slims down to 102x102 with two ports and a RA header at the end. I've got more silkscreen to add as well.

I'm definitely interested in trying out JLC's SMT assembly service to build a FT245R breakout that's on a 40pin header, and I think I can definitely get that cheaper than other popular FT245Rs.

_________________
https://github.com/Individual-Solid/

Oh, I'd not realized this! It seems to me then that you should just completely ignore RC6502 bus then and go with RC2014 bus, which saves you any argument about whether or not to keep or use Φ2out (pin 19) and Φ1out (pin 21), since those don't exist on RC2014 (they are M1, where you might put SYNC if you keep it, and /MREQ, which of course is required for any RC2014 memory-addressed peripheral). And there's no question that you need to maintain pin 26 as /IOREQ, as well as use /RD and /WR instead of R/WB.

The downside of this is that you're not only translating Motorola to Intel bus protocol for your CPU board, but also doing the same again for any peripheral boards you build.

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

To be clear, when I say "hardware compatibility with the backplane" I just literally mean being able to use an existing RC2014 extension backplane to plug in more modules. Like this one pictured.



Not actual signal level compatibility/peripheral compatibility. I have no desire to do synthetic signals for z80 peripherals.

Now, getting to compatibility with RC6502 peripherals is vaguely interesting, but since they're not manufactured regularly that I can tell, it's not as important to me as being able to reuse the backplane hardware. And I do owe a new post in that RC6502 thread with my latest thoughts about compatible bus signals.

_________________
https://github.com/Individual-Solid/

Oh! I completely misread that. May I suggest using the term "physical compatibility" for that? When I think "hardware compatibility" I tend to think of electronic devices working with other electronic devices. (E.g., a DE-9 serial port has physical compatibility with a DE-9 DRGB monitor input, but I would consider the serial port and the monitor two pieces of hardware that are not compatible.)

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