A (late) Merry Christmas and an (early) happy new year y’all! Just a quick update: The AM-B404 production is well in schedule. Some already sold… so it might be smart to inform me right now, if you’re interested in buying one… or two.
All posts by Axel
Too poor for cheap tools
There’s a deep wisdom in one of my fathers favorite saying (posed every time we went into an home improvement store): “I’m too poor for cheap tools”.
I should have remember that, when I started to shopping for an EPROM programmer (or ‘burner’ as we call’em in Germany) in 2002. I started cheap with a simple, used Batronix Parallel Port programmer which very soon reached its limits not supporting PALs/GALs and mid-size EPROMs (27C020 to be precise) only, so I was again looking for a better programmer.
In 2006 the GALEP-4 seemed to be the wet dream of every device-programing nerd. While not totally high-end it was quite expensive (~400 Euro)… well “I’m too poor…” you know.
After 2 years it became obvious that especially vintage ICs (e.g PAL16L8) aren’t supported – honestly, why should they, who’s crazy enough to support EOL devices!?!!
Elnec is! Ok, the BeeProg series is really everything else than cheap but it’s worth every cent. While I thought the supported devices list of the GALEP was huge (6057), Elnecs list is a behemoth (85347 and counting).
And on top of that, there’s their free AlgOR (Algorithms On Request) service. If you have an unsupported device and some sort of specs/datasheet you can ship it to them and they’ll do their best to add your device-from-mars to the endless list.
I just used this service, and it just went great. For my AM-B404 TRAM I need to test quite some SRAMs from a “New-Old-Stock” source, which I don’t completely trust. While my BeeProg+ supports a wide range of SRAMs already, of all things these weren’t on the list. So I’ve sent two samples to Slovakia and a week later that type was included in the most recent release of their software!
So – if you’re into vintage hardware restauration – don’t waste time & money with half-hearted solutions. Even the price is steep, given their quality and service I’m very confident that this is the one and only programmer you’ll ever need. Period.
The first Transputer TRAM since 1995
Say hello to the brand new AM-B404, a 2MB, Size-1 Transputer TRAM. It wouldn’t be a Geekdot’ish device, if it hadn’t at least one LED 😉
Besides this, its using as-recent-as-possible parts, is fully SRAM (i.e. fast) and just half the size of the original Inmos counterpart (IMS-B404). Oh, and did I mention the 2 LEDs?
The AM-B404
Here it is, my latest baby, the goal I was aiming for since years (4 to be exact) – not only to get more TRAMs for my systems but also to break the insane price spiral developing in the last years on ePay and other places. >300$ for a TRAM is crazy. Do not pay that amount! Even $100 is too much.
Update: Final version finished! Click here or scroll down for more.
Update 2: You can buy one, if you like…
My first CPU TRAM called AM-B404 in reminiscence to the IMS-B404 which comes closest to its specs:
- Size-1 TRAM
- 2MB low-power SRAM
- 2 LEDs showing the Transputers status (running and error)
Well, the original Inmos B404 had 2MB DRAM, too (and additional 32k SRAM) but was a Size-2 TRAM and LEDs weren’t available on any Inmos TRAM… and we all know how important LEDs are! 😉 Contrary to the IMS-B404, the AM-B404 is low-profile, SRAM-only, so the whole RAM is accessed at 3-cycles vs. the IMS-B404 4-cycle DRAM.
Using a 6-layer PCB and all-modern SMD parts (well, as modern as 5V parts can get) the power consumption is a bit lower, too. I’d say about 100mA for the whole Board (no Transputer of course). Finally, there’s an easy access solder-bridge on the backside to set the CPU clock (20/25MHz).
This is just the 1st prototype. After thorough testing, I will optimize its layout a tiny bit and give it the proper shape of a TRAM. When that’s done, we’ll see how I can make you a realistic price offer.
UPDATE:
From Shenzen with love. The final PCB designes arrived and the first test went perfectly fine.
And here are the first 4 PCBs waiting to be finished with the Trough-Hole parts (i.e. Transputer Socket and TRAM Pins)… 100 solder-points in total… per TRAM. That’s quite a bit to solder :-/
Video
Finally, here’s a short video showing the prototype AM-B404 in action (running Helios on my Inmos B020). The “exciting” thing is the blinking green LED which shows the CPUs activity. There’s even some brief red LED access (error) during boot-up which is triggered by Helios scanning the Transputer network.
The bright blue LED to the left is the T2i2c TRAM, so all TRAMs on the B020 are built by me now 😉
Want one?
If you hate the greedy ePay prices like I do, drop me a mail. I might have some AM-B404 left… even with T425/T800 Transputers.
Can I have the schematics?
No, not yet. Sorry. I have to break-even on this first…
Since people discovered there’s serious money in the retro-scene, some ‘smart guys’ started to clone every PCB they can get their hands on and thereby steal the initial investment which the original creators made.
I sell them a bit over the price they cost me to produce. And trust me, you won’t be able to go lower than me:
It’s a 6 layer PCB. ENIG Gold.
Sadly SRAM did not get cheaper, really. Especially the (obsolete) 5V 512kx8 I’m using were lately discovered by other projects to be very convenient and so the battle for SRAM was on. If you’re lucky you might get one for 4€… and you need 4 of them.
The 16 pins used to connect the TRAM to its carrier are very special. You have to buy them by the 1000s – 0.15€ a pop… you do the math.
Flat is the new 3D
Ok, so we all had a close look at if there was a “one more thing” at WDCC. Well, not for me – but that’s a personal view.
Looking through my Yester-Tech pair of glasses, one thing caught my eye (pun intended ;)): OS X UI design is getting flatter (and flatter). It just struck me this time as I was just thinking how to get a more modern window manager running on Helios’ X11, which offers twm and mwm for now, looking like this:
Doh. That looks flat. And simple. But it just does its job: Manage windows (move, pop-over/under etc.). But from the beginning of UIs, everybody was looking left and right what Apple, SGI or even Microsoft did design-wise. And they were all trying hard to get a more 3D’ish look, mostly by using embossing and beveling.
So, at a time MacOS 7.x looked like this
Windows 95 tried to catch up (W98/NT/2k looked pretty much the same)
and the free fvwm was the free alternative to $$$ Motiv on X-Window:
Then came Mac OS X with its Aqua-look and all of the sudden spherical buttons, rounded corners and lolli-pop colors became a must-have. The original:
And the look-alikes from MS (Windows XP):
…and yet another X window manager (KDE this time):
After that hell broke loose and all sorts of crazy, mostly Hollywood inspired and supported by the capabilities of all those l33t 3D video-cards, 3D user interfaces hit the street web. Bumptop was one of many:
Then, slowly people recognized that while a UI might look cool, it might also be unusable or gives you a headache when using it for real work. So things cooled down and the clock went backwards.
With Windows 8 (and Windows Mobile following) UIs started to get flat again. And rectangular. Besides the “Windows 8 Modern UI” (aka Metro), even standard desktop windows and dialogs got pretty flat
And last but not least with iOS 7 and soon-to-be-released MacOS X 10.10 Apples UIs also will get flatter…
Am I the only one who feels “been there, done that”? Is flat the new 3D after it’s been very flat before?
Smoothing the Edges
Several sections and chapters got updated.
- Finally opened the Software section for Transputers and the i860 (DSM boards). More to come when I find the time…
- Updated the Parsytec GigaCluster with more details on cooling and more hardware pictures – as well as some tiny new findings on the SuperCluster NCU boards.
- Some Housekeeping, due to the fact that Helios is becoming a bigger matter on GeekDot it was moved from a chapter to a full fledged section.
- Finally! Running X Window on Helios described… there’s even a screenshot 😉
- Small but adorable addition to the INMOS TRAM section – the mighty IMSB438, the ultimate graphics TRAM!
- Hauppauge 4860 manual added for downloading… nice read even you’re not in the owners club. Also I found a better piccy of the original framebuffer.
Helios – Back from the dead!
To start celebrating this years 30th anniversary of the Transputer, what else would be a nice present than reviving THE Transputer OS of that time?!
It’s here: Project “Helios NextGeneration” officially went public. Get the sources from github and join reviving a classic.
Hati
This is the 2nd phase following “Sköll”. Hati is the other wolf who chases the moon – less mystic, this means getting the “Helios-Sköll” sources to compile on Linux – still targeting Transputers, though.
Some tools already do compile, e.g. the Transputer Crosscompiler ‘nc’ (i.e Norcroft-C) but most others are still missing.
Status:
There’s a hati branch in the GitHub repository. I suggest to leave it branched until at least the hostutils are compiling fine.
NB: Because I really badly hacked the nc files to get them to compile I did not include the changes to the branch. If you’re getting to this part of the code, I’m happy to tell/send you what I did, but I assume there are people out there doing a better job than I did 😉
This branch only includes ‘makeinc/makelinux’ and ‘makeinc/LINUX.mak’ and a new makefile here and there.
For now calling ‘. makeinc/makelinux hostutil’ will get stuck in building ‘cmds/com/sysbuild.c’ because of some include-path mish-mash – that’s where we have to start working.
Rough todo:
- Create a proper Makefile. e.g. LINUX.mak currently has a lame workaround to point to GCCs include path
- Probably many optimisations for recent GCC and gMake versions ahead!
Sköll
This is the first and ongoing phase (as of Mar. 2014). While the main purpose of Sköll is to generally get the original source to compile on Solaris (v8) it also has several sub-tasks:
Compile
100%
Clean-up code
5%
Smooth edges
1%
Compile the original source
Several makefiles needed some adjustments to work with gcc (instead of suns own cc), also some tricky formatting f*ck ups needed to be corrected – (gnu)make is much more picky about this than whatever make they used back then.
Strip unnecessary parts
It’s not identified which parts are completely unnecessary, but the TI DSP code is something which can definitely go.
Other points might need to be discussed, e.g. what should happen to some very special servers (i.e. Terminalserver in Helios lingo) like SUN3 or ACORN R140?
Smoothing the edges
There are multiple strange code-constructs which should be cleaned – they lead back to buggy and awkward MSDOS compilers which needed some workarounds
Here are some examples:
The code is full of #define eq == defines. I was told that was a workaround for the “==” vs “=” issue in conditional expressions. Modern compilers warn you when a condition looks like an assignment, the Microsoft compiler they were using at the time didn’t.. Doh!
Then there’s #define elif(x) else if(x). WTF!? Well, this roots from BCPL, the ancestor of C. Most of the core-devs at Perihelion studied at Cambridge University where BCPL was invented and was used well into the 1980s. In addition to the standard if() and while() constructs, it also had unless() and until() statements, as well as elif().
To them used to these constructs, the code was more readable and boy, they do get used throughout the Helios sources way too much.
The Plan
| Welcome fellow reader of ‘el Reg’... you might have come here due to this The Register post from Dec. 6th 2021… thanks for the free ad chaps!
Yeah, it is a somewhat dusty project but that might be due to the fact that I’m working on this alone. Since years. On and off… more off than on honestly. Because there’s no fun in soliloquies. So have fun browsing this time-killing page… 150+ posts are waiting to make you wonder where the time went 😉 |
There’s a rough schedule where this project should go, given there are enough clever people joining in or at least display a certain degree of interest. So there’s a skech of the main-phases, aka “The Plan” (without dates):
Sköll
As said in the intro, Sköll is about “catching” the sun, i.e. get the original Helios 1.31 sources to compile on Solaris. This includes
- cleaning up the code
- weed out unneccesary parts (e.g. the TI DSP code)
- smooth the edges (There are multiple strange code-constructs which should be cleaned)
- get a general understanding of it all
Hati
Next phase/release/step after that will be “Hati”, the other wolf who chases the moon – less mystic, this means getting the “Helios-Sköll” sources to compile on Linux.
Some tools already do, e.g. the Transputer Assembler ‘as’… the Norcroft-C compiler is another story.
And as we all know, when Sköll and Hati finally managed to hunt down the sun and the moon, the world will be destroyed and reborn:
Ragnarök!
It’s certainly not the end of the world. I leave it open for now what that means in terms of Helios, but maybe there will be a critical mass of participants in the community to push “Helios-Hati” forward into version 1.4 running on x86 or current ARM implementations like Raspberry Pi and the like?
Secondary theater of War
Well, then there’s another part of Helios which needs some attention: The server.
This is the piece of software handling the communication between the Host (e.g. your DOS Box) and the connected Helios System (e.g. your Transputer(farm)).
There are several Server sources in the [HeliosRoot/]ioproc/server folder like DOS, Windows, RS6000, HP9000, Interactive UNIX, Sun3/4/i386, SCO etc… obviously all supporting very old versions of their OSes, e.g. Windows 3.x or Solaris 2.
So this part will need some love, too. I will mainly concentrate on DOS (that’s the [HeliosRoot/]ioproc/server/ibm folder), because that’s what I use to talk to Helios.
To support more recent ways of communication than ISA/SBUS/VME-cards, we have to create a new server, for example for Mikes USB-Link Interface.