All posts by Axel

Update 18, 19, 20…

Oh boy… I really neglected the news…  there are quite some updates on Geekdot, but they just happen 😉

Mainly there were lots of Apple Mac (68k) things going on – repairing, recapping, brighting and hacking… but there always was a major theme: I worked with other nerds specialists on their projects. Be it the Carrera 040 in an SE/30 effort or a very special PC not working anymore. It’s fun to dip your toe into different waters every now and then.

That said, I moved the sidebar around a bit. The recent posts went onto the top and this news section was moved down as I feel it’s a bit redundant.

 

Olivetti LSX 5010

Years ago I got that broken Olivetti CP486 board (the predecessor of the LSX 5010 and 5020 family) – one of the two ever made i486/i860 combo Mainboards (the other one was the 4860 by Hauppauge). Well because it was broken, missing important parts and I felt like I’m the only one on the planet having such system I dumped it.

There’s life out there!

Now I learned there are at least two LSX 5010 owners left on this planet and one of them contacted me, primarily asking for an i860… well, long story short:
His LSX 5010 was broken, too, but complete! We agreed on a deal: I try to fix it (plus an i860) and he’ll give me a system out of his collection.

Some days later I had everything I’d call a good-to-go system:

The grey box with an LCD display is the “console”, giving you POST information, a speaker and some buttons. Next to it the huge power-supply and in the slots you can spot the EVC-1 graphics card an my trusty ISA/PCI POST card…

Let there be light

Booting the system just the console showed a “CMOS Periodic Int Error“. Doing a warm-boot it replaced by a „Base 128k Ram Error“.
Additionally it behaved somehow flaky, booting  into different states every now and then:

These three Errors were solvable:

  • Flaky behavior: Replacing all caps – this always helps. Believe me. The system booted into a reproducible state after this.
  • CMOS error: The dreaded DALLAS CMOS clock-chip… we all know the drill. Its battery is empty and EISA systems heavily rely on a working CMOS storage. So it got an external battery surgery.
  • RAM error: That was a bit tricky. The LSX’es need parity RAM. One SIMM per bank. Max. mem is 16MB – I only have 16MB+ SIMMs. So I had to get small parity PS/2 SIMMs. 2x4MB did it.

Booting the system now, the console greeted me with

  • „Console Passed“
  • „P.O.D. Running“ (That’s the Power On Diagnostic)

…and then „Non-Maskable Int. Error“. Dammit! This can have many reasons, most of the time it’s RAM (parity). But in my case, it’s been different…

That was a fun one (actually two):
The trace to the i486 processor NMI-pin (B15) was scratched and needed repairs. But it still kept throwing that error. Why-oh-why?!?! After a whole day of digging I had a severe facepalm-moment:

The owner replaced the CPU by an 80486SX because he was under the assumption the LSX 5010 was an SX system. But it wasn’t. It’s a 80486DX @ 25Mhz system (while the 5020 is 33MHz).
And while everybody is claiming the SX is just a DX minus FPU… it is not a 100% drop-in replacement!
While the DX’es have their NMI-pin at B15 the SXes have it located at A15 (where DXes have IGNEE) and B15 is not-connected. Doh! (Checkout the pinout here)

So replacing the SX by one of my 486DX  we finally got a full boot! Tadaa:

Those stripes came from the EVC-1, which definitely also had its problems. So checking its board with my microscope I came about this:

Uhhh…. a cracked diode (D14) connected to address-line A0 to the video RAM. That explains the lines quite well.
When the new DA5 (BAR43S) diodes arrived I replaced the broken one, fired up the LSX 5010:
Looking good, booting into the EISA CMOS setup and while editing the config I could watch the picture disintegrating by every keystroke. More and more garbage was displayed, columns disappearing until it was all black.
The EVC-1 literally died in action in front of my eyes 🙁

I’m not sure what happened here. The fixed address-line can’t be responsible for this. All ICs still get their clean 5 volts. I suspect that one or more of the many old PALs (some of them even bipolar) died…

Ride on…

Anyhow, plugging in my ET4000 workhorse I was able to resume the setup. EISA systems always need a setup tool to tell them all the features of their Mainboard as well as the cards being installed. Luckily the owner had the basic tools at hand… you’re screwed without them.
So this is the one for the LSX booting:

After that’s been done I ran the diagnostic tool – in German just for the fun of it (You can spot all those “OKs”, right?)

But wait a second! Isn’t there something missing?
You’re right… here you go:

The mighty i860 RISC processor… and it is detected just fine: “Pass” 🙂

But does it work, too?

Yes it does! Hooray… mission accomplished!

Downloads

As usual, here are the dumps of the BIOS, Config EPROM and CMOS.
Additionally, you’ll find the floppy images of the config- and diagnostic tools in this archive.

Conclusion

The LSX 5010 is very much like the Hauppauge 4860 a fragile system to work with.
If the unusual configuration of EISA systems weren’t enough, the use of the many, many, many proprietary ICs (i.e. GALs and PALs) make them prone to aging and hard to fix.
They were bespoke designs, limited in their compatibility – Olivetti lists about 30 cards (VGA, SCSI, most of them multi-RS232) officially working – and most importantly need specific parts like the console and software.
Without the proper EISA config tool you always get at least error messages. Without drivers for the i860 you will not be able to use that and it’s just a heating-element inside your computers case.

Those (server) systems were meant to run as-is. Pretty much like a SUN, HP or SGI server of the same period. You can pick from like 2-3 devices to add and that’s pretty much it. They were not designed as an average PeeCee running Doom.

The truly worst Apple Product ever!

If you Googling for it it seems everybody (and his/her dog) has at least posted one top-10 listing of the worst Apple product ever (and ever-ever).

Same-Same

All those pages seem to “inspire” themselves from each other. So it’s essentially always the same suspects:

  • Apple III
  • Macintosh TV
  • Quicktake Camera
  • The Newton PDA
  • The Pippin Games-console
  • The Performa x200 family
  • The 20th Aniversary Mac
  • The first USB Mouse (aka Hockey Puck) as well as the Mighty Mouse
  • The G4 Cube and
  • the flimsy iPod Shuffle.

I’m ignoring those lists of people who learned about Apple as a company more or less with the launch of the iPhone. Pfffft, kids, come back in 20 years, will you?  😛

So before I tell you the truly worst Apple product ever (ever-ever-ever!) let me give you my two or three cents to that list…

Reality Check

First of all: All those products had a certain degree of design-language and an eye for details – I dare saying passion to them.

Even the Apple III was -at its time- a design statement (look at other computers of 1980: Commodore PET, TRS-80, ZX81 ot the KAYPROs). It was meant to be a better Apple II and yes, it had technical flaws, but if something made it “worse”, it was its price-tag.
I’d call the design of the 20th Anniversary Mac or the Hockey Puck  bold – maybe too bold for its time. And both, as well as the G4 Cube and the Newton (110 and up) were designs by Jony Ive – the much hyped designer who also did the iPhone, iMac and nearly everything since, well,  the iMac.
Some of them were more or less pioneers of their kind like the Newton being the first usable PDA and the Quicktake one of the first digital cameras (Put both put into one device, add 10 years: iPhone!)

