Tag Archives: Apple II

NumberCruncher Reloaded

NumberCruncher Reloaded

9 Comments

The NumberCruncher Reloaded is a peripheral card for the Apple II series that features a math co-processor, often also called a Floating Point Unit (FPU) which is specialized on, well, floating point calculations. Doing so, it is much, much faster than any 6502 or 65c816 CPU ever will be.

That said, the NumberCruncher Reloaded will not automatically speed-up your programs as CPU accelerators like the Transwarp GS, ZIP CHIP or AppleSqueezer would do. Programs will have to be either specifically written to use the NumberCruncher Reloaded or use a floating-point library like the SANE interface which then needs to be patched to itself use the NumberCruncher Reloaded for calculations instead of the main CPU.

TLDR; In a hurry? Here are some shortcuts for this page:

In the beginning…

The “Reloaded” in its name hints towards the fact that this is a reboot of an already existing card. To make writing/reading easier, NumberCruncher Reloaded might be shortened to ‘NC-R’ further down this page…
In 1988, there was the Floating Point Engine (FPE) created by Innovative Systems (‘iS’ for short).
Read more about those in my separate post over here.

While it was a great idea, it wasn’t the most stable design – but it laid the foundation especially and most importantly for the software we’re still using today.
Due to the FPE’s issues there was quite some displeasure in the user-ship and in 1990 a German company called Alternative Systems announced the Number Cruncher, an ‘overhaul’ of the original design – here’s their newsgroup announcement:

“The FPE is suffering from a major problem, namely the coproc is crashing internally and has to be reset in software. This happens in a non-deterministic way, and software written for that engineering junk must be adapted to that.
The Number Cruncher is compatible with the FPE but is actually what the FPE was supposed to be – a math coproc that works. It performs very well.”

Over the years the FPE as well as the NC faded in unobtanium. Because they were cool, and I love processors of all kinds it was time to revive the Number Cruncher.

Revival!

If you have read the above mentioned post about the the FPE you learned that the predecessors were built around the first, very obsolete and proprietary FPGA, a 555 timer and the 68881 FPU. All these parts would have a Facebook status of ‘#complicated’ today and needed to be replaced.

Logic: The Xilinx XC2064 FPGA was replaced by something more recent like my universal 5V-tolerant weapon of choice, the Altera EPM3064 (aka MAX3000). That little fellow has enough logical gates and using the 100-pin version sufficient I/O-pins are available even when using ISP. The timer for blinking the busy-LED went into this, too.

FPU: There are still some 68881 around, but the 68882 is much easier to find  and both are cheaper in PLCC packaging than ceramic PGAs as of today. But as future NC-R owners might already own one or the other, so we’ll go with… both. Yes – to offer maximum flexibility, you can use either Pin-Grid-Array or PLCC packages.
Physical differences aside, the original FPE/NC did not work with the 68882 – the NumberCruncher Reloaded does.

To sum it up the NumberCruncher Reloaded was improved in many aspects to make it much more usable in the 21st century:

  • it also supports the enhanced and the easier to find MC68882
  • FPU’s can be used either in pin-grid-array or PLCC package thanks to the two sockets provided. Again, the latter being much more common these days
  • Further increased stability by using low-power SMD parts and a 4-layer PCB with dedicated supply layers
  • Speed optimized FPU protocol handling
  • 2 more LEDs, which I consider very important.
  • Updatable firmware (ALTERA ByteBlaster required)

Provided Software

In contrast to my T2A2 Transputer Link-Adapter, there is already some software available for the NC-R.

The Tools Disk

This is a good start but was mainly intended for that warm fuzzy feeling of unboxing a real product 😉

Download: 2MG image or ShrinkIt image

  • Up to Sept.23rd 2021 there was an error in the 2MG image – One INIT was corrupted
  • On Nov. 3rd 2021 the image was updated with the new SANE patch INIT
  • May 27th 2022 – added some low-level benchmarks by Dirk Fröhling

