On 2013-12-22 10:08, Al Kossow wrote: Just use SSRAM (cy7c1460, ...) they are easier to deal with, and have 9/18/36 bit width ... And as you are connecting them via the FPGA to the ARM, you should be fine ...

On 12/22/13 9:08 AM, emanuel stiebler wrote: There are two interrelated things. Legacy peripherals with no peripheral controllers (DECtape, etc.) and CPUs with no peripheral controllers (TC08) or peripherals (RK8E/RK05 combo). There is also the problem of debugging legacy devices (how do you fix an 8E memory if you don't have anything that works). I have the problem that I have a lot of old media, a mix of peripheral devices but no interfaces or computers to put them in. I also would like to come up with a general solution that isn't OS or CPU specific. From the hobbyist perspective, there are some peripherals that you just can't find (RF08, TC08, anything for the PDP-15, etc.) even if you do have a working computer. So, how do you come up with something that isn't TOO hard to build, but you can think of lots of uses for, which is what I've done. Now, as usual whenever I think about this, I'll spend the next several weeks trying to get a tool chain running to actually get "hello world" running on an ARM proto board or the equivalent on an FPGA board. Maybe it'll actually work this time (I think I've tried doing this for several years running now and gave up when after buying a prototyping board I couldn't get anything to work).

On 12/22/2013 11:59 AM, Al Kossow wrote: I know people will flame me for this, but I do initial dev on a Windows box for this reason. Prepackaged bins are usually available for Windows, so no builds needed. Then, once I have success, I build on my Linux box. I also try to use the same toolchain on both. Eclipse for all projects, GCC, etc. Jim -- Jim Brain brain at jbrain.com www.jbrain.com

On 12/22/2013 11:30 AM, Al Kossow wrote: Sadly, it happens all the time with USB VIDs. I've got several devices here that either appropriate someone else's VID or simply invent one. --Chuck

On Mon, Dec 23, 2013 at 4:59 AM, Al Kossow <aek at bitsavers.org> wrote: Mixed strategy works for me: virtualisation + spare machines for when virtualisation doesn't work easily The aim is to avoid trying to make new toolchains co-exist with existing environments (and sink into dependency, versioning hell). With a new toolchain/widget, make a new environment just for it. Much easier time choosing the guest environment that matches the toolchain requirements, or even better the toolchain provider has conveniently provided a virtual image ready-to-boot. The slight drawback is integrating multiple environments but at least this boils down to known (more easily managed) access paths between disparate systems (via filesharing, networks etc). The other bonus with virtual images is you can suspend them with work-in-progress, return to them a long time later and find everything just where you left it.

On 12/28/13 6:54 PM, Philipp Hachtmann wrote: WHAT to use for the microprocessor and FPGA has been the stumbling block for the 10 or so years of false starts that I've had with microcontroller/FPGA projects. There never seems to be the right way to glue the two together. I thought a TI LM3 interface was the way to go, then TI dropped the series. Current thought is just connect the two boards with SPI and not try to tie the two boards together as intimately. I just went through my annual X86 PC SOC vs ARM microcontroller thrash when I saw the Intel Galileo boards at Frys for $60. It is the standard problem with them (and RPi) not enough I/O. Then I thought maybe glue it together with PCI-e, since there is a connector on the bottom. Then I looked at how f'ing complicated PCI-e is. So then, since like a fool I bought a couple of the Intel boards, I looked at PCI-e - PCI bridges at which point I said this is all getting WAY too complicated. So I'm back to a couple of bus translator PCBs with the actual microcontroller and FPGA on separate mezanine cards so whatever the silicon is that the bus translators stay the same. At least that's the theory. I'm currently finishing the design of the DECtape G888 replacements to get those sent off for fab. Again, KISS. One channel on a mezzanine card with a MC3470 for the read channel with JFET switches to isolate it during writes, and a high side +12v 100mA driver. I also think I understand what C10 and R12 on the G888 are for, and why the output oscillates when the tape isn't moving :-) I knew they used this fact on the clock channel for the up-to-speed circuit.

