15 Nov
2019
15 Nov
'19
1:07 p.m.
Its been a long time since last public post about UniBone, time for a
bragging broadcast.
*What it is:*
In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
systems containing a BeagleBone Black.
See http://retrocmp.com/projects/unibone.
This combo can simulate PDP-11 devices embedded in a physical machine.
So you can operate and repair incomplete UNIBUS PDP-11s and even VAXes,
just by emulating the missing parts.
Disk drive emulators accept SimH image files, which can be ftp'd to the
emulator (no SDcard changing!).
As UniBone can acquire bus mastership, its also UNIBUS diagnostic
console, as well as stimulate individual UNIBUS lines.
Realtime stuff is implemented on BBB's PRU coprocessors.
All programming is done in plain C/C++ under mainstream Debian Linux.
*Whats new in 2019:*
UniBone started with memory and RL11/RL02 emulation.
In 2019 we did a lot of programming and debugging (suppressing endless
techno-babble here).
Thanks to some gifted supporters, we have now these devices:
- DL11 serial port (first concept by David Richards)
- 11/20 CPU (Angelo Papenhoff)
- RK06 and MSCP disk drives (Josh Dersch)
In fact UniBone implements now a complete PDP-11 system... a bit like a
SimH with UNIBUS interface.
UniBone was tested (at least) against PDP-11/05, '34, '44, '84 and VAX
11/750.
Verified OSses include XXDP, Unix V6, 2.11BSD, RT11, RSX11M/M+, VAX
4.3BSD and Ultrixes.
Special thanks to Mark Matlock for endless testing.
*Available?*
Soon. About 25 complete systems were distributed, and the same amount in
kits. Not much complaints.
User group at https://groups.google.com/forum/#!forum/unibone
Just now I'm planing for a 2nd lot.
And it will be shown on http://vcfe.ch/doku.php in Zurich on Nov
30th/Dec 1st, probably plugged into a PDP-11/05.
best regards,
Joerg
15 Nov
15 Nov
8:01 p.m.
LOVE the ideas, loved it when I first heard of it. But I'm a QBUS guy! Put me on the
list when (if) you ever make one for qbus. GREAT idea!
Eugene
________________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of J?rg Hoppe via cctalk
<cctalk at classiccmp.org>
Sent: Friday, November 15, 2019 8:07 AM
To: General Discussion: On-Topic Posts
Subject: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
Its been a long time since last public post about UniBone, time for a
bragging broadcast.
*What it is:*
In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
systems containing a BeagleBone Black.
See http://retrocmp.com/projects/unibone.
This combo can simulate PDP-11 devices embedded in a physical machine.
So you can operate and repair incomplete UNIBUS PDP-11s and even VAXes,
just by emulating the missing parts.
Disk drive emulators accept SimH image files, which can be ftp'd to the
emulator (no SDcard changing!).
As UniBone can acquire bus mastership, its also UNIBUS diagnostic
console, as well as stimulate individual UNIBUS lines.
Realtime stuff is implemented on BBB's PRU coprocessors.
All programming is done in plain C/C++ under mainstream Debian Linux.
*Whats new in 2019:*
UniBone started with memory and RL11/RL02 emulation.
In 2019 we did a lot of programming and debugging (suppressing endless
techno-babble here).
Thanks to some gifted supporters, we have now these devices:
- DL11 serial port (first concept by David Richards)
- 11/20 CPU (Angelo Papenhoff)
- RK06 and MSCP disk drives (Josh Dersch)
In fact UniBone implements now a complete PDP-11 system... a bit like a
SimH with UNIBUS interface.
UniBone was tested (at least) against PDP-11/05, '34, '44, '84 and VAX
11/750.
Verified OSses include XXDP, Unix V6, 2.11BSD, RT11, RSX11M/M+, VAX
4.3BSD and Ultrixes.
Special thanks to Mark Matlock for endless testing.
*Available?*
Soon. About 25 complete systems were distributed, and the same amount in
kits. Not much complaints.
User group at https://groups.google.com/forum/#!forum/unibone
Just now I'm planing for a 2nd lot.
And it will be shown on http://vcfe.ch/doku.php in Zurich on Nov
30th/Dec 1st, probably plugged into a PDP-11/05.
best regards,
Joerg
8:23 p.m.
On 11/15/19 3:01 PM, W2HX via cctalk wrote:
LOVE the ideas, loved it when I first heard of it. But
I'm a QBUS guy! Put me on the list when (if) you ever make one for qbus. GREAT idea!
Eugene
Along these lines, it's been a long time since we've updated the list
regarding the QSIC project.? Have been slowly working away on the
project here.? The QSIC is, at a high level, similar to the UniBone
except it's on the QBUS and it's based around an FPGA rather than a BBB.
Work that's gone on is that the Verilog code has been written to access
the DDR SDRAM we have so we can support larger RAM disks and eventually
the Able ENABLE.? Haven't tested it yet.
Also have made good progress on designing the prototype circuit board to
replace our wire-wrapped test board that's served us well so far.? Some
final checks and it'll soon be time to send off to China and learn about
having circuit boards assembled.? Speaking of that circuit board design,
I put in the option to add bus termination resistors but they require a
part that no-one seems to stock.? I had a request in to Mouser to get it
for me and they said they'd look into it but I haven't heard anything
back for a few weeks now.? This jogs my memory to chase them a little to
find out what's happened.
Anyway, the web page for the QSIC is here along with a KiCad rendering
of what the prototype board would look like and a slightly more accurate
diagram of what the internal modules are like (may still modify that
some more as I learned about the AXI interface and may use that for
getting to the bus and that'll change how the crossbar switch works).
http://pdp10.froghouse.org/qsic/html/overview.html
Dave
8:26 p.m.
I think you will win a lot of friends if you can make something that
will emulate MSCP devices on the QBus - I have a micro11 and microVax
sans disk due to only having ESDI ate ST506 controllers!
cheers es 73 to the hams amongst us de Nigel ve3id
On 15/11/2019 15:23, David Bridgham via cctalk wrote:
On 11/15/19 3:01 PM, W2HX via cctalk wrote:
--
Nigel Johnson
MSc., MIEEE
VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
You can reach me by voice on Skype: TILBURY2591
If time travel ever will be possible, it already is. Ask me again yesterday
This e-mail is not and cannot, by its nature, be confidential. En route from me to you, it
will pass across the public Internet, easily readable by any number of system
administrators along the way.
Nigel Johnson <nw.johnson at ieee.org>
Please consider the environment when deciding if you really need to print this message
LOVE the ideas, loved it when I first heard of
it. But I'm a QBUS guy! Put me on the list when (if) you ever make one for qbus. GREAT
idea!
Eugene
Along these lines, it's been a long time since we've updated the list
regarding the QSIC project.? Have been slowly working away on the
project here.? The QSIC is, at a high level, similar to the UniBone
except it's on the QBUS and it's based around an FPGA rather than a BBB.
Work that's gone on is that the Verilog code has been written to access
the DDR SDRAM we have so we can support larger RAM disks and eventually
the Able ENABLE.? Haven't tested it yet.
Also have made good progress on designing the prototype circuit board to
replace our wire-wrapped test board that's served us well so far.? Some
final checks and it'll soon be time to send off to China and learn about
having circuit boards assembled.? Speaking of that circuit board design,
I put in the option to add bus termination resistors but they require a
part that no-one seems to stock.? I had a request in to Mouser to get it
for me and they said they'd look into it but I haven't heard anything
back for a few weeks now.? This jogs my memory to chase them a little to
find out what's happened.
Anyway, the web page for the QSIC is here along with a KiCad rendering
of what the prototype board would look like and a slightly more accurate
diagram of what the internal modules are like (may still modify that
some more as I learned about the AXI interface and may use that for
getting to the bus and that'll change how the crossbar switch works).
http://pdp10.froghouse.org/qsic/html/overview.html
Dave
9:22 p.m.
On 11/15/19 3:26 PM, Nigel Johnson via cctalk wrote:
I think you will win a lot of friends if you can make
something that
will emulate MSCP devices on the QBus - I have a micro11 and microVax
sans disk due to only having ESDI ate ST506 controllers!
cheers es 73 to the hams amongst us de Nigel ve3id
Our initial disk controllers will be more old school, the RK11 and
RP11.? When we were first tossing around ideas, we considered MSCP but
put that into the "too complicated" bin to be considered later, maybe
much later.
Since then, the design for the QSIC has become more solid and a couple
implementation ideas come to mind.? One, kinda the obvious one, is to
just put it in the Soft-11.? In order to implement the USB protocol, we
decided we needed a processor and the "easy" way to do that was to just
put a soft processor inside the FPGA.? And for that processor, what
better than a PDP-11?? Okay, there might be other, better choices but no
other choice would be as good a hack.? So that's the current plan
although we haven't done it yet.? Could put the MSCP implementation into
there.
I've also been looking more into microcoding and bitslice designs and it
could be a really neat little project to build a bitslice processor into
the FPGA and microcode that to implement MSCP (rather than microcoding
it to be a PDP-11 and then programming the PDP-11).
Whether Noel or I ever do MSCP, the code for all this will be
open-sourced and even in its early stage is already up on GitHub.? It's
just the Verilog, I haven't yet gone through the exercise to figure out
what-all Xilinx/Vivado specific files need to be uploaded so someone
else could reproduce the FPGA load files but once we have prototype QSIC
hardware that's semi-working and anyone else expresses interest in
playing with this stuff, I'll work with them to figure it out.
16 Nov
16 Nov
1:53 a.m.
On Nov 15, 2019, at 4:22 PM, David Bridgham via cctalk
<cctalk at classiccmp.org> wrote:
...
I've also been looking more into microcoding and bitslice designs and it
could be a really neat little project to build a bitslice processor into
the FPGA and microcode that to implement MSCP (rather than microcoding
it to be a PDP-11 and then programming the PDP-11).
I wonder if the UDA50 microcode can be found. That's a bitslice (2901 ALUs plus 2910
branch controller) which presumably would be pretty easy to emulate in a small FPGA.
I once saw a bit of the source code. It was very strange because it had two opcodes per
line, one for the ALU and one for the branch controller. Since the condition codes took a
cycle to get to the branch controller, you might see weird stuff like this (paraphrased, I
don't remember the actual opcodes):
CLR R0 ; BNE label
which takes some getting used to if you're a conventional sequential programmer.
Richie Lary of PDP-8 fame did part of that microcode.
paul
2:57 a.m.
On 11/15/19 20:53, Paul Koning wrote:
I wonder if the UDA50 microcode can be found.
That's a bitslice (2901 ALUs plus 2910 branch controller) which presumably would be
pretty easy to emulate in a small FPGA.
If it used Am2901 series parts, I wonder if it used Am2908s too for the
bus drivers.? We used those on our wirewrap prototype (they saved I/O
pins to the FPGA which was important at the time) but planned to go to
all DS8641s for the real thing (a 324 pin BGA package has a *lot* of I/O
pins and I've used most of them).? I guess it would be easy enough to
replicate the function of Am2908s inside the FGPA though.
Anyway, the difficult part of using the actual microcode from the UDA50
is going to be the other side of the device.? The interface to the disk
drive of the day is not going to look anything at all like an SD card.?
Not sure it'd be worth trying to fake out that interface unless yo had
some strong reason for wanting to run that microcode.
I once saw a bit of the source code. It was very
strange because it had two opcodes per line, one for the ALU and one for the branch
controller. Since the condition codes took a cycle to get to the branch controller, you
might see weird stuff like this (paraphrased, I don't remember the actual opcodes):
CLR R0 ; BNE label
which takes some getting used to if you're a conventional sequential programmer.
Richie Lary of PDP-8 fame did part of that microcode.
When I started getting more into this micro-coding stuff, Noel pointed
me to a book called Principles of Firmware Engineering in Microprogram
Control by Michael Andrews.? Interesting stuff and he presents several
designs that make this clear separation between the control portion of
your micro-instructions and the sequencing portion.
15 Nov
15 Nov
9:58 p.m.
This is interesting indeed. But if someone wanted to emulate a new function with the QSIC,
would they need to be able to program in verilog (or fpga language)? I think an
interesting angle using something like a BBB is that there is probably a range of
languages that could be used to implement functionality. I don't know how many people
know how to program an FPGA (or maybe a lot of peope do, but just not me :)
73 es GUD DX Eugene W2HX
________________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Nigel Johnson via
cctalk <cctalk at classiccmp.org>
Sent: Friday, November 15, 2019 3:26 PM
To: David Bridgham via cctalk
Subject: Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
I think you will win a lot of friends if you can make something that
will emulate MSCP devices on the QBus - I have a micro11 and microVax
sans disk due to only having ESDI ate ST506 controllers!
cheers es 73 to the hams amongst us de Nigel ve3id
On 15/11/2019 15:23, David Bridgham via cctalk wrote:
On 11/15/19 3:01 PM, W2HX via cctalk wrote:
--
Nigel Johnson
MSc., MIEEE
VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
You can reach me by voice on Skype: TILBURY2591
If time travel ever will be possible, it already is. Ask me again yesterday
This e-mail is not and cannot, by its nature, be confidential. En route from me to you, it
will pass across the public Internet, easily readable by any number of system
administrators along the way.
Nigel Johnson <nw.johnson at ieee.org>
Please consider the environment when deciding if you really need to print this message
LOVE the ideas, loved it when I first heard of
it. But I'm a QBUS guy! Put me on the list when (if) you ever make one for qbus. GREAT
idea!
Eugene
Along these lines, it's been a long time since we've updated the list
regarding the QSIC project. Have been slowly working away on the
project here. The QSIC is, at a high level, similar to the UniBone
except it's on the QBUS and it's based around an FPGA rather than a BBB.
Work that's gone on is that the Verilog code has been written to access
the DDR SDRAM we have so we can support larger RAM disks and eventually
the Able ENABLE. Haven't tested it yet.
Also have made good progress on designing the prototype circuit board to
replace our wire-wrapped test board that's served us well so far. Some
final checks and it'll soon be time to send off to China and learn about
having circuit boards assembled. Speaking of that circuit board design,
I put in the option to add bus termination resistors but they require a
part that no-one seems to stock. I had a request in to Mouser to get it
for me and they said they'd look into it but I haven't heard anything
back for a few weeks now. This jogs my memory to chase them a little to
find out what's happened.
Anyway, the web page for the QSIC is here along with a KiCad rendering
of what the prototype board would look like and a slightly more accurate
diagram of what the internal modules are like (may still modify that
some more as I learned about the AXI interface and may use that for
getting to the bus and that'll change how the crossbar switch works).
http://pdp10.froghouse.org/qsic/html/overview.html
Dave
10:08 p.m.
On Nov 15, 2019, at 4:58 PM, W2HX via cctalk
<cctalk at classiccmp.org> wrote:
This is interesting indeed. But if someone wanted to emulate a new function with the
QSIC, would they need to be able to program in verilog (or fpga language)? I think an
interesting angle using something like a BBB is that there is probably a range of
languages that could be used to implement functionality. I don't know how many people
know how to program an FPGA (or maybe a lot of peope do, but just not me :)
73 es GUD DX Eugene W2HX
Speaking as a software guy who's gotten into this stuff: it isn't all that hard.
It does require learning a new language (Verilog or VHDL; I picked the latter). And it
requires learning a somewhat different mindset. Instead of writing sequences of actions
where most of the time you have just one thread, you're describing all the things that
all the building blocks can do as they react to inputs. Also, you have to learn that
outputs don't instantaneously appear as inputs -- VHDL calls these "signals"
and models the fact that they don't become visible until the next simulation cycle.
There are simulators around that let you run VHDL (or Verilog, I assume, but I haven't
done that). Some are open source -- look at GHDL. I've used that to create quite
large models (including parts of a CDC 6600).
In other words: give it a try. You might like it.
paul
16 Nov
16 Nov
2:52 p.m.
fre 2019-11-15 klockan 14:07 +0100 skrev J?rg Hoppe via cctalk:
Its been a long time since last public post about
UniBone, time for
a
bragging broadcast.
*What it is:*
In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
systems containing a BeagleBone Black.
See http://retrocmp.com/projects/unibone.
This combo can simulate PDP-11 devices embedded in a physical
machine.
So you can operate and repair incomplete UNIBUS PDP-11s and even
VAXes,
just by emulating the missing parts.
Disk drive emulators accept SimH image files, which can be ftp'd to
the
emulator (no SDcard changing!).
As UniBone can acquire bus mastership, its also UNIBUS diagnostic
console, as well as stimulate individual UNIBUS lines.
Realtime stuff is implemented on BBB's PRU coprocessors.
All programming is done in plain C/C++ under mainstream Debian Linux.
Ethernet or FC connection ??
If so it would be possible to build an PDP-11 who is datacenter-
compatible today year 2019 ...
One requirement for todays datacenter (for some owners at least) is the
ability to directly connect the system to the storage system (ie
FC/SCSI or IP/iSCSI.)
Hint: with that requirement as far as i know it an ARM device in the
form of a Samsung S9 can't be data center compatible....
5:45 p.m.
Stefan,
Mot clear to me what
"data center compatibility" for a PDP-11 means.
Anyhow, the BeagleBone runs Debian Linux, has an Ethernet port and the
emulation software is a plain Linux application.
So all emulator binaries and all PDP-11 disk images or other data can
reside anwhere in the world and are not bound to the UniBone SDcard.
Joerg
*What it is:*
In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
systems containing a BeagleBone Black.
See http://retrocmp.com/projects/unibone.
This combo can simulate PDP-11 devices embedded in a physical
machine.
So you can operate and repair incomplete UNIBUS PDP-11s and even
VAXes,
just by emulating the missing parts.
Disk drive emulators accept SimH image files, which can be ftp'd to
the
emulator (no SDcard changing!).
Ethernet or FC connection ??
If so it would be possible to build an PDP-11 who is datacenter-
compatible today year 2019 ...
One requirement for todays datacenter (for some owners at least) is the
ability to directly connect the system to the storage system (ie
FC/SCSI or IP/iSCSI.)
Hint: with that requirement as far as i know it an ARM device in the
form of a Samsung S9 can't be data center compatible....
17 Nov
17 Nov
12:56 a.m.
Is the BBB not fast enough to do Qbus? Meaning, for qbus, would a FPGA be necessary? Or
was this just the op's choice among many possible options?
It does seem useful to have this thing run linux and ethernet and be able to pass files
(data and programs) back and forth very easily. the FPGA approach seems more technically
challenging but seems less universal (to my limited mind). It would seem a BBB you could
load software, test, and reload as easily as copying some executable code (I dont know if
that is correct or an over simplification). whereas the FPGA sounds like it needs to be
recompiled/re-burned each time?
I dont know whether an RPi could work or if the BBB is needed for speed etc.
Eugene
________________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of J?rg Hoppe via cctalk
<cctalk at classiccmp.org>
Sent: Saturday, November 16, 2019 12:45 PM
To: Stefan Skoglund; General Discussion: On-Topic and Off-Topic Posts; General Discussion:
On-Topic Posts
Subject: Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
Stefan,
Mot clear to me what
"data center compatibility" for a PDP-11 means.
Anyhow, the BeagleBone runs Debian Linux, has an Ethernet port and the
emulation software is a plain Linux application.
So all emulator binaries and all PDP-11 disk images or other data can
reside anwhere in the world and are not bound to the UniBone SDcard.
Joerg
*What it is:*
In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
systems containing a BeagleBone Black.
See http://retrocmp.com/projects/unibone.
This combo can simulate PDP-11 devices embedded in a physical
machine.
So you can operate and repair incomplete UNIBUS PDP-11s and even
VAXes,
just by emulating the missing parts.
Disk drive emulators accept SimH image files, which can be ftp'd to
the
emulator (no SDcard changing!).
Ethernet or FC connection ??
If so it would be possible to build an PDP-11 who is datacenter-
compatible today year 2019 ...
One requirement for todays datacenter (for some owners at least) is the
ability to directly connect the system to the storage system (ie
FC/SCSI or IP/iSCSI.)
Hint: with that requirement as far as i know it an ARM device in the
form of a Samsung S9 can't be data center compatible.... 
3:28 a.m.
On 11/16/2019 06:56 PM, W2HX via cctalk wrote:
Is the BBB not fast enough to do Qbus? Meaning, for
qbus, would a FPGA be necessary? Or was this just the op's choice among many possible
options?
The PRU on the Beagle Bone Black is pair of 200 MHz 32-bit
microcontrollers which can do all sorts of I/O tasks.
There is a limit on the number of direct I/O lines
available, however, so that may not be so simple. I've used
them
for 8-bit ports, plus a few control lines, and that all
worked great. There is a bit more latency if you need to
use non-direct GPIO pins to the PRU, but they still are
pretty fast.
The PRU has direct, 5ns access to a limited amount of shared
memory, but can access the ARM CPU's memory
with some additional delay. So, I think you could probably
do a Q-bus, but might have to go through some
contortions to get enough I/O pins and memory for larger
transfers.
Jon
5:43 a.m.
On Sat, Nov 16, 2019 at 4:59 PM W2HX via cctalk <cctalk at classiccmp.org>
wrote:
Is the BBB not fast enough to do Qbus? Meaning, for
qbus, would a FPGA be
necessary? Or was this just the op's choice among many possible options?
It does seem useful to have this thing run linux and ethernet and be able
to pass files (data and programs) back and forth very easily. the FPGA
approach seems more technically challenging but seems less universal (to my
limited mind). It would seem a BBB you could load software, test, and
reload as easily as copying some executable code (I dont know if that is
correct or an over simplification). whereas the FPGA sounds like it needs
to be recompiled/re-burned each time?
My personal experience with the Unibone is that it's very easy to work
with. Starting with zero knowledge of Joerg's platform I wrote an
RK11/RK05 emulation in about a week. MSCP took longer (about a month), but
that was entirely due to the complexity of the MSCP spec. Joerg has done
all the hard work here and has provided a really useful set of tools for
building device emulations.
I hope to have some time to do a few more devices soon -- TMSCP is on my
list, along with TC11 and RX11... I'm taking requests if anyone has 'em :).
- Josh
3:12 p.m.
On 11/16/19 19:56, W2HX via cctalk wrote:
Is the BBB not fast enough to do Qbus? Meaning, for
qbus, would a FPGA be necessary? Or was this just the op's choice among many possible
options?
I'd think that PRU in the BBB ought to be able to handle the QBUS
easily.? A state-machine in an FPGA seemed to me the more
straightforward way to implement bus cycles but absolutely that's not
the only possible choice.? In fact, that brings up one of the things
that I'm really enjoying about hardware development with FPGAs.? Once I
get hardware built with an FPGA in the middle, I have a wide range of
implementation options for any particular bit I'm building.? I can use
combinational logic, state-machines, micro-coding, or, with a soft
processor, I can approach it with software.? In fact, I can choose
different answers for the different pieces of the problem.? I quite
enjoy that flexibility even though it can be an excess of options at times.
It does seem useful to have this thing run linux and
ethernet and be able to pass files (data and programs) back and forth very easily. the
FPGA approach seems more technically challenging but seems less universal (to my limited
mind). It would seem a BBB you could load software, test, and reload as easily as copying
some executable code (I dont know if that is correct or an over simplification). whereas
the FPGA sounds like it needs to be recompiled/re-burned each time?
Yes, you do have to compile code for the FPGA but you have to compile
your code for the BBB too.? While I like the command-line interface to
gcc better than the GUI for Vivado (the Xilinx FPGA dev tool), I would
prefer to just be able to drive it all from a Makefile, either way
there's a compile step.? Eventually I intend to make loading new code
into the QSIC as simple as copying the binary file to an SD card or USB
thumb drive to update the flash.? Loading new code over Ethernet?? Not
sure I'll ever manage that one.
6:41 a.m.
Joerg said
>> *What it is:*
>> In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
>> systems containing a BeagleBone Black.
>>
>> See http://retrocmp.com/projects/unibone.
Is it possible to get it as a "kit+" where the SMD components only are already
soldered onto
the bare board, but all the rest left for those who are ok with a normal soldering iron
but
not confident on doing the SMD?
1878
days inactive
1880
days old
15 comments
9 participants
participants (9)
-
dab＠froghouse.org -
derschjo＠gmail.com -
elson＠pico-systems.com -
j_hoppe＠t-online.de -
nw.johnson＠ieee.org -
paulkoning＠comcast.net -
stefan.skoglund＠agj.net -
steven＠malikoff.com -
w2hx＠w2hx.com