Still, based on the original Innovative Systems disk (updated to the latest releases),  it provides everything you need to start:

  • All Apple IIGS-related software is located in the FPE.IIGS folder.
  • All Apple II/II+/IIe-related software is located in the FPE.6502 folder.
  • The Appleworks 2.x modification software is located in the APPPLEWORKS.FPE8 folder.
  • The EXAMPLES folder has some code snippets to show you how to talk to the NC(-R)
  • The BENCHMARKS folder contains the executables of the different benchmarks by Dirk Fröhling used in his blog entry.
    The archive on his page contains the sources, too.

In the FPE.IIGS folder you will find:

  • The folder called NCR.INIT containing the new SANE patch init which is highly recommended to be used with your Apple IIgs.
  • In the FPETOOLS.INIT folder you’ll find an archive containing the FPE tool set named FPE.INIT.Sx . These were developed by/for iS and are now deprecated and left on the disk for completeness.
  • The EXAMPLE folder contains an assembly language file which demonstrates the use of NC-R register-to-register operations to significantly improve floating point operations speed.
  • The BENCHMARK folder contains an ORCA/PASCAL version of the SAVAGE benchmark and an APW C version of the Byte Magazine floating point co-processor benchmark. (The program in example is an assembly language adaptation of the co-processor benchmark).
  • The APW.ORCA.FPE16 , MERLIN.FPEand LISA816 folders contain macros and equates files for use in assembly language programming.
👉 There’s an updated INIT (V1.15) available here, written by Vincent Hemeury . 
This fixes an issue when running the NC-R with other tools using the SANE API (e.g. Twighlight II 2.0 screensaver module “Ripple”)

The NCR.INIT requires some extra explanation because it is a very elegant solution to put the NC-R to use:

This init redirects every Standard Apple Numerics Environment™ (SANE) floating-point call to the NumberCruncher Reloaded – so as long an application using the SANE library calls it will be accelerated. All you need is to copy the INIT from the NCR.INIT/Init folder into your SYSTEM folder.

 

…and you’re done!

The INIT will automatically detect your NC-R in any slot (if installed) and will nicely show so during boot-up like so:

Apple II

Compared to the IIgs, the support of an FPU is generally limited.
Michael J. Mahon wrote a very good explanation how to still use the FPE/NumberCruncher Reloaded with an 8bit Apple II(e) and why it’s not as efficient as being used in a 16bit IIgs.
Still, he wrote a patch for FPBASIC as well as some example code how to make use of the 68882.

As mentioned before in the FPE.6502 folder you will find all tools for the Apple II.
That also has a SANE patch which can be found in TOOLSET:FPE8.TOOLSET.  This toolset uses the following calls:

jsr $2100 ; to call the fp6502 routines 
jsr $2104 ; to call the ELEMS6502 routines

It loads into locations beginning at $(00)2100 and has a length of less than $1000 bytes.

I have included the APW.ORCA.FPE8 and MERLIN8.FPE macro folders.

The APPLEWORKS.FPE8 folder contains the Appleworks 2.x modification. To modify your copy of Appleworks, just run FPE.SYSTEM from the root folder and answer the questions. The modified code will automatically access the FPE whenever a floating point operation is required.

Mandelbrot!

In the FPEfractal folder you will find Zoombaya (and other fractal programs, all by Glen Brendon).
This is my currently favorite tool for benchmarking and testing.
It’s written in Applesoft BASIC(!) and uses Glens cool so-called ProCMD module which sets up an interface between Applesoft programs. The downside is, that it uses some 65816/65802 specific commands. So running it on a 6502 CPU will lead to a crash.

“Real” Applications

Yes, there actually were some applications making use of an FPU accelerator, eg. function plotter, math tools like a poor man’s Mathematica etc. – all written for GS/OS. Sorry Apple II users… hopefully other A2 enthusiasts start writing programs using the NC-R, too.
I prepared an dedicated post about them to make this one as short as possible:
So if you’ looking for some ‘food’ for your NC-R head over to the NumberCruncher Reloaded Software post.

FAQ

The ever growing FAQ and programming details were put into a post of its own. So you’re kindly invited to follow this link if you have more specific questions…

Benchmark