So let’s recap:

They all might be commercial flops but they had a raison d’etre, followed a certain design concept and most important, you can feel a certain level of passion behind it. Maybe they were too expensive, released too early or just way ahead of its time – but in my humble opinion they were not the worst Apple products ever.
And do I have to add that mostly every product on that list is a highly sought-after collectors item now?

The truly worst Apple product ever

So finally, this is it. This Apple product is very unknown – probably rightly so. It ignores all the points I was recapping above:

  • No reason d’etre
  • No design philosophy or concept
  • And absolutely no passion at all!

Its only intention was to save costs… yeah, that can be reason for being, but in this case “it’s worse”.

Please let me introduce you to “M9103” also known as the “Apple Basic Color Monitor“.

It’s a product from the beginning of an era in which Apple was close to bankruptcy. Struggling against the much cheaper x86 PC the Macintosh product family got confusing and they tried to somehow compete with PC prices spitting out one low-cost system after another.
The rightfully hated Performa x200 (the #1 “road apple”) and PowerMac 4400 were the pinnacle of all cost-reduced products Apple released… and the M9103 is where it all started.

To protect you from severe shock I slowly move backwards, beginning with the label on its back, proving it’s a genuine Apple product:

Let’s take some distance to see it’s backside in full – still, there could be hope if they would have kept the more or less rectangular shape… but bottom of the case is not looking promising.

At the front you’ll spot the proof of absolute zero passion. The Apple logo somewhat slapped into the space which the OEM left there:

Yes, it’s a bog-standard,  VGA monitor, lowly specs and ugly as hell.

The photos don’t do it justice – it’s even uglier in real-life.

They even did not change the cable to the (back then) Apple 15-pin standard video port but just stuck an adapter to it:

No wonder it was so short-lived (February 10 to October 21, 1993)

Just to show that Apple was definitely to do better. The first monitors sat more or less flush on the computer cases. Even those with a swivel-base showed the typical design language, an embossed/color Apple logo etc.

My PC builds

In Jan 2020 was planning to build a new PC, after using its predecessor for 8 years, now that I’m done, I thought “hey, how many PC builds have I done already?” – Well let’s count while having a stroll down memory lane:
[Yes, I’m a ‘real man’ thus I never owned an off-the-shelf PeeCee]

1988 – The entry

My first x86 computer, built from parts I got in exchange for working at a local computer shop – Even I was totally happy with my Atari ST, I was intrigued by the many ways of hard- and software hacking possible… and of course by its quirkiness, i.e x86, strange offset/segmented memory access etc.
It was much worse than my Atari in every aspect except having a hard-drive which for the Atari would have cost me as much as the complete XT System:

  • CPU: NEC V20, 8MHz (overclocked to 10MHz after some weeks)
  • Mainboard: No-Name 8088, fully populated with 640KB and 5 ISA slots
  • Video: No-Name Hercules compatible (to an amber 12″ screen)
  • Media: Seagate ST-225, glorious 20MB, MFM controller and a 360KB 5.25″ Floppy drive

It was fun hacking my way through Turbo-C/ASM, TSRs and such but even overclocked it was a sloth…

1990 – Affordable 32bit! And an option of UNIX…

About quitting my job at the computer store I traded my XT for a bare 80386 system on my way out. Bare because I had no money left for a case… and also because having a ‘proper SCSI’ solution was more important to me after seeing Interactive UNIX running at a friends system I planned to have that too, some fine day… so this “PC” was running lying naked on my desk. It consisted of

  • CPU: AMD 80386, 33MHz
  • Mainboard: No-Name 386, populated with 4MB and five 16-bit ISA slots
  • Video: No-Name Trident 8900, 512K (IIRC)
  • Media: A 5.25″, full-hight 170MB SCSI monster (I think it was Micropolis and already considered vintage – but cheap!) attached to a fancy (and very much loved) Adaptec 1542b – and a 1.4MB 3.5″ floppy of course.

It turned out that there was no way to get a proper UNIX for cheap – and it wasn’t planned to pursue this path any further…
(During these days in my view Apple and Acorn still were the things to come – it shows how wrong you can be)

1992 – Linux happened

Early 1992 I got wind of this Finnish guy and his ‘tuned MINIX’ – digging into the news further I was on fire, got myself a ~40 Floppy Distro (A Slackware clone from ‘Linux Support Team Erlangen’) and immediately understood, that a 386 and 4MB isn’t much if you want X11, too.

So I swapped my x86 again and got myself a 80486/33 which I originally bought as office workhorse for my first own company (which did not work out so well). Having doubled the RAM this also brought a speedy ET4000 with a whopping 1MB video-RAM making X11 possible.

  • CPU: Intel 80486, 33MHz
  • Mainboard: No-Name 486, populated with 8MB and five 16-bit ISA slots
  • Video: ET4000, 1MB
  • Media: Replaced the lame AT-BUS by my SCSI rig from above.

1994 – Going serious

Finally I was in UNIX heaven… and using a UNIX system (Linux in this case) you never have a sufficiently fast system. It became clear that my 33MHz 486 hit its limits and even my dear AHA1542B felt slow looking at this brand new PCI-Bus everybody was going crazy about. So I skipped EISA and looked for the best solution.
Attending the release show [German] of the brand new Intel Pentium at Cebit ’93 it became clear that I’ll ignore that an go for an Am5x86 and the best board you can get: The ASUS PCI/I-486SP3G

  • CPU: AMD 5×86, 133MHz
  • Mainboard: Asus 468SP3G with 16MB, four 16-bit ISA and 3 PCI slots
  • Video:ET4000  (replaced in 1995 by an S3 Trio64, 2MB)
  • Media: Onboard NCR53c810 SCSI driving a 3.5″ 200MB HD and 2x CD-ROM

1996 – Bad Ass mode

Compiling kernels and stuff like that squeezed the last inch of performance out of my trusty 5×86 (now running at 160MHz) it had to be something faster again… Having some cash at hand I decided to go “32bit and no way  back” and opted for the cool & huge Pentium PRO @ 200MHz which I got for a very good price (used, from an integrator evaluation site) before I even had a board for it.
After some research it had to be the bad-ass Tyan S1662D mainboard, featuring a 2nd socket to go dual CPU – how crazy it that!? A year later, that socket got populated and besides my Linux power-house (make -j2!) this box also rendered Cinema-4D movies like a maniac (I even was beta-tester for Maxxon).

  • CPU: 2x Intel Pentium Pro/200
  • Mainboard: Tyan S1662D with 32MB, tree 16-bit ISA and 5 PCI slots. Stuffed to 256MB later.
  • Video: S3 ViRGE/VX 2MB, replaced by later by a very much loved Nvidia Riva 128/4MB
  • Media: Symbios Logic 53C875 PCI SCSI controller driving a 3.5″ 500MB HD and 2x CD-ROM

1999 – Last x86 update for a long time

Finishing my studies I mainly used my beloved PowerMac 6100 for creative work, while my ‘Pro’ was Linux and render-box only.
I started a day-job in IT earning real money and had the chance of hosting my server – so the PPro became my first physical server hosting this very page (and others). So I needed to get into PC builds gain – even I can’t remember a real reason for this 😉
Intels Pentium-II easily outperformed my two PPros already and AMD did not convince me with their product line, so it became an PII @ 333MHz and an Asus P2B-F board which ran solid as a rock… but when my iMac G4 with OS X moved in, I got the perfect UNIX/BSD system I ever wanted and this little PCs fate was clear… it replaced the PPro Webserver. The PC-at-home time ended…

  • CPU: Intel Pentium II 333MHz
  • Mainboard: Asus P2B-F with 512MB, tree 16-bit ISA and 5 PCI slots
  • Video: AGP Riva TNT
  • Media: ATA became cheaper and faster than affordable SCSI. So this was the end of an era.

The Orphan

In 2012 I inherited my work PC when they closed office and I was pink slipped. Well, if it’s free… and a nice system it was: The Intel i7 2600K is still considered a decent CPU and was an animal back then. The Gigabyte z68x-ud3 mainboard neither is a bad choice (if you don’t need the beta UEFI BIOS) and this box made a strong gaming box with some casual VM and Hackintosh experiments… but beyond that, Macs-only it was from 2000 up to now.

  • CPU: Intel i7 2600K
  • Mainboard: Gigabyte z68x-ud3 with 16GB, still two classic PCI slots and some PCIe.
  • Video: Some AMD 6950 I think…
  • Media: SATA SSD and HD

One box to rule them all

Because my MacPro 3,1 (early2008) finally reached its limits – even rigged and modded to run Mojave (Incl. Metal graphics) just fine. Compared to its size and power consumption the performance doesn’t justify running it for longer. The i7 PC sitting next to it started to annoy me with its beta UEFI BIOS and it clearly started showing its age.
So this brought me to the decision to modernize while consolidating. Still owning a legal licence of MacOS (and some more Macs in the household) I will build a single machine, hosting MacOS and Windoze 10 using all the latest shebang – and going back to where my x86 heart is (if there’s something like that ;-)): AMD.
AMD is back. Big time. The Zen architecture really brought them back into the race and they caught Intel cold.
This means my one-an-only (recent, not vintage ;)) system will something along these lines:

  • CPU: AMD Ryzen 3600
  • Mainboard: Asrock b450 pro4 with 16GB, no classic PCI slots and about 4 PCIe with different lanes.
  • Video: AMD R9 280…
  • Media: M.2 SSD and still some HD for the archives.

