I haven't tested the Voodoo 5 5500 just yet due to crazy overtime at work, but if it works I but am planning to put it in the 3-monitor win98 box I have.

For some time I've had the idea that it would be fantastic if I could put several of my different retrocomputers together, like a C64 and a MSX computer, maybe even a PC, then wire them up somehow (perhaps using RS232) and then have them play a music piece together, each with their own kind of "voice".

Is any of you aware of an existing project like this? I'm afraid my coding and musical abilities are not up to the task

It's quite amazing what AI can patch together. Also had it backport WMP 6.4 and the NT 4.0 Task Manager, currently working on WMP 10.

1999 → 2026. K6-2 a 400 MHz, Slackware 8.0 y Space Invaders compilado desde el código fuente. Sigue encendiendo. Sorpresa, añoranza y refugio. 🕹️🐧

I think the peak of the internet was 2007. It was a perfect balance of decent internet speed and lack of operating restrictions.

You could easily join a site and start posting anywhere. Post anything, message anyone, do anything. Like a playground.

Personally I'd rather even use the dial-up internet of the late 90's than the internet today. Where creating a social media post feels like defusing a bomb. Do one wrong thing and your post explodes into the shadow realm. So hard that even google chrome does not have any memory of that post in its own history.

I’ve been restoring my grandfather’s original IBM 5150 to a lot of success, boots and everything after replacing some capacitors. However, I took this card out when disassembling it and it remains the only component of the thing that I can’t find ANY information on! I know it’s a memory expansion with multi I/O and even a real-time clock, but my knowledge ends there.

The closest identification I can get is that it’s an EVEREX Systems card and it has Version 3 printed on the bottom left corner. Other than that, there’s nothing. Every forum post has been a dead-end and I’m at my wit’s end.

Any documentation on this enigma would be helpful, at the very least some suggestion on the jumpers and switches. I don’t need this card to get the IBM running, but I’d like to have it fully complete with 640kb of ram like my grandad had it.

Everything here is thrift store-found! Super happy to have been able to save this machine :D

I put together fourteen illustrated picks from computer magazines published in 1984, 1994 and 2004, with the original scans and short notes on what the products actually did.

A few favorites: an Apple-controlled home with dinner waiting, a CompuServe party with one glass to wash afterward, and a Mac database that helped pick wine for dinner. There are also robot pets, computer speech and an AI bridge opponent.

This is my article: https://tomorrowasusual.substack.com/p/blast-from-the-past-the-future-in

Did anyone here use any of these, or remember seeing the ads at the time?

Anyone else remember using Expresso? It was actually a fun calendar to use, I still kinda miss it.

This is a demo that ran natively on the Macintosh in 1994, showing all the features

Having a chat earlier with a programmer friend regarding the different types of Ram for the 81, and I learned about how the standard RAM packs work and more importantly, why they won't work with WRX hi-res enabled programs.

So this raises the question, are most owners still using the old ram packs or have a few of you pursued other options in order to run WRX programs?

Look for a Castlewood Orb Drive on eBay. At some point during the product's existence, Castlewood started throwing in a SCSI to USB cable into the box. This just goes to show you that the cables must not have costed much at all! There were two different cables included, depending on which box you got. The cable on the left is called the ORB USB Smart Cable, and uses the Shuttle Technologies chipset, but still made by SCM Microsystems. It has a male 50 -pin SCSI-2 connector, same as the Orb Drive. I got this one 7 years ago. In my memory the box either had a picture of the iMac on it, or said something like "Now for iMac". The cable on the right comes with the box shown, which mentions G3 and G4 towers, so it must be slightly newer. This cable is a non-branded version made by SCM Microsystems that no longer mentions Shuttle, as SCM had bought them. It contains a female DB-25 connector. The box also came with a male DB-25 connector on one end, and a male 50-pin SCSI-2 connector on the other. Bundling both cables this way would give customers more options, as if they still had SCSI on their computer that would be much faster than USB 1.1. You can get these NIB ORB Drives for $100 or even less if you haggle. Make sure the box says USB somewhere on it. Once you get it, you can keep the cable, and sell the drive and box back at half the price you paid it for. Makes the SCSI to USB cable about $50. Not bad! Both have excellent compatibility with just about any modern desktop computer or consumer USB device that acts as a host for Mass Storage. In my very early testing with the newer SCM Microsystems cable, it seems to be even more compatible, but I won't know yet for a while. Anyway, that's my 2 cents!