Still, we’re all hackers of some sort, so you might ask yourself “What’s the fastest option?” or “Can I make it even faster?”.
Well, while the 68882 is up to 30% faster than the 68881 due to its capability to execute commands in parallel this mostly doesn’t matter in the case of the NumberCruncher Reloaded.

As mentioned in the feature-list, thanks to protocol optimizations the NumberCruncher Reloaded is already a tiny bit (~4%) faster than the original at the same clock-speed, but more important is that it “saturates” later.
This means while with the FPE/NC you don’t see any improvements beyond 12MHz the NumberCruncher Reloaded still benefits from a faster clock up to 16MHz.

From there it does not make much sense as the Apple II bus, clocked at 1MHz, is the limiting factor here.

Using the ‘Zoombaya Mandelbrot’ program included on the Tools floppy disk on a TransWarp GS @ 10MHz gives these calculation times:

MHz Original NC NC-R 68882 NC-R 68881 Faster than NC
11 3:59 3:55 3:55 ~1.5%
12 3:55 3:45 3:45 ~4%
16 3:55 3:12 3:12 ~20%
20 N/A 3:12 N/A N/A

The speed of your Apple computer very much plays into the equation, too. It handles all the writing/reading and of course the endian conversion.
Here’s an NC-R clocked at the default 16MHz installed in an Apple IIgs running the same Mandelbrot at different clocking:

‘normal’  1MHz ‘fast’ 2.8MHz TWGS @ 10MHz TWGS @ 12 MHz
8:35 4:39 3:12 3:10

The TransWarp GS seems to saturate pretty early. Most likely because it’s running the code completely out of its cache.

❗👉 Dirk Fröhling, one of the original creators of the original Number Cruncher got a NC-R and did some very detailed benchmarks.
He also provides the sources to his benchmarks as well as the believed to be lost sources for Albert Chin-A-Young’s original SANE INIT!
Read more about those in Dirks blog article over here.
InSANEly savage!

Vincent Hemeury (the author of the new INIT) found an article in the famous BYTE magazine (from July 1987) where they compared the performances of a Mac SE with or without 68020/68881 accelerators and a PC AT or a Compaq Deskpro 386 with an 80287 numerical coprocessor.

The version of his InSANE in the archive sometimes uses direct access to the 68882 of the NC-R. In this case, a IIGS with an AppleSqueezer accelerator and the NC-R is 5.6 times faster than the Compaq Deskpro and 30% faster than the fastest machine (for the Savage test) of this benchmark, the 68020 HyperCharger.

As an outstanding example of the speed’s improvement of a coprocessor for some operations, the same machine is still faster than a 700 MHz IIGS (KEGS with a Mac Pro) for financial operations. And one limiting factor is the 8-bit bus at 1 MHz of the IIGS – imagine having this clocked faster…

Also, Vincent wrote a little benchmark (included in the INITs archive) called “inSANE” which tests the financial functions.
The speed gain is spectacular :

  • IIGS AppleSqueezer / NC-R disabled : 70 sec to complete the first test
  • IIGS AppleSqueezer / NC-R Init v1.03+ : A bit more than a Second(!) for the same test

A vanilla IIGS roughly needs more than 4.5 minutes to complete this test.

Purchase

Of course you want one now 😉 The first batch of 35 cards is sold out. That said…
The 2nd run of cards is available now. Output is slow as I have to hand-solder the 100pin TQFP CPLD (due to chip-shortage when I had them produced). On the plus-side, the PCB is ENIG gold plated now.
I’m building & testing them on-demand – just mail me if you’re interested in one.


Ahhh, look at those beauties!The NumberCruncher Reloaded comes in a nice, eco-friendly box with a high quality, glossy spiral-bound manual and an 800k ProDos floppy.

You can choose from 3 different configurations:

Config 1 “Plug’n’Play”:
NC-R with just the PLCC socket, a 68882 FPU is already installed. Plug the card into your Apple and you’re ready to go:  €88.82

Config 2A “I have a PLCC FPU”:
NC-R with just the PLCC socket – you provide and install a PLCC 68881 or 68882 yourself: €80.82

Config 2B “I have a PGA FPU”:
NC-R with PLCC plus a Pin-Grid-Array (PGA) socket – you provide and install a PLCC or PGA 68881 or 68882 yourself €84.82
(There’s no PGA-only option because the PLCC slot is used for the  final function-test)

