The question "FPGA or not?" keeps me still awake at night, so some
rambling here!
> 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 was considering a FPGA solution first, even had a Xilinx ZYNQ training
for that.
But switched to BeagleBone PRU soon for several reasons (many
non-technical ones).
Speed is essential. OK, UniBus/QBus are asynchronuous, so you can delay
bus cycles
when your emulated devices need processing time.
But the emulator has to watch bus activity in realtime for register
accesses to emulated devices.
Problem here is not ARM processing power (1+ GHz is fast enough), but
delays in the GPIO
access and random code delays by Linux task switching and RAM refreshes
and the like.
So you need to have some realtime logic on the bottom of all the C code.
UniBone should be "community friendly", a FPGA would mean:
- code developers need VHDL/Verilog skills and a special tool chain
- kit builders need to program the FPGA and solder these damn fine pitch
parts.
- Technically, a interface between ARM core and FPGA is time-critical,
would not work on RPi FPGA shields. So either you implement EVERYTHING
in FPGA, or you are bound to some FPGA SoC demo boards.
As the BeagleBone has these realtime PRUs:
- all development is done in C/C++, familiar cross platform debugging in
Eclipse.
- the edit-compile-debug cycle is very fast: 10 seconds for a partial
recompile & program start when
developing remote from a modern PC.
- The whole toolchain (gnu gcc and PRU C commpiler) also runs on the BBB
itself, so you can
develop new code immediately.
- BBB is slim enough to fit in a DEC card slot, is cheap (down to $60
now) and will be available for years.
- big Debian/BeagleBone community behind,
Drawbacks of the ARM+PRU approach were:
- the realtime stuff is done with sequential code, so manual
optimization was needed.
- the PRU code&RAM space is limited, design can not be scaled up endlessly.
- limited pin count available, a GPIO multiplier was needed.
UniBone is a success because indeed several contributors accepted it.
Despite choosing BBB, I wasn't sure for long wether that ARM+PRU
approach wouldn't be a dead end technology.
There was not much development on the BeagleBones for 5 years, but with
the new
BBONE-AI, everything has changed.
TI followed the "Linux ARM + coprocessors" road here in a spectacular way.
The mandatory move to "multi core, GHz, RAM, WiFi, GBit Ethernet, USB3"
has been done too.
> 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?
All true, see above.
>
> I dont know whether an RPi could work or if the BBB is needed for
speed etc.
RPi's are faster and have more ARM cores than BBB, but thats in fact not
needed.
"Realtime determinism" is the keyword here, as well as GPIO speed.
BBB PRUs can toggle GPIOs with 50+MHz.
regards,
Joerg
We would love tunnel diodes in packaging for our semiconductor? display ay smecc ed#
On Friday, November 15, 2019 charlesmorris800--- via cctalk <charlesmorris800 at centurytel.net; cctalk at classiccmp.org> wrote:
>I've got a bunch of tunnel diodes; never found a practical use for them
for me.
You must not own any older Tektronix scopes then. At one time I had fourteen and there were several tunnel diodes in almost every one (trigger circuits mostly).
And their characteristics do drift with age, sometimes out of the range of adjustment
:)
-Charles
I am the author of tcpser, a UNIX/Windows program that emulates a Hayes
modem.
Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to
fix some bugs and he also added in some parity code, which looks to
strip parity from the incoming serial connection (in the case that the
serial port is set as 8N1 and the computer attached to it sends in 7E1
or similar.
I am working to merge in all of his changes into the mainline codebase,
but I am unclear on prpper Hayes behavior.? His Readme says:
https://github.com/FozzTexx/tcpser/commit/5f0e28bb837463e597a1daf9b3c07e56a…
"I also made the modem routines automatically detect parity and ignore
it in AT commands and print out modem responses in matching
parity. Parity is *not* stripped when sending data over the
connection, which is how a real modem behaves. This may or may not be
what you want. Some servers will expect an 8 bit connection and may
not work."
Did Hayes modem really do that?? I thought most later modems self
detected parity and speed and thus would have switched both the comm on
the serial port and the data sent to the other side in the same parity
(if the terminal was 7E1, the modem would configure as 7E1 and send 7
bit data to the other side.
But, maybe real modems did as Chris notes. Anyone have guidance on
this?? The goal of tcpser is to emulate a Hayes modem as much as
possible, but I never really thought about mismatched parity on the
RS232 line and how to deal with it.
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
>I've got a bunch of tunnel diodes; never found a practical use for them
for me.
You must not own any older Tektronix scopes then. At one time I had fourteen and there were several tunnel diodes in almost every one (trigger circuits mostly).
And their characteristics do drift with age, sometimes out of the range of adjustment
:)
-Charles
I may be stating the obvious here but looking for a little advice and
reassurance from anyone on the list who may have had experience with these
machines.
I have a couple of TI99/4A's that I was given quite a long time ago along
with about 50 software cartridges (if I understand things correctly the
cartridges on their own a quite a bonus). What I am missing are power
supplies. On my research the inputs are 12 and/or 5 volt depending on the
number of power pins on the back (mine have 2).
These voltages appear to neatly align with most PC power supplies so I
should be able to tap into an old AT power supply of which I have quite a
few.
Thank you.
Kevin Parker
> From: Al Kossow
> These showed up on eBay, I'd been looking for them for over twenty years
As in, 'you all shouln't bid on those so I can grab them'? Or do you want
someone here to get them, and send you scans?
If the latter, people should co-coordinate so they aren't bidding against
each other.
Noel
I recently acquired a VAXmate with an LK250 keyboard. The problem is the
keyboard came without the cable. It uses an 8-pin SDL connector and the
usual tiny MMJ-like connector at the keyboard end. I don't know the pinout
and I don't have the necessary crimping tools, is there any source for such
a cable?
Thanks
Rob