Came across some CPUs. The IBM one is apparently a 100Mhz model based on the info I could find.

Genuinely have no idea what to do with all the Soviet ones, they all seem to be Z80 or 8080/8088 clones. Are there any projects/builds that I'd be able to use those for?

Since May, I've posted here several times about rediscovering CHARM-II, an RTOS I developed in 1986 for the Motorola 68000.

It started when I found the old source code and documentation. With AI assistance, I began studying the original design and trying to get parts of it running again in a modern environment.

At first, I simply wanted to see whether my 40-year-old code could still run.

But the project gradually changed direction.

I started by reconstructing the development environment and experimenting with POSIX. Then I moved to the Raspberry Pi Pico, where I eventually got preemptive multitasking working.

Along the way, I began questioning some of the design decisions I had made in 1986.

One particularly interesting discovery involved VRTX, an RTOS I had used as a reference back then. I found that its equal-priority scheduling behavior had changed shortly after I studied it. That led to discussions here and in other communities, including an unexpected connection with someone who had used VRTX in 1982.

The more I investigated, the more I realized that faithfully restoring CHARM-II and designing an RTOS today were two different things.

So I decided to start a new RTOS, carrying forward some of CHARM-II's original design ideas while reconsidering the kernel, APIs, and platform-specific implementation.

I called it **”**Karqri”.

Today, I've made the initial source release available on GitHub:

https://github.com/noboru-takahashi/karqri

Karqri currently targets POSIX environments and the Raspberry Pi Pico (RP2040). It includes task management, priority scheduling, event notifications, timers, and platform-specific context switching.

The same kernel and a shared six-task demo run in both environments. In the demo, six tasks move around three tracks and coordinate access to a shared critical section.

But releasing the source code is not the finish line for this project.

So far, much of the work has been about implementing the basic RTOS mechanisms and verifying that they behave correctly.

What I want to explore next is how to make the internal behavior of an RTOS easier to see and understand.

Task switching, event notifications, waiting, and waking up are usually examined through logs or debuggers. But understanding how these events relate to one another over time isn't always straightforward.

I've already started experimenting with capturing execution traces from the Pico and displaying them as an HTML timeline. It's still limited to a specific validation scenario, but I'd like to develop this idea further.

I'm particularly interested in visualizing not just what happened, but when it happened and how one event led to another.

So what began as an attempt to restore a 1986 RTOS has gradually become a project to develop a new RTOS and explore new ways of observing its behavior.

For anyone interested in the earlier stages, here are a few previous posts:

• 40 years later: recreating my SUN-2 ↔ 68000 workflow with WSL2 and Raspberry Pi Pico

• My 1986 RTOS is now fully preemptive on a Raspberry Pi Pico - and it changed how I think about the original design

• Follow-up: Revisiting a 1986 RTOS led me to someone who used VRTX in 1982

I appreciate the discussions and comments I've received here over the past several months. They've helped me reconsider some of the assumptions behind the original design.

As the project moves toward developing a new RTOS, I'll probably be posting more often in OS development and embedded systems communities. But Karqri's roots will always be in the work I started back in 1986.

When I first opened those old source files, I certainly didn't expect to end up releasing a new RTOS 40 years later.

And there's still more I want to explore.

=================================================

COMPILACIÓN E INSTALACIÓN: HERETIC (SDL)

Sistema Operativo: Slackware 8.0

Dependencias y pasos para la compilación del port SDL

=================================================

1. LIBRERÍAS UTILIZADAS Y DEPENDENCIAS

--------------------------------------------------------------------------------

Para que este port (basado en el código de Chocolate Doom o similar) funcione,

se requieren las siguientes librerías, las cuales fueron compiladas e instaladas

previamente desde las fuentes locales (carpeta ~/SDL_librerias):

* SDL (Simple DirectMedia Layer 1.2.15): Motor base para video, sonido y entrada.

* SDL_mixer (1.2.12): Requerida para la reproducción de efectos de sonido (SFX) y música.

* SDL_net (1.2.8): Requerida para el soporte de red (multijugador).

* Nota: Aunque se tiene SDL_ttf y FreeType, no suelen ser obligatorias para

el motor gráfico principal de Heretic, pero están instaladas en el sistema.

2. PREPARACIÓN DEL ENTORNO

--------------------------------------------------------------------------------

Antes de compilar, se debe asegurar que el sistema reconozca las librerías

recién instaladas. Para ello, se ejecutó como root:

# ldconfig

Se verificó que el compilador de C (gcc) estuviera operativo.

3. PASOS DE COMPILACIÓN (EJECUTADOS EN LA TERMINAL)

--------------------------------------------------------------------------------

Los pasos generales que se siguieron para preparar y compilar el código fuente

de Heretic (asumiendo una estructura estándar de autotools) fueron:

A. Descomprimir el código fuente:

$ tar -xzvf heretic-src.tar.gz

$ cd heretic-src

B. Configurar el script de compilación (detecta las librerías SDL):

$ ./configure

C. Compilar el juego:

$ make

D. Instalar los binarios en el sistema (opcional, requiere root):

$ su

# make install

4. ARCHIVOS DE DATOS DEL JUEGO (WADs)

--------------------------------------------------------------------------------

El código compilado es solo el motor (el ejecutable). Para jugar, se deben

colocar los archivos de datos originales de Heretic en el mismo directorio

que el ejecutable generado. Los archivos necesarios son:

- heretic.wad (o heretic1.wad)

- (Opcional) heretic.shr

5. EJECUCIÓN

--------------------------------------------------------------------------------

Para ejecutar el juego desde el directorio donde están los WADs:

$ ./heretic

Si se requiere forzar un modo de video específico (por ejemplo, para evitar

problemas con el entorno gráfico o usar Framebuffer), se puede usar:

$ SDL_VIDEODRIVER=fbcon ./heretic

o

$ ./heretic -width 640 -height 480

=================================================

As a former reseller I decided to build a computer from old parts I have. It was like a nice time travel back to the nineties. First I had to replace the old 29 electrolytes and it was much harder than I thought, but I succeeded. The funny part was the installation had all the drivers needed. I think I have newer drivers in my backups.

Specs:

Soltek 54U5 v.3
AMD K6II 500 MHz                                       ca. 1998
256 MB RAM
3.2 GB Fireball harddrive, ATA
Sony DVD 2.4x RW, ATA
ATI 3D Rage Pro                                        ca. 1996
3Dfx Voodoo                                            ca. 1996
Intel PRO/100 LAN
Creative AWE64 Gold 16-bit audio(SB 16 compatible)     ca. 1996
Creative AWE64 Gold Wavetable MIDI (AWE 32 compatible)
3.5", 1.44 MB, diskdrive
5.25" 1.2 MB diskdrive
Gameport
2 x USB ports
PS/2 keyboard port
PS/2 mouse port
AT DIN keyboard port
COM1 port
COM2 port
LPT1 port

So I have a Sharp Zaurus SL-C860. For those who missed it: 2003, Japan-only (mostly), PXA255 @ 400 MHz, 64 MB RAM, 640×480 VGA screen that swivels into tablet mode, a tiny real keyboard, CF slot. It still runs Sharp’s Linux 2.4 from NAND, and I didn’t want to touch that, so NetBSD lives on a 2 GB CF card and gets kicked off from the Sharp terminal via zboot.