Shipping

It’s 2021 and the world is  suffering from the COVID19 pandemic. Shipping services are still providing very limited services.
I am shipping from Germany as trackable package only. Also I chose the box dimensions that way, that it snugly fits into DHLs shipping categories. In that case, I will wrap the original box in strong wrapping paper. It weights 250 grams (that’s 0.55lbs or 8.8oz or 0.039 stone – no idea what’s that converted to Ningi 😉 )
Alternatively I can ship the box in an extra box for better protection against “Crazy delivery men”. That will increase the size and thus the shipping price.

Shipping into the European Union is relatively affordable with 9€ – if you want a “box around the box” it’ll be 14€
(Just in case, for Germany it’ll be 6€ as “Paket”)

UK and Switzerland will be 15€ already. Box-in-box will be 20€ then.

  The US  and Australia can choose between 15€ (or 24€ for box-in-box) and if you’re patient(*) or a hefty 50€ which will be priority shipping.

*) I had shipping times from 10 to a hefty 60 days. Totally random, no idea what influenced the one or the other.

That said, the priority shipping will be fine for 5kg (11lbs, i.e. good for ~15 NC-Rs plus padding), so if you can organize a group-buy, I’m more than happy to support you.

Ordering

Because of bad experiences in the past, this is pre-paid only.
Again: This is a hobby project made for fun & the community, I’m not a business.
I accept PayPal (for friends) and bank-transfer.
To order, send a mail to ncr@geekdot.com stating

  • your Address
  • the NC-R version(s) you like
  • the preferred shipping method
    • wrapped
    • box-in-box standard
    • box-in-box priority

I will then send you all the details for paying & shipping. As soon I received the money, I will ship and send you the tracking information.
If you want to arrange a group-buy I can reserve a certain amount of NC-Rs for a max of 5 days. After that they will be sold on-demand.

Apple II, Hardware

The Number Cruncher – FPU for the Apple II

3 Comments

This is a post I’d like to write since 2006… so 15 years after I’ve put all the Transputer, MIPS, i860 and-what-not stuff aside and made some room for my other (late) love: The Apple IIgs

You might have stumbled about my post/project connecting a Transputer to the Apple II called the T2A2… well, what I did not mention was, that the inspiration to this came from another card built in 1988, called the FPE made by Innovative Systems. That’s a small card featuring just a buffer, an old XILINX FPGA (actually the first of its kind) and the Motorola 68881 floating point co-processor.

Co-pro-ces-sor! I was hooked!  😯

After more research I learned that the FPE was actually a diva like this newsgroup post says:

“The FPE is suffering from a major problem, namely the coproc is crashing internally and has to be reset in software. This happens in a non deterministic way, and software written for that engineering junk must be adapted to that. “

But a bit later there was something better available: The Number Cruncher (NC for short). Fine German engineering  😉 And the newsgroup post was quite nice to it:
“The Number Cruncher is compatible with the FPE but is actually what the FPE was supposed to be – a math coproc that works. It perfoms very well.”

This is the “marketing blurb” from back then

  • totally compatible with the FPE from Innovative Systems
  • much less sensible to heat, voltage problems etc.
  • supports the FPE SANE patch for speeding up any program that does floating point calculations
  • you can compile ORCA/Pascal and C programs to use it directly with the special floatlib for the FPE provided by The Byte Works
  • works in any slot (slot 3 & 4 without need for setting it to “Your Card”)
  • works with TransWarp GS and Zip GS accelerators and RamFAST SCSI card
  • comes with lots of mathematical software and an enhanced SANE patch by Albert Chin-A-Young

I directly contacted the creators of the NC, Dirk and Andreas, but both of them hadn’t had a tiny bit of the NC left. No schematic, no HDL, no nothing 🙁

During looooong and wild eBay raids I managed to get my hands onto an FPE as well as on an NumberCruncher. Woohoo! They both work with the same driver and yes, the NC is much more robust than the FPE.
But it seems that there are only a handful of them survived, if anymore at all. So I thought it might be interesting for me and others to make a re-release…

