Re: IBM PC Connecting to DECNET
On 6/3/22 08:55, Bill Gunshannon via cctalk wrote: On 6/3/22 08:46, Antonio Carlini via cctalk wrote: It's predecessor, the DEQNA, was "Digital ETHERNET Q-Bus Network Adapter", according to its user guide, or "broken", according to most people :-) I see comments like this all the time but I used DEQNA, DELQA, DELUA and DEUNA for years with minimal problems. I too have wondered about these comments. I know I wrote a driver for the DEQNA for the C Gateway and I don't recall having any particular difficulty with it. It wasn't as good a programming interface as the Proteon Ringnet, for example, but everything was trending to becoming more complex at that point (like how programming the RK11 compares with MSCP). The DQNA worked for me though and just kept on working. Dave
Re: RK11-C indicator panel inlays?
On 12/6/21 17:45, Mike Katz wrote: If I may8 ask a question. I have never had boards made before. How do I find a good board house that is reasonable and how do I specify the board especially for the PDP-8 Omnibus which should have gold fingers on the edge connectors? I was planning to try PCBWay for my boards. They say they do hard gold fingers and they have a board assembly option that looks like it can do what I need. I haven't used them before so this will be an experiment in that direction as well. If you're using KiCad for your designs (and if the Omnibus uses the standard DEC boards), I have templates for double and quad height boards that you're welcome to. Since I haven't yet made boards from them, check yourself that they're right before ordering but at least they'd be a start. Dave
Re: RK11-C indicator panel inlays?
On 12/6/21 10:36 AM, Mike Katz via cctalk wrote: > Each LED requires 24 bits of data. That would be 3,456 bits. The > WS2812B has a 300uS low start indication and 1.25 uS per bit. That > would mean it would take. 4.62mS to update the all of the LEDs. If I'd known about those when I designed my boards, I might well have gone that way. They're surprisingly inexpensive even. Instead, I ended up using a 16-LED driver chip that basically looks like a shift-register. I clock in the 144 bits (just on-off, no fancy tri-color LEDs I'm afraid), toggle the latch signal, and there it is. If you want to support more indicator panels, it's just a longer shift register. I then added RS422 driver chips for noise immunity and there I was. Dave
Re: RK11-C indicator panel inlays?
On 12/6/21 10:13 AM, Henk Gooijen via cctalk wrote: > If this RK11-C “blinkenlight” panel would also become available in a 60% > scaled format, > I would buy it immediately. It would be an “übercool” addition to the > PiDP-11/70 and > my 60% scaled (“working”) RK05 drive. I only modified the files pdp11_cpu and > pdp11_rk05, > and added my own code to handle the 2 switches, 8 indicators and the door / > disk loading. > see https://www.pdp-11.nl/pidp1170/rk05/rk05startpage.html (at the bottom of > the page). > I will check whether it could be scaled to 60% using standard 3 mm > (warm-white) LEDs > (if those exist, else I would probably use yellow-ish). I do agree that it would be very cool to add a scaled indicator panel to your PiDP-11 and scaled RK05. You'd have to do new scaled circuit boards to be driven from the RPi and a new scaled bezel and light-shield as well as the inlay. It's all possible but I don't think I'll be doing it. You are most welcome, though, to the work I've done on any and all of those pieces if you want to take them and scale them down. If you watched the little video I posted of my early blinking lights, you probably noticed how blue those white LEDs were. I've since switched to a different LED that looks, at least to my eye, a whole lot better. In these pictures you can see a comparison. http://pdp10.froghouse.org/qsic/new-led.jpg http://pdp10.froghouse.org/qsic/new-led-2.jpg Dave
Re: RK11-C indicator panel inlays?
On 12/5/21 4:43 PM, Henk Gooijen via cctalk wrote: > I am definitely interested. Never saw the RK-11C (except once on eBay some 15 > years ago)! > However, I have *two* DX11 front panels with the 144 lamps & 4 ”paddle” > connections boards. > I developed a 100x160 mm (Euro-card size) PCB with a PIC18F252 and 10 > MCP23S17 ICs. > You serially send a command to the PIC and the PIC controls the MCP23S17 > outputs. > Per command you control 8 lamps. On the PCB is one difficult part: a 4 > position one-slot block > to put the 4 paddle boards in. Fun. That's a way to get some more lights into your life. I like it. > Given you have 144 lamps panel with the RK11-C front, what would you do to > light up the lamps? I think the only reason to have an RK11-C inlay is if you have an RK11-C. Otherwise I can't see that it makes much sense. The one other place I might, maybe, possibly see one being used is along with one of our QSICs or USICs. I could add an option to drive an RK11-C inlay if someone really thought that was what they wanted but the RK11-F inlay that we came up with really is a better match and more functional (which is why we came up with it) as well as supporting the RP11 implementation that I'm sure I'll get working any day now (snort). Dave
Re: RK11-C indicator panel inlays?
On 12/5/21 3:24 PM, Ethan Dicks via cctalk wrote: > This would be really cool as a debugging tool > more than just as amazing lights. A great lead-in to my story. I was working away on the RK11 implementation in the QSIC and when I felt like taking a break but still wanted to get something done, I'd work on the indicator panel. Of course, the indicator panel ended working before the RK11. Just having 144 lights that I could assign to any purpose was useful but then came the day when the RK11 was mostly working. I loaded up an RK11 exerciser program that Noel wrote and just sat back to bask in the glow of the blinking lights. It was a good feeling. Then I noticed something that wasn't right. Even though the exerciser was working, I saw a pattern in the lights that showed up a bug in my implementation. I'd really only implemented the indicator panel because I thought it was fun but it lead me to a bug to fix right off. Here's a short video clip of the indicator panel in operation and showing that bug. I'll leave this for a day or two (or until I remember again or someone asks) and then say what it is I saw. I think anyone with a reasonable familiarity with the QBUS will be able to pick it out though I'll say that "Latched Address" is the address "half" of the data/Address Lines, that is the value of those signals when SYNC is asserted. http://pdp10.froghouse.org/qsic/ip-full.mp4 > P.S. - not to derail things, but definitely loop me in on the (future) > thread for making reproductions. I have access to some tools that > might make parts of it easier. The inlays are mostly not done with any tools I have. I do the graphics with Inkscape. Rod made up the blanks with silk screening. Then I have the white printing done at a printshop I found who has a large, flatbed printer that can print white ink. I do have some ideas about how I might try to make up blanks with a laser etcher I have access to but at the moment we have an ample supply. Also, I've experimented with making my own bezels out of PVC board from Home Depot using a CNC router. In the pictures below, the yellowed bezels are old DEC bezels while the white ones are ones I made. I figured that if we ever get the QSIC shipping and people want indicator panels (I hope they'll want indicator panels), I'd rather not depend on them ripping apart old DEC bezels to make this work. Anyway, I'd be most happy to have another person with more tools to help build bits and pieces of this stuff. I've noticed that as I gained access to different tools, I came up with different ideas about how to make things. I didn't think the laser etcher was all that useful until I started using it. Now I want to use it for everything. Turns out it can't quite handle 3/8" Delrin; it just melts it and makes a mess. Speaking of help, if anyone wants to review the QSIC design, I'd welcome that. This is by far the most complex circuit board I've ever designed. Back to indicator panels, here's a picture showing a bit of the evolution of my indicator panels. The video above shows it really early, when I just taped a paper inlay to the circuit boards. Then the bottom panel in this picture is taping that paper inlay to an MDF light shield. The top panel is using one of Rod's blanks with paper labels taped to it. And then the third panel down is a printed inlay like we're talking about now for the RK11-C. The second indicator panel is a TC08 inlay that I borrowed from Noel to use as a model as I worked on the graphics for our own. http://pdp10.froghouse.org/qsic/indicator-panel-stack.jpg Here's a close-up of the TC08 and our printed inlay. I'm rather pleased with how it looks, I have to admit. The only real thing I'd like to change is the gloss. Somehow, DEC's inlay is as flat as flat can be. There is no glare to it whatsoever while ours are quite glossy. I've looked at frosted acrylic and it's a little better though really it just diffuses the glare, it doesn't eliminate it. I've also tried some spray-on frosting which helps a little but it also has a tendency for its solvents to melt the printing that's already there so that's a bit fraught. http://pdp10.froghouse.org/qsic/indicator-panel-printed.jpg Dave
Re: APL\360
On 2/1/21 1:59 PM, John Ames via cctech wrote: > This one has always boggled me, because it's the one aspect of the > Endian Wars where there's a simple, straightforward answer grounded in > basic mathematics - base ^ digit-number only gives the correct > place-value when the lowest-order bit is numbered zero. It's beyond my > ken how anybody thought the reverse was *valid,* let alone a good > idea. For all that I agree with you that little-endian is clearly the right answer and for exactly the reason you state, it's pretty easy to see where big-endian representation came from. That's how we write numbers in English, we write them big-endian. There ya go, it's as simple as that. Sure, one can get into the story that our numbers come from Arabic and Arabic is written right-to-left so in fact they were originally little-endian and just didn't get flipped around when incorporated into left-to-right languages but that's all lost in the past. Today, we write numbers, in English, big-endian so it's no surprise at all that some computers followed that common practice. Dave
Re: Looking for an IDE simulator
On 8/28/20 4:00 PM, Chuck Guzis via cctalk wrote: Plenty of code libraries out there. Why dink around when silicon is cheap? MCUs are everywhere; in many cases cheaper than discrete logic. Might have been better but I had the FPGA there anyway for other reasons so I just connected a few pins to the SD card and started writing code.
Re: Looking for an IDE simulator
On 8/28/20 3:31 PM, Warner Losh wrote: There's some other speed increase (UHS) that comes along with also dropping from 3.3V down to 1.8V. I don't know how to program FPGAs to do that or even know if they can. I thought it was going from SPI mode to MMC mode that did this, not the double clocking nor the 1bit to 4bit bus steps. I knew it wasn't either the double clocking or using all four lanes, I just didn't know what it was called and was too lazy to dig out the SD protocol spec. But now I pulled up the spec and it's saying that it's UHS cards that support the modes that use the lower voltage and there are seven bus speed modes: DS (Default Speed) HS (High Speed) SDR12 SDR25 SDR50 DDR50 SDR104 DS and HS use 3.3V signaling while the SDR and DDR modes use 1.8V. Then UHS-II adds a couple more modes. SPI mode is separate from all of this, something just tossed in there for us hobbyists to play around with.
Re: Looking for an IDE simulator
On 8/28/20 1:10 PM, Paul Koning wrote: SD is a packet based storage device on a serial interconnect, minimally one lane wide but it can also be four lanes (and that's typically how you use it). Apparently it starts out in a SPI compatible mode, interesting. Also, SD requires a rather complex handshake at power up to get to the point where you can do I/O. I've implemented the SPI protocol in a little micro-coded engine on an FPGA and have considered upgrading it to the standard interface over one to four lanes except it looks like the SD licensing says I'm not supposed to do that without paying them a bunch of money. And yeah, it took me a while to work through the initialization dance and it still fails from time to time (and from SD card to SD card). However ... One oddity I remember from a decade ago is that it has a high speed mode where the clock speed is doubled. That's not strange. What's strange is that when you do this, the device switches from clocking data on the rising edge to clocking on the falling edge, or the other way around, I don't remember which. Fortunately I wasn't the hardware designer who had to cope with all that strangeness. ... this I had totally missed. Doubling the clock speed (from 25 to 50 MHz) would be relatively easy (once I'm not running this over long ribbon cable) but switching the clock around like that would have really confused me, I think. Thanks for the heads-up. There's some other speed increase (UHS) that comes along with also dropping from 3.3V down to 1.8V. I don't know how to program FPGAs to do that or even know if they can.
Re: Looking for an IDE simulator
> in an online search - the CFADPTHD seems like it's close to what I'd want, > except it's Compact Flash; I'd have preferred SD but I guess converting > their interface to IDE is more work. Yeah, I think Compact Flash actually uses the IDE protocol just with a different form-factor while SD cards are their own thing so a conversion from SD to IDE is a whole lot more work. Although, I did find these so I guess you're not the first to want this: https://www.amazon.com/40Pin-Male-Hard-Drive-Adapter/dp/B01ANIQNK4 https://www.amazon.com/dp/B076597T9H/ref=dp_prsubs_1 https://www.newegg.com/syba-sd-cf-ide-br-ide-to-compact-flash/p/N82E16812186002?Description=ide%20to%20sd%20adapter&cm_re=ide_to%20sd%20adapter-_-12-186-002-_-Product&quicklink=true https://www.newegg.com/syba-sd-cf-ide-di-ide-to-compact-flash/p/N82E16822998003?Description=ide%20to%20sd%20adapter&cm_re=ide_to%20sd%20adapter-_-22-998-003-_-Product https://www.newegg.com/syba-sd-ada45006-ide-to-compact-flash/p/N82E16812186098?Description=ide%20to%20sd%20adapter&cm_re=ide_to%20sd%20adapter-_-12-186-098-_-Product&quicklink=true
Re: (V)HDL Toolsets
On 5/20/20 10:22 PM, Jay Jaeger via cctech wrote: > I'd be interesting in hearing from folks what toolsets they have used > for HDL (VHDL in particular). I've been using Verilog rather than VHDL but I started with Quartus for a little while then moved over to Vivado which I like a little better. I agree with Peter's point that I sure wish the bitstreams were open so that a crop of open-source tools could be developed and we'd have a bit more choice. Along these lines, I've been wondering if I ought to take a closer look at SymbiFlow, but I have digressed. What I really use more often though is the Icarus Verilog simulator. Besides Verilog testbenches, I've been running the PDP-10 diagnostics under Icarus. I even wrote a PDP-10 disassembler in Verilog so it disassembles and prints out the instructions as it executes them. I also came across Verilator, a Verilog to C++ compiler. It makes for faster running simulations but so far I'm only using it for its 'lint' function which is pretty nice. It catches logic loops that just put Icarus into infinite loops.
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
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.
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
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.
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
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.
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
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
Re: KiCad pcb file
On 9/17/19 15:00, Ed Groenenberg via cctalk wrote: > Hello. > > I'm looking for a PCB layout file / template of a 2 slot Unibus card, > which I want to use in KiCad. > > Can someone help me with this? Here's a KiCad template for a double-height QBUS card. I haven't verified it or cleaned it up but it ought to make a good starting point and deleting the QBUS bits will be easy. Eventually I'll need to do a quad-height Unibus card too. http://pdp10.froghouse.org/qsic/qbus-template.tar.gz If you're building your own DEC boards, this is the best dimensional diagram I've come across; I pulled it out of a uVAX manual. The one bug I've found in it is the "1.00±.010" in the corner where the edge fingers start. I think it's supposed to be "0.100±.010" but I'd double-check that against other diagrams or measure a real board. http://pdp10.froghouse.org/qsic/qbus-dimensions.pdf
Re: Email delivery protocols / methods.
Obviously that message wasn't supposed to go to the list. I forget how the list re-writes the message headers like that. Sorry about that. Dave
Re: Email delivery protocols / methods.
On 7/6/19 8:46 AM, Noel Chiappa via cctalk wrote: > So here's one I'm not sure anyone else will catch: TFTP has an email mode! I knew about that one. :-) Did anyone other than CSR ever use it? Not much airplane news. I've spent some time chasing down wheels and brakes for the Galaxie. The designer is planning to use hubs and brakes designed for trailers and farm implement tires on his. I was preferring more aircraft parts so I went off to find what I could in that direction. It was more difficult than expected but, in the end, I have a plan that I think will work well. The final part is axles and the designer says that with the specs I've found, he can machine up what I need. Been hearing more interest in running a KiCAD class at the MakerSpace so the past few days I've been putting together a more detailed outline of what I want to do there. One of the things I came across is "back annotation" which is something I've wanted a few times. This is where I do design-work on the circuit board and push that back to the schematic. Where I've wanted it in the past is in wiring up connectors or the LEDs on the indicator panel boards. In many cases I don't particularly care which goes to where as far as the electronics go but I want to make my life easier with the board layout. On the QSIC I've had that with wiring which bus drivers go to which bus signals and I will have it big time with wiring between the FPGA and the bus. Except for a couple signals that need to go to clock inputs on the FPGA, the rest all just go to any old I/O pin. Need to go learn this back annotation thing before starting that. I have tinkered with the QSIC circuit board design some more and have the bus drivers all routed. I didn't know about back annotation so I just did that by hand. That is, I look at the circuit board to see what signals are crossed and flip back to the schematic to swap signals around and then back to the circuit board until everything routed easily as possible. It was a pain but it's done and seems like a good job. I've also taken a stab at routing the signals from the FPGA to the memory chip. That's a new and interesting challenge. I've almost been able to do it with a 4-layer board. That plastic supply place that I'd talked about? Turns out I had a brain fart reading their webpage and it's not in New London like I was thinking but Londonderry. That means an hour and a half drive rather than a half hour drive. Sigh. At least it's still in the state. I heard a bit more from Greg up in Kantishna. He had an AVM and a small brain bleed but says it's all fixed up now. Still, he's grounded for at least a year and was asking about fill-in pilots. I thought about it some and decided that I could go up later in the summer say August sometime, and then finish out the season. He'd put the work out to a bunch of people and, last news I had, he was covered for now. And, holy crap, there was another accident in Ketchikan. No fatalities on this one, fortunately, but it was the company that shares the dock with us so I almost certainly know the pilot. Damn. They'd just rebuilt that plane last winter too. I hope your summer is going well and you got lots of wood out of that tree that almost crushed your house. Dave
Re: Font for DEC indicator panels
On 11/12/18 5:04 PM, Paul Koning wrote: > The name of the font translates to "Bold Extended". DIN 1451 is a family of > fonts, see Wikipedia. You're looking at one of the members of the family, > the bold wide one. It's not all that bold, judging by the pictures; if you > need something bolder still you may be out of luck. I hadn't meant to send that message to the list, sorry, but since I did, here it is with Alte Haas Grotesk. http://pdp10.froghouse.org/qsic/inlay-rk11-f-altehaasgrotesk.pdf > That also suggests that the DEC font isn't this one. Could it simply be > Helvetica? Entirely possible. Found this one that might look even more authentic. :-) https://www.1001fonts.com/helveticrap-font.html
Re: Font for DEC indicator panels
> > "DIN 1451 Fette Breitschrift 1936". That is probably the > > font next to the knob on the right and the bit numbers above the > > switches. > > Yeah, that latter is the one we're looking for (mostly). I was able to download a version of that one that worked but I don't think I like the results. One problem is that the instance of the font I found didn't have a bold face version. You can see the results here. http://pdp10.froghouse.org/qsic/inlay-rk11-f.pdf
Re: GCC for pdp11
Hey, glad to hear of some improvement on GCC for the PDP-11. Last spring I ended up side-tracked on the QSIC project and working more on FPGA issues than writing PDP-11 code but that's going to change here at some point. I still want to put a soft PDP-11 into the FPGA as an I/O controller and will need to be writing code for it. For the moment, I'm off at my summer job in Alaska but when I get home this fall, it's back to working away on the QSIC and maybe my PDP-10 project where I'm thinking I may also use a soft PDP-11 as an I/O processor. Anyway, I'll grab up the new GCC and see if my issues with the 'volatile' keyword are still there. Dave
Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
> Imagine our chagrin when days of trying to correct the > problem led to the conclusion that the diagnostic was incorrect. I may have a situation like this in working on my FPGA PDP-10. The Processor Reference Manuals seem quite clear that the rotate instructions take E mod 256. One of the manuals I've found even adds that they never move more than 255 positions. And yet the diagnostics I have clearly want ROT AC,-256 to move 256 positions to the right, not 0. Not having a real PDP-10 to compare against, I don't know which is right. Doing it mod 256 would be easier; I had to add an extra rotor to my barrel shifter to handle the -256 case to make the diagnostic pass.
Re: QSIC update - v6 Unix boots and runs
> That sounds pretty awesome. Good job there! Thanks. Feeling good today after a bit of frustration with development not going faster. > Do you know how hard it would be to take this design and make a UNIBUS > version? I have an 11/34 languishing under the bench in my hardware > lab and one of the principal reasons for the languishing is that I > don't have any drives to go with it. Our plan is to produce a Unibus board as well, we just chose the QBUS first. A Unibus version of the hardware ought to be a fairly straightforward adaptation of the QBUS board while the QBUS modules in Verilog will just have to be replaced with Unibus versions. The busses work pretty similarly so we're expecting that to also be relatively straightforward. Yeah, I've told myself that before. :-) For the Unibus (actually, this should work with Q18 QBUS systems as well), we plan to also implement the Able ENABLE+ functionality which would give 11/70 size memory. We'll have some SDRAM onboard that we'll use for RAM disks but we'll carve out 4MB of that for machine memory and include mapping tables to access it. This will, of course, require you to modify your OS to support this non-standard memory. Noel has already done so for v6 Unix.
Re: QSIC update - v6 Unix boots and runs
> FWIW, so does RT11, and in the case of writes, it requires the rest of the > block to be zero-filled. Not everything depends on this, but some parts do; > I think Fortran is one. I did implement that too. Unix doesn't need it but I had to fill the block with something and it wasn't that hard to zero out the value. I figured something would come along that required it. There is still a whole lot of the RK11 functionality I need to implement, much having to do with handling and properly reporting error conditions. It's still pretty cool to boot up Unix and type commands at it. Doubly cool to watch the indicator panel blink away while I run programs. By the way, that indicator panel has been ridiculously valuable for debugging this thing. I did it initially just because I thought it would be fun and I needed to take a break from some frustrating bug but it's turned out to be far easier to use than the logic analyzer (which I've never hooked up). I just generate a custom FPGA load that displays some register I think will tell me what's going on or even sometimes create additional counters with specific triggers that can monitor the internals of my implementation.
QSIC update - v6 Unix boots and runs
For those of you who are following along with our QSIC project, today we booted v6 Unix successfully for the first time. We'd first tried this a week or two back but discovered that Unix does use partial block reads and writes after all and I hadn't implemented those yet. We're running this on an 11/23 using the QSIC with an SD card emulating a couple RK05s. Moving on to a small RAM disk next so we don't have to swap off the flash memory. After that, either a larger RAM disk using the SDRAM or an RP11 to get larger disks than RK05s. We're getting close to the time when we need to think about making our own circuit board rather than using the wire-wrap prototype we've been having fun with so far.
Re: DECtape madness
> So why are reels of DECtape selling for unbelievable prices on eBait? See, > e.g. here: I had those on my watch-list and just shake my head at the astonishing prices for the things. I've wondered if you might not make DECtape tape from 3/4" video tape. I know that DECtape has mylar on both sides but what if you somehow glued two strips of video tape together with the mylar backing on the outside. Probably want to build a jig of some sort and I'm not sure what glue to use.
Re: QSIC update and request
On 1/2/18 15:38, Toby Thain via cctalk wrote: > Err.. could be my mistake... I meant wherever you posted your last > technical note about QBus quirks. (I didn't look up the reference) Oh, that paper I wrote about how bus arbitration works on the Unibus and QBUS. I'd thought of it as just a way of passing on information I'd learned to the community about something I thought was interesting but you're right, it also serves to document some of the internals of the QSIC since that's where I took it from.
Re: QSIC update and request
On 01/02/2018 02:05 PM, Toby Thain via cctalk wrote: >> Oh, I hadn't thought of Toby possibly meaning that. Yeah, I'm unlikely >> to write up much documentation on the internals of the QSIC for people >> who want to add other devices. However, not only will the source be > Yes, that's what I meant. In fact I thought that was the point of the > device :) Well, I guess I thought the point was to produce a working replacement for the disk drives that are nearly unobtainable but if it turns out that lots of people are seriously interested in developing for the QSIC itself, then I'll have to revisit that supposition. In that case, I'd probably write up more internals documentation than I would otherwise. > Hope so. And there's always the blog? Blog? Is there a blog about the QSIC that I don't know about? I'm not much of a blogger but if you get me started talking about things that interest me I tend to rattle on to excess.
Re: Asynchronous design - was Re: Computing from 1976
On 01/02/2018 02:07 PM, Toby Thain via cctalk wrote: > On 2018-01-02 1:57 PM, David Bridgham via cctalk wrote: >> The link didn't work for me but I definitely have that paper -- good >> stuff indeed. I should collect my library in one place so I don't lose >> track of what I have. >> > Sorry, this is a better link: > > https://dl.acm.org/citation.cfm?id=1283946 That one works, thanks. It's some pretty interesting work.
Re: Asynchronous design - was Re: Computing from 1976
The link didn't work for me but I definitely have that paper -- good stuff indeed. I should collect my library in one place so I don't lose track of what I have. On 01/02/2018 01:54 PM, Toby Thain via cctalk wrote: > In this vein, Ivan Sutherland's Turing Award lecture, "Micropipelines", > might be interesting: > > http://delivery.acm.org/10.1145/7/63532/a1988-sutherland-1.pdf > > --Toby
Re: Computing from 1976
On 01/01/2018 08:06 PM, Paul Koning wrote: > Neat. I found this 2011 paper that's interesting: > http://www.cs.columbia.edu/~nowick/nowick-singh-ieee-dt-11-published.pdf Thanks for this paper, Paul. I'm quite interested in the idea of asynchronous circuit design and I hadn't come across those dynamic pipeline designs before.
Re: QSIC update and request
On 01/02/2018 01:13 PM, Noel Chiappa via cctalk wrote: > If you mean the 'software' for additional controllers - that would be a _lot_ > harder (plus to which it's an entirely different tool-chain, yadda-yadda). > 'Use the source, Luke!', I'm probably afraid... Oh, I hadn't thought of Toby possibly meaning that. Yeah, I'm unlikely to write up much documentation on the internals of the QSIC for people who want to add other devices. However, not only will the source be available, I'll be around (hopefully) and will be quite willing to answer questions. Shoot, if anyone shows interest I'll probably talk their ear off about it.
Re: QSIC update and request
On 01/02/2018 12:45 PM, Toby Thain via cctalk wrote: > If the documentation is good enough, people in the community will be > able to provide the software. The quick answer is that it's pretty simple. We take the cylinder/head/sector addresses and consider them a Linear Block Address. Then we look around the device registers and pick up a few more bits that were unused in the RP11 and we end up with a 28-bit Linear Block Address which works out to a ridiculously huge disk for any PDP-11 ever conceived. But yeah, we'll document it. There will also be an entirely new programming interface into the QSIC itself, mainly having to do with configuration (like whether or not the RP11 implementation is stock or extended and how portions of the SD cards are mapped to various disk packs mounted on the emulated disk drives). I intend to write that up too so that people are able to write programs for their favorite OS that drive the device however they wish. I may joke about pointing people to the source to figure out how it works (it was hard to write, it should be hard to read) but I actually quite like well-done documentation and will endeavor to produce some.
Re: Computing from 1976
On 01/01/2018 03:33 PM, Noel Chiappa via cctalk wrote: > > From: Paul Koning > > > The only asynchronous computer I can think of is the Dutch ARRA 1 > > Isn't the KA10 basically asynchronous? (I know, it has a clock, but I'm > not sure how much it is used for.) This was my understanding, as well. More recently there was the AMULET processors designed at the University of Manchester. https://en.wikipedia.org/wiki/AMULET_microprocessor One of the stories I read about the AMULET was that they wrote a little program to blink an LED where the timing was determined by a busy loop. If they sat a hot cup of coffee on the processor, the light would blink slower; a cup of ice water and it would blink faster. If this were a different group, I might suggest that this points the way to designing computers that transition gracefully in Vinge's Zones of Thought but I'll just leave that digression alone. The Advances Processor Technologies group at the University of Manchester also came up with the Balsa language, an HDL for asynchronous design. When I started working on my own PDP-10 implementation, I began by writing it in Balsa, thinking I wanted it to be a follow-on to the KA10. I'm still interested in asynchronous design but I've let that implementation go for the moment.
QSIC update and request
Even though I've been quiet, I have been making slow progress on the QSIC in the background. For those who've forgotten what the QSIC project is about, here's the description: http://pdp10.froghouse.org/qsic/html/overview.html We've been working away on getting communications with the SD card working and that's basically there now. It initializes and reads and writes blocks. I've also connected it through an async FIFO to the minimal RK11 controller I had working before and that's mostly working. That is, it can read and write blocks under control from the QBUS PDP-11 as if it were a real RK11/RK05. What more could you ask for? Well, I could ask for a lot more really but that's pretty good. There's a lot of RK11 functionality that I haven't implemented yet and all sorts of configuration options we need to get in there. Also, there's a bug where it sometimes scrambles data so it's not quite ready to boot and run a real OS yet but it's getting awfully close. Here's a picture to my test setup: http://pdp10.froghouse.org/qsic/qsic-setup.jpg And a picture of a test of some spray-on glass frosting used as a light diffuser on the indicator panel. In this picture you can also see the new LEDs I found that are a much better color match to the old incandescent bulbs than the LEDs I picked for my first attempt. http://pdp10.froghouse.org/qsic/frosting.jpg Now for the request. I've decided that I'd like to put a soft-processor in the FPGA to handle a bunch of things (configuration duties and the USB protocol being two of the big ones). My preference would be for this soft-processor to be a PDP-11. Surely there's hack value in using a PDP-11 as the I/O processor for a PDP-11 but there are practical advantages to this as well. For one, we're already familiar with it and have a suite of development tools. Also, I can re-arrange the I/O devices I intend to give to this soft-11 and put them directly on the QBUS instead and do initial development there. I'd rather not get diverted by yet another substantial development project so I'm looking for a decent little FPGA implementation of a PDP-11 that I could just pick up use for this purpose. Something that's already debugged. I'm thinking closer to an 11/04 than an 11/70 and likely just running out of block RAM on the FPGA. Thanks for any pointers to such an implementation and thanks to everyone who's given support and assistance as Noel and I have poked along on this project. Dave
Re: DEC indicator panel mounting details
On 12/19/2017 05:36 PM, Josh Dersch via cctalk wrote: > See the pictures at the below link: > > https://1drv.ms/f/s!Aqb36sqnCIfMotpQIuc2-tDUva3iBw > > It looks to be fairly straightforward; the plastic "ball on post" brackets > are mounted to the rack rails, and there are metal brackets that screw into > the BOP brackets that hold the PCB/lamp assembly. > > Hope this is the right assembly for you, if not, or if you have questions, > let me know and I can try to fill in the holes... Those pictures are just what we were looking for. That's pretty close to what we thought but I wouldn't have guessed that the metal brackets to the PCB/lamp assembly screwed to the ball-on-post brackets rather than directly to the rack rails. Thanks, Dave
Re: Microassembler, etc, available
On 11/28/17 13:27, emanuel stiebler via cctalk wrote: > Dave has a KV10 already in verilog, so why not port it to the uengine? > ;-) Once the QSIC is far enough along that I go back to working on the KV10, I expect I'll do just that.
Re: 2.11BSD on two RL02 drives? Probably not, but...
On 8/5/17 04:29, emanuel stiebler wrote: >> Xilinx Artix 7. More specifically, we're using a ZTEX 2.13 FPGA module >> for our prototyping. Unless some good reason came up, I was thinking to >> stick with the same FPGA. > > Artix 7? Nice, use them a lot. > > Vivado or ISE? Vivado. Another huge learning experience. Does ISE even support the Artix 7?
Re: 2.11BSD on two RL02 drives? Probably not, but...
On 8/4/17 11:25, emanuel stiebler wrote: > http://ww1.microchip.com/downloads/en/DeviceDoc/1678B.pdf > that the one I use a lot... Oh, a USB PHY chip. Yeah, that might be the way to go now that we're not counting I/O pins. >> 1:1 block mapping. I'm going to have enough fun with trying to >> implement the USB stack in the FPGA without doing FAT16 too. > > Yikes ;-) Yeah, I know. Partly it's a challenge and partly it's something I'd like to have around for another project. > Please do yourself a favor, and put a small micr0controller in the FPGA. > Get it working, then you can optimize and write HDL for it. We've talked about a soft microcontroller, an actual microcontroller, and just writing it in some sort of microcode. Want to get the SD card working first so Noel can start using the prototype board as an actual storage device. > What FPGAs are you using? Xilinx Artix 7. More specifically, we're using a ZTEX 2.13 FPGA module for our prototyping. Unless some good reason came up, I was thinking to stick with the same FPGA.
Re: 2.11BSD on two RL02 drives? Probably not, but...
On 8/4/17 11:16, emanuel stiebler via cctalk wrote: > Use the memory as disk cache locally. Otherwise you need to write > drivers for all different versions of OSs out there. Transparent cache, > write through ... > > Then no changes are needed on the system Well, we are going to make the RAM look like an RK05 or RP03 so no changes should be needed to the OS drivers. I thought briefly about putting in caching but then the whole issue arises of when I issue the interrupt is the write actually complete? The old systems expect that, I believe, and I'm not sure I'm ready to break that assumption. In any case, any serious consideration of caching is also for later. That's a software/firmware update. :-) Dave
Re: 2.11BSD on two RL02 drives? Probably not, but...
On 8/4/17 10:46, emanuel stiebler via cctalk wrote: >> > USB with 480MHz is fast enough >> >> I think our plan was to skip that speed, and go with the next one down, > Probably sufficient for a start ... > > on >> the grounds that the analog part at that speed would be too tricky >> for us. > > No, it isn't. Definitely I'll stick with 12Mb/s USB to start (for sure on our wire-wrapped prototype board) but I'd love to boost that to 480Mb/s later. The analog issue is one thing that made me dubious about going to high-speed but also whether the FPGA without special serial hardware can go that fast. If it can, fantastic. I'll take all the pointers I can get. > You use container files in fat16, or simply 1:1 block mapping? 1:1 block mapping. I'm going to have enough fun with trying to implement the USB stack in the FPGA without doing FAT16 too. > I agree some how with your approach, but it leads to debugging of > issues, you wouldn't have on real boards ... No doubt. It's been a learning experience and we still have a long ways to go. Dave
Re: 2.11BSD on two RL02 drives? Probably not, but...
On 8/4/17 09:26, Paul Koning wrote: >> So my question is: do industrial SD cards exist? > Yes; we've been using them for years now in the products I work on. While > you can still wear them out if you beat on them hard enough, they do have > good reliability. Okay, that's good news then. Any suggestions on what to look for when looking for these SD cards? That is, how to reliably distinguish them from consumer grade? > If you have a ready-made SD interface, these cards work nicely. If you need > to build one from scratch it gets tricky, because the interface is fairly > high speed serial (packet based) signaling, and the initialization sequence > before you can do any I/O is fairly convoluted. It is reasonably well > documented in the SD standard, but still, it takes a while to get all the > code working. BTDT. Yeah, I'm in the middle of figuring all that out. I got it running through the initialization sequence (as far as I can tell) and as soon as I get home from my summer job I'll start working on doing data transfers. Dave
Re: 2.11BSD on two RL02 drives? Probably not, but...
On 8/4/17 05:49, systems_glitch via cctalk wrote: > Going with SLC/"industrial" Flash is indeed the key to avoiding random > failures. I have many deployed systems using industrial Flash modules (IDE > DOMs) As Noel said, he initially talked using an IDE interface for the QSIC. I proposed SD cards to solve two problems. First is that we were worried about FPGA I/O pins. Since we've decided we'll have to go with a BGA part anyway, that problem has been dealt with (though we'd have to think about how to wire it into the prototype board we have). The second was the 5V/3.3V issue. Obviously that's fixable, we had to do so for the QBUS interface, but it's always easier to not. Dave Conroy told me about using these industrial flash IDE modules on his PDP-10/x and running them on 3.3V. That's great except it does nothing for the people who want to run their old stock of IDE disks. So my question is: do industrial SD cards exist? I don't think I'm up to going with a higher-end FPGA and trying to implement SATA even though in many ways I think that's the right answer. If there's a SATA PHY chip, that's a maybe. Dave
QSIC Update
It's been a while since I've sent an update on the QSIC project and since work is currently on-hold while I'm in Alaska for my summer job, this is a good time. With the QBUS protocol pieces all working from the previous winter, last winter's work was to get some sort of storage medium working. SD cards seemed the right first choice so that was the task. After a few months of staring at a state machine implementation and having nothing click for me, I set that aside and considered the idea of building a micro-coded machine. Noel and I kicked it around, came up with a design, he wrote up a micro-assembler and I did the Verilog. This was my first micro-machine but it worked out pretty well, I think. Anyway, we got the design running the SD card through its initialization sequence. Pretty pleased with that. The next step is transferring data blocks but I ran out of time. Also this winter I finally got myself a Github account and moved the code up there. Look for dabridgham/QSIC if you're interested. The webpage describing the QSIC project is http://pdp10.froghouse.org/qsic/html/overview.html. In related news, as we were working through the QBUS implementation Noel and I had a bunch of discussions about bus arbitration. I think we ended up with a decent understanding and so I decided to write it up for anyone else playing around with QBUS or Unibus designs. Yeah, I know, there aren't likely to be too many of us. Anyway, the paper is here: http://www.froghouse.org/~dab/papers/bus-arbitration/bus-arbitration.html There's a pdf version too but the formatting left off the overbar over Q in one section so it might be a bit confusing. Dave
Re: Cross-talk square-wave?
> Don't trust ANYTHING! Recent Xilinx FPGAs have permanent "weak > keepers" on all pins, they can not be turned off. > What this is is a non-inverting receiver on the pad, that is driving > back to the pad with about a 50K Ohm resistor. > Plays hob with analog stuff like crystal oscillators. The weak keeper > would PERFECTLY explain your square wave! > When it gets a narrow pulse to high, it holds the line high. When it > gets a narrow pulse to low, it will switch to holding the line low. > So, if you are using a Xilinx FPGA of recent vintage, or some of their > CPLDs, they will do exactly this. Looks like we have an explanation then. We're using an XC7A75T-CSG324, a Xilinx Artix 7 series FPGA. Thank you very much.
Re: Cross-talk square-wave?
> It's not clear C-coupling is what's going on here (the wave shape looks > pretty sharp for what I understand of the circuit/layout). > Notably though, C-coupling would remove any DC bias, but David's screen shot > indicates a DC bias on the line. > > Is this line currently connected to the FPGA, or is it just the wire and R? > Perhaps the bias is coming from the FPGA, with C-coupling of the wave via the > wire. > Or perhaps it's all crosstalk from within the FPGA, 'visible' because of the > high load R. Yes, the wire is connected to the FPGA at one end. That FPGA I/O pin is *supposed* to be configured for high-Z but that's the only place I can see the DC bias coming from. > If the wire and FPGA pin are connected, separate them (reduce the wire > circuit to just the wire and R to GND): see whether the DC bias and/or the > square wave disappear. Because of the way it's built, I'm not seeing a reasonable way to disconnected the FPGA while leaving the rest intact. However, I did move the signal to another wire in the ribbon cable and the problem is basically gone. This lets me move on with other issues but am still a bit puzzled with this one.
Re: Cross-talk square-wave?
And I think this picture is the smoking gun. http://pdp10.froghouse.org/qsic/pic_24_2.gif Again, the bottom trace is the CS signal in question and the upper trace is now one of the QBUS DAL lines (after the bus transceiver and level converter) that's running across the ribbon cable near the CS signal. It does appear that induction can make a fairly clean square wave. Well, the purpose of a prototype is to learn and this has been one learning experience after another.
Re: Cross-talk square-wave?
> There are few things that come to mind here. The op seemed to indicate the > lines are terminated. If they are not terminated in the characteristic > impedance of the source and the transmission line, it is very unlikely he > would be seeing nice square waves at either end. The reflections would > distort the square wave. Given the reported squareness and that the op > indicates terminated line, I do not think impedance mismatch is the issue > here. There's certainly some ringing there but it's not the spike followed by an exponential decay that I'd expect from an induced signal. However, maybe I just don't know what an induced signal can look like so that's the question. > I also agree that an induced current in an adjacent line would not be square. > So I agree with the op's thoughts that this signal is getting on this line in > some other fashion, I don't believe this is an issue of cross talk. However, > some pictures of some waveforms would be interesting to see Ask and receive. See: http://pdp10.froghouse.org/qsic/pic_24_1.gif The bottom signal is the one in question and the top signal is the clock I'm sending to the SD card (which isn't plugged in at this time). I wanted to see if it was the clock single I was seeing coupled here and it's obviously not, though you can clearly see the clock inducing some noise in the CS signal. The other thing I'm seeing from this trace that I hadn't really noticed before is that 0 is not 0. The 0 for the bottom trace is where the 2 is on the left side. This line is suppose to be going from the 270k resistor to ground on one side across the ribbon cable to an FPGA pin which is set to high-impedance on the other. Clearly something else is going on here.
Re: Cross-talk square-wave?
> 270k seems like a rather strange value, it certainly can't be a termination > and it isn't a plausible pulldown either. The SD spec should explain what is > expected; I knew it at one time but forgot by now. I'll agree that 270k is a strange value. The idea is that the SD card contains an internal 50k pull-up on that line (dat[3]) so if you put a 270k pull-down on the board then you can use it for card detection. It's a little funky and I wish I'd just gone with an SD socket that had a card-detect switch but this is supposed to work too. The 1V square pulse, whereever it's coming from, is just enough that I'm detecting the card presence when there's no card plugged in yet. I can work around this in various ways but I want to understand it well enough that I'm sure I'm not ignoring a problem that's going to bite when we go to a production board. In other words, if it's simply a result of the silly ribbon cable, then I'm happy for now with a work-around.
Re: Cross-talk square-wave?
> 1v across 270K represents 3.7 microamps, which isn't much, particularly > at 25MHz. (I assume that you're using SPI to access the card, but the > observation still holds). Yup, I'm planning to use the SD card in SPI mode (at least for now). And this line is the CS/CD line, so it's not even running at 25MHz. And as Noel pointed out, this is happening without the SD card even being plugged in. I'm not surprised at cross-talk, I'm surprised that the cross-talk appears so clean. It's not spikes but fairly clean, 1V square pulses. > And if you're using SPI, have you installed > pullups on unused pins? Yup, I put in all the pull-ups. > I'd go to interleaved ground cable or UTP for the device. Also, make > sure that your 3.3V supply is adequately decoupled--an SD card can draw > somewhere n the neighborhood of 100ma when operating, if the datasheets > are to be believed. I use a separate 3.3V LDO regulator at the SD card > socket. Good point. I really should have put a good decoupling cap nearby and the production card should have its own regulator.
