CRTs Are Too Mainstream, So Game On A Mechanical TV Instead

Aside from nostalgia, people claim to like CRTs because they’re apprehendable– the technology just makes more sense than the arcane wibbly-wobbly solid-state madness going on inside the driver chip of your new OLED. CRTs weren’t the first technology used to display moving images though, and their mechanical forebears were even easier to understand. For that reason we suppose it was only a matter of time before one of The Youths– in this case a British YouTuber by the name of [smill]–tried gaming on a mechanical television display.

The game in question was Minecraft— because of course it was, that’s the new generation’s DOOM–and the mechanical TV in question is not a priceless 1920s antique but a commercial kit that reproduces [John Logie Baird]s 1925 televisor. If you’re not familiar, it uses a flat disk– called a Nipkow disk after its inventor– with a series of holes in a spiral to demodulate a single lamp’s brightness variations into monochrome image made of scan-lines. As you might imagine, the resolution depends both on the size of the disk and its speed, so with a tabletop example you’re not going to get much– in this case, 32 holes for 32 lines. At least they’re not interlaced this time.

Getting a video signal from the computer to the LED in the televisor kit was the hard part of the hack. Aside from actually playing on the diminutive monochrome display, that is. There is a “video2NBTV” tool that can do the job, as the Narrow Band TV signal used by amateur radio enthusiasts still has the compatible timing values and modulation as what the televisor kit uses. We suspect that’s because the Televisor people used the modern NBTV standard as a starting point for their electronics, since [Baird]’s device reportedly ran 30 lines at only 5 frames per second, compared to the 32 lines at 15 FPS here.

Some of you may turn your nose up at this as a mere YouTube stunt, which is fair enough. At the same time, we cannot wait for the eventual arms race. Imagine when someone decides to go for 4K cred? Staring through a supersonic Nipkow disk makes pointing a particle accelerator at your face downright mundane. The kit [smill] used was monochrome, but if you want to repeat his antics in glorious colour, you can 3D print your own TV.

Continue reading “CRTs Are Too Mainstream, So Game On A Mechanical TV Instead”

Reverse-Engineering And Documenting The Fisher Price Pixter

Between 2000 and 2002 the Fisher Price Pixter was sold to children as an educational handheld toy with a touch screen that enabled drawing and listening to music in addition to cartridge-based games and more. It was followed up by multiple new iterations of the system, but as an ecosystem didn’t last beyond 2007. This has left much of the system in obscurity, with people like [Dmitry] doing their best to reverse-engineer, dump and document what they can, such as recently for the entire range of Pixter devices and most of the games.

One of the reasons why [Dmitri] got interested in the second-generation Pixter Color originally was as a potential PalmOS porting target, which gives somewhat of an idea of how these devices were meant to be used.

With absolutely no remaining known official documentation on how to develop software for the hardware reverse-engineering posed somewhat of a challenge. Fortunately this was made somewhat easier by the Pixter Color using the ARM-based LH7541, but worse by just how much of a minimal ARM7 implementation the SoC is. This was meant to go into a cheap-ish kid’s toy after all.

Where things got wild was that the firmware implements a 16-bit stack-based virtual machine, possibly due to initially having selected a completely different SoC. From here things get even crazier with how audio output is implemented, with [Dmitry] descending into a long-winded rant on this and all the weird things encountered during reverse-engineering.

After the Color Pixter its Multimedia sibling with slightly better SoC was also reverse-engineered, as well as the Classic device that started it all. This particular device uses an 8-bit VM, but a black-blob 6502 processor, which is rather astounding for a 2000-era device, but then again it was meant to be a toy.

In addition to getting a lot of reverse-engineering woes off his chest, [Dmitri] also details how he reverse-engineered and dumped the cartridges, as well as writing emulators to ensure that the Pixter legacy will endure, for better or worse.

Top image: Pixter with opened case. (Credit: Raimond Spekking, Wikimedia)