Let’s re-animate the Number Cruncher!

So, again, it’s up to me to save the world… reverse-engineering time again!
This job consists of two parts – dissect the hardware and to get a better understanding of this, the software/driver, too.

Hardware

Well, you could simply rebuild the card, copy the bitstream from the serial PROM for the FPGA and you’re done.
But it’s not so easy, as the FPGA which has been used, the XILINX XC2064 is long time EOL’ed and if you buy old stock, they’re more expensive than a comparably recent CPLD – if they’re not Chinese fakes and/or broken… not mentioning that a simple copy-paste job is not really manly 😉

The XC2064 is a 5V FPGA (the first of its kind actually), has 600-1000 logical gates and 58 user IO pins of which 32 are used. It is getting its bitstream fed by an external 12K serial PROM. I’ve pulled the bitstream in a file available here, but because XILINX never documented that format, it’s pretty much useless.

The rest is all standard stuff. A ‘245 transceiver, an oscillator (~12MHz)  and some chicken feed.

Revving it up

To prove that I got everything right and having a better attack analysis vector I designed the “NumberCruncher Reloaded v0.1“… more or less a 1:1 clone but bringing out all FPGA signals to pin-headers to have a convenient access for my logic analyzer.
Also I used a PLCC version of the 68881, because I have more of those.

Then, out went the logic analyzer and weeks and weeks of looking/listening to the the FPGAs conversation to the the FPU and Apple bus while having the 68881 manual on my lap, I got an idea of what’s going on.

Software

Later I found the original floppy which came with the NumberCruncher containing  just the init-files for GS/OS patching SANE to use the FPU instead of the 65c816  (download the ShrinkIt archive here) – well, at least something!

Next came my ol’ buddy Mr. disassembler… a lot. About a year on-and-off… and here’s my initial, slightly commented disassembly of the SANE patch.

Again, some years down the road I found the floppies which were delivered with the FPE and those are quite helpful with code examples, assembler macros and libs etc. – that would have been quite helpful during the disassembly  😕 Anyhow, it’s good to see that most of my interpretations were correct.
Also, the FPE came with quite a nice manual – which actually was more valuable than the card 😉
It very well describes the basic functionality, the FPU registers used and the programming side of things – even the most important parts from the 68881 manual are cited. Very good job on that Innovative Systems!

Having all this at my hands I was prepared to start and after some huffing and puffing the NumberCruncher Reloaded v.1.0 was born.

Apple II, DIY Projects, T2A2

T2A2 for everyone

5 Comments
While the guys over at OpenApple were speculating in their latest podcast what a Transputer actually is… well, there are about a 100 links and ways on this page to find out – but hey… just click here – and of course that box saying search would do great wonders, too.

But seriously, my bad: I should have mentioned that this page your looking at is really just one post of many… so make sure you start at a Chapter (Menu. At the Top. ↑…yes up there) and read them in the order you’d read a book 😉

After quite some years (and a handful Apple II users requests) I felt the urge to finally put the T2A2 prototype (read that post to get a more general understanding) into a real expansion card… and here it is: Say “Hello!” to the T2A2 version 1.1!

It came a long way…

t2a2_evolution

…in more detail:

t2a2_front

As you can see, the final T2A2 is much smaller than the prototype (which used an 8bit Baby one-for-all PCB) and offers many additional features

  • 2 size-1 TRAM slots (or one size-2) – double the processing power!
  • Low-power, low-profile parts used where possible (3.3V CPLD, HCT logic)
  • External Transputer-link available as edge connector – extend your network to “near infinitum“
  • Jumpers for LinkSpeed and optional power to the Transputer-link connector
  • Fully buffered to be a good Apple II bus citizen
  • Works in any slot set to “your card”

Beyond this, everything said about the prototype is still true.

Most important:

a) It’s not tested in the ][ or ][+. I simply don’t own one of those.
Update: One owner reported it’s perfectly working in his IIe!
b) The T2A2 won’t instantly speed up any of your Apple II[e/gs] applications.