Conclusion… for now.

Phew, this all came a long way. 31 years of building x86 PCs… and how things changed (as they did with my SPARC comparison):

Let’s compare the first and last CPU of the above list

Spec NEC V20 Ryzen 3600 factor
Max stock MHz 8 4200 33600
External Bus-width 8 64 8
Max addressable RAM in MB 1 32000 32000
Pins 40 1331 33.2
Manufacturing process 1200nm (less than half of Intels 8088) 7nm 171.42
Transistors 63.000 (double of an i8088) 9.900.000.000 (sum of chiplets and IOD) 157142.8
Cache 0 35.3 MB (all levels)

(more Cache than a 286 could even address)

Opcodes 154 About 1013 (incl. everything from MMX, SSEx to SGX/VMX/SMX) 6.5

That’s quite impressive, isn’t it? I’m still blown away by the number of instructions… ~1013! Holy Bat-Opcode! IIRC the 6502/10 had 56… and still isn’t considered pure RISC.

The final Cube – Snow white coffin

This is it. Hooray! The final Cube as I always wanted it to be.
It just took me about 2 years of planning, blood, sweat & tears, huffing and puffing. Many tries to find the right parts, plenty materials evaluated always trying to keep the budget low.

The sleeping beauty – yeah, it’s a bit snow white coffin’ish

Meet the ancestors

You might have followed the route I took for quite some time now:
It began with the ‘Tower of Power‘, basically a component carrier with a power-supply.
After some years it was replaced by the first Cube.  Well, yes, while it had a somewhat cubic’ish case, is still was just a dull standard industrial case. Not really what I imagined how my computer should look.

Form follows function

If you’ve read some posts here on GeekDot, you might already got the impression that I’m a sucker for design. Well, not that kind of a surprise, given I studied design some decades ago 🙄
I’m also heavily influenced by the works and philosophy of Dieter Rams (mainly for BRAUN) and Hartmut Esslinger (of frog design), of which you might not have heard about, but you know their designs for sure…
So I fell in love with the Parsytec x’plorer and other iconic computer designs like these ‘cubistic’ examples:

Yes, I am a strong believer that a computer, while basically being a rather boring calculation tool, should look good, timeless and might give you an idea of its innards are actually doing something.
We could probably go on forever, defining how a well designed computer should look like. But like the Romans used to say: “non potest argui per gustum” (You can’t argue about taste)…
Let’s say, I’m probably not totally off, given that most designs I like are also on display at the Museum Of Modern Art 😉

So mentioning the Final Cubes design, it’s  case we’re talking about: If you’re really picky, then yes, the Final Cube is actually two cubes:

The carrier-cage on the top which I tried to keep simplistic and invisible to give the PCBs as much stage as possible. The user should be able to see the many, shining CPUs. So 10x10mm aluminum square tubes are connected by 3D-printed frame-corners to provide maximum view onto the technology.
For protection but also as a design statement and tribute to Rams’/Gugelots famous ‘snow white’s coffin‘ everything is surrounded by a 30x30x30cm translucent acrylic cube.

The white base actually isn’t cubical at all being much wider than tall. Nevertheless, its design should be even more simplistic and cautious to serve three purposes:

  • Give the computing-parts above it a proper podium
  • House the LED array which provides the fitting aura
  • …and finally house all the tech the user should not care about

With quite a big fan between the base and the top both work like a chimney (following the convection) sucking the air from the bottom and blowing it through 169 holes in the top plate of the cube.
Here’s an idea out how it looks “working”:

When one thing comes to another

The parts of which the Final Cube is build from aren’t all created this year. Actually only the case and the cage-frame are from 2019 – all other parts were designed by me some years before.

The core of everything are TRAMs – these are Transputer computing modules defined by Inmos back in 1990. The specific TRAMs used are my own AM-B404, each containing a 25MHz T800 and 2MB of  fast SRAM.

Finest home-made TRAMs

16 of these TRAMs are placed onto an Inmos B012 (or compatible) carrier board. And up to 10 of these carriers can be put into the Cubes carrier-frame creating the cluster.

Under the hood

Below the carrier-frame, in the base, you can spot a 32×16 LED panel. This one is actually from 2012 when I designed the T2i2c, an i2c-bus to Transputer TRAM.

Yes, that’s an Arduino Micro on top of a TRAM

So it was a natural move to make the T2i2c into a system-controller. It does not only controls the LEDs displaying the current load of all Transputers, but also using a photo-diode to set the display brightness as well as measuring the internal temperature and overall power consumption.

Here’s an overview of the base internals:

I know, the venting holes are not pretty – but they do their job and prevent you from accidentally touching the power-supply.