On Dec 29, 2013, at 10:26 AM, Mark J. Blair <nf6x at nf6x.net> wrote: <snip> There are also Xilinx parts that have hard ARM cores in them too. To keep it ?classic?, I?m aware that one list member has done some work with a Xilinx Spartan 3E and put a fairly complete PDP-11 as the programmable controller. That implementation as I recall took only about 10% of the gate count in the 3E (I think it was a 1200 but can?t be sure). I?ve looked at this issue a number of times and I feel Al?s pain trying to interface an FPGA to a micro. I?ve come to the conclusion that the best way to do this is to get some open implementation of a processor and include it within the FPGA itself. That way the interface between the micro and the rest of the logic can be exactly what you need/want. Of course it means that there?s more stuff to implement in the FPGA. However, most folks I?ve talked to, have found that the constraints with FPGAs is I/Os and not gate count. TTFN - Guy

On 2013-12-29 12:14, Mark J. Blair wrote: And they are pretty cheap, for what they offer. But most people would run away from a 10 layer board for hobbyist use ;-)

On 2014-01-02 02:58, Eric Smith wrote: OK, let's try again ;-) If you compare what's inside of a zynq, and compare to to a solution which is made out of a external ARM + FPGA attached to it, please compare it to an at least ARTIX-7 series, and a dual core with a pretty decent amount of peripherals. Then subtract the headaches of constructing a decent bus between the two, and you probably know why I think they are cheap. If you don't need the performance at all, you probably get away with much smaller FPGA & a cortex MCU, but it is getting very close in price. Cheers

On Thu, 2 Jan 2014, Eric Smith wrote: Thats been my conclusion as well (reluctantly because I would like a integrated chip for our uses) The Zynq is just way overpriced for what it is. Unless you need high processor <=> FPGA bandwidth, a Spartan6 and a seperate Arm chip with simple bus interface is 1/2 the price or less. Peter Wallace Mesa Electronics

On Thu, 2 Jan 2014, Al Kossow wrote: Really depends on what performance is needed. For low end I would be tempted to use a LPC4330 now (~$6) and a Spartan6 (TQFP-144) if thats enough free pins (say 60) or 1mm BGA FPGA otherwise. This is ~$17 together for both leaded parts and say $20 for BGA FPGA with maybe 120 free pins (SP6 LX9 FPGA) Peter Wallace Mesa Electronics

Am 02.01.2014 20:41, schrieb Al Kossow: I'm not Peter, but here's an answer... I used an FPGA board from ztex.de for recovering data from a Diablo 44 drive bit by bit and for simulating a DG disk subsystem. All I had to add was the DG bus interface with 3.3V logic on the FPGA side, which can also be connected to the D44 with an adapter cable. A simple 2 layer PCB. For the data recovery project I used the on-board CY68013 USB interface to a PC. The PC could be replaced by one of the small ARM based boards. The CY68013 has plenty of bandwith for my applications. It wasn't even necessary to go deep into USB as there are lots of examples for this chip. Opal Kelly has nice boards up to USB 3.0 and PCIe and a nice API with HDL examples which require even less USB or PCIe knowledge. For such projects, which are not mass production and don't depend on a certain form factor, I'd never develop an FPGA/processor platform by myself. For the disk emulator I used a stand-alone solution with a soft CPU, first the Gaisler Leon-3, later a MIPS from a colleague, programmed in plain C. I planned to run RTEMS, but found the whole thing bloated for my application. I will re-develop the emulator using the J1 Forth CPU, which is very nice for small control applications. Just a small FPGA, an SD Card and the DG bus interface. No high performance CPU, no OS, no external RAM. I always come to a point where I think a high performance CPU could run simh, a large FPGA could swallow all the vintage hardware. For just solving the problem it's fine, but it somehow hurts my eyes. Andre

Am 04.01.2014 02:09, schrieb Philipp Hachtmann: There are not too much active DG focused people around anyway... True! You will have a PC with all the fancy development tools nearby anyway, so where is the need for an on-board CPU? Use the PC as controller. Just buy an FPGA board with high-performace USB and plug it on a cheap 2 layer PCB with custom interfaces. For a stand alone board I would go for a soft CPU core unless high performance is required. I spend a few restless nights searching the holy grail. Didn't find it. FPGA vendor cores are usually not portable. The Leon3 (Sparc V8) is a nice CPU, it even runs Linux if you want. Consider the license for commercial use. We heavily use Leon based chips at work so I can't even hear the name anymore. Has a great debugging tool (GRMON). OpenCore's Plasma (MIPS) is around for a long time, still maintained, and comes with an RTOS and TCP/IP. It's on my "to be tried" list. For simple control tasks I use the J1 ported to VHDL. I'm really not a Forth freak, but I have a soft spot for Forth CPUs. In the past, numerous space projects used Forth CPUs. What is good for them should be good for me. BTW, if you have a sense of humor and want network, use a 6502 core at 40 MHz running Contiki. Andre