It’s more like a co-processor attached to it. And even then, you’ll need something really calculation-intensive to justify the time you’ll loose due to communication between the Apple and the Transputer. A single square-root for example wouldn’t make much sense – but having a complex algorithm (like the Mandelbrot fractal in my demo)  does absolutely make sense, as you just pass the parameters to the Transputer and let him do the sweating.

But on the other hand, FPU cards like the Innovative Systems FPE (using an M68881) or my even faster clone “NumberCruncher Reloaded” did just send instruction by instruction. So I somehow fancy the idea writing a SANE driver for GS/OS to integrate the T2A2 more transparently.

Want your own T2A2?

So now you’re keen to get one yourself? Please check this list first:

  • Do you have a TRAM already? (*)
  • You are aware that there’s no real software (yet) besides my little Mandelbrot demo?
  • You are keen to program something yourself – or are fine to wait until somebody else did?

While the Apple II side of coding is pretty easy, you have to get a grip about the Transputer development, too. That includes a DOS/Windows (<=XP) setup and some knowledge of C and/or OCCAM. I’ve created a little Transputer “SDK”, namely a VirtualBox image running DOS.

Plenty of Dev-Docs are available here.  
I suggest using the INMOS cross-compilers for C or OCCAM. An alternative C compiler came from LSC, which might suit you more if you don’t like the INMOS stuff.

Ok, so you’re still with me… so I have the first batch of 20 T2A2 PCBs ready which I will populate on-demand, and for 40€ (plus shipping) one of them can be yours.
(*) I might be able to offer you a TRAM, too. The price depends on available model, RAM size and CPU used.

⇒ drop me a mail tonobody likes SPAM
(Sorry, you have to type that into your mail-client – nobody likes SPAM, so do I)

Also check the T2A2 forum for current availability, shipping procedure and built status.

Some more technical details

Here’s a T2A2 with a size-1 TRAM installed in Slot-0:

t2a2_with_tram

The T2A2’s CPLD programming can be updated any time through a JTAG port (the lower 2×5 pin-row at the edge).
The jumper above it can be used to set the linkspeed for the TRAMs (10 or 20mbps). If you look very close, there’s a tiny LED next to that jumper. It’s the error LED controlled by the CPLD.
The next single jumper enables the VCC pins on the external Link connector, meant for (small!) external extensions. This connector is the same used on the Gerlach card and is very convenient because of its ubiquitous standard 2×5 shrouded pcb header connector. Here’s the pinout:

As said, the V1.1 T2A2 offers two size-1 TRAM slots. Before plugging in 40MIPS of raw processing power consider the amount of juice being pulled there. Depending on the amount of RAM and load a single TRAM can use up to 800mA of power!  😯
Given the max. of 4A on a standard IIgs power-supply, two TRAMs could bring your souped-up GS into trouble… it’s better to use the external connector with just one smaller TRAM or even simply bridge the Link0In/Out pins with Link3In/Out so that the T2A2 works as a TRAM-less adapter.
That said, there are size-2 TRAMs in existence which will snugly fit  and won’t hurt that much.

Blog

Updates for Apple OSes… but not what you think.

Leave a comment

Yeah, iOS got an Update a couple of days ago… and so will Mac OS,  MacOS X, OS X, macOS in 4 days, making your 2010 Apple device obsolete (perfectly fitting in my last rant blog post). Boring… not the Apple OSes we’re looking for.

No, what I’m talking about is ProDOS just got updated to version 2.4! Yes, THAT ProDOS from  1983 running on Apple IIe computers.
Thanks to internet goddess, you can even play around with it in your browser.

prodos_2_4

But not enough: After 22 years, 2 months, 2 days and 2 hours GS/OS got an update to V 6.0.2, too. That’s the System 6 look-alike OS running on the 8/16 bit Apple IIgs machine. By the way, one of my favorite Apples (also used in some of my projects).

welcometo602

That’s the spirit guys!

DIY Projects, DIY Transputer interfacing, T2A2

Mandelbrot and Video

Leave a comment

Like with the C64, this is probably the reason you came here:

The friggin’ fastest Mandelbrot displayed on a IIgs, ever! 😉