The red arrow points to the T2i2c being connected to the LED panel to the left as well as to a hall-sensor (blue arrow) measuring the power consumption, a temperature sensor (orange) and a photo-diode (green).
You cannot overlook the 22cm fan in the back sucking air from the bottom along the power-supply and pushing it up to the Transputers above to keep them cool.

And their power consumption is not to be trivialized. In average a single Transputer TRAM requires is about 1 ampere… so the math is easy. This means the quest for a powerful power-supply was on.
After some months I found what used to be the power-supply meant for a 3Com Corebuilder 7000: The mighty 3C37010A. A whopping 90A@5V should be OK for starters… here’s the fitting procedure:

Mooooore powerrrrrrr, Igor! You touch, you die!

The back of the medal…

The backside did not change compared to the previous Cube back  – well besides the supply-cabling which now goes down into the base instead to the side of the cage.


In consequence you’ll spot the power-connector there. No switch though  – still thinking about that… as well as a nicer cable-management for the link-cable which is normally connected to the host.

Next up would be a host matching the look. Mhhhh….

ATW800 Farmcard

Sometimes a man has to do what a man has to do 😉 And this time it got to be an ATW800 Farmcard.
A what? ATW800 stands for ATARI Transputer Workstation – basically an Atari ST and a Transputer subsystem in a tower case (just about 250 were build and sold) and looks like this:

Atw front.jpg

Background

Even I still do not own an ATARI Transputer Workstation (yet), I “know” it from the very first presentation when working at the 1988 CeBIT Atari booth back then. The initial demo version used a standard Atari Mega-ST connected to a blunt Atari-PC3 case which housed the Transputer stuff… and the whole thing ran the Helios Operation System about which you can read quite a lot in this GeekDot chapter. Well, actually that was no wonder given that Perihelion Ltd. was not only the creator of Helios but also the birthplace of the ATW800 (Called ABAQ in the early stages).

The final version (the one in the tower case) used so-called Farmcards to expand the number of Transputers available to the system. A Farmcard featured 4 fixed Transputers (T425 or T800) with 1MB of RAM each. Here’s a piccy (click to zoom):

That might be plenty back then, but even in those days progress was made quickly and INMOS presented their TRAM Modules at nearly the same time… and these give you so much more flexibility and also save space. Actually, if you closely read the marketing material from Perihelion you will spot the announcement of a TRAM Farmcard. It just never made it…

I did it my way…

So it was just a question of time until I start to design a TRAM-Farmcard. After many years of unsuccessfully hunting an ATW which is for sale, I at least met shock__ (atari-home.de forum) a lucky ATW800 owner who was happy to help. So using the available documentation and the data provided by shock__ I created this:

Features

So what gives? Well, first of all, there aren’t any original Farmcards available anymore. Even if there were, they’re pretty limited. One Megabyte is enough for a computing slave using pure OCCAM but if you’re using Helios, 300k will already ate up by its core demons. Then there’s space for just 4 Transputers, not many given the size of the card.
That said here’s what this new Farmcard provides:

  • 8 TRAM slots. Can be used for anything. Computing, SCSI, Ethernet or graphics TRAMs. Be it size-1 to 8. There were many, many cool modules available. Today you can at least use my AM-B404 TRAM, a super-fast 2MB size-1 compute TRAM.
    This would mean twice the CPU oomp, and double the RAM.
  • Freely programmable Altera EPM7032/64 CPLD. It will implement Perihelions diagnostic-bus, meant for controlling each Transputer separately. Updates can be done in-field.
  • An external RS422-link. Using differential transceivers (26LS31/32) one can connect external Transputer networks over a distance up to 20-30 meters (vs. 30cm in pure TTL).
  • 4 layer PCB design giving stable power distribution throughout the board. Still, simple layout, easy to patch and only through-hole parts being used to make building as easy as possible.
  • 2 LEDs. Just say’in…

Because of the added Transputer-Slots the network topology looks a bit different than is used to be on the original Farmcard.
This is the “old one”, a simple square, each Transputer has two free links being available at the edge connectors J1-J8:

And this is how the 8 slots are connected:

Now each Transputer has just one link connected to the edge-connectors. Slot 7 uses link-3 to connect to the optional external RS422 connector.

Free as free beer!

Because there are probably only two handful of ATW800 owners out there, I made the schematics freely available here under the GPL license. But to make things clear:
This is untested stuff! The card is huge. It is not cheap to have it manufactured. The best price for 10 PCBs I was able to find was about $250.

The hard part

While the cards design was pretty straightforward the “firmware” of the CPLD will be a different beast. As said, Perihelion used a proprietary bus called “diagnostic bus” (DBus) – a two wire bus used to address all or just a single Transputer in a network to either reset or put him into the so-called analyze-state to do some post-mortem debugging. Pretty advanced stuff given that standard Transputer networks simply used a global reset.

Luckily the DBus is documented in the (short) Farmcard Manual (p.8-10). So we have a rough idea what’s going to be expected:

The DBus is daisy-chained through all Farmcards on the slots as well as on the edge-connectors J9 & J10 (in/out). Because I hadn’t had an original Farmcard at hand I wasn’t sure which of these signals are needed to be controlled by the CPLD. So I connected them all using all available I/O ports.  This is the pinout:

pin function
04 5_ANA
05 1_RES
06 1_ANA
08 LED1 (Error)
09 L_IN
11 L_OUT
12 FAST_IN
14 FAST_OUT
16 SLOW_IN
17 SLOW_OUT
18 GLOBAL_RESET_IN
19 GLOBAL_RESET_OUT
20 T_ERR_IN
21 T_ERR_OUT
24 LED2 (Opt)
25 4_ANA
26 4_RES
27 2_ANA
28 2_RES
29 3_ANA
31 3_RES
33 7_ANA
34 7_RES
36 6_ANA
37 6_RES
39 0_ANA
40 0_RES
41 5_RES

So, this is it for now… it’s an ongoing project and it depends on you how fast progress will be made.

  • Do you own an ATW800? We’re looking for brave testers!
  • Are you a VHDL hero? Grab the manual and do your thing!
  • Transputer nut? Feel free to check the schematic… I’m not swearing it’s 100% bug-free.

To be continued…

Atari, my love.

This blog post is due to the fact I was just reanimating my Atari 2080ST, which triggered lots of memories I urgently needed to write down… so here we go:
Yes, the 1st proper (i.e. not soldered) computer I owned was a C64… I loved it, really. I loved it for 3 years… and seriously dreamt about getting an C128D – until I’ve read the fist reports about that Atari 260ST.

I was hooked just by the specs on paper. For me it looked like a Macintosh but with a realistic chance to own one some fine day.
Actually there was a day in the beginning of 1985 when I sat with Heinrich-Hermann Huth, (one of the founders of later Application System Heidelberg, ASH for short) discussing what’s the best upcoming computer. He was 100% Commodore 128… until I started my Atari ST anthem.
Around June or July, he invited me to his parents house to “show me something exciting”. There it was, one of the first STs in Germany, serial number 6, directly picked-up at Frankfurt airport. TOS came on an awesome 3.5″ floppy, the included Basic was slow as hell and the the Digital Research SDK left me puzzled. C? Compiler? Linker?
It became clear that I have to learn a lot to be worthy for such a serious system.
Looking back I wonder if ASH would ever been founded without my evangelism 😉