Reverse-engineering The 1998 Ultima Online Demo Server

In any MMORPG, the average user will generally only encounter the client side of the system. This makes building a compatible open source version of the proprietary server into a bit of a chore. Of course, sometimes you get a bit of a break, such as with the – still active – MMORPG Ultima Online, when the disc for the 1998 The Second Age expansion contained a stand-alone demo. This also meant a (stripped-down) server which has been gratefully reverse-engineered by the community, with [draxinar] now claiming to have made the most complete server based on this demo server.

To make things extra challenging, the originally written in C++ server binary was reverse-engineered into C99 code, meaning that the use of classes and associated vtables had to be left intact, just without the critter comforts provided by C++.

The total process took about a decade with occasional progress, with the current server binary being mostly identical to a 1998-era Ultima Online server. Some features that were stubbed out or disabled in the demo server had to be re-enabled or reimplemented, including the user account system.

Features that were left out of the final release like the ecology system were also enabled in so far as they were implemented. Although there is probably still a lot more work to be done on the code, [draxinar] reckons that this is a good point for the community to get involved to do some testing and provide feedback. There are also some missing server-related resource files that may still be saved somewhere.

Thanks to [adistuder] for the tip.

Pushing As Many Pixels As Possible To A CRT: Interlaced 4K

Some people love CRTs to a degree that the uninitiated may find obsessive. We all have our thing, and for [Found Tech], it’s absolutely pointing particle accelerators at his face to play video games. He likes modern games, with modern resolutions– none of this 1080p nonsense. Today’s gamers demand 4K! Can a CRT keep up? The answer is a resounding “No, but actually, yes!”

[Found Tech] has an IBM P275 monitor, which is one of the last generation of CRTs.  Officially, the resolution maxes out at 1920 dots by 1440 lines. While one might (inaccurately) call that UHD output “2K”, you certainly cannot claim it is 4K. So, what’s the secret? Interlacing. Yes, interlacing, like old analog TV signals.

Apparently, in spite of what the manual says, getting the screen to absorb the 2880×2160 interlaced signal wasn’t the hard part, but generating it was. NVIDIA and AMD graphics cards are absolutely unable to create an interlaced signal, but Intel integrated GPUs are– if you get the right combo of chip and old driver. Sadly, the video doesn’t list exactly what he used. Of course an iGPU isn’t going to give you a very good gaming experience at this high resolution, so [Found Tech] has his games do their rendering on the discrete card before piping that over to the iGPU for display on the CRT.

Technically, you still can’t call the 2880×2160 picture “4K”, as that trademark refers to 2160p at 16:9, and this is both interlaced and 4:3. Still, close enough. In spite of the artifacting that turned us all against interlaced signals back in the day, this apparently has [Found Tech]’s eyes fooled– he says it’s as good as 2160p on his OLED, plus the extra magic that comes with glowing phosphors.

It certainly looks great in a recording, but the monitor in the recording isn’t displayed at a high enough resolution to say for sure if it’s 4K. Still, if you’re into CRT gaming, maybe give this high-res interlacing a try. If you still don’t get what’s so great about CRTs, check here, and remember it could be worse– at least we’re not going on about Plasma TVs. Continue reading “Pushing As Many Pixels As Possible To A CRT: Interlaced 4K”

Running DOOM On A Travel Router With Touch Screen

Continuing his quest to put DOOM on literally everything that has a capable enough processor and a screen, [Aaron Christophel]’s most recent target is a Slate 7 Pro travel router. With a generous 2.8″ touch screen and a lot of onboard processing power to handle all the advertised networking and routing features via its WAN and (W)LAN interfaces, it should be able to run the game really quite well. As usual the main question is how to get the game to run on it first.

The port of choice is fbdoom, with instructions on how to run it on this router provided on the GitHub project page. The reason for the touch screen is so that you can see the status of interfaces and interact with it without having to open the web interface. Boringly, this router has an SSH daemon ready to connect to, giving you full root access to the Linux-based firmware.