Yeah, you’re right, it’s not the fastest Mandelbrot calculated by an IIgs (its very own 65c816 CPU, that is)… but hey, it’s still kinda cool – and sooooo much faster!

Okey-Dokey, here we go, a complete Mandelbrot in 60s. This time in color… and zooming in! I couldn’t do that on the C64 as the C-Compiler didn’t natively support IEEE754 doubles (like Orca-C does) and having a mouse also helps a bit, too:

Wow, that was nice, wasn’t it?! (Sorry for the shaking, need to get a tripod soon)
Especially when you take in concern how ‘far’ the native 65c816 code got during the video on a ‘sped-up’ 10MHz TransWarp GS.

Like with the T2C64 version there are surely several things which could be improved, but the IIgs (even at native speed) is well capable to handle the little bit of extra work. The limiting factor is the bus-speed, i.e. how quick the Transputer can push his data into the host (IIgs). You can clearly see that by the time it took the display the 3 zooms: They all took about 60 seconds, even each zoom means more calculations as the iteration is doubled each zoom, in this case 32, 64, 128.
The Orca-C source/binary of this demo -and the previous AppleSoft sample- is available here (zip’ed PRODOS disk-image). It won’t make much sense without a T2A2 and is GS/OS-only as it uses QuickDraw II and the EventManager (for mouse & keyboard).

Final words: Don’t get too excited about the acceleration of the IIgs… it’s not accelerated at all. It’s more like a co-processor attached to it. And even then, you’ll need something really calculation-intensive to justify the time you’ll loose due to communication between the Apple and the Transputer. A single square-root for example wouldn’t make much sense.
But OTOH, that’s exactly things are handled with the Innovative Systems FPE (using a M68881). So it might be worth evaluating. Maybe I’ll write a SANE driver if I have the time to get a deeper understanding of GS/OS.

As my two targets (C64 & Apple II) are working now, I’m thinking about creating a ‘real PCB’ in the medium term. Given the rarity of the Link-Adaptor (Inmos C012) I’m currently looking into the possibility to use a larger CPLD to move the C012 into that. This would actually make this ‘project’ a product to buy.
But don’t hold your breath, need to get an eval kit first. Then some 100 days of fiddling, cursing and crying… and then more.

well, 6 years later it happened: The T2A2 became a proper PCB design… and got some additions too!

DIY Projects, DIY Transputer interfacing, T2A2

1st basic example

Leave a comment

Like with the T2C64, the CPLD on the T2A2 maps the C012 registers into the memory area of the used slot, using just 6 addresses starting at 0xc080 + (SLOT# * 0x10). So for e.g. Slot 4 this would be:

  • BASE        (0xc080 + (4 * 0x10))  = 49344
  • Data in:    BASE                   49344
  • Data out:  (BASE + 1)           49345
  • in-status:  (BASE + 2)           49346
  • out-status:(BASE + 3)           49347
  • reset:       (BASE + 8)           49352 (writing)
  • analyse:   (BASE + 12)          49356
  • errorflag:  (BASE + 8)           49352 (reading)

With this ‘knowlege’ we can start talking to the Transputer… and to make our first babysteps we’re using BASIC. It’s pretty much the same code as used on the C64 with the exception that there’s no “elegant” timeout handling due to the missing clock in AppleSoft, so you have to wait a bit longer until you get the printout in the end.
For details about what’s going on here, see the C64 page.

 10  PRINT "INIT TRANSPUTER"
11 BASE = 49344:IN = BASE:OUT = BASE + 1:IS = BASE + 2
12 OS = BASE + 3:RESET = BASE + 8:ANA = BASE + 12
13  POKE RESET,0: POKE ANA,1: POKE RESET,1
20  REM CLEAR I/O ENABLE
21  POKE IS,0
22  POKE OS,0
30  REM READ STATI
31  PRINT "I STATUS: ";( PEEK (IS) AND 1)
35  PRINT "O STATUS: ";( PEEK (OS) AND 1)
40  PRINT "ERROR: ";( PEEK (RESET) AND 1)
45  PRINT "SENDING POKE COMMAND"
46  POKE OUT,0
50  PRINT "O STATUS: ";( PEEK (OS) AND 1)
58 :
59  PRINT "SENDING DATA TO T."
60  POKE OUT,0: POKE OUT,0: POKE OUT,0: POKE OUT,128
61  POKE OUT,12: POKE OUT,34: POKE OUT,56: POKE OUT,78
70  PRINT "I STATUS: ";( PEEK (IS) AND 1)
79 :
80  PRINT "READING FROM T."
90  POKE OUT,1: REM PEEKING
100  POKE OUT,0: POKE OUT,0: POKE OUT,0: POKE OUT,128
110  PRINT  PEEK (IN); PEEK (IN); PEEK (IN); PEEK (IN)
128  DIM R(4)
129  PRINT "SENDING PROGRAM TO TRANSPUTER..."
130  FOR X = 1 TO 24
140  READ T: POKE OUT,T
150  WAIT OS,1
160  NEXT X
170  PRINT : PRINT "READING RESULT:"
175 C = 0: REM RETRIES
180  IF C = 10 GOTO 220
181  FOR X = 0 TO 5000: NEXT X: REM DELAY
189 ER = ER + 1: IF ER = 10 GOTO 220
190  IF ( PEEK (IS) AND 1) = 0 GOTO 181
195 R(C) =  PEEK (IN)
200 C = C + 1:ER = 0
210  GOTO 180
211  REM ------------------------
220  IF C = 1 THEN  PRINT "C004 FOUND"
230  IF C = 2 THEN  PRINT "16 BIT TRANSPUTER FOUND"
240  IF C = 4 THEN  PRINT "32 BIT TRANSPUTER FOUND"
250  IF C = 0 OR C > 4 THEN  PRINT "COULD NOT IDENTIFY""
1000  DATA 23,177,209,36,242,33,252,36,242,33,248
1001  DATA 240,96,92,42,42,42,74,255,33,47,255,2,0 

Ok, if this is running fine, i.e. a Transputer was actually found and your Apple didn’t went up in smoke, we’re set for some serious numbercruncing… and a video! Yay! We love Videos, don’t we?

(I’m skipping the other sample code available on the T2C64 page. It’ll work the same on an Apple, so no need for redundancy)

DIY Projects, DIY Transputer interfacing, T2A2

T2A2

Leave a comment

Ok, here it is. The T2A2. What sounds like a robot from StarWars is actually a Transputer to Apple II interface. Its design is pretty much the same than its cousin, the T2C64, with the addition of some buffers to behave like a good citizen of the Apple-II bus. So this is how the little beast looks as of now (v0.5):

T2A_front

To use the Apple-II bus-connector of the 8Bit-Baby (another brainchild of mine), I had to shuffle the parts around a bit. On top you’ll see the same TRAM used on the T2C64… 20MHz T800 Transputer, 128KB SRAM. Right below it is an LS245 octal bus-transciever to handle signals like DevSel, R/W and A0-3. To its right its the IMS012 Linkadapter converting 8bit parallel bus into INMOS’ serial link-protocol. Below that, there’s the silver 5MHz oscillator to clock the IMS012 as well as the Transputer and another 245 to buffer the data-lines (D0-7). Finally on the left bottom there’s the CPLD which handles the Analyze, Reset and Error lines of the Tranputer as well as chipselect and such (Thanks to Mike for helping out on VHDL here!).

The picture above is the first Prototype and it’s finally working… even it’s a nightmare to look at its back side 😀

T2A_back

But because I’m a Commodore guy who wasn’t able to afford an Apple II in its hey-days I had to start from scratch and learn a lot…
That said, when I finally could afford an Apple II system, I went straight for the IIgs. I think IIgs is the perfect platform for an 8-bit Transputer interface given the amount of available/adressable RAM, native access to harddisks and a decent screen resolution.

Because of its simple design, the T2A2 should also work in any Apple-IIe etc. There’s no ‘firmware’, no EPROM. Just plain simple reading and writing to some (slot)specific addresses.
Due to its close relationship to the T2C64, programming is quite similiar. As a matter of fact I just slightly changed the examples I’ve used on the C64… which is the beauty of the idea.

So jump to the next post to see the first little test proggie in AppleSoft BASIC…