So in early 1986 it was my turn: My Confirmation. This is a big deal over here and the most “profitable” observance. While the standard wish of kids in these days were big stereos, mine was clear.
Thanks to perfect timing, the 520ST just became 520ST+ and now had a whopping megabyte… it was heaven.

The glory of the 80s… bad jumpers and paper 3D-glasses.The right half shows the C64 moved into a far corner before it was sold to buy a 2nd floppy for my ST.

Just about that time, Application Systems Heidelberg was founded… in the child’s room of Heinrich-Herrmann, who somehow managed to get the exclusive distribution rights of Megamax C for Germany.
This proved to be a lucky pick, because the ST was taking the German market by storm and there was no good SDK available. So magazine ads were needed and I was the only one who had a design talent. This was my first design made with my brand new 520+:

The company logo was cut out and glued onto the b/w print which came out of a 9-needle-printer.

Mind the small pencil in the lower left corner. In German, that’s a “Stift”, which is also slang for “apprentice” – which was me 😆
There’s even an article about this ad in the german ST-Computer magazine over here (pg. 7/8).  Quote:

Doch selbst der Software­Gigant aus Heidelberg fing klein an: Auf einer Viertelseite bewarb die Firma in der Ausgabe 07­08/1986 das Megamax C­ Entwicklungssystem, gestaltet wurde die Anzeige mit der Systemschrift und den Füllmustern des STs.

Which translates into “Even the software giant from Heidelberg started out small: In issue 07-08/1986 the company advertised the Megamax-C SDK  on a quarter-page, designed using system fonts and the fill-patterns of the ST“.
Yeah, that’s all true. And “The Stift” was payed for this and other ads by being allowed to keep the glorious Citizen MSP-20 9-needle printer.

In the following years I spend my time mostly in 3 places: In school because I had to, at home in front of my Atari ST or in the ASH office because it was just so cool. During these days I did many thing for them:

  • Packed so many, many, many Megamax, Signum! and STAD boxes, labeled 100s of floppy-disks (was payed in M&M currency)
  • Some levels for Oxyd, Bolo and Esprit.
  • Some Signum! Fonts (forgot which ones, but they were in the 1st 251-Fonts book)
  • Phoenix Ornitho Database (containing samples of each bird singing)
  • The cartoon on the last page of their in-house magazine. Was quite a fancy oversized, glossy thing.
  • Probably 10 other things I forgot…

Icons and Infobox for Script v1

…and Scarabus.

Boy – this was definitely one of the top-5 times of my life. Thanks for this H3, Volker, Ojo (always in my heart), Karen (my heart ;)), Oili, Thomas and all the other great guys’n’gals from back then! Love y’all!

Atari 2080STF – a prototype?

I bought this Atari 2080STF in 2003 and stored it as-is in my collection. The ST being my first 16bit machine I thought it could be a good point in time to un-dust and resurrect it 16 years later.

Atari 2080STF2080??  Yes, that’s true. There are different stories out there about their prototype/fake status.
As far as I see, there are two 2080STF versions out there:

  • The “Yugoslavian Version”
  • My Prototype

The Yugoslavian 2080STF is a pretty simple re-batching of a 1040ST which was upped to 2MB RAM and sold by a company called Mladinska Knjiga.

My 2080STF is different. In contrast to the Yugoslavian it features a proper, 3d embossed label, not some flat DIY thing.
Instead of some serial# printing looking like made with a children-stamping kit it says this:

MarkeTTing Sample… should it have been an omen?

Marketting? Well… somebody’s been in a hurry or not native to English. Anyhow, the label shows the same quality as those used with Ataris produced in greater numbers. That said, there’s no serial number and the model ist just a paper-sticker.

Next unique thing is the floppy cut-out on the right side. It’s the same square one like on a Falcon, but the plastics are in the proper ST grey. Mhhhh….

Looks Falcon’ish, but it isn’t…

Finally the mainboard: Yes, it’s very 1040STFM without the M(odulator) part. But then it features a yet undocumented issue number of C100059, production week 8813. And mind the installed Blitter at the lower right.

Lots of ugly mods to be removed ASAP! But I’ll keep that IDE controller sitting on top of the 68k.

So what do we got here? Not having any matching-numbers system like in the vintage car world, we can only guess…
It might be a real “Marketing Sample” made for a planned pimp-up of the 1040 family. On the other hand it also can be a nicely composed Frankenstein system made of parts e.g. being sold at Ataris sell-out in 1995.
Given the sum of the unique parts being used, I opt for the “real marketing sample”, probably being put together using available parts and meant for checking out, if there’s a demand/market for such model(s)… and history taught us that there wasn’t.

Anyhow, I pulled out the crap which had been “installed” over the previous years…

Boy, look at that IDE “cable adaptor”… a soldering nightmare. And who needs more than 19200 baud anyhow?

So the noisy 2.5″ 80MB harddrive got replaced by a CF-Card which nicely fits where the modulator would be, if this would be a STFM.
Additionally I 3D-printed a mounting thing for it which you can download here.
Finally, the build-in Hard & Software TOS-Card II 2.06 (that’s a long product name!) got fixed so it actually can switch between the on-board TOS and the 2.06 sitting on the card.

When everything’s done, it looks nice and tidy down there:

Yeah, that’s a 4MB card… just for testing. I took a “spliced” IDE cable I made ages ago – does a good job to squeeze underneath the keyboard.

So I think I’m all set for some pure 8MHz 68000 fun… oh boy, did I love those days.

Carrera in an SE/30 – the code part 3

Ahh, back in cosy main: – looks much easier now after that crazy MMU stuff in the previous part, right?

The next subroutine called is proc32. In the complete source code (reminder: Available at GitHub) I commented that with “works (get some RSC strings)“… and well, that sums it up pretty good.
proc32 loads (i.e. creates handles) from the resource-fork, e.g. the icons used in the menu-bar and several error-messages like “This application must run on the 68030 processor, please quit all other 68040 applications and re-run this application.“. That’s it. Boring…

That boredom instantly changes when we get to the next subroutine proc43located at 0x29DA…

I did it my way…

One fascinating thing about classic Mac OS is how easy it is to patch system calls, aka Toolbox traps. For example in the previous post we came about _BlockMove, which is a Toolbox call to copy an amount of RAM from A to B.
For example you have just read this article about a faster BlockMove method, you’re totally free to patch (read: replace) _BlockMove with your speedier version and automatically use this throughout your application – or even system-wide, if you’ve created an INIT…  [If you want to know all about it… here’s a book for you]

And that’s what proc43 heavily does. Because it’s a long subroutine (230 lines) so I will give you just one example – the inline comments should do…

