Microsoft open sources GWBASIC
Seems of interest. Will be interesting to play with. https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/
Re: 2.11bsd unix resolver
On Solaris it’s the “hosts” line in the /etc/nsswitch.conf/ file. Perhaps something similar in BSD. Sent from Mail for Windows 10
Re: Nova BASIC paper tape image
G'day Camiel - I will contact you off list - Bruce Ray Wild Hare Computer Systems, Inc. Boulder, Colorado USA b...@wildharecomputers.com ...preserving the Data General legacy: www.NovasAreForever.org On 5/21/2020 7:48 AM, Camiel Vanderhoeven via cctech wrote: Does anyone have an image of the BASIC interpreter paper tape for the DG Nova?
Re: (V)HDL Toolsets
On 5/21/2020 5:37 PM, Jon Elson wrote: Windows should be trivial, just read the release notes on what systems it is compatible with. I must have miscommunicated. I have Xilinx ISE WebPack installed and running. I was asking about getting the Lattice toolchain up and running, which programming cable to get, and suggestions for a test board for Lattice. -- Jim Brain br...@jbrain.com www.jbrain.com
Re: Keyboard inverters/converters for terminals
On Thu, May 21, 2020 at 10:20 AM Eric Smith via cctalk < cctalk@classiccmp.org> wrote: > IMNSHO, there's a special place in hell reserved for those who have > designed equipment to (ab)use modular connectors other than for telephone > lines and 10BASEx Ethernet, and I really think a better connector should > have been chosen for 10BASEx. > The whole concept of "if the plug fits, it will at least not blow up" is kind of a late invention. And I'm amazed when this actually holds true in situations where I wouldn't quite expect that to be the case (e.g. all those electrically not quite compatible PCI/PCI-X/PCIe variants that have coded notches to prevent you from frying your computer/card. Except that you can stick a PCI card backwards into a PCIe slot) DEC using MMJ may get a pass because they at least attempted to prevent > connecting the wrong stuff together. > Any ideas why it took so much longer for keyboard interfaces to converge than most other peripherals? Display interfaces, HDDs/floppies/tapes etc., serial ports, and even mice converged on only a few variants more or less the moment they became commonplace. I'd really like some first hand insight into why anyone would want to invent a new interface/protocol from scratch every time they start developing a new machine (I'm mostly talking about the "simple async serial protocol sending up/down events" kind). Luckily there are only 12 different ways to wire a 4P4C, but there exist way more incompatible keyboards using that connector. Is it really easier to develop an incompatible serial keyboard interface from scratch than to re-use one that already exists? [actually, I kinda know, because of course it's easier to do a one-off and not care about documentation, licensing, extensibility, or forwards/backwards compatibility]
Re: (V)HDL Toolsets
On 05/21/2020 12:42 PM, Jim Brain via cctalk wrote: On 5/21/2020 12:24 PM, Eric Smith via cctalk wrote: On Thu, May 21, 2020 at 10:07 AM Jon Elson via cctalk wrote: (I also use Coolrunner II and XC9500XL devices in some of my products.) I used to use XC9500XL series (mostly XC9572XL) quite a bit, but I have switched to Lattice LC4000ZE series because they are less expensive and lower power, and (like the XC9500XL) have 5V tolerant inputs. I'm not thrilled with having to use yet another different toolset, but c'est la vie. Is it possible for you or someone to post about how to get an environment up and running in Windows and/or Linux? (or link to one you used?) Windows should be trivial, just read the release notes on what systems it is compatible with. Linux generally will install on many OS variants, even if not the specific ones Xilinx says are supported. They have an install script that tells you if other packages need to be installed. The only tricky area is to support certain download/debug "cables". I had a HELL of a time getting a Digilent pod to work at work. But, I bought a (probably clone) Xilinx Platform Cable USB and it worked pretty much right away on my home system. I only do smaller FPGAs, such as XC3S50A, but the last versions of ise support much higher-end chips. Xilinx changed the built-in serial PROM on the XC3S50AN, and that requires a patch file to be used instead of the default. Otherwise, it all just works under Linux as expected. Ise ver. 10 cannot be run on a 64-bit system, due to export controls. It should be able to be hacked, but i couldn't get it to work. Later versions seem to install fine on 64-bit OS's. Jon
Re: (V)HDL Toolsets
> On May 21, 2020, at 3:56 PM, Jay Jaeger wrote: > > On 5/21/2020 11:55 AM, Paul Koning wrote: >> >> ... >> This sort of question is why I found starting with the simulator is helpful. >> In a simulation you can specify delays directly. So for my 6600, I have >> the gate delay (5 ns) and the wire delays (1.3 ns per foot, in the twisted >> pair, or 25 ns for coax cables including tx/rx circuit). Actually, I only >> include wire delays for "long" wires; the design clearly uses wires longer >> than needed in various places for delay reasons, but my guess is that short >> wires are not time sensitive. That may be wrong; I need to run it again >> without that assumption to see if it helps. > > I do indeed plan on starting with simulation - just not for that reason. > Its just easier to debug then the FPGA proper. ;) > > I suppose I could figure out the actual wire list, and thus wire > lengths, but it would be have to be limited only to inter-panel wires, > and even that much would be painful and very time consuming. But yeah, > it makes sense to model gate delays in a general way and then perhaps > lower them to see what happens at higher speeds, as you suggest below. As I said, for most machines it is not likely to be useful to model wire lengths. For the 6600, it is mandatory, and obvious from the design files: when you see a 96 inch wire connecting two modules one inch apart, you know there is a reason why that wasn't a 4 inch wire instead. Not to mention when "adjust to get x ns pulse" shows up in an annotation. One good example of this is the master clock oscillator. In most 6600s it's a 10 MHz crystal clock, but in the first 7 units built, it's a 4 stage ring oscillator, with 96 inch wires to produce 25 ns delay between the four main phases. The later version gets rid of the ring oscillator, but retains the four buffers with wire delays, as n * 25 ns phase shifters. If I were working on, say, a PDP-11, I wouldn't expect to have to deal with any of this sort of craziness. But a 6600 is at, if not over, the hairy edge of possible speed for when it was built. Even the peripheral processors are well optimized, so they can run many of their instructions in 1 microsecond -- which is the memory cycle time. Fetching and executing a new opcode every cycle is a pretty hard task. The PPUs are actually pipelined, though the descriptions you'll read about them don't make this clear at all. Come to think of it, another nice optimization example is the process context switch, which in the 6000 series is a single instruction -- 16 read/modify/write core memory cycles 100 ns apart, so the whole thing including pipeline drain and restart takes 3 or so microseconds. Watching that in simulation is fun. paul
Re: (V)HDL Toolsets
On 5/21/2020 11:55 AM, Paul Koning wrote: > > >> On May 21, 2020, at 12:21 PM, Jay Jaeger wrote: >> >> On 5/21/2020 9:51 AM, Paul Koning wrote: >>> >> ... >>> If the timing in your machine is reasonably sane and has enough margin, the >>> simulation should be painless and synthesis should produce few issues. If >>> you have bits that are sensitive to wire or circuit delays, that's >>> different. Unfortunately, the 6600 is utterly infested with such issues, >>> to the point that it's hard to see how it ever worked at all -- the timing >>> documented in the manuals and implied by the wiring can't actually work. A >>> 1410 is probably better, especially considering that IBM had some senior >>> designers who had experienced timing pain first-hand and had learned to >>> avoid it. I'm thinking of people like Gerrit Blaauw (not sure if he was on >>> that project, though). >> >> There may be some such sensitivities, but I doubt there are many - the >> 1410 was not a fast machine by any stretch of the imagination. >> Actually, the situation I am most concerned about in that department is >> that the FPGA signals will propagate faster than the original, so a >> signal might change state too quickly as compared to the original. > > This sort of question is why I found starting with the simulator is helpful. > In a simulation you can specify delays directly. So for my 6600, I have the > gate delay (5 ns) and the wire delays (1.3 ns per foot, in the twisted pair, > or 25 ns for coax cables including tx/rx circuit). Actually, I only include > wire delays for "long" wires; the design clearly uses wires longer than > needed in various places for delay reasons, but my guess is that short wires > are not time sensitive. That may be wrong; I need to run it again without > that assumption to see if it helps. I do indeed plan on starting with simulation - just not for that reason. Its just easier to debug then the FPGA proper. ;) I suppose I could figure out the actual wire list, and thus wire lengths, but it would be have to be limited only to inter-panel wires, and even that much would be painful and very time consuming. But yeah, it makes sense to model gate delays in a general way and then perhaps lower them to see what happens at higher speeds, as you suggest below. > > Once the design works that way, I can then see what would happen in > synthesis, by replacing the original stage and wire delays by much smaller > values. Any place where that breaks things needs an explicit register > inserted to replace the wire "register". I know there will be a bunch of > those, hopefully hundreds and not tens of thousands. I hope not to introduce any delays not present in the original. Instead I do plan to insert D flip flops anywhere there is a combinatorial loop. > > For more sane machines like a 1410 or an EL-X8, the same approach lets you > determine whether there is any timing sensitive stuff in the design. If not, > then changing the model delays from "original" to "very fast" would break > nothing. If so, turning off the delays gives you a synthesizable design, or > very nearly one. > > paul > > JRJ
Re: Nova BASIC paper tape image
I have uploaded somewhere a star trek for Data General if anyone finds this. The listing is mostly source, but some binary content. On 5/21/2020 6:48 AM, Camiel Vanderhoeven via cctalk wrote: Does anyone have an image of the BASIC interpreter paper tape for the DG Nova?
Re: (V)HDL Toolsets
I call complete BS on Bunnie Huang's notion that both the way the HDL module is written and the lack of area optimization is due to some nefarious intent to sell bigger silicon by Xilinx. I'm really not a fan of that guy so maybe my glasses are tinted anti-rose. But the design of large HDL modules like their DDR controller and PCI Express cores are written to be as flexible as possible to the largest set of applications. People code 'code' and thus it is always subject to design over-sights and mistakes. Actually Lattice has some of the most bloated and abstracted code I've seen from the bigger 4 vendors. The lack of a compile time flag to turn off the sub-bridge was most likely an oversight. Xilinx and Intel/Altera's main customer base are large customers that buy expensive chips. Their canned IP is always going to be designed for those larger applications first. He also makes the assertion Vivado declined to optimize out that sub-module when all it's inputs were at deterministic levels. I find that impossible to believe. IMPOSSIBLE. The tools just don't do that. It's 1000 times more likely there was a path in the code that he missed that was causing a logic inference that cascaded throughout that module. Yet he immediately jumped to the conclusion Xilinx was just after more money - the main reason I think that guy is a class A tool. I'm a fan of the FOSS toolchains for Lattice ice40 and ESP5 parts myself. But not for the reasons you argue. We can arm-wrestle over it later. -A On 2020-05-21 09:23, David Kuder via cctalk wrote: I've taken to using parts supported by the open source toolchains & IP, that mostly limits me to using Lattice parts, but the efficiencies obtained from not instancing all the extra garbage from a vendor's IP library is worth it. When you use the vendor tools, they want to waste as many gates as they can get away with so you buy larger more expensive parts. The open source toolchains optimize out stuff that would just get left dangling. https://www.bunniestudios.com/blog/?p=5018 gives a good overview of what this can look like and the NeTV2 is a project that uses the migen/litex toolchain well. On Thu, May 21, 2020, 7:34 AM Sytse van Slooten via cctalk < cctalk@classiccmp.org> wrote:
Re: (V)HDL Toolsets
On 2020-05-21 07:34, Sytse van Slooten via cctalk wrote: > One of the things I’ve done with my pdp11 vhdl from the start is that I’ve > not used any vendor specific constructs or language extensions. That’s > probably the only design decision that I’m still really happy about - it > allows me to change to another vendor and another tool chain at will. That's actually VERY important! There is always a way, to get around the vendor specifics, and actually, all three (altera/lattice/xilinx) got better over time, to figure what you actually like to do (inferring RAM/ROM/Tables etc.). So using the vendor specific stuff, gets you the last ns squeezed out of the design, but in most cases it isn't necessary. However, in some cases, you can't get around (DDR3/DDR4/etc) it is simpler to use the Macros/Wizard to do. And, just look around, there are some open projects, which use all three in them, so you can learn a lot, how to hide the differences ... Personally, I like to play with all of them, also to be able to compare chips & tool chain. (made some carrier boards, and plug in little modules, which just contain the FPGAs on them, to be able to easier exchange them) Cheers!
Re: (V)HDL Toolsets
On 5/21/2020 12:24 PM, Eric Smith via cctalk wrote: On Thu, May 21, 2020 at 10:07 AM Jon Elson via cctalk wrote: (I also use Coolrunner II and XC9500XL devices in some of my products.) I used to use XC9500XL series (mostly XC9572XL) quite a bit, but I have switched to Lattice LC4000ZE series because they are less expensive and lower power, and (like the XC9500XL) have 5V tolerant inputs. I'm not thrilled with having to use yet another different toolset, but c'est la vie. Is it possible for you or someone to post about how to get an environment up and running in Windows and/or Linux? (or link to one you used?) I use xc9500xl parts with IDE 14.7 on Win10 x64 (with DLL fix) here, and the environment works well. But, I have a few things that I would love to fix/address: * CPLD work goes fine with the fix, but the FPGA toolchain portions of ISE won't work in Windows 10, even with the DLL fix (at least for me). I'd like to fix this, as some of my designs are too big for xc95288xl. * Alan Hightower praises the open source toolchains and Lattice units, but my initial attempt to bring up a working environment here went down in flames. I think I need a step-by-step guide (and maybe someone who has time to help a poor soul get something up and running) * As much as I like the GUI, I want to learn how to write (or beg/borrow/steal) Makefile-based tooling for all my CPLD projects, whether Xilinx or other. All my existing CPLD work is online: https://github.com/go4retro/ , warts and all. Jim -- Jim Brain br...@jbrain.com www.jbrain.com
Re: (V)HDL Toolsets
On 5/20/2020 8:22 PM, Jay Jaeger via cctech wrote: As I wrote in my last post, but write here for use as a separate thread: I'd be interesting in hearing from folks what toolsets they have used for HDL (VHDL in particular). I started with Xilinx ISE and then graduated to Vivado for later chipsets - unfortunately, Vivado seems to be something of a dog, in terms of time to compile HDL and synthesize logic. JRJ I use ALTERA (now INTEL) as hobby and the AHDL programing language. What I found is compiling simple logic is no problem but real world problems tend to device specific to the FPGA brand like ram or rom memory and acessing said items. Things are not portable is if need a popup wizard to define some feature. Ben.
Re: (V)HDL Toolsets
On 5/21/20 11:27 AM, Jay Jaeger via cctalk wrote: > On 5/21/2020 11:22 AM, Jay Jaeger via cctalk wrote: >> On 5/21/2020 10:00 AM, Tom Uban wrote: >>> Paul, your project is super interesting. Is there a website where I can >>> track it? >>> >>> --tom >>> >> Mainly the github.com/cube1us/IBM1410SMS . >> >> I do have a website: www.computercollection.net . I do post there, but >> not often. >> >> JRJ >> > D'oh. Never mind. I'm not Paul, of cousre. ;) > > JRJ No worries. Your collection looks quite nice, matching mine with regard to PDP-11s in many ways. I never did anything with IBM machines, but old hardware is still interesting. Best, --tom
Re: SMS Data Gathering App Announcement
On 05/20/2020 10:40 PM, Jay Jaeger via cctech wrote: On 5/20/2020 9:27 PM, Jon Elson wrote: Umm, if it can take ALDs, then (maybe with some tweaking) it ought to be able to do the same for SLT and MST machines, too! That might get a few more people interested in the concept. Jon I doubt it would be easy based on a quick look at an 1130 (1131-C) ALD. OK, these are the sort of issues I expected would be encountered. But, there have been rumors of people trying to do gate-level reimplementations of 360s and 370s so accurate they would run diagnostics and FLT decks without squawks. Such a tool would make a project like that more approachable. But, yes, that's for somebody who wants to do such a project to make the conversion. (I tried to build a quasi-360 in 1981 or so. I built a 32-bit AMD 2903/2910 microcode engine with a Z-80 CP/M as front end and diagnostic console. I got that working at 125 ns cycle time for 2-address instructions, but then realized HOW MUCH work lay ahead before I could actually run a program on it, no less have an OS and peripherals on it. I still have it in my basement. See: http://pico-systems.com/stories/1982.html if interested. ) Jon
Re: (V)HDL Toolsets
I've taken to using parts supported by the open source toolchains & IP, that mostly limits me to using Lattice parts, but the efficiencies obtained from not instancing all the extra garbage from a vendor's IP library is worth it. When you use the vendor tools, they want to waste as many gates as they can get away with so you buy larger more expensive parts. The open source toolchains optimize out stuff that would just get left dangling. https://www.bunniestudios.com/blog/?p=5018 gives a good overview of what this can look like and the NeTV2 is a project that uses the migen/litex toolchain well. On Thu, May 21, 2020, 7:34 AM Sytse van Slooten via cctalk < cctalk@classiccmp.org> wrote: > If you’re targeting FPGA hardware (opposed to a design for a foundry, or a > design you want to run exclusively in a simulator), it is kind of > inevitable that you work with the toolchains that the hardware vendor > supplies. Would be nice if you could choose freely from competing > toolchains, but the hardware isn’t exactly open, so that’s not going to > happen. > > So basically what it comes down to is Quartus or Vivado. I’ve kind of > implicitly chosen Quartus, because the Altera based development boards tend > to be a lot nicer and cheaper than the Xilinx based stuff. I haven’t even > followed the upgrades from ISE to Vivado. > > Not sure if the level of doggyness is any different between those, it’s > more like getting to know the specific bugs and working around them. Can be > pretty annoying at times though. For instance, one of the things Quartus > doesn’t get is that if source files are changed, it might make sense to > recompile - it only gets that if you change sources through its own editor. > Not really a big problem maybe, but it shows that the tools are far from > friendly. > > One of the things I’ve done with my pdp11 vhdl from the start is that I’ve > not used any vendor specific constructs or language extensions. That’s > probably the only design decision that I’m still really happy about - it > allows me to change to another vendor and another tool chain at will. > > Cheers > Sytse > > > On 21 May 2020, at 04:22, Jay Jaeger via cctalk > wrote: > > > > As I wrote in my last post, but write here for use as a separate thread: > > > > I'd be interesting in hearing from folks what toolsets they have used > > for HDL (VHDL in particular). I started with Xilinx ISE and then > > graduated to Vivado for later chipsets - unfortunately, Vivado seems to > > be something of a dog, in terms of time to compile HDL and synthesize > logic. > > > > JRJ > > > >
Nova BASIC paper tape image
Does anyone have an image of the BASIC interpreter paper tape for the DG Nova?
Re: (V)HDL Toolsets
On 5/21/20 9:51 AM, Paul Koning via cctalk wrote: > >> On May 20, 2020, at 10:22 PM, Jay Jaeger via cctalk >> wrote: >> >> As I wrote in my last post, but write here for use as a separate thread: >> >> I'd be interesting in hearing from folks what toolsets they have used >> for HDL (VHDL in particular). I started with Xilinx ISE and then >> graduated to Vivado for later chipsets - unfortunately, Vivado seems to >> be something of a dog, in terms of time to compile HDL and synthesize logic. >> >> JRJ > I have been working, very slowly, on a project analogous to yours: a gate > level model of the CDC 6600 supercomputer. > > The source material for this is the wiring lists, which show the module > connections and also the module logic diagrams. I used the diagrams to > create gate-level models for each module, and ran the wire lists through OCR > to get the connections. Those are then run through a simple Python program > to generate the equivalent structural model. > > I wanted to start with simulation, and treat synthesis as a later step. So > rather than use any particular vendor tools I used GHDL. That works quite > nicely. Among other benefits, since it generates executable code (it's a GCC > front end) it can call C functions. In my case, the memory and I/O devices > are C models, which the VHDL code talks to. GHDL supports output to GTKwave > to let you see what it is doing. And, at least to some extent, you can use > GDB on it. I haven't done much of that. > > The whole process of going from wiring to VHDL is quite straightforward. > Getting the wire lists exactly correct takes some work partly because of OCR > errors and partly because there may be typos in the wire lists. Also in the > 6600 case, the wire lists are per chassis and they aren't all the same > revision of the product. :-( > > If the timing in your machine is reasonably sane and has enough margin, the > simulation should be painless and synthesis should produce few issues. If > you have bits that are sensitive to wire or circuit delays, that's different. > Unfortunately, the 6600 is utterly infested with such issues, to the point > that it's hard to see how it ever worked at all -- the timing documented in > the manuals and implied by the wiring can't actually work. A 1410 is > probably better, especially considering that IBM had some senior designers > who had experienced timing pain first-hand and had learned to avoid it. I'm > thinking of people like Gerrit Blaauw (not sure if he was on that project, > though). > > If you have delay-sensitive elements, that will probably require adding extra > stages to the logic, such as additional latches, to produce the required > sequencing with modern logic, which in turn may require extra clock phases. > Here too the 6600 is amazingly painful: I found myself with a 20-phase clock > to get even close to sane operation, in what is typically described as a four > phase clock design. > > Others have mentioned Verilog. I have no experience with that. I landed on > VHDL mostly by accident, because I wanted an open source simulator and GHDL > showed up. There may be open source Verilog simulators at this point, I'm > not sure. Avoiding Windows was also a requirement. > > paul > Paul, your project is super interesting. Is there a website where I can track it? --tom
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: (V)HDL Toolsets
On Thu, May 21, 2020 at 10:07 AM Jon Elson via cctalk wrote: > (I also use Coolrunner II and XC9500XL devices in some of my > products.) > I used to use XC9500XL series (mostly XC9572XL) quite a bit, but I have switched to Lattice LC4000ZE series because they are less expensive and lower power, and (like the XC9500XL) have 5V tolerant inputs. I'm not thrilled with having to use yet another different toolset, but c'est la vie.
Re: Keyboard inverters/converters for terminals
On Thu, May 21, 2020 at 9:37 AM Electronics Plus via cctalk < cctalk@classiccmp.org> wrote: > https://www.vecmar.com/products/search.asp > Type in keyboard > The first result allows a terminal keyboard to be used on a PS/2 port. > The second result allows a PS/2 keyboard to be used on a terminal. > >From the limited information available (almost none), it appears that they are selling passive adapters that work with ADDS 4000 terminals that use PS/2 protocol on a modular jack. As has been noted earlier in this thread, there are a huge number of computers that use modular plugs and jacks for keyboard interfaces, and there is NO standard for their electrical or protocol characteristics. Plugging in the wrong combination can result in damage to either or both devices. Even using the wrong modular cable can do that, because common 4P4C modular cables are wired with a flip (1 to 4, 2 to 3, etc), while modular cables for computers are sometimes (e.g. Macintosh 128/512/Plus) wired straight through (1 to 1, 2 to 2, etc.) IMNSHO, there's a special place in hell reserved for those who have designed equipment to (ab)use modular connectors other than for telephone lines and 10BASEx Ethernet, and I really think a better connector should have been chosen for 10BASEx. DEC using MMJ may get a pass because they at least attempted to prevent connecting the wrong stuff together.
Re: (V)HDL Toolsets
> On May 21, 2020, at 12:21 PM, Jay Jaeger wrote: > > On 5/21/2020 9:51 AM, Paul Koning wrote: >> > ... >> If the timing in your machine is reasonably sane and has enough margin, the >> simulation should be painless and synthesis should produce few issues. If >> you have bits that are sensitive to wire or circuit delays, that's >> different. Unfortunately, the 6600 is utterly infested with such issues, to >> the point that it's hard to see how it ever worked at all -- the timing >> documented in the manuals and implied by the wiring can't actually work. A >> 1410 is probably better, especially considering that IBM had some senior >> designers who had experienced timing pain first-hand and had learned to >> avoid it. I'm thinking of people like Gerrit Blaauw (not sure if he was on >> that project, though). > > There may be some such sensitivities, but I doubt there are many - the > 1410 was not a fast machine by any stretch of the imagination. > Actually, the situation I am most concerned about in that department is > that the FPGA signals will propagate faster than the original, so a > signal might change state too quickly as compared to the original. This sort of question is why I found starting with the simulator is helpful. In a simulation you can specify delays directly. So for my 6600, I have the gate delay (5 ns) and the wire delays (1.3 ns per foot, in the twisted pair, or 25 ns for coax cables including tx/rx circuit). Actually, I only include wire delays for "long" wires; the design clearly uses wires longer than needed in various places for delay reasons, but my guess is that short wires are not time sensitive. That may be wrong; I need to run it again without that assumption to see if it helps. Once the design works that way, I can then see what would happen in synthesis, by replacing the original stage and wire delays by much smaller values. Any place where that breaks things needs an explicit register inserted to replace the wire "register". I know there will be a bunch of those, hopefully hundreds and not tens of thousands. For more sane machines like a 1410 or an EL-X8, the same approach lets you determine whether there is any timing sensitive stuff in the design. If not, then changing the model delays from "original" to "very fast" would break nothing. If so, turning off the delays gives you a synthesizable design, or very nearly one. paul
Re: (V)HDL Toolsets
> On May 21, 2020, at 11:00 AM, Tom Uban wrote: > > On 5/21/20 9:51 AM, Paul Koning via cctalk wrote: >> >>> ... >> I have been working, very slowly, on a project analogous to yours: a gate >> level model of the CDC 6600 supercomputer. >> ... > Paul, your project is super interesting. Is there a website where I can track > it? Not a website, but you can see the source files on my Subversion server: svn://akdesign.dyndns.org/dtcyber/trunk -- the model code and tools are in the "vhdl" subdirectory. FYA, there's also a "spice" subdirectory, which contains my attempts at a model of the DD60 display console. It's not accurate enough yet, unfortunately. The 6600 model has working peripherals processors and display controller. The CPU doesn't work yet, I'm still debugging the instruction fetch machinery to get all the variations of branch timing right. It does start, though (the "exchange jump" instruction works). paul
Re: (V)HDL Toolsets
On 5/21/2020 11:22 AM, Jay Jaeger via cctalk wrote: > On 5/21/2020 10:00 AM, Tom Uban wrote: >>> >> Paul, your project is super interesting. Is there a website where I can >> track it? >> >> --tom >> > > Mainly the github.com/cube1us/IBM1410SMS . > > I do have a website: www.computercollection.net . I do post there, but > not often. > > JRJ > D'oh. Never mind. I'm not Paul, of cousre. ;) JRJ
Re: (V)HDL Toolsets
On 5/21/2020 11:07 AM, Jon Elson wrote: > On 05/20/2020 09:22 PM, Jay Jaeger via cctalk wrote: >> As I wrote in my last post, but write here for use as a separate thread: >> >> I'd be interesting in hearing from folks what toolsets they have used >> for HDL (VHDL in particular). I started with Xilinx ISE and then >> graduated to Vivado for later chipsets - unfortunately, Vivado seems to >> be something of a dog, in terms of time to compile HDL and synthesize >> logic. > Well, I don't use the latest, super fast FPGAs, I go for old standards > that are cheap. > Right now, I have ise 13.4 installed on Linux, it seems to be stable, > quite fast for the small FPGAs > I do, and doesn't complain about my coding style. I use mostly Spartan > 3 in the > XC3S50A(N) sizes. I've done some units with 32-bit counters running at > 150 MHz with plenty > of margin left, that's fast enough for me. I only use VHDL, although I > can read Verilog. > (I also use Coolrunner II and XC9500XL devices in some of my products.) > > Jon Yes, ISE was much better than Vivado, but doesn't support the chip on my Nexys4 Xilink development board. I do have ISE running with the requisite DLL fixup. JRJ
Re: (V)HDL Toolsets
On 5/21/2020 10:00 AM, Tom Uban wrote: >> > Paul, your project is super interesting. Is there a website where I can track > it? > > --tom > Mainly the github.com/cube1us/IBM1410SMS . I do have a website: www.computercollection.net . I do post there, but not often. JRJ
Re: (V)HDL Toolsets
On 5/21/2020 9:51 AM, Paul Koning wrote: > > >> On May 20, 2020, at 10:22 PM, Jay Jaeger via cctalk >> wrote: >> >> As I wrote in my last post, but write here for use as a separate thread: >> >> I'd be interesting in hearing from folks what toolsets they have used >> for HDL (VHDL in particular). I started with Xilinx ISE and then >> graduated to Vivado for later chipsets - unfortunately, Vivado seems to >> be something of a dog, in terms of time to compile HDL and synthesize logic. >> >> JRJ > > I have been working, very slowly, on a project analogous to yours: a gate > level model of the CDC 6600 supercomputer. I recall you mentioning that along the way. You have my sympathy and empathy. ;) > > The source material for this is the wiring lists, which show the module > connections and also the module logic diagrams. I used the diagrams to > create gate-level models for each module, and ran the wire lists through OCR > to get the connections. Those are then run through a simple Python program > to generate the equivalent structural model. > > I wanted to start with simulation, and treat synthesis as a later step. So > rather than use any particular vendor tools I used GHDL. That works quite > nicely. Among other benefits, since it generates executable code (it's a GCC > front end) it can call C functions. In my case, the memory and I/O devices > are C models, which the VHDL code talks to. GHDL supports output to GTKwave > to let you see what it is doing. And, at least to some extent, you can use > GDB on it. I haven't done much of that. > My eventual plans for I/O devices is to use one of the various serial busses for that, talking to additional FPGAs or even microcontrollers. > The whole process of going from wiring to VHDL is quite straightforward. > Getting the wire lists exactly correct takes some work partly because of OCR > errors and partly because there may be typos in the wire lists. Also in the > 6600 case, the wire lists are per chassis and they aren't all the same > revision of the product. :-( > Again, I sympathize and empathize. I am in the same boat with the IBM 1410. I was a little naive when I picked through the materials to decide what to take to scan, and time was limited. The 1410 had an "accelerator" feature. Most of the pages I have are for that version, but not all of them (and my reports pick up on some issues that result from that.) Worse, I have a few missing pages, where I'll just have to hand code something based on the CE Instructional materials and lessons learned when I wrote my simulator. > If the timing in your machine is reasonably sane and has enough margin, the > simulation should be painless and synthesis should produce few issues. If > you have bits that are sensitive to wire or circuit delays, that's different. > Unfortunately, the 6600 is utterly infested with such issues, to the point > that it's hard to see how it ever worked at all -- the timing documented in > the manuals and implied by the wiring can't actually work. A 1410 is > probably better, especially considering that IBM had some senior designers > who had experienced timing pain first-hand and had learned to avoid it. I'm > thinking of people like Gerrit Blaauw (not sure if he was on that project, > though). There may be some such sensitivities, but I doubt there are many - the 1410 was not a fast machine by any stretch of the imagination. Actually, the situation I am most concerned about in that department is that the FPGA signals will propagate faster than the original, so a signal might change state too quickly as compared to the original. I took a course in semiconductor physics from Prof. Henry Guckel at U. Wisconsin. He described working for IBM on some really fast machines (like the 360/95, I think).He described pulling their hair out (and he didn't have much left) where they would add some delays in places to make timing work, and by the time they were done with that effort, the result was the machine ran more slowly than it did with a slower system clock. > > If you have delay-sensitive elements, that will probably require adding extra > stages to the logic, such as additional latches, to produce the required > sequencing with modern logic, which in turn may require extra clock phases. > Here too the 6600 is amazingly painful: I found myself with a 20-phase clock > to get even close to sane operation, in what is typically described as a four > phase clock design. Fortunately the 1410 seems to be much much simpler, and largely asynchronous. It has at most two phases: the main 1.5 MHz (well, on the ALD 1.5 MC ;) ) clock and one that is delayed a bit in order to make one trigger work correctly. After that there is just the main clock pulse stream, and a 2nd one that is 180 degrees out of phase. > > Others have mentioned Verilog. I have no experience with that. I landed on > VHDL mostly by accident, because I
Re: (V)HDL Toolsets
On 05/20/2020 09:22 PM, Jay Jaeger via cctalk wrote: As I wrote in my last post, but write here for use as a separate thread: I'd be interesting in hearing from folks what toolsets they have used for HDL (VHDL in particular). I started with Xilinx ISE and then graduated to Vivado for later chipsets - unfortunately, Vivado seems to be something of a dog, in terms of time to compile HDL and synthesize logic. Well, I don't use the latest, super fast FPGAs, I go for old standards that are cheap. Right now, I have ise 13.4 installed on Linux, it seems to be stable, quite fast for the small FPGAs I do, and doesn't complain about my coding style. I use mostly Spartan 3 in the XC3S50A(N) sizes. I've done some units with 32-bit counters running at 150 MHz with plenty of margin left, that's fast enough for me. I only use VHDL, although I can read Verilog. (I also use Coolrunner II and XC9500XL devices in some of my products.) Jon
Re: (V)HDL Toolsets
On 5/21/2020 7:41 AM, Peter Corlett via cctalk wrote: > On Thu, May 21, 2020 at 01:34:09PM +0200, Sytse van Slooten via cctalk wrote: > [...] >> So basically what it comes down to is Quartus or Vivado. I’ve kind of >> implicitly chosen Quartus, because the Altera based development boards tend >> to be a lot nicer and cheaper than the Xilinx based stuff. I haven’t even >> followed the upgrades from ISE to Vivado. > > My understanding from when I was looing at FPGAs in ~2013 is that Xilinx make > better FPGAs than Altera (now Intel), but Altera's tools are better. Having > had > the "joy" of using Altera's Quartus, I dread to think how terrible ISE must > be. >>From a cursory check, Vivado appears to be just an rebranded newer version of > ISE rather than a fundamental change. ISE isn't/wasn't so bad, performance-wise. Vivado has been painful. > > Quartus puts me in mind of the dark days of the 1980s with its expensive, > closed-source, and generally shoddy software development environments before > GNU came along and wiped them out. Good riddance do the lot of them. > > Even the HDLs themselves are stuck in the 1980s. Verilog is described as being > C-like, but that's not exactly a compliment. VHDL is Ada-like or Pascal-like, > i.e. designed by a committee and/or academics who have definite opinions about > how other people should write code, but don't do much of it themselves. The design of my application is such that it should not be difficult to adapt it to generate whatever kind of HDL one might want. I learned both Verilog and VHDL along the way, using the Mano/Kime book "Logic and Computer Design Fundamentals" - it was a coin flip which I decided to work with first. (Prof. Charles Kime was my adviser when I was an ECE student in the early 1970's). > > There are at least finally some open-source HDLs banging about which have > incorporated useful ideas from the last four decades of language design and > thus be easier to create correct code. (Thich is a crucial difference from > "easier to create something which runs", which is C/Verilog's schtick.) > Unfortunately, because of the lack of documententation on the FPGA bitstreams, > the best they can do is be a source-to-source translator piped into the > proprietary tooling. > That's an interesting idea for later, maybe. Thanks. JRJ
Re: SMS Data Gathering App Announcement
On 5/21/2020 7:38 AM, ste...@malikoff.com wrote: > Jay said >> The application was/is developed in C# under Visual Studio 2017 to run >> under Windows, primarily because I was interested in trying out C#. I >> would expect it to build in VS 2019 with little or no change, but have >> not tried it. > > It builds under VS2019 but I needed to add the Nuget package for MySql.Data > to fix the references up, and also changed the connection string a little. > Thanks for doing that. Good to hear! Yeah, the connection info should probably really be in little flat ini file somewhere. > I also should have looked at the contents of the directory a little more > closely as I did not see the .sql.gz there initially, and ended up converting > the proprietary LarryWare .mwb file to .sql and then wondering why there was > no > example data when I ran it.. > "LarryWare". ;) Chuckle. Hadn't heard that one before. BTW, that is more than just an "example". That database is an up to date snapshot of the actual database I am working with (for machine 1411). I take a new snapshot whenever I change the database design (typically these days only to add columns or tables.) The other stuff is just junk for safely testing. > After noticing the compressed db, unzipped and scripted it in and it all > loaded > up. The importing is a bit flaky for one or two types but wow, what an amazing > project, that is a huge amount of work you've put into it! I guess one day it > could be extended to cover SLT too???!!! :) Yes, the imports are shaky, and the spreadsheet data has not been updated as I have corrected errors in the data. I have fixed up a few things in the import code as I came across them, but for sure one would want to back up the database before using them. ;) There was a separate discussion of SLT. It would take time, but probably not impossibly long. I am very unlikely to undertake the effort, though. > > Great job Jay. > Thanks. > Steve > JRJ
Re: (V)HDL Toolsets
On 5/21/2020 6:45 AM, emanuel stiebler wrote: > On 2020-05-20 22:22, Jay Jaeger via cctalk wrote: >> As I wrote in my last post, but write here for use as a separate thread: >> >> I'd be interesting in hearing from folks what toolsets they have used >> for HDL (VHDL in particular). I started with Xilinx ISE and then >> graduated to Vivado for later chipsets - unfortunately, Vivado seems to >> be something of a dog, in terms of time to compile HDL and synthesize logic. > > I feel your pain ;-) > > To deal with the ISE<->Vivado speeds, we always chose a target which is > supported on both. One of the reasons, I have the artix7-100 on all my > boards, makes life much easier. > Then just use ISE for the "quick around" time, and vivado for the tough > stuff. > That's a great suggestion. Fortunately, I do have experience with the DLL fix for ISE, which they no longer support, so I can run ISE if I want to. And, hey, if the design fits, I even have an older Nexsys 2 to fit it to. > Vivado was pretty much useless in the first revisions, but now it is at > a stage, where it is really usable. Yes, it is slow :( Even that confirmation is helpful. ;) > On the other hand, the simulator in Vivado got much better, and works > for both, Verilog & VHDL, and also in mixed mode, which helps a lot. > > And it is tough to complain about a free tool, which runs on Linux & Win ... > As a hobbyist, I agree. If I were doing this stuff professionally, in quantity, I'd be all over them like a wet blanket just from a standpoint of lost productive time. I suspect that if either one, Intel/Altera or Xilinx came up with a substantially more productive toolchain, it could move the needle on market share. > A lot of guys I know, use also GHDL for simulations, if command line is > your thing. > I have seen that suggestion from another correspondent on the list as well, and I think it is a good one, likely to save lots of time. I don't mind command lines - I go all the way back through UNIX 6th edition to card decks. ;) Thanks. JRJ
Re: (V)HDL Toolsets
Helpful tips - I agree with avoiding vendor extensions. Thanks. I seem to recall some issues regarding edits inside vs. outside Vivado as well, but it has been more than a year, so the recollection is fuzzy. JRJ On 5/21/2020 6:34 AM, Sytse van Slooten wrote: > If you’re targeting FPGA hardware (opposed to a design for a foundry, or a > design you want to run exclusively in a simulator), it is kind of inevitable > that you work with the toolchains that the hardware vendor supplies. Would be > nice if you could choose freely from competing toolchains, but the hardware > isn’t exactly open, so that’s not going to happen. > > So basically what it comes down to is Quartus or Vivado. I’ve kind of > implicitly chosen Quartus, because the Altera based development boards tend > to be a lot nicer and cheaper than the Xilinx based stuff. I haven’t even > followed the upgrades from ISE to Vivado. > > Not sure if the level of doggyness is any different between those, it’s more > like getting to know the specific bugs and working around them. Can be pretty > annoying at times though. For instance, one of the things Quartus doesn’t get > is that if source files are changed, it might make sense to recompile - it > only gets that if you change sources through its own editor. Not really a big > problem maybe, but it shows that the tools are far from friendly. > > One of the things I’ve done with my pdp11 vhdl from the start is that I’ve > not used any vendor specific constructs or language extensions. That’s > probably the only design decision that I’m still really happy about - it > allows me to change to another vendor and another tool chain at will. > > Cheers > Sytse > >> On 21 May 2020, at 04:22, Jay Jaeger via cctalk >> wrote: >> >> As I wrote in my last post, but write here for use as a separate thread: >> >> I'd be interesting in hearing from folks what toolsets they have used >> for HDL (VHDL in particular). I started with Xilinx ISE and then >> graduated to Vivado for later chipsets - unfortunately, Vivado seems to >> be something of a dog, in terms of time to compile HDL and synthesize logic. >> >> JRJ >> >
Keyboard inverters/converters for terminals
https://www.vecmar.com/products/search.asp Type in keyboard The first result allows a terminal keyboard to be used on a PS/2 port. The second result allows a PS/2 keyboard to be used on a terminal. Not affiliated with seller, etc. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sa...@elecplus.com -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: (V)HDL Toolsets
> On May 20, 2020, at 10:22 PM, Jay Jaeger via cctalk > wrote: > > As I wrote in my last post, but write here for use as a separate thread: > > I'd be interesting in hearing from folks what toolsets they have used > for HDL (VHDL in particular). I started with Xilinx ISE and then > graduated to Vivado for later chipsets - unfortunately, Vivado seems to > be something of a dog, in terms of time to compile HDL and synthesize logic. > > JRJ I have been working, very slowly, on a project analogous to yours: a gate level model of the CDC 6600 supercomputer. The source material for this is the wiring lists, which show the module connections and also the module logic diagrams. I used the diagrams to create gate-level models for each module, and ran the wire lists through OCR to get the connections. Those are then run through a simple Python program to generate the equivalent structural model. I wanted to start with simulation, and treat synthesis as a later step. So rather than use any particular vendor tools I used GHDL. That works quite nicely. Among other benefits, since it generates executable code (it's a GCC front end) it can call C functions. In my case, the memory and I/O devices are C models, which the VHDL code talks to. GHDL supports output to GTKwave to let you see what it is doing. And, at least to some extent, you can use GDB on it. I haven't done much of that. The whole process of going from wiring to VHDL is quite straightforward. Getting the wire lists exactly correct takes some work partly because of OCR errors and partly because there may be typos in the wire lists. Also in the 6600 case, the wire lists are per chassis and they aren't all the same revision of the product. :-( If the timing in your machine is reasonably sane and has enough margin, the simulation should be painless and synthesis should produce few issues. If you have bits that are sensitive to wire or circuit delays, that's different. Unfortunately, the 6600 is utterly infested with such issues, to the point that it's hard to see how it ever worked at all -- the timing documented in the manuals and implied by the wiring can't actually work. A 1410 is probably better, especially considering that IBM had some senior designers who had experienced timing pain first-hand and had learned to avoid it. I'm thinking of people like Gerrit Blaauw (not sure if he was on that project, though). If you have delay-sensitive elements, that will probably require adding extra stages to the logic, such as additional latches, to produce the required sequencing with modern logic, which in turn may require extra clock phases. Here too the 6600 is amazingly painful: I found myself with a 20-phase clock to get even close to sane operation, in what is typically described as a four phase clock design. Others have mentioned Verilog. I have no experience with that. I landed on VHDL mostly by accident, because I wanted an open source simulator and GHDL showed up. There may be open source Verilog simulators at this point, I'm not sure. Avoiding Windows was also a requirement. paul
Re: (V)HDL Toolsets
On Thu, May 21, 2020 at 01:34:09PM +0200, Sytse van Slooten via cctalk wrote: [...] > So basically what it comes down to is Quartus or Vivado. I’ve kind of > implicitly chosen Quartus, because the Altera based development boards tend > to be a lot nicer and cheaper than the Xilinx based stuff. I haven’t even > followed the upgrades from ISE to Vivado. My understanding from when I was looing at FPGAs in ~2013 is that Xilinx make better FPGAs than Altera (now Intel), but Altera's tools are better. Having had the "joy" of using Altera's Quartus, I dread to think how terrible ISE must be. >From a cursory check, Vivado appears to be just an rebranded newer version of ISE rather than a fundamental change. Quartus puts me in mind of the dark days of the 1980s with its expensive, closed-source, and generally shoddy software development environments before GNU came along and wiped them out. Good riddance do the lot of them. Even the HDLs themselves are stuck in the 1980s. Verilog is described as being C-like, but that's not exactly a compliment. VHDL is Ada-like or Pascal-like, i.e. designed by a committee and/or academics who have definite opinions about how other people should write code, but don't do much of it themselves. There are at least finally some open-source HDLs banging about which have incorporated useful ideas from the last four decades of language design and thus be easier to create correct code. (Thich is a crucial difference from "easier to create something which runs", which is C/Verilog's schtick.) Unfortunately, because of the lack of documententation on the FPGA bitstreams, the best they can do is be a source-to-source translator piped into the proprietary tooling.
Re: SMS Data Gathering App Announcement
Jay said > The application was/is developed in C# under Visual Studio 2017 to run > under Windows, primarily because I was interested in trying out C#. I > would expect it to build in VS 2019 with little or no change, but have > not tried it. It builds under VS2019 but I needed to add the Nuget package for MySql.Data to fix the references up, and also changed the connection string a little. I also should have looked at the contents of the directory a little more closely as I did not see the .sql.gz there initially, and ended up converting the proprietary LarryWare .mwb file to .sql and then wondering why there was no example data when I ran it.. After noticing the compressed db, unzipped and scripted it in and it all loaded up. The importing is a bit flaky for one or two types but wow, what an amazing project, that is a huge amount of work you've put into it! I guess one day it could be extended to cover SLT too???!!! :) Great job Jay. Steve
Re: (V)HDL Toolsets
On 2020-05-20 22:22, Jay Jaeger via cctalk wrote: > As I wrote in my last post, but write here for use as a separate thread: > > I'd be interesting in hearing from folks what toolsets they have used > for HDL (VHDL in particular). I started with Xilinx ISE and then > graduated to Vivado for later chipsets - unfortunately, Vivado seems to > be something of a dog, in terms of time to compile HDL and synthesize logic. I feel your pain ;-) To deal with the ISE<->Vivado speeds, we always chose a target which is supported on both. One of the reasons, I have the artix7-100 on all my boards, makes life much easier. Then just use ISE for the "quick around" time, and vivado for the tough stuff. Vivado was pretty much useless in the first revisions, but now it is at a stage, where it is really usable. Yes, it is slow :( On the other hand, the simulator in Vivado got much better, and works for both, Verilog & VHDL, and also in mixed mode, which helps a lot. And it is tough to complain about a free tool, which runs on Linux & Win ... A lot of guys I know, use also GHDL for simulations, if command line is your thing.
Re: (V)HDL Toolsets
If you’re targeting FPGA hardware (opposed to a design for a foundry, or a design you want to run exclusively in a simulator), it is kind of inevitable that you work with the toolchains that the hardware vendor supplies. Would be nice if you could choose freely from competing toolchains, but the hardware isn’t exactly open, so that’s not going to happen. So basically what it comes down to is Quartus or Vivado. I’ve kind of implicitly chosen Quartus, because the Altera based development boards tend to be a lot nicer and cheaper than the Xilinx based stuff. I haven’t even followed the upgrades from ISE to Vivado. Not sure if the level of doggyness is any different between those, it’s more like getting to know the specific bugs and working around them. Can be pretty annoying at times though. For instance, one of the things Quartus doesn’t get is that if source files are changed, it might make sense to recompile - it only gets that if you change sources through its own editor. Not really a big problem maybe, but it shows that the tools are far from friendly. One of the things I’ve done with my pdp11 vhdl from the start is that I’ve not used any vendor specific constructs or language extensions. That’s probably the only design decision that I’m still really happy about - it allows me to change to another vendor and another tool chain at will. Cheers Sytse > On 21 May 2020, at 04:22, Jay Jaeger via cctalk wrote: > > As I wrote in my last post, but write here for use as a separate thread: > > I'd be interesting in hearing from folks what toolsets they have used > for HDL (VHDL in particular). I started with Xilinx ISE and then > graduated to Vivado for later chipsets - unfortunately, Vivado seems to > be something of a dog, in terms of time to compile HDL and synthesize logic. > > JRJ >
Re: SMS Data Gathering App Announcement
On 5/20/2020 9:27 PM, Jon Elson wrote: > On 05/20/2020 09:21 PM, Jay Jaeger via cctech wrote: > WOW, what a huge effort! It has definitely been time consuming. ;) >> I also spent quite a bit of time generalizing it, so that it will >> hopefully be usable (perhaps with some more fixes / enhancements / >> generalizing for most any SMS machine (IBM 1620, IBM 709x, IBM 1401 etc. >> etc. etc.) >> >> > Umm, if it can take ALDs, then (maybe with some tweaking) it ought to be > able to do the > same for SLT and MST machines, too! That might get a few more people > interested in the > concept. > > Jon I doubt it would be easy based on a quick look at an 1130 (1131-C) ALD. Some of the things I see: The card location chart is a lot different - how card slots are identified is different - the packaging is different. Pin names - while the database doesn't care, the application sort of presumes pin names with single or maybe two letters, but the SLT ones seem to be 3 characters (a letter and two digits). This might not be too hard to deal with. ALD grid layout. The SMS is a 5 x 8 grid. The SLT one is (at least) 7 x 13. This would affect a couple of the dialogs in a major way (plus the grid coordinates themselves. It would need to be scrollable and have a more complex coodinate system. Card slot identification is different. The SLT drawings have little triangles on the inputs and outputs in some cases, which I suspect are for inverting inputs and outputs. The SMS application has sort of a notion of an inverted output, but not inputs. SMS drawings always have logic blocks of the same size (but sometimes with an extension to another block below it.) The SLT for the 1130 at least has some double and triple sized blocks. At least the way signals enter and leave sheets is more or less the same. ;) (Had to find one positive thing, ya know. ) Page nomenclature is very different, but in most places the app just treats it as a plain old string. (11.10.20.1 vs KG111 for example). So "that's another thing we've got" to borrow from a popular song with a twist. There are probably fields that would need to be added to capture more sophisticated logic block information. I'd have to read a manual on SLT ALDs and packaging to really know what other issues there might be (and I am sure there are plenty), but I expect it would not be easy to do. Of one thing I am certain: I am not personally going to tackle that. ;) JRJ
Re: SMS Data Gathering App Announcement
On 05/20/2020 09:21 PM, Jay Jaeger via cctech wrote: WOW, what a huge effort! I also spent quite a bit of time generalizing it, so that it will hopefully be usable (perhaps with some more fixes / enhancements / generalizing for most any SMS machine (IBM 1620, IBM 709x, IBM 1401 etc. etc. etc.) Umm, if it can take ALDs, then (maybe with some tweaking) it ought to be able to do the same for SLT and MST machines, too! That might get a few more people interested in the concept. Jon
(V)HDL Toolsets
As I wrote in my last post, but write here for use as a separate thread: I'd be interesting in hearing from folks what toolsets they have used for HDL (VHDL in particular). I started with Xilinx ISE and then graduated to Vivado for later chipsets - unfortunately, Vivado seems to be something of a dog, in terms of time to compile HDL and synthesize logic. JRJ
SMS Data Gathering App Announcement
As some here probably know, I have been working the last couple of years working towards an FGPA gate-authentic replica of the IBM 1410 - the larger cousin to the IBM 1401. In 2018 I developed an application for gathering information of of ALDs and stuffing it into a MySQL database, then spent the rest of the year entering the information from the ALDs into the system, but I did not share that application or the data. Then I took a year off - it had been a grind. This year I took up the torch again. I put the application up on github, gave it the requisite GPL attributions, and started tracking my bugs, fixes and enhancements there, even though I am working alone. I fixed some of the warts, generalized it some, fixed a few bugs, added some database checking reports and data checking reports, and so on. I also spent quite a bit of time generalizing it, so that it will hopefully be usable (perhaps with some more fixes / enhancements / generalizing for most any SMS machine (IBM 1620, IBM 709x, IBM 1401 etc. etc. etc.) The application is available on github at: https://github.com/cube1us/IBM1410SMS The actual "root" source control is on my system at home using subversion. I use "git svn" to keep a git version in sync, and then push that to github. The application was/is developed in C# under Visual Studio 2017 to run under Windows, primarily because I was interested in trying out C#. I would expect it to build in VS 2019 with little or no change, but have not tried it. I could have used a more basic tool setup (say, C or C++ and a non-windows presentation layer), but I figured not all that many people would be interested in the thing, and the VS environment eased development quite a bit. I suspect it would work OK under WINE, but I have not tried doing so. There are also a couple of tools, one in Perl for generating database related classes from the database, and one in Python for checking for database referential integrity. ( was curious about Python, and this seemed a good candidate for an evaluation of it. It did, however reinforce my dislike for many things about Python. The application is comprised of two Visual Studio projects, one for the data gather app itself, the other a very very light weight database interface, that ought to make it not too hard to port it to a different DBMS. github also has a copy of the database, the MySQL Workbench data model (and a PDF print) and documentation in MS Word (and a PDF print). The code is not good. There, I said it. It is not truly OO at all. I didn't do much refactoring even when I saw common code or saw considerable potential to consolidate code. The downside of that is that there is lots of duplicate code. The upside is that you don't have to go umpteen layers deep in OO design to figure out what the darn thing does. Doesn't even use database views, though they probably would have been helpful. Just a bunch of tables. Lots of tables in a close but not fully relational model. The data gathered by the application in the database comprises about: 917 ALD (Automated Logic Diagram) 11" x 17" pages 10596 Logic Blocks on those pages (so average of 11.5 per page) 1281 DOT functions (Wired OR / AND) 14021 Inter-sheet signals (which appear on multiple sheets) 4222 Distinct inter-sheet signals 32746 Connections between the above items That connection number makes me shake my head - I had to enter each and every one of the darn things. Yeesh. Capturing all of that was between something like 600 and 1000 hours, maybe more (but not 2000 hours), after maybe 200 hours on the initial version of the application. My next phase is working hard on the part of the project that generates HDL for FPGA synthesis. I expect that to take many months as I synthesize, simulate with the tool set and figure stuff out. I'd be interesting in hearing from folks what toolsets they have used for HDL (VHDL in particular). I started with Xilinx ISE and then graduated to Vivado for later chipsets - unfortunately, Vivado seems to be something of a dog, in terms of time to compile HDL and synthesize logic. If folks find this interesting, and especially if they want to use it, I'd love to know about it. I intend to keep this a single-person effort, git-wise, but folks can feel free to fork (if anyone wants to bother ;) ), and let me know if they find anything seriously wrong. For what it's worth, my IBM 1410 cycle-level simulator for the IBM 1410 is also available, at: https://github.com/cube1us/1410