On Jan 2, 2014, at 2:41 PM, Al Kossow <aek at bitsavers.org> wrote: I really like the STM32 series with a parallel interface for anything that needs some real speed. If you don't need lots of speed, SPI is pretty good and not too sluggish. STM32F4 goes a long way and packs a lot of punch. I like STM32 because their parallel interface is pretty straightforward. Freescale's Kinetis is similarly good, but as much as I like Freescale chips, they're quite complex to get off the ground and they often have an errata list a mile long. TI has some nice parts in their Stellaris line, but they seem to be axing one of the best ones (which had both a parallel bus AND a built-in 10/100 PHY, which was great for cutting board space). I'm also slightly biased against the TI chips because they often only take 3.3v as a supply (a problem for my low-power RF projects), but that's not such a bad thing in this context. The STM32F4DISCOVERY kit is dirt-cheap and comes with an open-source compatible USB debug device built in. It takes some leg work to get up and running, though, and there's no real RS232 port on board (you can use one of FTDI's flying-lead CMOS-level USB->UART cables to attach to the pins of one of the UARTs, though, which is almost as good). No Ethernet on that board, though. - Dave

On 2013-12-29 12:03, Guy Sotomayor wrote: with FPGAs You actually really pay per I/O pin on an FPGA. And the problem of most people is, that they dream of 500 I/O pins in a hand solder-able package. This ship sailed ;-) As soon, as you decide to pay the premium for a BGA, the sky is the limit ...

On 2013-12-29 12:53, Mark J. Blair wrote: From my experience it will, because it is complex, so you do care. I'm making more mistakes on the 20/40 pin chips. And please don't ask me, how many times I switched TxD & RxD ;-)

On 2013-12-29 13:58, ben wrote: Trust me, I feel your pain, but this ship sailed too :( I enjoyed the time, when one was developing stuff, where pretty much most of the stuff on the board was 5V, and they came from a backplane anyway ... Now, 30% of the design effort & time is power supply (1v0, 1v2, 1v8, 2v5, 3v3 and 5v). Going back, dreaming ;-)

On 29/12/2013 21:32, emanuel stiebler wrote: Yes I have a Spartan 3E Sample Pack board and was looking to use it to build a Strobe for timing my Teletypes so was looking at the power to see how much drive I could get. I was amazed to find the PSU is the most complex part of the circuit with 3 x ICs, three filters .... Dave

On 2013-12-29 13:58, ben wrote: Actually, the next one around the corner is 1v8, so try to lift this one up to the "legacy" I/O of 5V :(

On 2014-01-01 22:04, Philipp Hachtmann wrote: Why do you need an MMU?

On 2 January 2014 15:11, Paul Koning <paulkoning at comcast.net> wrote: Yes, it is, as Peter points out below. http://www.colorforth.com/S40.htm ? :?) -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Tel: +44 20-8685-0498 ? Cell: +44 7939-087884

On 2014-01-02 08:11, Paul Koning wrote: But specially Linux also works on CPU without one, it doesn't have all the features, but for most of the stuff on this list, it should be really sufficient. Personally, I prefer Real Time OSes, but played with embedded linux before Did you check the ones on: http://www.forth.org/cores.html ? The J1 ? Cheers

On Thu, Jan 02, 2014 at 07:19:31AM -0700, emanuel stiebler wrote: [...] Full-fat Linux requires a MMU so it can firewall processes off from each other. There's ?Clinux which will boot on a variety of oddball processors, including the soft cores provided by both Altera and Xilinx, but this is really only good for tightly-controlled embedded systems.

Getting back on point with what you are trying to do... Why not just add a simple SPI interface to a CPLD and use one of those SPI to Ethernet bridge chips from Microchip? They run at 10Mbps which is surely fast enough for a PDP8 or just about any vintage machine prior to the mid 90s. A couple 8 bit shift registers, simple state machine, and parallel bus mapping would only take a couple dozen macro cells and a hundred lines of Verilog - if that. For version 0.1, KISS - Keep It Stupid Simple. -Alan Sent from my iPad On Jan 2, 2014, at 12:50 PM, "Peterson, Roe (LAI)" <roe at liveblockauctions.com> wrote:

On 03.01.2014 02:51, Jim Brain wrote: A common approach. Some people just do it - and some don't. With respect to programmable logic and all those funny things there are several kinds of people. Those who don't even start. Those who are happy with counters and registers. And those who just do it. The discussion is going into a direction I do not like. Thinks should be done the right way. There are differnet right ways, some of them probably more right than others. But using a CPLD, microcontroller and some obscure ethernet IC for bitbanging anything vintage computer bus related is considered not to be anything near a right way. Sorry for being so rude. But this reminds me to people who made me suffering. People who say phrases like "[approach] is sufficient, it works" or "this is not for me, it's for the pros"... As far as I followed this interesting thread now, the current right way for the inital problem would be: - Full size (vintage bus size like quad wide flip chip) application specific board with interface logic and - some kind of add-on board with a nice and more or less solderable FPGA, some SDRAM, ethernet PHY and other toys - Run custom hardware design with embedded openrisc processor inside the FPGA. I'd use Linux of course. With selfmade drivers for the custom logic. And yes: This kind of stuff can be done. Has be done. By MANY people. And last but not least by me. :-)

On 02.01.2014 16:20, Peter Corlett wrote: At least Xilinx' Microblaze comes with MMU (optional) since a few years. So you are not obliged to use uCLinux.

On 03.01.2014 10:05, Peter Corlett wrote: It fails on being free, isn't that what you wanted to express? :-) If that think is easy integratable - then it must be WONDERFUL! And I just found openrisc in my Linux tree. That sounds promising! -- Dipl.-Inf. (FH) Philipp Hachtmann Buchdruck, Bleisatz, Spezialit?ten Alemannstr. 21, D-30165 Hannover Tel. 0511/3522222, Mobil 0171/2632239 Fax. 0511/3500439 philipp at hachtmann.com www.tiegeldruck.de UStdID DE 202668329

On Thu, Jan 02, 2014 at 06:04:47AM +0100, Philipp Hachtmann wrote: [...] There are a few likely-looking MIPS implementations on Opencores, but I've not tried any of them. Looking through the various CPUs that have actually been implemented as opposed to the placeholder projects, they seem to be mainly going for rather simple CPU designs, shirking away from coprocessors such as MMUs. I fancy having a go at implementing a 68040 (with MMU but perhaps not FPU) in Verilog, but so far I've only managed to implement a submodule of a small support chip that was last made in the early 1990s. Altera's FPGA development and testing tools seem about 15 years behind the curve compared to what I'm used to for software development.

On 12/29/13 10:26 AM, Mark J. Blair wrote: The intersection of microcontroller, FPGA and implementation language on cctlk seems to be the null set. I had been tinkering with Cyclone parts, but most people here use Xilinx. I think Verilog vs VHDL is about half and half. Over Christmas, I bought myself a Pipistrello board with level converter shield http://pipistrello.saanlima.com/index.php?title=Welcome_to_Pipistrello To use as the capture part of the DECtape reader prototype (easier than dragging one of my 16500Bs into work). Using the OpenBench Logic Sniffer 64MB port http://www.saanlima.com/download/pipistrello-v2.0/Pipistrello_OLS_64M_10052… As you say, as the parts have become cheaper, non synthesized CPUs are becoming less interesting. I had hoped to split the custom things that I needed to do into the FPGA, and leverage the jellybean stuff to the microcontroller where I have more experience and there should be more running code available (assuming you can pull the toolchain together and have it work with the code that's out there).

On Sun, Dec 29, 2013 at 11:05:35AM -0800, Al Kossow wrote: [...] My research into FPGAs so far has come up with the following: I am informed that Xilinx's FPGAs are better than Altera's, but Altera's development tools are much better. Having actually *used* Altera's Quartus II and found it to be pretty hateful, I dread to think how horrible Xilinx's tools must be. Verilog claims to be C-like, but this isn't particularly true. Some of its expression syntax is C-inspired, but you could describe it as Perl-like or Java-like at that point! It's somewhat more Perl-like in that you can just glue fragments together and it'll generally work. Even a rank amateur like myself managed to get a blinking LED after barely twenty hours or so of effort :) VHDL appears to be much more strongly-typed, which I approve of as it means code that actually compiles is much more likely to be correct, however a beginner is going to find themselves utterly flummoxed because they're having to learn circuit design and a rather picky language. I decided to leave learning VHDL for the day when I embark upon a more ambitious project that would benefit from a more rigorous design.