2BE2:        MOVE    #$A02E,D0     ; BlockMove
2BE6:        _GetTrapAddress newOS ; (D0/trapNum:Word):A0\ProcPtr 
2BE8:        MOVE.L  A0,$270(A5)   ; oldBlockmove
2BEC:        LEA     data42,A0     ; myBlockMove
2BF0:        TST.B   MMU32bit      ; loMem global "current address mode"
2BF4:        BNE.S   lae_70        ; skip if 32bit clean machine else
2BF6:        LEA     data43,A0     ; use a different entry for dirty machines
2BFA: lae_70 MOVE.L  A0,$274(A5)   ; save routine pointer to $274(A5)	
2BFE:        LEA     data41,A0     ; DC.L 0000 0000
2C02:        MOVE.L  $270(A5),(A0) ; save oldBlockmove vector into there
2C06:        MOVE.L  #$A02E,D0     ; BlockMove
2C0C:        LEA     data40,A0     ; aaaand replace it by myBlockmove
2C10:        _SetTrapAddress newOS; (A0/trapAddr:ProcPtr; D0/trapNum:Word)

This is the sum up what else being done:

  • Save all debugger vectors into A5-world locations (suspicious. I sense Macsbug killing…)
  • Load the PACK4 resource, that’s the Floating Point emulation package (aka SANE) if no FPU found
  • Check & read several system Gestalt codes into A5-world (0x2AAC-0x2B44)
  • Patch several Toolbox traps
    • SwapMMUMode replaced by data19
    • VM_Displatch by data22
    • Pack4 by data10
    • Pack5 by data11
    • BlockMove by data40
    • jClearCache by myClearCache
    • GetNextEvent by myGetNextEvent
    • GetResource by myGetResource
    • SCSIdispatch by mySCSIdispatch
    • DrawMenuBar by myDrawMB
    • LoadSeg by data31
    • UnLoadSeg by data32
    • HWPriv by data33
    • vStdExit by data34

So far, so many.  Then there’s some RAM copying going on, of which I’m currently not quite sure what it is good for (0x2CAC-0x2CD8) 💡 .

Finally, the myShutdown routine is installed into the Shutdown Manager, i.e. it will executed before the Mac is powered down/restarting (it simply switches the host back to its own 68030). After that, RTS into main…

“There and back again…”

Barely back in main, a JSR 12(A6) warps us into MacII_4th, the last of the four handlers every supported system has.

This loads specific data from the FPSP into RAM (namely IDs 0x12C and 0x12D).
Finally a special floppy driver is installed (myFloppyDrvr @ 0x954) which IMHO just differs from the original in handling the ‘040 caches correctly. That was that and back to main…

The next sub-routine in line is chkATalkVer. I can rightfully name that routine because it’s short and crystal clear: Figure out if AppleTalk is installed, and if true, return its version in D0 (and also write it into A5-world). C’est ca…

This is the end…

It’s getting ugly (for now)… proc42 will be called – the last subroutine in main before my SE/30 crashes and burns  😥

The first few lines (0x28F4-0x293C) are comparably harmless. They are working around a bug in System 7.1 which was corrected in 2/17/92 according to some dark sources (“Corrected value of timeSCSIDB from 0DA6 to 0B24”).
After that, proc38 (0x293C) is called which again calls proc39 and something’s done with the TimeManager, not really sure what’s exactly going on, but it feels like a timing-benchmark heavily using InsTime, PrimeTime and RmvTime Toolbox calls.

[hold yer breath] Then we’re getting closer to the flat line… The stack is filled with these parameters:

2940:   CLR.L   -(A7)       ;PUSH.L 00000000 
2942:   CLR.L   -(A7)       ;PUSH.L 00000000 
2944:   CLR.L   -(A7)       ;PUSH.L 00000000 
2946:   PUSH.L  #$80008000  ;       80008000
294C:   CLR.L   -(A7)       ;PUSH.L 00000000 
294E:   PUSH.L  #64         ;       00000040
2954:   PUSH.L  #1          ;       00000001

and SpeedProc is called…

…To be continued 😉

P.S: I changed course (again) and started to investigate more into the C040’s hardware. The more I understand of the INIT/CP workings the more I can’t fight the idea that it really might be a hardware timing issue.

Carrera in an SE/30 – the code part 2

3rd handler

Next up is the 3rd handler, MacII_3rd: (0x3F94) in our case. Actually it’s called with JSR 8(A6), but that’s an 8 byte offset to the ‘base-address’ of any handler. Clever stuff, huh (Google for ‘pointer-table’)?

This subroutine contains serious magic and was a real hard nut to crack. Especially because it tricked me into believing that I’ve found the ‘crashsite’… which, to spoil the tension, isn’t.
It just kept on killing  Macsbug, because it’s so low-level.

What this routine does is replacing the Vector Base Register (VBR) which ‘lives’ at address 0x00000000. Evil stuff.

  • After disabling interrupts and switching to 32bit-mode a field with 6 long-words (data107) will be populated with data generated in other routines.
    For now I can only guess what these entries are (Values from my SE/30 given in brackets). We’ll discuss all that further down.
  • 0x3FC6 to 0x3FD8 calculates the size of the chunk of code starting at data106 (0x4008) to the beginning of MacII_4th (i.e. the end of Mac_3rd), which is 180 bytes.
  • Using this length, the routine first saves the current VBR onto the stack using the system call _BlockMove.
    Then the original VBR (+some more) will be replaced by the new version beginning at data106. (Killing Macsbug – more on that later)
  • BSR 53_cmd_1x is been called. This brings the Carrera040 into life most likely using the just copied VBR (This is discussed in much detail further down).
  • Now the contents of the stack (= copy of the original VBR) will be copied back into its place, this time using a classic DBRA loop (0x3FF4). My guess, no Toolbox call possible at the moment.
  • Adjust the stack, back to 16bit mode, restore Registers and return-from-subroutiene. Done.

Here’s the code doing all this:

3F94:MacII_3rd: MOVE    SR,-(A7)     ; 3rd call from MacII handler
3F96:           ORI     #$700,SR       ; Set bit 9-11 of SR (disable Interrupts)
3F9A:           MOVEM.L D0-D2/A0-A2,-(A7)
3F9E:           MOVEQ   #1,D0
3FA0:           _SwapMMUMode  
3FA2:           PUSH.B  D0
3FA4:           SUBA.L  A2,A2         ; faster movea.l #0,a2
3FA6:           LEA     data107,A0    ; Filling the data into the 6x32 field
3FAA:           MOVE.L  96(A5),D0
3FAE:           MOVE.L  D0,(A0)+      ; SE30: 9FE00
3FB0:           LEA     data69,A1
3FB4:           MOVE.L  A1,(A0)+      ; SE30: 9D6E2 (User/Supervisor Rootpointer?)
3FB6:           MOVE.L  $64(A5),(A0)+ ; 807FC040
3FBA:           MOVE.L  $6C(A5),(A0)+ ; 807FC040
3FBE:           MOVE.L  $68(A5),(A0)+ ; 00000000
3FC2:           MOVE.L  $70(A5),(A0)+ ; 00000000
3FC6:           LEA     MacII_4th,A0
3FCA:           MOVE.L  A0,D2
3FCC:           LEA     data106,A0
3FD0:           SUB.L   A0,D2         ; 'distance' from data106 to MacII_4th
3FD2:           SUBA.L  D2,A7
3FD4:           MOVEA.L A2,A0
3FD6:           MOVEA.L A7,A1
	  	; save the current VBR to the stack
3FD8:           MOVE.L  D2,D0
	  	; A0 = SE30: 00000000 (src)  - IIci: $FBB08000
	  	; A1 = SE30: 027ff34c (dest) - IIci: $3BF9FC6
	  	; D0 = B4    (count)   - SAME on the IIci!    
3FDA:           _BlockMove ; (A0/srcPtr,A1/destPtr:Ptr; D0/byteCount:Size) 
	  	; write my own VBR...
                ; This copies 180 bytes into 0x000000000 replacing the original VBR. 
                ; ... and kills Macsbug if not circumvented properly.
3FDC:           LEA     data106,A0
3FE0:           MOVEA.L A2,A1
3FE2:           MOVE.L  D2,D0
	  	; A0 = 9F900 (src)   - IIci 10C4EA (data88)    
	  	; A1 = 00000 (dest)  - IIci FBB08000
	  	; D0 = B4    (count) - IIci same  
3FE4:           _BlockMove ; (A0/srcPtr,A1/destPtr:Ptr; D0/byteCount:Size) 
3FE6:           BSR     53_cmd_1x  ; Bring the C040 to life
3FEA:           MOVEA.L A7,A0  ; SP to A0
3FEC:           MOVEA.L A2,A1  ; SE30: 00000000
3FEE:           MOVE.L  D2,D0  ; the code length (B4 again)
3FF0:           BRA.S   lae_163
3FF2:   lae_162 MOVE.B  (A0)+,(A1)+ ; Write the VBR back from the stack
3FF4:   lae_163 DBRA    D0,lae_162
3FF8:           ADDA.L  D2,A7 ; adjust the stack
3FFA:           POP.B   D0
3FFC:           _SwapMMUMode  
3FFE:           MOVEM.L (A7)+,D0-D2/A0-A2
4002:           MOVE    (A7)+,SR
4004:           MOVEQ   #0,D0
4006:           RTS     
 
; Start of VBR replacement- and 040-Code being copied to 0x0 the by line 0x3FE4 
; /if/ theses are the Vectors 0-17, then their meaning would be:
 
4008: data106:  DC.L    #$00001000 ; Reset initial Stack Pointer
400C:           DC.L    #$00000050 ; Reset initial Program Counter
; - ALL of these Vectors point to addr 4050 (offset 0x48) -
4010:           DC.L    #$00000048 ; Buserror  
4014:           DC.L    #$00000048 ; Adress Error
4018:           DC.L    #$00000048 ; Illegal Instruction
401C:           DC.L    #$00000048 ; Zero Divide
4020:           DC.L    #$00000048 ; CHK, CHK2 instruction
4024:           DC.L    #$00000048 ; cpTRAPcc, TRAPcc, TRAPV instruction
4028:           DC.L    #$00000048 ; Privilige Violation
402C:           DC.L    #$00000048 ; Trace
4030:           DC.L    #$00000048 ; LINE 1010 Emulation
4034:           DC.L    #$00000048 ; LINE 1111 Emulation
 
; THESE are definitely no vectors, they are dynamically written by the code above
; and to be used to setup the 040 MMU registers.
4038: data107:  DC.L    #$0009FE00 ;  
403C:           DC.L    #$0009D6E2; 
4040:           DC.L    #$807FC040 ; 
4044:           DC.L    #$807FC040 ; SE30: 
4048:           DC.L    #$00000000 ; SE30: 00000000 
404C:           DC.L    #$00000000 ; SE30: 00000000 
 
4050:           CLR.L   $53000000  ; Poke 0 to $53000000
4056:           BRA     lae_164    ; This points to itself... I'm lost at the moment.
4058:           LEA     data107,A0 ; SE30: 9F900
405C:           MOVE.L  (A0)+,D1   ; SE30: 0009FE00 (User/Supervisor Rootpointer)
405E:           MOVEA.L (A0)+,A1   ; 0009D6E2
4060:           MOVE.L  (A0)+,D4   ; 807FC040
4062:           MOVE.L  (A0)+,D5   ; 807FC040
4064:           MOVE.L  (A0)+,D6   ; 00000000
4066:           MOVE.L  (A0)+,D7   ; 00000000
4068:           MOVE.L  #$C000,D0
406E$           MOVEC   D0,ITT0   ; Set Instruction Transparent Translation
4072$           MOVEC   D0,DTT0   ; Set Data Transparent Translation
4076$           MOVEC   D1,SRP    ; Set Supervisor Rootpointer
407A$           MOVEC   D1,URP    ; Set User Rootpointer
407E:           MOVE.L  #$C000,D0
4084$           PFLUSHA           ; Invalidates all entries in the address translation cache
4086$           MOVEC   D0,TC 
408A:           LEA     data108,A0
408E:           ADDA.L  #$53002000,A0 ; (=0x530A1900)
4094:           JMP     (A0)      ; JuMP to data108 code (below) in C040 RAM range?     
 
4096:  data108: MOVEQ   #0,D0
4098$           MOVEC   D0,ITT0 
409C$           MOVEC   D0,DTT0 
40A0$           MOVEC   D4,ITT0 
40A4$           MOVEC   D5,DTT0 
40A8$           MOVEC   D6,ITT1 
40AC$           MOVEC   D7,DTT1 
40B0$           CINVA   BC
40B2:           NOP     
40B4:           MOVEQ   #0,D0
40B6$           MOVEC   D0,CACR
40BA:           JMP     (A1)    ; 0009D6E2
 
; END 040 Code being copied to somewhere by line 3FE4 
40BC: MacII_4th: MOVEM.L D1-D7/A0-A4,-(A7)  ; 4th subroutine called my MacII_handler
[...]

The Vector Base Register

I wasn’t precise when I initially said “replacing the VBR”. What actually happens is that this routine uses what I’d call an interim-VBR for the moment it initializes the 68040 on the C040. You’ve probably saw the link referring to what the VBR is in the 1st post of this series, but let me go a bit more into detail.

The VBR is a list of addresses (aka vectors) the CPU refers to in case of an exception – and this is true for every 68k system out there, e.g. Mac, SUN, NeXT, Amiga or Atari. Some of them might do some relocation using their MMU, but even the virtual address will be 0x00000000 and the order is the same.  There are 16 basic vectors as listed here:

If for example a divide-by-zero happens, the CPU would call a handler which address is stored in 0x14.  Pretty simple.
So let’s have a look what MacII_3rd left in the VBR (and below that) when the ‘interim VBR’ is in place:

0000: data106:  DC.L    #$00001000 ; Reset initial Stack Pointer
0004:           DC.L    #$00000050 ; Reset initial Program Counter
     ; - ALL of these Vectors point to addr 0x48 -
