sslxy

The story behind the code

Since 1996 I have supported the web presence of the Hotel Goldener Ochsen in Hohenstaufen from a technical side with a rather simple basic attitude: build things cleanly, keep them understandable, and maintain them in a way that keeps them readable and useful later on. This way of working has proved itself not only there, but also in other web projects.

What matters to me is the separation in time. 1996 is the beginning of the web work. The technical story behind it begins earlier. As early as from 1979 onward, the basic mindset was shaped by early computer experience. From 1983 onward, this turned into a small circle in which floppy disks, repairs, improvisation and shared experimentation were part of everyday life. In the wider circle there were around 15 teenagers. The small fixed core consisted of 5 – our hard core, which we half ironically called the crazies among ourselves. In 1994, transition systems such as the two C65 units came within reach. Only after that did shell accounts, HTML and log files turn into the later visible web layer.

The hotel website was not constantly reinvented, but developed quietly over many years – step by step. That still fits my approach far more than any talk about major redesigns.

I am neither a software architect nor an agency. In truth I am simply someone who started writing HTML in 1996, but whose technical way of thinking had already been shaped many years before. Perhaps that is exactly why I preferred to stay with clear structures while much around me kept becoming more complicated.

Today, that attitude also includes testing modern tools such as AI models and cloud services in real use. Not out of enthusiasm for buzzwords, but in order to recognize usefulness, limits and unnecessary ballast in practice. And that quite consciously includes not only free entry points, but also paid variants when that is the only way to judge what a tool can actually do.

I tend to maintain this system like an old garden: by hand, without large machines, and with a lot of patience. My knowledge of PET, VC 20, C64, Amiga and other older systems is now mainly a private archive hobby. But something important for my work has remained from it: a preference for order, calmness and technical clarity.

I like it when things still work after decades without needing a whole team of specialists. To me, good code is like a neatly arranged toolbox: not spectacular, but clear, reliable, and built so that you can find everything again without thinking.

Why the name sslxy stayed

The name sslxy emerged in late 1995 / early 1996 not as an artist name, not as a deliberately invented pseudonym, and not with any thought of deeper meaning. It arose simply from practical necessity.

What is meant here is my first self-programmed website on a shell account, not yet the Ochsen website. I had indeed been working on the Ochsen site during 1995, but it only went online on 30 December 1995. The shell account needed a short username – for FTP, CGI and log files. The internal server name was ssl-server-xy.

ssl stood for early SSL experiments, among other things with SSLeay on FreeBSD – the direct predecessor of OpenSSL, still actively developed in the mid-1990s – and with self-signed certificates. xy was a simple identifier for a test system – in the sense of machine Y, because X was already taken.

One of the first log files was called sslxy.log. The string simply remained – first technically, later also outwardly: for Usenet, mail and static pages.

There is really no more behind it. No alias in the classic sense, no deeper meaning, no staged figure. More a technical leftover that remained because it worked.

“No alias. No deeper meaning. More a filename that simply stayed.”

File overview and existing subpages

This page is the quiet overview. The deeper individual topics already live on their own files. That way sslxy.htm remains the main map, while the specific device, attitude and archive topics are distributed across the matching subpages.

All listed files are visibly anchored here. The main page explains the line, the subpages carry the depth.

From the PET 2001 to the Amiga – some systems that remained

The technical history behind SSLXY is more than just a list of old machine names. Each of these computers stands for a certain experience, a different way of working, and a technical understanding built over many years.

One thing matters here: the following systems are not meant to create the impression that they were somehow collected around 1996 in order to decorate a story afterwards. The roots of this technical biography go back to 1979 onward. From 1983 onward it became a small practical circle. In the wider circle there were around 15 teenagers, with a fixed core of 5. The later machines and archive pieces build on that.

More than an overview is on the dedicated chronicle page systems.htm. The larger device map with further cross-links is on hardware.htm.

The hard core

What later became visible as web work had its practical origin much earlier. From 1983 onward there was a small circle of like-minded people. Not official, not polished, and usually organized quite pragmatically. We met, compared systems, brought floppy disks, tested software, talked about expansions, and kept trying things out.

In the wider circle there were around 15 teenagers. The small fixed core consisted of 5 – our hard core, which we half ironically called the crazies among ourselves. It was not an official group and not a heavily staged name, but more the rough direct tone of that time.

This also included contact with a computer shop at the time, where we sometimes got parts or software at a better price. Occasionally that simply grew from the fact that we helped normal customers or even the shop itself with hardware and software problems. For exactly that reason, this circle was not a pose, but technology actually lived in practice.

It was also the time when we repaired game consoles and other devices, including Atari, ColecoVision, Vectrex and cassette recorders. We also repaired Video 2000 and Betamax machines within our abilities, VHS rather less often. That was often how it worked: not as a fixed system, but out of personal contact, technical knowledge and mutual support.

It also included typical improvised solutions of that era: an interface was built into a Triumph-Adler Gabriele 8008 typewriter so it could be used as a printer on the C64. First experiments with self-built acoustic couplers also belong to that time. Precisely such improvisations were formative, because one did not merely use technology, but actually understood it and learned it step by step. Naturally, a lot also went wrong, and often those mistakes taught the most.

There were cables, manuals, printouts, floppy boxes, notes, screwdrivers and sometimes even a soldering iron lying everywhere, along with open devices and often parts whose purpose was no longer immediately obvious. Exactly this workshop atmosphere mattered. Technology was not merely used, but understood, discussed and thought further in small steps. The small circle from back then can now only rarely meet in person, because life has long since taken everyone in very different directions. But from time to time contact still exists over the net.

“In the wider circle around 15 teenagers. The small fixed core: 5 – internally simply the crazies.”

This small chaos was not pointless. Understanding grew out of it. One learned not only how something starts, but also why it works. One learned how to organize systems, build them logically and get them running again when problems occurred. Anyone with such experience later values clean structures not from theory, but from practice.

• Do not merely use technology, but understand it.
• Do not merely save things, but archive them in an organized way.
• Do not merely make something run, but keep it manageable.
• Do not rely on showmanship, but on robust logic.

The more detailed pages for workshop, repairs and the quieter technical attitude are werkstatt.htm, interfaces.htm and repair-attitude.htm.

Two C65 units – for understanding, not for display

The two C65 units came into my surroundings in 1994 not as collectors' items, but more as a technical puzzle. Someone I knew from the Commodore environment asked me at the time whether I would be interested in two C65 units. The situation was already tense by then, and I had the impression that it mattered less to him to pass them on in an ordinary way than to place them in reliable hands.

Shortly afterwards he sent them to me by post. Perhaps that is why my view of them has remained pragmatic to this day: I do not see trophies in them, but systems that you switch on, compare and examine in their architecture.

From a technical point of view, the C65 is a fascinating transition system. One quickly recognizes the attempt to expand the familiar 8-bit world without entirely abandoning its Commodore lineage. The CSG 4510 as an extended CPU and the VIC-III (CSG 4567) clearly point beyond the classic C64: higher resolutions, more colours, a different register logic, and overall the impression of a system that was already thinking in a new direction. The integrated 3.5-inch drive also follows a completely different order from the familiar external 1541 peripheral world.

A particularly revealing detail is the power supply. Externally it sits in a standard C64 housing with the corresponding embossing, but internally the circuitry was adapted for operation with the C65. Exactly such improvised transition solutions tell me more than any smooth production product, because they make the development process visible. One can see how hardware was rethought under time pressure, with existing housings, and with practical modifications.

The fact that the entire accompanying environment has survived to this day – cartons, styrofoam, foils and even the power-supply boxes – I see mainly as a lucky case for documentation. For me it is not a question of increasing value, but a rare chance to reconstruct the original delivery state of a system that never actually reached the mass market in a normal way.

