Later versions of the filesystem would be more likely to use 2k or 4k blocks. The FST contents would be the filesystem metadata, wherever that has landed. De

:) Starting on pdf page 135 here is a description of the FST data structures from circa 1986: https://bitsavers.org/pdf/ibm/370/VM_SP/Release_5_Dec86/LY24-5221-2_VM_SP_R… Might help sort the CMSN block. De

Take a look at the link I pointed you too. There is code in there to list the files on the tape and copy then to a PC disk. It will work with AWS files and physical tapes. Dave

I'm working on the design for an Omnibus (PDP-8/E) debug board and I am not very good at circuit design.  I know there are programs that will compile something that looks like C into Verilog/VHDL/Abel/Etc for use on some kind of large (more than 64 pins) programmable logic device. Can any of you recommend a good C like tool for programmable logic? Thank you,              Mike

Spartan 2 FPGAs have (among other things) 3.3 volt output drivers, with a minimum high output spec of 2.4 volts. That's probably good enough to drive 5 volt TTL devices. (FWIW, I've had good luck driving 5V logic from the 3.3 volt I/O of a Raspberry Pico. Not quite the same but similar). They also show 5 volt tolerant inputs, so while the device is powered by 3.3 volt it can accept 5V TTL inputs without complaint. I recently built a device that had a lot of inputs to that Raspberry Pico, which is documented as NOT 5V tolerant. So instead of searching for level shifters I simply used an array of resistive voltage dividers. Worked flawlessly. As for a C like tool, I've heard of something called "System C" for logic design. No idea if it is reality for any FPGA, let alone for the older ones. The difficulty is that C is a sequential system description, which is fine for (single core) computers. But logic such as FPGAs does many things concurrently, and that calls for a different way of describing what you need. I'd suggest learning VHDL; it isn't all that hard. Or Verilog I suppose, which I don't know. Years ago I bought Peter Ashenden's "Designer's guide to VHDL" which is very good. paul

On 9/22/23 11:34, emanuel stiebler via cctalk wrote: I still have a few 84 pin PLCC XC95108 5V CPLDs Originally, I did a tape controller design with one before Xilinx discontinued them. I figured that using a discontinued part was not the way forward, so I dropped the project. Xilinx did/does have its ISE design suite, which is fairly easy to use. Eventually, it turned out that using a reasonably fast MCU with 5V tolerant I/O worked just as well and avoided the "mystery in a chip" of a CPLD. --Chuck

Oh, and Verilog all the way. I just can't with VHDL. 😆 -- Anders Nelson www.andersknelson.com On Fri, Sep 22, 2023 at 3:24 PM Anders Nelson <anders.k.nelson(a)gmail.com> wrote:

I only know VHDL but I had heard that Verilog is C-like, and yes, C offers an unusually large set of tools to shoot yourself in the foot with. So it wouldn't surprise me that Verilog does likewise, which certainly means that it would be the option to avoid. VHDL is very clearly based on Ada, which like Pascal and ALGOL takes data types seriously rather than only as suggestions the way C does. I've built some very large designs with VHDL, but not because I actually wrote that much code -- a lot is generated code produced from wire lists. But I did write all the models of all the 6000 modules, which does add up. Apart from vendor tools for producing bits for particular FPGAs, you can also find VHDL simulators that just simulate a model but don't deliver it to a particular chip. I use GHDL, which is part of the GCC toolset. Yes, a VHDL compiler, interesting. Among other things, it allows you to link bits in other languages, so I can take device models from the DtCyber emulator and attach them to a VHDL-modeled I/O channel. On FPGAs, it's worth checking what the story is for vendor tools. Some devices and vendors try to suck large sums of money out of you for them; Lattice is an example. Even for small devices (like the ispLSI2032 I used years ago) that expense adds up rapidly. I think they have become somewhat more reasonable now, offering free tools for the smaller devices. I know Xilinx does so, and "smaller" covers a surprising amount of capacity these days. I'm pretty sure a PDP-11 model would fit fine in one of those "free tool" devices, though a CDC 6600 probably won't. paul

There are now some open source tools for working with fpgas. They started with the ice40 but have now been extended to cover others such that it's worth googling for free fpga tools rather than going to a single site. example https://www.digikey.co.uk/en/maker/projects/introduction-to-fpga-part-2-too… On Sat, Sep 23, 2023 at 2:30 AM Martin Bishop via cctalk < cctalk(a)classiccmp.org&gt; wrote:

On 2023-09-23 12:36 p.m., Paul Koning via cctalk wrote: I say get the memory first, who knows what you need will be around later. I wish you good luck, as FPGA software does what it thinks is right, not what you think is right. Ben.

I used an Arduino Feather that way, for my PS-2 to LK201 converter. And while not 5V tolerant, a Raspberry Pico is a particularly powerful and cheap option; one of my projects could run DDCMP at 10 Mb/s including the "integral modem" compatible signaling. As I mentioned, 5V tolerant inputs can, at least for not too high speeds, be done simply by resistive voltage dividers. paul

