B36502X Single Board Computer

[GARTHWILSON]

Sometimes NC pins are used in production testing, and are not truly unconnected on the inside, only intended that the user not connect them. Caution might be appropriate. If it is connected on the inside, maybe there are the usual protection diodes there which you could detect by measuring with the continuity meter function of a DMM. Or, you could just cut the pin off. I've done that a couple of times, and eliminated the hole and the pad on the PC board so the space could be used to route traces.

[BigDumbDinosaur]

plasmo wrote:

In SST39SF0x0 data sheet it says "unconnected pins" for the NC symbol.
Bill

I did see that when I read the data sheet—it's ambiguous. Manufacturers usually make a statement as to whether an NC pin should not be connected to anything or can safely be used as a "tie point." Given the vagueness of the data sheet, I wouldn't connect it.

[Michael]

Individual_Solid wrote:

Michael wrote:

May I mention the SST 39SFxxx series Parallel FLASH ROMs in PDIP package as an alternative to the AT28C256 EEPROM? The 128-KiB 39SF010A is $1.47 at Mouser or $1.52 at Digikey while the AT28C256-15PU EEPROM is $10.75 at Mouser or $10.66 at Digikey (15-Aug-2021). Example (untested) designs below.

Cheerful regards, Mike

Neat suggestion. It's not pin compatible with the EEPROM, which makes it not a great solution for this kit where I want to encourage folks to use the hardware they already purchased for a breadboard build. However, it might be worth while to fab a "converter" card that could drop in a ZIF socket that was intended to hold the AT28C256.

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

[Michael]

kernelthread wrote:

One more thing to consider is that, if you want to be able to program the flash device in situ under the control of the 6502, the 6502 must be able to control A0-A14, and A15 and A16 must either be both low or both high. This is because to initiate erase or program operations you need to perform a specific sequence of writes to the device satisfying those conditions.

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

[kernelthread]

BigDumbDinosaur wrote:

kernelthread wrote:

Pin 30 is NC on the 010, so we can connect it to VDD.

You sure about that? As a fairly general rule, if the data sheet indicates a pin as a no-connect it should not be connected to anything.

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.

[kernelthread]

Michael wrote:

kernelthread wrote:

One more thing to consider is that, if you want to be able to program the flash device in situ under the control of the 6502, the 6502 must be able to control A0-A14, and A15 and A16 must either be both low or both high. This is because to initiate erase or program operations you need to perform a specific sequence of writes to the device satisfying those conditions.

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

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?

[cjs]

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.

jfoucher wrote:

Looks great, but If the female headers on the right hand side are your expansion connectors, they seem very close together....

jfoucher wrote:

And here's mine, about 19mm on centers. Most things fit, but sometimes a bit tighter than I'd like. I've actually shorted the back of one board a few times.

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.

Quote:

Because of these choices, an 74HC00 can be used for address decoding instead of the '132 (chip included in BE kit)

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. :-/

Quote:

[The SST 39SFxxx series is] not pin compatible with the EEPROM, which makes it not a great solution for this kit where I want to encourage folks to use the hardware they already purchased for a breadboard build.

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):

Code: Select all

                        ┌─────────∪─────────┐
                ────────│1                32│──────── (Vcc)
          (A16) ────────│2                31│──────── (A15)
     (A14, Vpp) ────────│3  1          28 30│──────── (Vcc, CS2)
          (A12) ────────│4  2          27 29│──────── (P̅G̅M̅, W̅E̅, A14)
                   A7 ━━│5  3  1    24 26 28│──────── (Vcc, A13)
                   A6 ━━│6  4  2    23 25 27│━━ A8
                   A5 ━━│7  5  3    22 24 26│━━ A9
                   A4 ━━│8  6  4    21 23 25│──────── (W̅E̅,  A11, Vpp, A12)
                   A3 ━━│9  7  5    20 22 24│━━ O̅E̅¶ ─ (C̅S̅)
                   A2 ━━│10 8  6    19 21 23│━━ A10
                   A1 ━━│11 9  7    18 20 22│━━ C̅E̅ ── (A11)
                   A0 ━━│12 10 8    17 19 21│━━ D7
                   D0 ━━│13 11 9    16 18 20│━━ D6
                   D1 ━━│14 12 10   15 17 19│━━ D5
                   D2 ━━│15 13 11   14 16 18│━━ D4
                  GND ━━│16 14 12   13 15 17│━━ D3
                        └───────────────────┘

(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.

Individual_Solid wrote:

Here is a part I used in several designs that may help driving down your BOM cost. W27C512 EEPROM is an obsoleted part but can be easily acquired on eBay for about $1 each.

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.

[Individual_Solid]

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

Quote:

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.

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.

Quote:

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.

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.

Quote:

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.

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.

[Michael]

kernelthread wrote:

Michael wrote:

kernelthread wrote:

One more thing to consider is that, if you want to be able to program the flash device in situ under the control of the 6502, the 6502 must be able to control A0-A14, and A15 and A16 must either be both low or both high. This is because to initiate erase or program operations you need to perform a specific sequence of writes to the device satisfying those conditions.

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

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?

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

[cjs]

Individual_Solid wrote:

If I do smoosh this board down to 100x100 (dropping pin 40)

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."

Individual_Solid wrote:

Quote:

For what it's worth, the "standard" RC6502 backplane board is 24 mm centre-to-centre.

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

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.)

Quote:

Quote:

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.

The boards (SC SBC and RC2014 Mini) both use Right Angle headers to pass through to a standalone backplane.

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:

rc6502 SBC bus connector.jpg (59.4 KiB) Viewed 1296 times

[plasmo]

cjs wrote:

Individual_Solid wrote:

If I do smoosh this board down to 100x100 (dropping pin 40)

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."

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

[Individual_Solid]

Quote:

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.

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.

Quote:

(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.)

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.

Quote:

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.

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.

[cjs]

Individual_Solid wrote:

I'll admit that hardware compatibility with the RC2014 backplane families is more interesting to me (than compatibility with any particular RC6502 design)...

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.

[Individual_Solid]

cjs wrote:

Individual_Solid wrote:

I'll admit that hardware compatibility with the RC2014 backplane families is more interesting to me (than compatibility with any particular RC6502 design)...

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.

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.

[cjs]

Individual_Solid wrote:

cjs wrote:

I'll admit that hardware compatibility with the RC2014 backplane families is more interesting to me (than compatibility with any particular RC6502 design)...

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.

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.)