At the moment I consciously mention only one serial number publicly: 000213. With such computers it was never my aim to mark them as loudly as possible. What interests me more is the quiet analysis of a technical intermediate stage that shows, in many details, where Commodore might have gone next. For me the C65 is therefore above all one thing: hardware and system logic to understand, not to show off.

“I did not look at rarity, but at how a system was actually conceived.”

The dedicated deep page remains c65.htm. The power-supply topic connects directly with power-supplies.htm.

C65: the technical bridge between 8-bit origins and a new system logic

The two C65 units that reached me in 1994 through a Commodore contact are, to me, above all witnesses of an unfinished evolution. Once you open the case, you see an architecture that was meant not only to extend the C64, but to surpass it clearly in several points. At the centre is the CSG 4510, an extended 65xx CPU running at 3.54 MHz, with additional bit operations and a relocatable zero page. Precisely there one can see how strongly the C65 still grows out of the 8-bit world, while already pointing toward another direction.

The graphics unit CSG 4567 VIC-III is especially revealing. While the C64 was bound to clearly limited graphics modes, the VIC-III already works with a significantly extended register and graphics logic, including bitplane structures, high resolutions of up to 1280 × 400 pixels and a palette of 256 out of 4096 colours. What is remarkable is not only the raw capability, but also the fact that the connection to the older Commodore world remains visible in several places. Exactly this mixture of the familiar and the new is what makes the C65 so technically interesting.

The peripheral logic was also rebuilt in a noticeable way. The removal of the datasette port and the addition of the fast-disk port for the 3.5-inch drive clearly mark a break with the cassette era. Also interesting for a technician: the user port no longer supplies 9V AC, which limits compatibility with older expansions, while the expansion port was enlarged to 50 pins. Details like this show that the C65 was not meant to be merely a larger C64, but an independent step into a new system order.

One almost casual detail underlines the prototype status even further: the power supply sits in an ordinary C64 housing, but was internally adapted for the specific requirements of the C65. These are exactly the inconspicuous transition solutions that speak most strongly to me, because they make visible how hardware development often looks in reality: pragmatic, solution-oriented, and frequently based on already existing case shapes and parts.

The fact that the entire accompanying environment – from styrofoam to the power-supply box – is still preserved today allows an unusually unfiltered look at this system. For me, the C65, and specifically the publicly mentioned unit 000213, remains not a showpiece, but an object for understanding, for testing register logic, and for reconstructing a technical vision that was stopped just before the finish.

“It is often the unfinished transitions that tell more about technology than the finished production product.”

The Amiga 1000 – an architecture study and restoration

I did not acquire my Amiga 1000 as a display piece, but took it over as a defective system from an acquaintance. For me, the aim was never possession of an early milestone, but the technical challenge of understanding the first Amiga generation in its original form and making it operational again. Whoever repairs a system usually learns the logic of the board better than any pure user.

Technically, the A1000 is especially interesting because of its Writable Control Store (WCS). Since Kickstart was not yet fixed in a classic ROM, the system has to load it from a bootstrap disk into a special 256 KB memory. This boot procedure in particular shows how experimental and open the early Amiga phase still was. When opening the case, one also encounters the engraved signatures of the developers around Jay Miner – a detail that still makes the close connection between hardware layout and personal handwriting tangible.

The decentralized architecture remains especially fascinating. While many other systems of the period burdened the main CPU with graphics and sound tasks as well, the Amiga distributes the work to its own chips such as Denise for graphics and Paula for audio and floppy logic. Even the so-called keyboard garage under the case and the early Amiga checkmark logo belong, for me, to those functional decisions that lifted the machine above the mass of home computers of the time.

For me the A1000 is therefore far more than just the first Amiga model. It is a system to work with, to understand early OCS logic, and proof that good technology can still be brought back into a traceable and usable condition after decades through targeted maintenance. Precisely because it was a defective machine, it was instructive: during restoration, myth does not matter – the real structure of the board does.

“Bought as a defective unit, repaired out of curiosity – hardware understanding begins on the board.”

The Amiga 2000 – sober system architecture instead of living-room design

The Amiga 2000 never worked for me through any emotional aura. It was rather the practical answer to the question of an expandable work system. While the smaller models aimed more at the living room table, the A2000 felt from the beginning more sober, more technical, and much more open to serious expansions.

From a technical point of view, what impresses most about the A2000 is the clear bus and expansion logic. With its Zorro II slots and AutoConfig, it offered a remarkably comfortable expansion structure for its time. There was also the video slot for matching additional hardware and the ISA slots, which became especially interesting in combination with bridgeboards. Precisely this open architecture made the machine convincing: not as a showpiece, but as a system that could be adapted, tested and thought further.

Even the rear side of the case shows this attitude very clearly: serial and parallel interfaces, external floppy connection, separate audio outputs, and overall an arrangement that looks less like decoration than function. It was not playful design, but a clear technical surface. For that reason alone, the A2000 felt more like a serious work machine than a mere home computer for quick use on a television.

Technology like the A2000 makes it clear that one does not have to be at the mercy of systems. The accessibility of the internal structure and the clear arrangement of the components made it possible not only to accept expansions and problems, but to really understand them. That is where its credibility lay for me: no flattering appearance, but substance, order and the freedom to rebuild a system according to one’s own requirements.

“Not spectacular in appearance, but consistent in structure – hardware you can truly understand.”

The Amiga 500 – redundancy and relief for the main system

I originally bought the Amiga 500 as a second machine alongside my A2000. The logic behind it was purely pragmatic: spare the larger desktop system for serious work and more extensive expansions, while the A500 served as a robust everyday machine – for direct work, for testing, and of course also for games. While the A2000 focused more strongly on expandability, the A500 was the compact and technically closely related solution for immediate access.

Architecturally, the A500 is based on the same solid foundation: a Motorola 68000 CPU running at 7.09 MHz in PAL mode, and the proven OCS chipset. What distinguished it was the concentration on essentials inside the compact wedge case. The trapdoor slot on the underside in particular was a practical solution for quick memory expansions, usually with an A501 or a comparable module. In practice, that often meant more calm in everyday work and a system that felt noticeably more relaxed, even if that extra memory was not always fully available as chip RAM depending on the configuration.

Despite its home-market orientation, the A500 remained a serious system. Through the side expansion connector, the machine could be extended with hard-drive solutions, additional fast RAM or other hardware. That is exactly what made it interesting to me: not merely as a games machine, but as a reliable reserve alongside the main system. While the A2000 was the more expandable centre, the A500 could absorb a lot without forcing the larger machine to be used for every minor task.

Games on the Amiga 500 were never merely pastime for me. They showed very clearly what clean programming and well-matched hardware could do. On the A500, Kickstart was already in ROM; Workbench, games or other software then came from disk. Precisely this direct, clear way of working shaped my understanding of efficient code: switch the system on, insert the disk, work or play – without unnecessary detours, without artificial heaviness.

That is why the A500 was more to me than just a little brother to the A2000. It was redundancy, relief, and at the same time proof of how much technical quality can live inside a compact system. The machine seemed simpler, but it was anything but trivial. Its strength lay precisely in this mixture of accessibility, clarity and robust everyday usefulness.

“The A500 was insurance for my A2000 – and proof that directness and technical quality belong together.”

The Amiga 4000 Tower – an early system from the final Commodore period

A special point was my Amiga 4000 Tower in early 1994. It was not a later rebuild, but an original Commodore machine with serial number #0000098.

For me, the attraction lay in the internal substance. The machine runs with a Motorola 68040 at 25 MHz on the legendary A3640 processor card. Added to that are the AGA chipset with Alice, Lisa and Paula, Super Buster 11, Ramsey 7, and the integrated NCR-53C710 SCSI-2 controller. One does not see such details from the outside, but they say a great deal about how serious and clearly built this machine was.

The basic architecture was also strong: 2 MB chip RAM, 16 MB fast RAM on the mainboard, a lithium battery and two 1.76 MB floppy drives. Added to that were the internal buffered IDE connector, Fast SCSI-2 operation through the integrated controller, and the internal 50-pin SCSI bus. For my two SyQuest removable drives, that was not a gimmick, but a very practical and clearly organized working environment.

The true tower potential, however, lay in expansion: five Zorro III slots, two video slots, four ISA slots and the CPU slot. Such a system did not feel like a closed device, but like a platform that already assumed serious expansion and orderly work from the outset.

The idea behind it was simple. Do not mix system and data unnecessarily. Organize media in such a way that one can continue working quickly if something fails. If one drive failed, the next removable cartridge went in – and work continued.

Experiences like that still shape the view of software and web development today. Anyone who has once learned to build systems consciously later pays automatic attention to structure, maintainability and a clean technical foundation in code as well.

“It was never only about rarity, but always about the technical clarity of a system.”

The large dedicated page remains amiga4000t.htm. The removable-media page connected to it is syquest.htm.

From Amiga to PC – not a rupture, more a quiet transition

My move from the Amiga 4000 Tower to a PC system did not arise from a conscious decision in favour of a new platform, but rather from a quiet shift in practical reality.

The A4000T was technically clean, understandable and coherent in itself. Expansions, mass storage, system structure – everything was ordered and manageable. That fit my idea of a good computer.

Over time, however, the problem became less the hardware itself than the surrounding environment. Software was harder to obtain, data exchange became more complicated, and many tools moved onto systems that were more widely used. At some point, the decisive issue was no longer which system was technically more convincing, but on which system work could still be continued sensibly in everyday life at all.

The first Windows PC on which this transition became concrete for me was a Sony VAIO PCV-R702. On such a machine the shift became very clear: away from the familiar Amiga world, toward a system that convinced less through technical elegance than through practical integration into the software and work environment then available.

The PC with Windows was therefore not a conscious turn toward something supposedly more modern, but simply the platform on which things continued to develop. Drivers, programs, interfaces and exchange were available there – not necessarily more elegantly, but available.

Apple did not play a major role for me in that context. The systems seemed more closed to me and less designed for the kind of openness in which one takes a machine apart, expands it and understands it in detail in the same way I had been used to with the Amiga. For my approach, the image mattered less than the question of whether a system remained open enough to be understood.

The transition therefore did not arise as an ideological break, but as a quiet shift: from the Amiga as a clearly structured work machine to a PC that was used above all because work could practically continue on it.

The more detailed dedicated page remains pcshift.htm.

Video technology – not only computers, but also tape machines

For me, technology was never limited to computers alone. With video devices as well, it was not merely operation or brand names that interested me, but construction, mechanics, signal path and the question of how cleanly a system was really built. Precisely in the field of analogue recording, it quickly became clear whether a machine had been designed merely for everyday use or whether it had genuine technical substance.

Some of these machines are still present today, including a Sony SL-HF950 ES, a Sony SL-HF100 ES and a Sony SL-8000E. This range is especially interesting to me because it shows not only individual models, but also a line of development: from early Betamax machines to later, more elaborate and higher-quality units.

For me, such recorders were never merely consumer entertainment electronics. What mattered was transport mechanics, head assembly, signal path, control logic and the question of how well a machine could be maintained, compared and, if necessary, brought back into working order. That is exactly where they resemble my attitude toward computers: not mere ownership, but whether a system is built in a traceable way and can truly be understood.

That is why these video devices belong, for me, to the same technical biography as PET, C64, Amiga or later the first Windows PC. They are different worlds, but the same gaze: look at things, compare them, preserve them, and take their construction seriously.