I can't answer for Paul, but I can tell you how to do approximate calculations for yourself. You need to know two things: the equivalent parallel resistance (Thevenin equivalent) of the two series resistors and the input capacitance of the driven pin (including stray capacitance.) If you assume the input+stray capacitance is 10 pF (a reasonable first approximation) and the resistance is 1000 Ohms, the time constant (time for the signal to go from 0 to 63% of max) will be 1000 * 10E(-12) seconds or 10,000 picoseconds = 10 nanoseconds. That assumes the 5V output can switch instantaneously into the 5 mA or so load. I would double that for the real world. So the signal gets delayed around 20 nS and the output has to drive 5 mA or so. A more realistic divider might be 5K or 10K resistance for less power consumption and less strain on the output. With 10K you are looking at a delay of 100 to 200 nS. If the timing isn't critical you "might" be able to go as high as 5 MHz that way. But probably more like 1 MHz is more realistic. I've used voltage divider level translation at about 1 MHz, using something like 2200 and 4700 ohms for the divider (Thevenin equivalent 1500.) ymmv Will If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

On 2023-09-22 12:34 p.m., emanuel stiebler via cctalk wrote: I hate both. You can't shoot yourself in the foot, because you can never figure where the feet are with all that verbose. I use ADHL. It is vender specific, but I can figure out the logic. FPGA's have too many vender specific features,to go from one brand to the other. Schematic capture, is the other option. One gota with FPGA's, flip flops only have asyncronus clears, not preset.

Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop.  I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction.  If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus.  I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one.  I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_S… Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates.  I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks.

My plan is to have both a serial port for connection to a PC/Terminal and an I2C output to a multi line display. Thanks for the suggestion. On 9/22/2023 4:45 PM, ben via cctalk wrote:

Stupid question, I know, but someone has to ask it. Is there some overwhelming reason that the FPGA and associated logic couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, 200 MHz? I can't believe that a PDP8 is all that fast... --Chuck

I have no plans to emulate the CPU.  This is intended to be a board to help debug programs and possibly some hardware issues. On 9/22/2023 6:06 PM, Martin Bishop via cctalk wrote:

Mike An M0 will require an FPGA below it to interact with the OmniBus A BeagleBone, using the PRUs - which are ~microcoded, would be in with more of a chance Industrial grade SoCs / FPGAs should have no difficulty Martin -----Original Message----- From: Mike Katz via cctalk [mailto:cctalk@classiccmp.org] Sent: 23 September 2023 00:27 To: General Discussion: On-Topic and Off-Topic Posts &lt;cctalk(a)classiccmp.org&gt; Cc: Mike Katz &lt;bitwiz(a)12bitsbest.com&gt; Subject: [cctalk] Re: Good C to FPGA/PLA compiler I plan on controlling the gate array with an RP2040 dual core cortex M0 running at 133 MHz and 8 PIO processors. However, the Data Break (DMA) timings on the Omnibus are in the 100nS range.  The bus runs 6 different timing signals plus manipulating all of the other signals to implement Data Break. I just don't think a micro would be fast enough. That same holds for the break point.  In order to be able to respond to address, data, r/w and count for 4 breakpoints in the <1uS window to stop the CPU before the start of the next cycle would stress most embedded micros (sub  $10 micros anyway). The PDP-8/E main clocks are derived from a 20MHz crystal (That's a 50nS minimum timing). Quoting the DEC Omnibus Standard Document Memory, Address and Data must be settled within 50nS  minimum and no more than 250nS depending on what is going on on the bus. There is a boot strap board that emulates the front panel with an Arduino and an I/O expander. But to implement Data Break requires much more tight timing.  This bus was designed to handle core memory which requires a write after read because the read is destructive. On 9/22/2023 5:52 PM, Chuck Guzis via cctalk wrote:

Mike I shall focus a few specifics I did 30+ years of software, with occasional hardware toys, before I added 20 years of Hw, FPGA & Sw : old dogs can learn. FPGA logic source has more in common with software than old school (SSI / MSI / LSI) hardware. With the bonus that it all happens in parallel. Essentially you instantiate lots of little processors / state machines, with some interconnect and some IO knitting. It has not got any better since the OmiBus data break spec, the AXI spec is sufficiently complex that testing DMA interfaces is done at a minimum with verification IP. Although AXI busses do at least have a "global" synchronous clock. Interface complexity / verification is just one of those little challenges. I appreciate that OmniBus is not a multiplexed bus, like Q-bus. I was suggesting that you could multiplex the bus signals to/fr your processing hardware to enable the use of cheaper/simpler hardware. Of course, YMMV. The data being on either memory or data bus would not defeat an FPGA, as it would know the state of RnW and make the appropriate comparison. And, in VHDL it would all read like "parallel" Ada. Down to 0.5 mm pitch gull wing legs can be readily hand soldered by a wireman. Surface mount double sided PCBs can be hand assembled (by me), in small quantities, by restricting the components to 0603 and 0.65 mm pitch using an under board heater and hot air. The fine pitch stuff goes on first. OTOH a good wireman can hand solder 0402 components. So, don't back off completely from SMD. You "only" need: a quartz heater, a hot air wand, and a solder paste dispenser (you spit it on by hand). Note that surface tension squares everything up and moves the solder onto the pads; which need to be (hand assembly) oversize. NB this approach is for very low volume / zero budget / assemble tonight work; for serious boards / volumes you send the kit to the assembler. BGAs are another story - dodge them; e.g. use https://digilent.com/shop/cmod-a7-35t-breadboardable-artix-7-fpga-module/ or similar to apply FPGAs in a 0.1" DIL form factor, at LVTTL levels. You could build an OmniBus interface with two of these, some bus interface chips 74LVC for Rx, something OD (and not too fast) for Tx, and a "host" processor. Best Regards Martin -----Original Message----- From: Mike Katz [mailto:bitwiz@12bitsbest.com] Sent: 23 September 2023 01:16 To: General Discussion: On-Topic and Off-Topic Posts &lt;cctalk(a)classiccmp.org&gt; Cc: Martin Bishop &lt;mjd.bishop(a)emeritus-solutions.com&gt; Subject: Re: [cctalk] Re: Good C to FPGA/PLA compiler Martin, Thank you for all of your suggestions. I am a software guy who has dabbled in hardware since I built my first Heathkit in 1972.  I have designed simple 6809 single boards in my past professional life but the Omnibus is several orders of magnitude more complicated than a 6809. Just reading the Single Cycle Data Break documentation in the Omnibus spec is enough to give me a headache. I think in C much better than I think in logic gates.  I can write parallel C to describe parallel circuits.  The last time I programmed any programmable logic it was FPGA's of the 10L8/16V10 variety. Sometimes the data is on the memory bus, sometimes it is on the data bus, depending on whether you are reading or writing to memory, for example. There is no bus multplexing between address and data or data and memory busses. Here is the basic definition of the Omnibus: Memory Address:         15 Signals Memory Data:               12 Signals Memory Direction:          1 Signal Data Bus:                        12 Signals I/O Control Signals:       10 Signals DMA Control Signals:      8 Signals Timing Signals:                 9 Signals CPU State:                         6 Signals Memory Timing:              5 Signals Misc Signals:                   18 Signals (Mostly used by the front panel) One of my goals here is to use thru hole parts and sockets so the average person can assemble it.  I realize this may be impossible bit I'm trying. I have a good surface mount contract manufacturer close to my home that I have a business relationship will so I can go to full surface mount if I have to but that will increase the cost of the boards. On 9/22/2023 6:53 PM, Martin Bishop via cctalk wrote:

On 2023-09-22 20:16, Mike Katz via cctalk wrote: Actually, there is something like you're trying to do, on discord, he is making a board for the data general nova: https://discord.com/channels/700194611091472415/805549176238112768/11375905…

Mike A key factor is that 60 years have passed: - the PDP8/E (and its chums) were core store machines - the bus time slots are 300 + 250 + 350 + 300 ns = 1200 ns [T1 T2 T3 T4 phases of core access] - FPGA fabric can trivially run at 100 MHz, and talk to an AXI bus + Arm Core - SoCs have 32 / 64 bit “external” data busses - Arm cores run at 666 MHz and above - consequently the test hardware is ~3 orders of magnitude faster than the old iron, wider and capable of performing lots of (hardware) logic in 10 ns – a cascade of 10 LUT6’s is not unreasonable on a mid range FPGA. To cut to the chase, a clone of the UniBone should be possible and largely a software project – there is a large body of code and experience to build on and the Omni and Uni / Q Busses are similar. The 96 signals need not define the scale of the FPGA / SoC hardware. There is probably scope for multiplexing / serialising the lines to / from the OmniBus – I should think the RetroCmp designs use this technology – unfortunately I have not had the time to read them sufficiently carefully to say. Interfacing between the omnibus and an FPGA / SoC will require debouncing and a metastable hardened synchronisers (~3 stages of FFs) to bring the signals into the FPGA/SoC synchronous domain. Beyond a Schmidt trigger / equivalent front end this is a job for modern digits, in the input FPGA/CPLD(s). Re your specific requirements: 1) Was a hardware task 60 years ago, It would now be trivial to do it with an FPGA controlled by any reasonable processor 2) You should be able to this by bit banging over JTAG, maybe with a little hardware assist 3) Sequencer breakpoints in FPGAs are straightforward, provide the condition and it pulls the stop line; all that is required are condition register sets and comparison logic 4) see comment above re Mux/Serial 5) I should think avoiding stubs will be more important than the specific input devices I would restate your needs / the design as: a) bus interface b) FPGA interface c) bus receiving, driving, uC demand (e.g. DMA, FP emulation, breakpoint conditions) and reactive logic d) uC code HtH; Best Regards Martin From: Mike Katz [mailto:bitwiz@12bitsbest.com] Sent: 22 September 2023 22:17 To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>> Cc: Martin Bishop <mjd.bishop@emeritus-solutions.com<mailto:mjd.bishop@emeritus-solutions.com>> Subject: Re: [cctalk] Re: Good C to FPGA/PLA compiler Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop. I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction. If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_S… Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates. I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks.