Home » RBC Forums » General Discussion » New Board Development - SBC6120-RBC Edition
|
Re: New Board Development - SBC6120-RBC Edition [message #667 is a reply to message #666] |
Mon, 09 May 2016 16:50   |
 |
Wayne W
Messages: 385 Registered: October 2015 Location: Fallbrook, California, US...
|
Senior Member |
|
|
When I put the v271 ROM (non-scrambled) on my original STG SBC, the second row of lights misbehaves. Again, I am saying that the second row of lights (data bits) only work when the rotary is in the MD position. So... this points more suspicion to the v271 image we are using which apparently is not binary identical to the one Andrew dumped from his ROMs.
Thoughts?
Oh, and no joy on the 47uF cap added at the 50-pin power pins. Startup of the RBC SBC is still flaky. I am noticing that startup when the board is cold (has been turned off for a while) seems to be 100% reliable. Flakiness starts after board has warmed up for about 5 mins. I am going to go over all my solder joints just for fun. However, it perplexes me that the flakiness only occurs when attached to the front panel. Voltage at my chips runs between 4.94 and 4.96 which should be OK. Actually, the voltage at my chips when I run without the front panel is ~4.75 due to the fuse that applies in that scenario.
-Wayne
[Updated on: Mon, 09 May 2016 17:03] Report message to a moderator
|
|
|
|
|
|
Re: Front Panel for the SBC6120-RBC Edition [message #677 is a reply to message #676] |
Tue, 10 May 2016 17:06   |
jcoffman
Messages: 332 Registered: October 2015
|
Senior Member |
|
|
The problem with my board is solved. Interesting story today when it magically started to work. At first, two switching power supplies were suspect, since the board seemed to work best off of a little breadboard power supply with a 7805. Hmmm, high frequency ripple on the switching supplies? But the problem returned when I moved out here with that little analog supply and connected to a terminal. Stop at '5'. ROM checksum bad. The same setup works in the back bedroom--on the metal desk. So now I am here on the wooden computer bench, hooked to a terminal, seeing the SBC6120 monitor. The difference: a sheet of aluminum foil underneath all (insulated with thicknesses of paper). The SBC6120 works fine. No chip changes; no new components; no problem with the board or soldering.
For some reason, this board appears to be extremely sensitive to noise, whether background or self generated. It works with the old Apple switching power supply, the little analog supply -- but only if it is sitting above a good ground plane. IT WILL NOT WORK ON A WOODEN SURFACE.
In the process, I added a 1000uF cap between the two test points on either side of the Zener. It works with or without this extra cap. The ground plane is the thing.
[Perhaps there was a reason for the STG board to be 4 layers.]
--John
|
|
|
Re: Front Panel for the SBC6120-RBC Edition [message #678 is a reply to message #676] |
Tue, 10 May 2016 20:07   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Wayne W wrote on Tue, 10 May 2016 13:08
John,
In the process of switching from the v271 to v320 ROMs, I wound up using slightly different chips. I was previously using Xicor X28C256 and am now using Atmel AT28C256. In both cases the chips had a speed rating of 150ns. I need a few more hours to say for sure, but it looks like the AT28C256 chips have improved (possibly fixed) my boards reliability problem. I think you said you originally were using 250ns parts. I wasn't clear from your posts if you have tried different ROM chips. Wonder if you have tried anything else? Especially something faster? When my board was previously failing to start, the most common place for it to get stuck was the ROM Checksum. I need a few more hours to say if my startup reliability is totally resolved.
Quote:For some reason, this board appears to be extremely sensitive to noise, whether background or self generated. It works with the old Apple switching power supply, the little analog supply -- but only if it is sitting above a good ground plane. IT WILL NOT WORK ON A WOODEN SURFACE.
I've done all of my testing sitting on a wooden desk, with 150ns AT28C256's...... So it seems like overall these prototypes are not super stable, which is unfortunate (and completely on me, since the original design is quite reliable).
One thing John pointed out in an email is that /WE of the EEPROMs should really be pulled HIGH which the board does not do, it leaves Pin 27 of the EEPROM sockets floating with the jumper in the 28C256 position. Wayne, if you intend to use only EEPROMs in your board, perhaps making that modification would resolve the difference you are seeing between the two EEPROM brands/speeds. John also suggested a slick 4-pin jumper arrangement that will make sure we are putting all the pins at the right voltages when switching between 27C256 and 28C256 - which I should have spent more time thinking about and reviewing the different data sheets.
|
|
|
Re: Front Panel for the SBC6120-RBC Edition [message #679 is a reply to message #678] |
Tue, 10 May 2016 20:31   |
 |
Wayne W
Messages: 385 Registered: October 2015 Location: Fallbrook, California, US...
|
Senior Member |
|
|
Andrew B wrote on Tue, 10 May 2016 20:07
I've done all of my testing sitting on a wooden desk, with 150ns AT28C256's...... So it seems like overall these prototypes are not super stable, which is unfortunate (and completely on me, since the original design is quite reliable).
One thing John pointed out in an email is that /WE of the EEPROMs should really be pulled HIGH which the board does not do, it leaves Pin 27 of the EEPROM sockets floating with the jumper in the 28C256 position. Wayne, if you intend to use only EEPROMs in your board, perhaps making that modification would resolve the difference you are seeing between the two EEPROM brands/speeds. John also suggested a slick 4-pin jumper arrangement that will make sure we are putting all the pins at the right voltages when switching between 27C256 and 28C256 - which I should have spent more time thinking about and reviewing the different data sheets.
I don't want to restrict myself to EEPROMs, but I can easily try the Xicor X28C256 EEPROMs with a temporary strap on pin 27 to +5V. I will let you know if that helps.
Regardless, I am definitely finding that switching from the Xicor ROMs to Atmel ROMs has stabilized my board. Now seems to be 100% stable.
-Wayne
|
|
|
Re: Front Panel for the SBC6120-RBC Edition [message #681 is a reply to message #679] |
Tue, 10 May 2016 23:53   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Looking at some datasheets (attached for reference).
Data input from EEPROM to HD-6120, HIGH state:
HD-6120: VIH, Min = 70% VCC => 5.0V*.70 = 3.5V
AT28C256, XC28C256: VOH, Min = 2.4V
(Looks like -1.1V margin on this one?)
Data input from EEPROM to HD-6120, LOW state:
HD-6120: VIL, Max = 30% VCC => 1.5V
AT28C256, XC28C256: VOL, Max = 0.45V
(1.05V margin here)
Data input to EEPROM from HD-6120, HIGH state:
AT28C256, XC28C256: VIH, Min = 2.0V
HD-6120: VOH, Min = VCC-0.5V => 5.0V-0.5V = 4.5V
(2.5V margin here)
Data input to EEPROM from HD-6120, LOW state:
AT28C256, XC28C256: VIL, Max = 0.8V
HS-6120: VOL, Max = 0.5V
(0.3V of margin)
So, just looking at the datasheets for the parts, it seems like we'd likely have susceptibility to the differences between EPROMs and EEPROMs, manufacturer-to-manufacturer variations, and potentially PCB-layout related noise on ROM reads. Most E(E)PROMS will probably output a 'high' signal that is better than their datasheet minimum spec.....but it's not guaranteed. I could definitely see the 4-layer board helping if I am reading these datasheets correctly.
Can one of you guys check and make sure I'm not reading this wrong and totally off base here?
Edit: I think I'm wrong above, because the 'test condition' on the EEPROM data sheets is a current of -400uA on the outputs, while the maximum input leakage current on the HD-6120 inputs is 10uA. So the ROM outputs should end up at a much higher voltage than what is in the datasheet for the test condition. This 27C256 datasheet - http://www.ee.ryerson.ca/~jkoch/data_pdf/27c256.pdf - shows 2.4V at -400 uA, but 4.4V at 0 uA.
Leaving the rest of the post for the datasheets and stuff.
[Updated on: Wed, 11 May 2016 00:10] Report message to a moderator
|
|
|
|
|
Re: Front Panel for the SBC6120-RBC Edition [message #685 is a reply to message #684] |
Wed, 11 May 2016 07:12   |
gkaufman
Messages: 186 Registered: October 2015
|
Senior Member |
|
|
I missed a bit of this discussion as I was unfortunately out of town.
I used "old fashioned" 27C256 Eproms. AMD AM27C256-205DC with the 271 scrambled code.
Power supply is a junky floppy power cube from Ebay.
No shielding (sitting on a towel on a wood bench).
I'll run it some more tonight, but before I left I played adventure for a while with no glitches.
- Gary
[Updated on: Wed, 11 May 2016 07:12] Report message to a moderator
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #686 is a reply to message #454] |
Wed, 11 May 2016 08:34   |
sparetimegizmos
Messages: 5 Registered: May 2016
|
Junior Member |
|
|
A few comments regarding the SBC6120 ROMS which may be helpful -
- The PDP-8 numbers its bits from left to right. That's not the modern convention, but you're not building a modern computer. I think you already figured this out the hard way and you can cope with it any way you want, but that's why the address bits on the original SBC6120 were not wired up to the EPROM as you expected.
- BTS6120 v320 was for the SBC6120-RC (not RBC) model, but it was fully backward compatible with the original SBC6120. Whenever somebody ordered an SBC6120 I would ship the latest firmware, so whoever got the v320 ROMs in his SBC6120 simply has one of the last production units. There's no mystery there.
- There's a build date and time in BTS6120. This isn't a secret - it prints out the timestamp when you boot it. If you reassemble, for example, the v271 source then it's going to get today's date and time and the ROM image you get won't be byte for byte identical to the v271 ROMs I shipped. And as a consequence, the ROM checksums will change as well.
- OS/8 really wants 7M1 as the RS232 format - that's what a real ASR33 would have done. Most programs ignore the MSB, so 7E1 also usually works. BTS6120 is perfectly happy with 8N1, 7E1 or 7M1. There's no need to change the terminal settings when booting.
Bob
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #688 is a reply to message #687] |
Wed, 11 May 2016 09:08   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Thanks for the suggestions Bob. This has definitely been a learning experience. I thought of sitting down with both the original schematic and my schematic with a highlighter and red pen to do a final check, like how I check mechanical drawings at work, but my excitement got the best of me and I just went to fab. Otherwise I would have caught the ROM pinout issue for sure.
On the CPREQ interrupt, I think I figured it out. The orientation of the CPREQ jumper J10 on our boards is reversed from the orientation on the original STG boards.
When the board is being used alone this isn't a problem, but when it interfaces with the FP6120 or IOB6120, the pinout is incorrect.
I have to head to work now but tonight I'll post some pictures of the problem and a fix. It will take cutting two traces and two jumper wires on the bottom of the board to fix.
Wayne - if you check J10 with a multimeter on your STG board and the prototype board and see which pin goes to the adjacent 74HC04 and which goes to the CPU, you'll see what I mean. It's reversed.
Added to my list of fixes for V1.00.
[Updated on: Wed, 11 May 2016 09:13] Report message to a moderator
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #690 is a reply to message #688] |
Wed, 11 May 2016 10:14   |
sparetimegizmos
Messages: 5 Registered: May 2016
|
Junior Member |
|
|
FWIW, when I originally designed the SBC6120 I wanted to make a "modern" PDP-8 - something along the lines of a MicroVAX or LSI-11. I never intended there to be a front panel of any kind, and all the panel functions were in firmware. The form factor of the SBC6120 was designed to mate with a 5-1/4" IDE drive and it was intended to piggyback on top of an HDD. The size of the SBC6120 PC board, the IDE and power connector locations, the 4 pin Molex power connector, and even the location of the five mounting holes, were all designed to mate with an IDE drive. My vision was a drive and SBC6120 stack that you could stick in a little external drive enclosure on your desktop. It would have no controls other than POWER and RESET.
But people really wanted a front panel. I resisted for about a year, but eventually I caved in and designed one. The whole front panel design, including the mechanical arrangement where the SBC6120 mounts on the back of the panel, the whole CPREQ jumper/connector "hack", and the power distribution from the front panel to the SBC6120, is a consequence of the fact that it was all added on to something that was never intended to have it. C'est la vie...
The SBC6120-RC (not RBC) was designed from the beginning to have an integrated front panel. Although it's software compatible, including the same BTS6120 boot ROMs, that machine is electrically and mechanically quite a bit different and is a much cleaner design for that end goal.
Bob
|
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #693 is a reply to message #692] |
Wed, 11 May 2016 21:47   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
I think I'd like to focus right now on taking all of the feedback and tweaks we have found and finishing the schematic/routing V1.00 of this board.
I'm still a bit concerned about the instability that John C. has been seeing so I'd like to get some more feedback on that as well. Maybe some manual routing is in order, or going back to 4 layers.
I do wonder if we should change the name a bit for the final board, since it is so close to SBC6120-RC. I'd be open to suggestions in that respect.
As for the future - I've had a few things in my mind:
-Try out rkoolstar's 'mini front panel' board with panel mount switches and lights. A bit fiddly to build, but gives the builder a large flexibility in light and switch selection.
-Make a version with most of the 74xx logic & GALs replaced with a single ATF1508 PLCC CPLD. (This is a bit selfishly driven by my own desire to learn more about VHDL....
-Use the 8255 PPI IOTs to drive Sergey's ParPortProp board, and write a modified BTS6120 and OS/8 device handlers to use that display and storage (I already have that board built and tested with my Zeta, so just wiring + software). This would also leave the existing console SLU free for other OS/8 uses, and create an interesting mashup with some of our existing boards.
-Make a version like the -RC, but also with the CPLD, and use the freed up space to put the VGA/PS2 console directly onto the board
-Etc
My 'real life' work is going to be a bit busy here for a few months, so anything new will probably need to wait for a lull.
|
|
|
|
|
|
|
|
|
Re: Front Panel for the SBC6120-RBC Edition [message #709 is a reply to message #454] |
Thu, 12 May 2016 11:17   |
jcoffman
Messages: 332 Registered: October 2015
|
Senior Member |
|
|
Andrew,
4 layers, although it doubles the production cost, would probably solve the problem I see. I assume I have some component that is very sensitive to signal ringing. That is probably what the foil under-layer reduces, since it should reduce trace inductance. I am surprised to see any problem on a board that I ran as slow as 3.58mHz. BTW: with the foil under-layer, the board is good at 8mHz.
Somewhere in the back of my mind I think I read a caution with CMOS about its high capacitance, and that switching causes large current transients. Relatively narrow traces distribute power on this board, but I would think that any bouncing of the power supply would be offset by the power & ground zones. Maybe some extra decoupling (electrolytic) on the ROM side of the board would help. Something to try.
Perhaps, also, the trouble I see is just a fluke with the particular CPU I have: Intersil HD1-6120-8, but I believe Will is working with the same CPU.
--John
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #710 is a reply to message #701] |
Thu, 12 May 2016 20:20   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
I took a look at the VHDL code for the IOB6120 (on http://www.jkearney.com/sbc6120/iob6120.htm), and the Pin 141 (INTGNT) is referred to in only 3 places.
Entity Definition:
entity iob is
port
(clk_in: in std_logic; -- 29.4912 MHz
-- CPU bus interface
cpu_ioclr_n : in std_logic;
dx : inout std_logic_vector(0 to 11);
clk_write_n_raw : in std_logic; -- async
cpu_read_n : in std_logic;
cpu_sr_read_n : in std_logic;
cpu_sr_write_n : in std_logic;
clk_lxdar_n_raw : in std_logic; -- async
cpu_c0_n : out std_logic;
cpu_c1_n : out std_logic;
cpu_skip_n : out std_logic;
cpu_intreq_n : out std_logic;
cpu_intgrnt_n : inout std_logic;
cpreq_n: inout std_logic;
Pin definition:
attribute loc of kb_clk : signal is "P138";
attribute pullup of kb_clk : signal is "yes";
attribute loc of kb_data : signal is "P133";
attribute pullup of kb_data : signal is "yes";
attribute loc of lpt_ack : signal is "P91";
attribute loc of lpt_busy_n : signal is "P121";
attribute loc of lpt_data : signal is "P66 P63 P59 P56 P51 P43 P47 P38";
attribute loc of lpt_ddir : signal is "P28";
attribute loc of lpt_error : signal is "P137";
attribute loc of lpt_init : signal is "P7";
attribute loc of lpt_paper_end_n : signal is "P136";
attribute loc of lpt_select_in_n : signal is "P124";
attribute loc of lpt_strobe : signal is "P10";
attribute loc of reprogram : signal is "P85";
attribute loc of rxd : signal is "P23 P26 P27";
attribute loc of txd : signal is "P11 P21 P115";
attribute loc of vga_hs : signal is "P117";
attribute loc of vga_rgb : signal is "P99 P126 P120";
attribute loc of vga_vs : signal is "P102";
attribute loc of cpu_intgrnt_n : signal is "P141";
attribute loc of cpreq_n : signal is "P113";
And one line that sets it to High-Z state:
------------------------------------------------------------ -----------------------------
-- utility and shared logic
------------------------------------------------------------ -----------------------------
cpu_intgrnt_n <= 'Z';
Based on this, I don't think the IOB6120 uses the signal either. Correcting the error and hooking up the correct CPU pin makes the most sense to me.
[Updated on: Thu, 12 May 2016 20:20] Report message to a moderator
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #711 is a reply to message #710] |
Thu, 12 May 2016 20:30   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Updating my list of items to fix for V1.00
Outstanding:
9. Draw in simple silkscreen outlines for the Molex power connector and the power switch
Maybe:
13. Manually route the decoupling caps to each IC to keep from making large loops on the board that might cause noise
DONE:
1. Connect 2 /LXMAR nets (add global net output for /LXMAR on CPU page of schematic to get KiCAD to hook them up)
2. Fix ROM address line order (probably swap RAM lines to match too just for OCD-ish reasons)
3. Add jumper+PTCC fuse to feed VCC to IDE pin 20 for CF card adapters.
4. Move RAM chip footprints a little bit away from the ROM chips (no room for inserting a chip puller if you want to remove the chips!)
5. Add a 2-pin connector for case reset button (modify existing test point near the reset switch)
6. Mark the net between the Molex connector and the fuse as a 2x width trace in Freerouting to be consistent with the other VCC/GND traces being 2x width - (VCC comes out of the fuse)
7. Add a 'Square pins positive' text note near the MAX232 polarized caps. This will be more readable than tiny plus signs while still providing a visible reminder on the board itself
8. Update text next to J15 - BTS2160 ROM monitor code is now too large for a 27C64 or 28C64, so 27C256 or 28C256 are required. No sense in calling out a part number that won't work on the silkscreen.
10. Update J15 to be a 2x2 pin connector so that we end up with the unused pins (Either Vpp or /WE) properly pulled to VCC
11. Switch orientation of CPREQ connector to match STG board
12. Connect Pin 10 on J4 to INTGNT/Pin 31 on CPU
13. To be consistent with other RBC boards KiCAD/Freerouting rules - use smaller DIP pads (to allow two traces to fit through if required), larger power/GND traces, and larger signal and power/GND vias
[Updated on: Sat, 04 June 2016 19:11] Report message to a moderator
|
|
|
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #728 is a reply to message #727] |
Thu, 19 May 2016 09:16   |
djones60
Messages: 18 Registered: October 2015 Location: Scottsburg, IN
|
Junior Member |
|
|
Sounds great. No hurry. I've too many other projects waiting for my attention as it is! When you get that far, you might want to post something in the Spare Time Gizmos yahoo group. I'm sure there would be interest there. At least, that's where I'd been looking before I ran into it here. Sort of funny, I started out looking for info on the original, pre v4, 8 slot s-100 backplane and seen this:)
Hope things go well getting the house sold.
[Updated on: Thu, 19 May 2016 09:18] Report message to a moderator
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #735 is a reply to message #729] |
Sat, 21 May 2016 16:58   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
John sent me his problematic 74ACT373 chips. I was able to reproduce the same POST hang behavior on my RBC Edition board. The original STG board is unaffected and works fine with the ACT chips.
I made smaller and smaller foil sheets and put them under 2 sheets of printer paper under my board. Shielding just the area under the MEM GAL and the 2 '373 chips was sufficient to make the board boot.
I soldered an additional 0.22uf decoupling cap directly between VCC and GND on the back side of the board under the 2 '373 sockets. This fixed the issue (RBCE board boots with no problems with the ACT chips and no nearby shielding).
One drawback to the way I did the prototype boards was that Freerouting routed the decoupling caps "however it wanted", instead of routing them to each adjacent IC. This potentially reduces the effectiveness of the decoupling caps in actually doing their job, and may actually make things worse by creating large 'loops' on the board that act as antennas. (See https://www.fairchildsemi.com/application-notes/AN/AN-389.pd f for a good discussion of decoupling)
I plan to keep the V1.00 boards as a 2-layer board, with the following modifications in the copper routing process:
-Based on feedback from John C. on KiCAD/Freerouting settings that have been using on boards such as the KISS-68030 board:
--Use larger vias for signal traces
--Use larger trace width and larger vias for VCC/GND traces
--Slightly reduce the DIP pad diameters (to match the older RBC boards; the new KiCAD libraries have larger pads on the chips) to allow 2 traces to be routed between each set of pins if required
-Hand-routed decoupling cap connections for the '373 chips to address the stability issue
-*Possibly* hand-routed decoupling caps for all the other chips, if it doesn't make the rest of the board too hard to route (will try both ways)
I will also fabricate the boards with 2oz copper instead of 1oz copper, which should further improve the VCC/GND distribution.
I don't recommend logic family substitution on this board, but I am taking the fact that the ACT chips only caused a problem on the RBC Edition board as an indication that I need to in general improve the VCC/GND paths and more closely couple the decoupling caps.
[Updated on: Sat, 21 May 2016 17:01] Report message to a moderator
|
|
|
|
|
|
|
Current Time: Sat Feb 08 21:57:22 PST 2025
Total time taken to generate the page: 0.01006 seconds
|