“Not only computers – video technology too was always something to understand.”

The pure video page remains video.htm. The workshop connection to it is on werkstatt.htm.

The Dell Precision M50 – a work machine instead of disposable hardware

A system does not have to be disposable. A good example still reliably boots its original Windows XP Professional to this day: my Dell Precision M50 workstation from 2002 in a concrete full configuration.

This machine was built for serious work: robust, modular, heavy and honest. Mobile Intel Pentium 4-M at 2.2 GHz, 2 GB RAM, a UXGA display with 1600 × 1200 pixels, NVIDIA Quadro4 500 GoGL, 60 GB IDE hard disk, Media Bay and a range of ports for which one would now often need several adapters.

• Processor & attitude: not an ultra-thin fashion device, but a mobile workstation with a real working purpose.
• Display: 15-inch UXGA, 1600 × 1200 pixels – plenty of space for programming, parallel windows and longer sessions.
• Graphics: NVIDIA Quadro4 500 GoGL – professional orientation rather than mere standard display.
• Media Bay: CD/DVD, floppy drive, ZIP drive, second hard-drive module or second battery.
• Ports: Ethernet, modem, PCMCIA, VGA, S-Video, FireWire, infrared, PS/2, serial, parallel, USB.
• Operating system: Windows XP Professional – still operational on exactly this machine today.

That is exactly why the M50 fits well into this story. It stands for the same basic idea as the Amiga tower with its SyQuest removable drives: technology does not have to be fashionable, but traceable, resilient and useful in daily work.

Such devices now feel almost like technical time capsules. But they are more than nostalgia. They show a style of construction that took professional users seriously: connectivity, expandability and usefulness. That still feels convincing today.

“Not a disposable device, but a work computer that still fulfils its purpose.”

The M50 as a dedicated page remains m50.htm.

Today: Dell Pro Max 16 Plus, but basically the same attitude

The tools have changed, but the basic attitude has remained. Today I no longer write code on a tower, but on a Dell Pro Max 16 Plus. What has not changed, however, is the preference for clarity, calmness and leaving unnecessary things out.

• Handwritten HTML5 & CSS3: no page builder, no unnecessary overhead, no artificial complexity.
• Vanilla JavaScript: used only where it truly makes sense for function, usability or accessibility.
• Performance first: pages should remain light, quiet and fast.
• Static solutions: what does not need to be calculated dynamically does not create unnecessary attack surface either.
• Maintainability: a good solution is still readable, maintainable and understandable later on.
• Modern tools: AI models and cloud services are tested in practice – not by hype, but by usefulness, limits and everyday viability.

Handwritten code is not an end in itself for me. It is more the logical consequence of a long computing history. Anyone who learned early to deal with limited resources and real responsibility for keeping a system working almost automatically develops a need for clarity and technical honesty.

That also applies to modern tools now. AI models and cloud services are neither treated with reverence nor rejected across the board. They are tested, compared against each other, observed in their limits, and only taken seriously if they actually carry something in real use. That is why I care less about their marketing tone than about the practical question: what really helps, where are the breaks, and what only creates new ballast in the end?

The same is true for websites overall. Technical visibility and clean discoverability matter. But a good ranking is worth little if the visitor is disappointed afterwards. A page is only truly useful when it is not only found, but when the information on it is also clear, honest and practically helpful.

What remained from that time

That is exactly why my solutions are deliberately kept lean. No unnecessary overhead, no loud constructions just because something is supposed to look modern. Better understandable HTML structures, clean CSS, selective JavaScript and a technical handwriting that relies on dependability.

In the end, what remains visible is usually only the surface. What carries everything underneath is structure. And that structure should not only work today, but remain understandable later on as well.

“In the best case, good structure does not stand out at all. It simply ensures that things work.”

The more detailed attitude page remains philosophy.htm.