It’s just your typical AArch64 ARM-based system, with the gl_screen process running for the touch screen display. From there it was easy enough to deduce the settings to jot into fbdoom so that it too could use the same screen and touch inputs. After copying the compiled binary with SCP over to the router, it can then be started like any application. With touch inputs somewhat awkwardly mapped to certain areas of the touch screen, it’d be nice to see the USB 2.0 port used for USB HID inputs, but it does show how easy things can be when it runs something like Linux and you got full root access.

Incidentally this also heavily blurs the lines between something like a Valve Steamdeck and a router, with the latter just missing some gamepad controls on the side to do some on-the-go gaming when you’re not using it for routing network traffic.

Continue reading “Running DOOM On A Travel Router With Touch Screen”

Building An X86 Gaming PC Without Intel, NVIDIA Or AMD Parts

This is an interesting challenge from the “why not?” files — [GPUSpecs] over on YouTube built a gaming PC without using a single component from NVIDIA, Intel, or AMD. That immediately makes us think of the high-power ARM workstations or perhaps even perhaps the new “AI workstations” coming available with RISC V architecture, but the challenge here was specifically “gaming PC,” not workstation. A gaming PC, without a GPU by one of those three? To make it even more interesting, the x86 CPU isn’t Intel or AMD either.

If you’re of a certain vintage, you may remember Cyrix. Cyrix reverse-engineered the x86 ISA and made their own compatible chips in the 90s, before being bought out by National Semiconductor, and then VIA Technologies. VIA partnered with the Government of Shanghai to found Zhaoxin, and it is from Zhaoxin that the KaiXian KX 7000 CPU hails — an x86-64 device, that isn’t Intel or AMD. We’ve actually covered the company before. This particular chip benchmarks like an old i5, so not spectacular, but usable. 

Continue reading “Building An X86 Gaming PC Without Intel, NVIDIA Or AMD Parts”

Wipeout Clone Runs Native On ESP32-S3

Psygnosis’s 1995 game Wipeout is remembered for two things: being one of the greatest games of all time, and taking advantage of the then-new PlayStation’s capacity for 3D graphics. The ESP32-S3 might not be your first choice to replace Sony’s iconic console, but [Michael Biggins] a.k.a. [PhonicUK] is working on doing just that, with his own clone of Wipeout on the Expressif MCU. 

It’s actually not that crazy when you think about it. The PlayStation had a 32-bit RISC processor, and the ESP32-S3 is a 32-bit RISC processor. The PlayStation’s was only good for about 30 Million Instructions Per Second (MIPS) but it had a graphics co-processor to help out with the polygons — the ESP32-S3 has two cores that can help each other, which combine to about 300 MIPS. In terms of RAM, the board in use has 8 MB of PSRAM, while the faster 512 kB on the chip is used, in effect, as video ram.

The demo is very impressive, especially considering he’s fit in three computer players. He’s also got it blasting out 60 frames per second, which is probably double what the original Wipeout ran on the PS1. Part of that is the two cores in action: he’s got them working together on the interlaced video output, one sending while the other finishes the second half of the frame. Each half of the video gets dedicated space in the internal memory. Using a 480×320 pixel display doesn’t hurt for speed, either. Sure, it’s paltry by modern standards, but the original Wipeout got by with even fewer pixels — and it didn’t run on a microcontroller. Granted it’s a beefy micro, but we really love how [Michael] is pushing its limits here.

Right now there’s just the Reddit thread and the demo video below. [Michael] is considering sharing the source code for his underlying 3D engine under an open license. We do hope he shares the code, as there are surely tricks in there some of us here could learn from. If it’s all old hat to you, perhaps you’d rather spend a weekend learning raytracing.

Continue reading Wipeout Clone Runs Native On ESP32-S3″