0008:           DC.L    #$00000048 ; Buserror  
000C:           DC.L    #$00000048 ; Adress Error
0010:           DC.L    #$00000048 ; Illegal Instruction
0014:           DC.L    #$00000048 ; Zero Divide
0018:           DC.L    #$00000048 ; CHK, CHK2 instruction
001C:           DC.L    #$00000048 ; cpTRAPcc, TRAPcc, TRAPV instruction
0020:           DC.L    #$00000048 ; Privilige Violation
0024:           DC.L    #$00000048 ; Trace
0028:           DC.L    #$00000048 ; LINE 1010 Emulation
002C:           DC.L    #$00000048 ; LINE 1111 Emulation
     ; - THESE are definitely no vectors, they are dynamically written by the 
     ;   code above and to be used to setup the 040 MMU registers.
0030:  data107: DC.L    #$00000000 ; SE30: 0009FE00  (12)
0034:           DC.L    #$00000000 ; SE30: 0009D6E2  (13)
0038:           DC.L    #$00000000 ; SE30: 807FC040  (14) 
003C:           DC.L    #$00000000 ; SE30: 807FC040  (15)
0040:           DC.L    #$00000000 ; SE30: 00000000 
0044:           DC.L    #$00000000 ; SE30: 00000000 
 
0048:           CLR.L   $53000000  ; Poke 0 to $53000000 ; C040 off
004C:  blocker3 BRA     blocker3    ; Points to itself... probably a "blocker"
0050:           LEA     data107,A0 ; initial Program Counter (SE30: 9F900)
0054:           MOVE.L  (A0)+,D1   ; SE30: 0009FE00 (User/Supervisor Rootpointer)
0058:           MOVEA.L (A0)+,A1   ; 0009D6E2
005C:           MOVE.L  (A0)+,D4   ; 807FC040
0060:           MOVE.L  (A0)+,D5   ; 807FC040
0064:           MOVE.L  (A0)+,D6   ; 00000000
0068:           MOVE.L  (A0)+,D7   ; 00000000
006C:           MOVE.L  #$C000,D0
0070:           MOVEC   D0,ITT0    ; Set Instruction Transparent Translation
0074:           MOVEC   D0,DTT0    ; Set Data Transparent Translation
0078:           MOVEC   D1,SRP     ; Set Supervisor Rootpointer
007C:           MOVEC   D1,URP     ; Set User Rootpointer
0080:           MOVE.L  #$C000,D0
0084:           PFLUSHA            ; Invalidates all entries in the address translation cache
0088:           MOVEC   D0,TC 
008C:           LEA     data108,A0
0090:           ADDA.L  #$53002000,A0 ; (=0x530A1900)
0094:           JMP     (A0)       ; JuMP to data108 code (below) in C040 RAM range? 
 
009C:  data108: MOVEQ   #0,D0
00A0:           MOVEC   D0,ITT0 ; 0
00A4:           MOVEC   D0,DTT0 ; 0
00A8:           MOVEC   D4,ITT0 ; 807FC040
00AC:           MOVEC   D5,DTT0 ; 807FC040
00B0:           MOVEC   D6,ITT1 ; 00000000
00B4:           MOVEC   D7,DTT1 ; 00000000
00B8:           CINVA   BC
00BC:           NOP     
00C0:           MOVEQ   #0,D0
00C4:           MOVEC   D0,CACR
00C8:           JMP     (A1)    ; 0009D6E2
Farewell, old friend

At this point, my SE/30 always froze and I thought this must be the point where to find incompatibilities between the IIci and SE/30.
But after understanding, what’s really going on, it was clear that overwriting the TRAP exception (Nr.7), Macsbug was simply kicked out of the game as this exception is triggered after every step/trace you do in a debugger…
So to get beyond this point, I had to modify the program counter to skip the point where TRAP is copied-over… which is done inside the Toolbox’ _BlockMove call. So I had to single-step into that and find the right call/time to do a ‘pc=pc+2’ 😉 (Good thing you can define a macro for that).

Okayyyyy. After that’s been written, 53_cmd_1x is called, presumably telling the C040 to come to life.
And keen as it is, it’ll look up the “Reset initial Program Counter” (VBR: 0xC) and starts executing code from 0x50. Any other occurring exception will call the ‘handler’ at 0x48, simply switching the C004 off and sit in an endless loop (0x4C) – probably making the 68030 to take over again.

EmEmYou!

Given everything’s fine, the code at 0x50 will start reading the previously populated data from data107 into several registers.
Then some serious 68040 MMU table setup happens – so this is some kind of ‘040 initialization routine… and the ‘040 is actually running. Woohoo!

Time for some special register explanation:
As we all know, the 68040 has two in-build 4k caches and an MMU. The latter can be programmed how and what to cache. This is defined in 4 registers of which only 2 are of interest here: ITT0 and DTT0, the Instruction and Data Transparent Translation registers, both sharing the same bit-fields following this pattern:

BBBBBBBBMMMMMMMMESS000UU0CC00W00

  • BLogical Address Base – compared with address bits A31-A24. Addresses that match in this comparison are transparently translated
  • MLogical Address Mask – setting a bit in this field causes corresponding bit in Base field to be ignored
  • E – Enable Bit – 1 – translation enabled; 0 – disabled
  • SSupervisor Mode – 00 – match only in user mode 01 – match only in supervisor mode 1x – ignore mode when matching
  • U – User Page Attributes – ignored by 040
  • CCache mode – 00 – Cacheable, Write-through 01 – Cacheable, Copyback 10 – Noncacheable, Serialized 11 – Noncacheable
  • WWrite protect – 0 – write permitted; 1 – write disabled

Here’s an example:

807FC040 = 10000000011111111100000001000000 
           BBBBBBBBMMMMMMMMESS000UU0CC00W00

which means:

  • a bit less than 2GB transparently translated (2032MB)
  • translation enabled
  • Supervisor Mode: ignore mode when matching
  • Cache mode: Noncacheable, Serialized
  • Write permitted

So let’s have a look at the code again:

At 0x70/0x74 the MMU is set to 0xC000, i.e. Enable translation, apply for user & supervisor mode, write-though cache, for logical address space 0x80000000-0x00ffffff (2GB minus the bottom 16MB).
Then Supervisor & User Rootpointer are set to 0x9FE00, then the address translation cache is flushed to finally set the Translation Control register to Enable & 8K page size (0x88)… up to here this was pretty much ‘by the book’ of how to set-up MMU tables.

Having its MMU all set, the 68040 now gets something to chew on:
The address of data108 is added to 0x53002000 and jumped to!
💡  Does 0x53002000 equal 0x00000000 for the C040?

Let’s assume the C040 executes the code at data108 for now. That is:

  • Clear the ITT/DTT registers
  • Set the MMU to 0x807FC040 (see decoding example above)
  • invalidate caches and wait’a’NOP to have that happened
  • then disable all caches
  • and jump to where A1 points to. In my SE/30 that’s 0x9D6E2, previously loaded from data107 in 0x58

Writing all this from the top of my head, I’m not 100% sure where this address is pointing to. I must be somewhat back into MacII_3rd (0x3FEA), because this is where the program execution resumes (Need to check this with Macsbug and will update).

For now, I’m tempted to call MacII_3rd something like ‘C040_MMU_setup‘… but I’d love to have this confirmed  💡 by somebody who knows more than me 😉

Next up will be continuing working further through the main: procedure again… so move over here.