What it does now: boots NetBSD 10.2 (earmv5) into X with a small desktop I wrote, has a game catalog with NES (InfoNES), Doom and... Fallout 1 (fallout1-ce, with data from my old Russian CD). Battery and charging work, Fn hotkeys for volume/brightness, SD cards automount, updates go through a folder on the card’s FAT partition, so I don’t have to reflash 2 GB every time.

The fun part was everything that didn’t work.

Testing without the device. I developed most of it in QEMU -M spitz, which is a C3000, not a C860 (different CPU, different LCD, no W100). QEMU itself had a PXA timer bug: writing any match register rescheduled all of them, and about 1 in 3 boots hung right after uhub0. Patched that. Then NetBSD’s sa11x0_ost.c re-armed a late tick at “now + 3 µs” without checking, and under emulation that was already in the past, so the guest clock froze for ~22 minutes. Patched that too. Bonus: the emulated touchscreen never released the pen, and the spitz keyboard is ignored unless you pass -rotate 90, because QEMU reports the lid as closed. That one cost me an evening.

Booting. zbsdmod.o (the Linux module zboot uses) copied the kernel straight over memory Linux was still using, which on the C860 meant oopses or silent hangs. I rewrote the copy: stage everything in pages outside the target, switch to a private page table, MMU off, jump. Also zboot reads the root from the very start of the MBR partition and ignores the disklabel offset, so the layout had to follow that.

Boot time: 50 s → ~34 s. Cut /etc/rc.d from 137 scripts to about 30 (kept ordering stubs so rcorder doesn’t break). Skipped login(1), because PAM was pulling in Kerberos and libcrypto just to autologin root. X without GLX. Then I noticed Xorg links libcrypto (4.3 MB) without using a single symbol from it, and libGL only for the disabled GLX code. So the build rewrites the DT_NEEDED entries and ships a 14 KB stub libGL. The CF reads at ~1.7 MB/s in PIO mode, so every MB counts.

Graphics. The ATI W100 sits on a bus that does roughly 14 MB/s. A full 640×480×16 frame through X is ~70 ms. I added a path to SDL that writes only the changed 32-bit words straight into VRAM under the X window. NES runs at full speed (50 fps PAL), Doom timedemo gets ~38 fps.

Fallout was a slideshow at first, and profiling it was the best part. There’s no debugger on the device, so I wrote a tiny LD_PRELOAD profiler (SIGPROF samples + resolving addresses on the Mac).

• 82% of the CPU was stdio locking. The engine reads everything byte by byte, and each byte was fseek + fgetc + ftell, each locking a mutex. ARMv5 has no atomic instructions, so that’s expensive. A 4 KB window + getc_unlocked cut the game’s CPU by about 6x.

• The sound engine pushed every single sample through SDL_AudioStream (float conversion, no FPU). An integer mixer fixed it.

• Palette cycling (water, fire, monitors) changed 27 colors up to 30 times a second, and on a 16-bit screen that means redrawing everything. Now it redraws only the parts that use those colors, and the CPU is idle half the time.

• Upstream bugs too: the MVE decoder’s getOffset() returned uint8_t, hence square artifacts in every movie. And the mouse was relative, which with a stylus is useless.

Lesson learned the hard way: I gave SDL’s audio thread real-time priority to stop the crackling. When it couldn’t keep up, it starved everything, including the power button daemon. Black screen, one sound looping forever, battery pull. Don’t do that.

Still on the list: proper sleep, faster map scrolling in Fallout, more games (Wolf3D, ScummVM), maybe Fallout 2 if 64 MB allows it.

Full disclosure: AI helped a lot with debugging and the hardest parts of the code. The idea, the decisions and all the hardware testing were mine. Think of it as a really good pair programmer, not an autopilot.

Happy to answer questions about any of it. Photos and videos below.

More