SMS Data Gathering App Announcement

[Jay Jaeger]

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