On Jan 2, 2014, at 11:15 AM, Peter Corlett <abuse at cabal.org.uk> wrote: I don?t know Verilog, but if it really is PERL-like that?s quite a strong condemnation. VHDL is clearly inspired by Ada. I?ve done some elementary VHDL work and like it a lot. FWIW, there is an open source VHDL simulator available (just a simulator, not tied to any real world FPGA) that?s integrated into GCC ? called GHDL. It seems to work well; I?ve fed it some rather large models that simulate nicely. No matter the syntax, an HDL is a very different beast than a programming languages. Programs are single threads of execution, give or take some threading stuff thrown on top. FPGA designs inherently do many things in parallel. Languages like VHDL make that explicit, and you do need to understand this for your design to make any sense. When I mentioned the Forth chip design whose designer didn?t realize VHDL isn?t C, that?s what I meant ? not the differences in syntax, which are trivial enough to handle, but the fundamental difference in conceptual model. If you don?t know that changes to a VHDL ?signal? are not visible until the next model cycle, you won?t get very far... paul

On Jan 3, 2014, at 5:12 AM, Peter Corlett <abuse at cabal.org.uk> wrote: I use it on my Mac, which required building it. More precisely, I think the i386 build was available but not a 64 bit build, and I wanted one. That requires getting the GNU Ada compiler (GNAT) up first, because GHDL is written in Ada. GHDL doesn?t have a GUI, but it can write waveform files that can be viewed with viewers such as gtkwave. One benefit from the fact it?s a GCC front end is that you can link in code in other languages. For example, you can write custom test harness code in C or any other convenient programming language; the VHDL signals are visible to C code so you can feed inputs and look at outputs easily. I found an excellent VHDL textbook: http://www.amazon.com/gp/product/0120887851/ref=oh_details_o00_s00_i00?ie=U… paul

On 1/4/14 1:31 PM, Paul Koning wrote: FWIW, you can pick up the 2011 international softcover for <$25 http://www.abebooks.com/servlet/BookDetailsPL?bi=11461184780

On 03.01.2014 19:57, Rob Doyle wrote: Oh, this *is* worth a (little and friendly) flame war. Oh yes! And having a typo in a signal name does not result in silently having a new unconnected signal. And implicitely assigning something to something that does not fit - just does not work.

On Jan 3, 2014, at 1:57 PM, Rob Doyle <radioengr at gmail.com> wrote: I used the term ?simulator? to mean something that executes a VHDL model (as opposed to synthesizing a design for an FPGA or an ASIC). GHDL compiles into bytecode on Windows? That seems unlikely. As you said, it?s a language front end for the GCC compiler suite. The target OS has little effect on what code GCC generates. I wouldn?t expect Windows GDHL to produce byte code any more than I would expect the Windows C compiler in GCC to produce byte code. Both should produce machine code for whatever your target machine is. paul

On Jan 4, 2014, at 6:27 PM, Rob Doyle <radioengr at gmail.com> wrote: There?s next to nothing in Google, quite unusual. One of the meanings of ?mcode? seems to tie to Matlab. I wonder if that?s valid. Then again, another is a shorthand for ?machine code?. Looking at the code, I see stuff that looks like it turns mcode into x86 machine code. So this feels a bit like a limited-purpose compiler/assembler/linker all in one so people working in Windows don?t have to figure out how to run GCC. Not that this is hard, so I wonder what the point is. It also looks like there is a Mac version of the mcode variant of GHDL, so that confirms the notion that this is an alternative back end. Conversely, it might well be possible to build a GCC flavored GHDL for Windows, if you really want to run Windows... paul

On Jan 2, 2014, at 11:15 AM, Peter Corlett <abuse at cabal.org.uk> wrote: Such "information" is highly suspect, in my view. The superiority of one brand of FPGAs changes over time; I vastly preferred Altera FPGAs up until Xilinx's recent 7-series came out, which is generally better in most ways. Both of them have pretty comparable lines, and they move back and forth, but I think Xilinx gets a lot of sockets because it's the name everyone knows. Beyond that, what brand is better really depends on what you need to accomplish. Altera usually has the upper hand in terms of multiplier quantity and capability, though there are some DSP-specific things that Xilinx's multipliers have traditionally done better. Altera has also usually had better transceivers. Xilinx typically comes out on top for general I/O, especially with the 7-series. Both of them have pretty nice-looking SoC chips, though I haven't used either yet; as Eric Smith pointed out, there's usually not much point in using one unless you have a good reason not to just bolt on an external uC (the pins and routing required to interface a parallel bus to the uC can be a driving issue). Both toolchains are pretty bad from a GUI standpoint, though they are fine from the command line. I generally prefer Quartus, though they have made some UI regressions of late (though most of that coincided with a move to Qt for the GUI framework instead of using a really awful Win32 translation library for the Linux port, so everything actually WORKS on Linux now). ISE has always been a pretty awful GUI, but they're trying to push people to their new "Vivado" system now, which I haven't tried yet. I will point out that Xilinx has consistently been about 4-5 years behind Altera in making their synthesizer and fitter multiprocessor-capable, which is really just absurd for something that insanely parallelizable. All the GUIs are going to be pretty hateful until you understand that they're not software IDEs; the compile-debug-revise cycle is just about the worst way you can go about it. You want to be doing your debugging and revisions with a simulator, not the actual FPGA compiler; that's really only for when you have something that's actually ready to be tried on real silicon. I don't find Verilog to be even remotely Perl-like, and I use both quite a lot. If anything, syntax-wise, it's more of a fusion of C and Pascal, but I feel like it's mostly C-like. Where do you get Perl from? VHDL is nice in a way; the strong typing does keep you from shooting yourself in the foot a lot, but it really tends to stump new users quite a bit (as does the fact that a "signal" describes both a register and a net, depending on how you use it, which is a little baffling; of course, in Verilog, you can use a "reg" to describe a combinatorial process, which is equally baffling). My problem with both languages is that for testbenching, they both have significant, non-intersecting areas of advantage. Verilog has much better methods of making functional simulation models (you can make modules on which you can essentially call methods, e.g. a PCI master, in ways that you really can't do in VHDL). VHDL allows for dynamic allocation, though it's very limited; still, for doing sophisticated testbenches where you need to queue up results or the like, it's invaluable. You can do that in SystemVerilog, but support for that among test vendors is nearly absent. BTW, among all the talk about GHDL, no one seems to have mentioned Icarus Verilog. It's a nice open-source Verilog simulation engine (it's not compiled like GHDL is, but interpreted). I use it quite a bit, though it's not up to par with the commercial simulators; it's not as fast and it's sometimes buggy and it doesn't always have the Verilog features implemented that you want. But it does an OK enough job that I'm happy with it for my home needs. - Dave

On Dec 29, 2013, at 12:41 , Sytse van Slooten <sytse at sytse.net> wrote: Cost and ease of hand assembly: The Zynq chips from Xilinx with hard ARM cores start at $55 and are in BGA packages. Spartan 6 chips start at $11 and can be had in TQFP packages. I'm not sure whether the free license versions of the Xilinx tools support Zynq or not (I haven't looked into that). My current home project ideas have low performance requirements, too, so that makes me gravitate towards cheaper parts. I haven't really looked at the lower end of the Zynq line yet, though. We're using the high end parts at work so my brain associates "Zynq" with "$3500 dev board". Maybe a smaller Zynq part would be a good match for this Ethernet bus interface? -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

On 29.12.2013 16:38, Al Kossow wrote: The last thing I actually did in a commercial/industrial environment (i.e. in my last job) was some sort of ARM processor with FPGA attached via SRAM interface and a glue CPLD. The CPLD's main function was to provide a bitstream loader device that could then used by the microprocessor. The whole thing runs extremely reliably. Today I would not hesitate to use the TI processor that's used on the Beglebone board. You can even use a beaglebone board on top of a selfmade FPGA board. The only thing to achieve (probably already done) is setting up the memory controller to use the external bus/memory interface to the attached FPGA. Another approach: Use a soft processor like Microblaze (Xilinx) or the equivalent Altera thing. I have used Microblaze in several setups. Currently I'd like to give Xilinx Zynq 7000 a try. Powerful ARM + FPGA in one package. Probably easy to implement. But then you would have quite low bandwidth between your host computer and the vintage system. Even worse when ethernet is tied to the microcontroller. I think it's really worth learning PCI-E. I wish to find some time to play with PCI-E on FPGA. That's quite a good idea: The bus driver stuff can even be homebrew. And needs large boards. Having the high tech part on an extra board is fine. Oh, I'd be interested in several of them! :-)

On 1/2/14 6:19 AM, Al Kossow wrote: In this little thought experiment, I had forgotten the clock speed is variable +/- 10% because the reels aren't constant speed. Clock recovery from the Manchester signal with that much variation would have been a pretty complicated circuit for avoiding some track skew, which can be fixed with a few shims on the head block (no fun to do on a TU56, if you've ever looked at the instructions on how to do it, but much cheaper). With a microcontroller generating the clock track, it should be possible to vary the frequency of the clock track when recording it, which would get around the little problem that DEC made later tapes shorter so that you can't format as many blocks on them as you originally could. Back in the day, you got around the problem by putting your thumb on the reel as it got faster while you were formatting it. Of course, that got me thinking about putting tachs on the reel motors and redoing the H bridges :-) But that would be too much of a hack to the original hardware. What I'm doing is all reversible.

I came to pretty much the same conclusion for QBUS. It takes 42 drivers and 44 receivers (assuming your board will never be driving POK or DCOK, which seemed like a reasonable assumption). I'm using a high-speed comparator for the input buffer, though, since the DEC spec is 1.5v threshold, far away from any current manufacture ICs. Comparators of appropriate specification turn out to be expensive, though; even in quad gate packages, they tend to be around a dollar a gate. My current paddle board design (not yet fabricated) connects to the host via a 40-pin ribbon cable, and supports 80- conductor ATA cables (there are some ground pins internally tied together in those, so you lose some functional pins). It gives me a design that can be used for both QBUS and UNIBUS using the same host, though. Currently, the QBUS adaptor fits nicely in a small "CPLD" (in quotes because the MAX II and V families are actually just very small FPGAs). The current design requires an FPGA or another CPLD on the host end for the very timing-critical custom bus, but that still is easy to bolt on to a micro. - Dave

You could always use a quick switch. Since vintage busses are usually AC terminated with strong pull-ups, they work quick well for bi-directional level shifting and carry only a few nanoseconds of prop delay. This one from TI runs off 3.3V, readily available, but a bit expensive: http://www.ti.com/lit/ds/symlink/sn74cb3t16211.pdf <http://www.ti.com/lit/ds/symlink/sn74cb3t16211.pdf> NXP has a similar one that runs off a 5V supply and much cheaper: http://www.nxp.com/documents/data_sheet/CBTD16211.pdf <http://www.nxp.com/documents/data_sheet/CBTD16211.pdf> Both have smaller siblings in the families along with a few variations. I know nothing about the DEC electrical characteristics, however I've used both parts above for level shifting ISA, 5V PCI, and MFM (input only) control signals for FPGA applications. -Alan On January 5, 2014 at 2:37 PM "Mark J. Blair" <nf6x at nf6x.net> wrote:

On 1/5/14 8:08 PM, Philipp Hachtmann wrote: I've been designing digital logic since the 70's. Wrapping my head around someone else's large project, be it in a HDL or some hairball of C++ out of a SVN repository is the problem :-) Understanding digital stuff IS simple, if you have a single clock domain. Looking at how large blocks of logic are clocked is one of the first thing that I look at. Understanding how the DECtape interfaces work again has been fun. Think about building a peripheral interface where your input clock varies +/- 10% All sorts of fun things to look at in old CPUs as far as how they were clocked. I was scanning in the Burroughs B 5500 drawings recently and didn't know the system was designed with a single distributed 1MHz clock. The early DEC CPUs, in the MIT tradition, have a pulse that ripples down through the logic, popping out at the other end to start the cycle over again. I've been told, but haven't verified that the Interdata 8/32 works the same way. I think the farthest I dug into that was to notice that the CPU has no clock oscillator.

On Jan 6, 2014, at 07:04 , dwight <dkelvey at hotmail.com> wrote: That reminds me of a guy I worked with back in the 90s. He inherited my *working* VHDL model of a SCSI host, used for exercising our SCSI disk controller IC interfaces in simulation. He got confused by the active-low signals on the SCSI bus, so he added an inversion to each signal. Then it didn't work any more, of course, so he added *another* inversion to each signal. After we convinced him to go work for somebody else (hopefully a competitor), we literally rolled back his year of work in the revision control system. Sad, really. He was a nice guy and he interviewed well, but he couldn't actually do anything productive in the field we were working in. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/