Despite the drawbacks and impractical nature of this device, space science researcher @dyd_Nao created a USB drive made of magnetic core memory – a technology that was used a lot in space technology of the 1950’s and 60’s.
It’s really awesome – despite the fact it only holds 128 bytes of data and is the size of a small dinner plate.
Ah, the good old days of using INT 10h, AH=0x00 graphics modes to write directly to video memory at 0xA0000/0xB0000/0xB8000 (depending on the mode).
Nir Lichtman walks us through some of the things I was teaching myself in middle school – writing VGA graphics in assembly (often using the great book Programmer’s Guide to the EGA and VGA Cards by Ferraro, Richard F.
I even wrote my own (terrible) little paint program that would then save the buffer into a file and reload it. What good times!
Giulioz gives a sequel to last year’s talk “Proprietary silicon ICs and dubious marketing claims? Let’s fight those with a microscope!“, where he showed how he reverse engineered a pretty old device by looking at microscope silicon pics alone, with manual tracing and some custom tools.
Fast forward, he shows how he reverse engineered a much modern chip: the custom Roland/Toshiba TC170C140 ESP chip (1995). Completing this task required a different approach, as doing it manually would have required too much time. He used a guided, automated approach that combines clever microscopy with computer vision to automatically classify standard cells in the chip, saving us most of the manual work.
They then sped things up even further by directly probing the chip: by exploiting test routines and sending random data to the chip he figured out how the internal registers worked to create a bit-accurate emulator. He even gives the source code out on github so you can emulate the devices yourself.
Listen to the result at 32:19 where they play Darude Sandstorm.
Links:
Inkbox decides everything in computing since sending man to the moon was a bad idea. Even operating systems and programming languages!
He sets out to write a complete clone of Zaxxon in assembly language with no operating system. He handles display, keyboard, mouse input, booting the system himself – and walks us through it all.
This kind of coding is exactly what got me into computer science as a kid. Watching demo scene videos and learning to program right to the display buffer with assembly was an era we don’t see much anymore. Still, I did get to make a graphics app that directly booted the display controller on recent hardware for an embedded platform (but that’s a story for another time).
How does it go? Awesome! Open Source Project on GitHub: https://github.com/InkboxSoftware/spacegamex64/
Apple II copy protection was a really interesting thing. While floppy controllers were partly hardware/firmware devices, Apple II floppy disk controller was incredibly simple and most of the work of reading/writing was done in software. This meant that copy protection schemes for the Apple II could utilize a LOT more clever and difficult tricks such as custom data encoding, half tracks, empty tracks, bad crcs, bad addressing headers, etc.
As time has gone on, original Apple II disks are becoming more and more scarce. Even worse early cracking efforts often hacked the games in ways that got around disk protection, but also removed or broke things. Unfortunately, that meant removing opening cut scenes or other game-altering changes.
The 4am Archive on the Internet Archive is an attempt to back up those original copy protected games as they were. So far there are 1673 Apple II titles safely imaged.
4am has even been interviewed by Paeleotronic on how and why he went about this. He even provides some of his tools like Passport.
Definitely give the interview a read and also check out some of the games on the archive. Many of his images (like Maniac Mansion for Apple II) come with a text file that gives all the details about what protection was found and how he worked around it.
Inkbox decides to program without an OS. Back in the day, we used to do this by programming directly to the system or to BIOS with interrupts for things like disk, device, and display access.
Fast forward, and if you want to do this today, one doesn’t talk to BIOS – they need to program via UEFI services. Inkbox walks us through doing multi-core bare metal programming of the old game Zaxxon. It’s excellent work and fun walkthrough.
I got my start in programming with type-in BASIC programs. Back in the 80’s, almost every computer had BASIC built-in, but almost no kid could afford games. Or even get them – the nearest store that sold software from me was over 30 miles away. Mail order took 2-3 weeks. On top of that – kids are notoriously broke. What I did have was a library, and plenty of time.
Enter Compute! magazine. After ravenously devouring all the programming books our small Carnegie library had, I branched into magazines. BYTE was too news oriented and didn’t have type-in programs; though reading about the technology was fun. When I found Compute! – I was hooked. I eventually checked out just about every single magazine they had a dozen times over. I remember digging in the downstairs old issue stacks in search of any I might not have seen. I spent whole weekend afternoons typing the programs in – and then even more hours debugging each line to figure out where I’d gone wrong.
Nate Anderson recently wrote an article about those early days of type-in programs. Even more fun is the comments section full of people sharing their similar experiences.
With the internet and instantly available content and content development tools – it makes me wonder how the next generation’s engineers will develop. How will the instantly available world of free software and tools shape them compared to our generation of type-in programmers?
Thankfully, all these wonderful magazine scans have been saved in the Compute! Magazine Archive on the Internet Archive. I even sat down and typed one in (well – heavily utilized OCR as well!). What a blast.
Links:
Fluxfox is a floppy disk image library – written in Rust. It’s intended to serve the needs of the emulator world and supports IBM, Amiga, Macintosh, and Atari ST formats. It can even perform operations on disk images consistent with typical operations of a PC floppy disk controller, while also giving low-level access to the track bitstream for other controllers.
It’s written by martypc/GloriousCow that has written a lot about floppy protection schemes.
Back in the day, software didn’t come on encrypted, online, distributed marketplaces, they came on humble floppy disks. This made them susceptible to copying. To fight this, developers started using all kinds of interesting tricks, which hackers would try to break. Thus started a nearly decade-long war of hackers and copy protection schemes.
GloriousCow started a series of investigations on historical floppy protection schemes on his blog. His site is amazing – he makes his own tools as well as shows the assembly code and has great diagrams. He covers things like EliaShim CodeSafe, XEMAG Xelok, Vault Prolok, EA Interlock, Softguard Superlok, Formaster Copy-Lock, and even got an interview with Robert McQuaid who made the protection circumventing CopyWrite software.
I particularly like his article about Copy-Lock mechanism used by Kings Quest. Copy-Lock employed several tricks such as sectors with non-standard sizes and putting purposefully incorrect CRC values on tracks to make standard copying incorrect.
In this case, Copy-Lock used a mechanism in which sector 1 on track 6 was intentionally written as only 256 bytes (instead of 512 bytes), with a 256-byte blank section to fill the gap. Additionally, the CRC was also altered to make a normal read think it was invalid. A normal INT 13h disk read would search and fail the read and CRC check.
CopyLock worked by bypassing the BIOS and talking directly to the disk controller. It would issue an INT 13h read on sector 1 track 6 that it knew would fail. This would place the head on the right track. The code would then tell the floppy controller directly to read track – and dump all 512 bytes. It was looking for the special byte 0xF7 as the final byte of that supposedly empty section of the track. The key is that it is not possible to create invalid tracks with invalid CRC’s like this using a standard IBM PC floppy controller. Copy-Lock created the special hardware that could write in this way and sold that, along with the checking code, as their solution.
His article has all the assembly code – which is really awesome.
Links:
New Wave makes some amazing, fully functioning miniature retro arcade models – or replicades. One of their more recent additions was the ever-fabulous arcade fortune telling machine Zoltar.