skip to content
evv42's webpage
hi there, this is evv42's webpage !
skip to article list
software projects
every piece of code i want to share is on that git thingie that i host
some cool stuff:
- kyacopycat, a Canon Cat emulator;
- nenemark2, a NES/Famicom compatible computer;
- lumasum, a tool for sorting images by luminance;
- 98tombr, a tool for reading PC-98 drives on other systems;
- keyrisame, a keyboard/joystick adapter for PC-98;
- saccalc, a simple RPN calulator;
contact
- electronic mail: my pseudonym at caramail dot com
- fediverse: @evv42@donotsta.re
- fax: you lost the game
- irc: ask
see also
end of list
boo
crappyspeccy: a zx spectrum on breadboards that tries its best
[top]
I always wanted a sinclair computer but can't really afford the weirdly horrendous prices they command.
I got a broken ZX81 a long while ago but never was able to make it work. Since then, i got around trying
to make my own ZX computer at home but the 80/81 suffer from being quite complex due to trying to get the Z80
CPU to do as much as possible.
what is a speccy ? a miserable pile of memory
The big lines of the ZX Spectrum architecture are relatively simple: a 16K ROM, a 256x192 framebuffer
with simple colour attributes, some RAM (16 or 48 KiBs), an input port for the keyboard and tape input,
an output port for the tape output and speaker.
The secret sauce resides in the ULA, a medium-scale custom
chip that interfaces the standard components with the DRAM to achieve a cheap machine that's more powerful
and easier to program than sinclair's previous iterations.
The original hardware is notable from having been cloned to death, mainly in eastern europe which machines
either outright cloned the ULA chip or replaced it with the many discrete logic chips it substitutes.
Getting an ULA is pricey on a good day and the discrete equivalent relies on DRAM and uses too many counters and
multiplexers to be an afternoon project to build on two breadboards. So, how can we make less with less ?
if you can't do it you can use the *hum hum* z80 features
The Z80 is quite a featureful processor that has many tricks up its sleeve to make medium-complexity systems
a bit easier to make.
Among them is DMA, accomplished by the /BREQ and /BACK signal pair, which
allow the system bus of the Z80 to be put in high-impedance and the CPU to be stalled for other devices to
assume control and do tasks that'd be quite annoying for the CPU to accomplish.
magical video processor
The motorola MC6847 (a.k.a. Video Display Generator or VDG) is a very versatile video chip that shines among all
the others by its sheer simplicity and high function integration. It got quite popular in a wide variety
of home computers, mostly throughout the 1980s. Some personal picks would be the acorn atom (6502),
the vtech laser 200 and nec pc-6000 (Z80) and the dragon 32 (6809).
The chip takes a 3.58 MHz clock and controls itself entirely using 8 input signals that can either
be controlled through some simple circuitry or preset to have either a text/semigraphic display
using the integrated character generator or an external one, or a more straightforward framebuffer approach.
At its core, the chip is based around a 256x192 framebuffer that it can use as is, or at lower
resolutions, adding some colour capabilities along the way.
now, the curses
These were the two informations that triggered the following horrors, upon initial reading of basic information
about the ZX spectrum.
Before engaging in what would definitely end up being a many-days project, i did want to confirm that there
wasn't anything subtle i missed about this architecture (foreshadowing), so i did set up a very basic emulator
using the knowledge i gathered about the machine.
The first image did speak for itself, and it turns out that the framebuffer is not linear for some reason but
interlaced. Thankfully, wikipedia
has a quite detailed article about the ZX spectrum graphics
for some reason, and it's explained in simple terms how the interlacing works:
the A5, A6 and A7 lines are inverted with the A8, A9 and A10 lines.
After swapping that in software we end up with a more familiar screen:
The keyboard routines in rom need the triggering of the maskable interrupt which is wired to the
display vertical sync (*1), and with that we have a working minimal system, so let's build it !
(*1) The signal as-is would pose a problem due to IRQ being level-triggered on the Z80, you want
circuitry to account for that, ask me how i know !
the schematics, explained
It's relatively straightforward. the data bus goes to the data bus, the address bus goes to the address bus,
with the slight twist to the 6847 to account for the interlaced framebuffer.
The /MS input from the 6847 will receive the inverted /BACK from the 6847 so that the chip only gets access
to the bus when the Z80 yields it. as a consequence of the Z80 placing the bus in a high impedance state and
the 6847 lacking proper signaling circuitry to address the memory, we'll place some high value resistors along
some signals to force the memory into giving the information the VDG needs to display video.
The Z80 simply being on the same bus as the 6847 without any isolation does have the major drawback
of the latter getting most of the time to display the framebuffer.
To accommodate for this, we'll use the horizontal sync signal (/HS) (*2) as the primary way to get the bus
available for the Z80.
The second signal that'll be ANDed (so ORed in negative logic) to it will be variably wired depending on how
we want to distribute the time between the CPU and VDP. Here's some combinations that can be used:
- to VCC, gets ignored
- to GND, the CPU gets all the time
- to A14, the CPU gets all the time (mainly) while it's accessing the ROM, notably gets ignored in HALT mode
- floating/time split, the VDP and CPU gets an equal share on average,
on the display the information looks covered in snow
The third signal to be ANDed will be the /IORQ signal, this allows for timings to get just accurate enough for
a tape to be loaded in the third mode if the program uses the ROM routines to load (that is, it doesn't use a
"fast" loader)
Since we're using a single memory chip for holding both the ROM and the RAM, we may want some mechanism
to protect the ROM from getting erased by a rogue program that'd try to write to it
(see my article on battery-backed SRAM for more info)
You'll need a 32KiB SRAM for a 16K spectrum and a 64KiB SRAM for a 48K one, the larger SRAM usually have
the advantage of having a active-high chip enable signal that can be used as protection with the reset circuitry
The analog circuitry is a mess and the seasoned designer can probably do a better job but it does work properly
enough, most of the time. Getting the tape input to work was a pain.
There is three sections in the schematics with multiple circuit options, depending on what features and
complexity you want the system to have. The 16K variant can barely be built on two breadboards, the 48K one
definetly needs three unless you combine the logic into a single array chip (that's a story for another time).
(*2) We could use also use the /FS signal of the 6847, but it isn't regular unlike the /HS one
keyboard
For testing, i used a random matrix i had laying around that had absolutely no correspondence.
Then, i made a proper keyboard using a 20x15cm single sided PCB, cut in half vertically and in four
horizontally, soldered 8 wires to each zone, then soldered 5 buttons to each zone and wired the other sides
together in concentric "U" shapes to replicate the original ZX spectrum matrix.
Here's what it looks like:
And this is the key labels to print and stick to the plate (300 DPI):
It's not the best design by far but it's functional enough and was made with stuff i already had.
so, how good is that
Aside from the aforementioned timing issues, there's the issue of colour. The ZX Spectrum can assign any of ~16
colours for both the background and foreground values for each block of pixels. For the most part, it does
not impact the usability of programs, with the notable exception of ones which use palette swapping tricks,
like most of the tetrises for instance.
The general usage of the timing "modes" is as follows:
Mode 1 allows for a proper display at the expense of
speed.
Mode 3 is a compromise that allows for a mostly correct display while inside BASIC and allows for loading
games from tapes which are using the ROM routines.
For games which use a "fast" loader located in RAM, Mode 2
allows for the most accurate timings to hopefully load the program correctly, at the expense of being unable to
see anything on the display (the LEDs on the output ports would be the only indication of the program
loading or not).
Mode 4 is a catch-all mode for using loaded programs that, depending of which option you used,
varies from flickery to very "snowy". It allows for playing games at a usable but slightly slower pace, which
is the best you're gonna get on this machine.
but what about games
Here's some which i tried, that are notable enough to be at the end of this article.
16K Superchess (1983, 16K)
A basic chess game that works well, except for the pieces being undistinguishable.
Crabs (1982, 16K)
Your funky pac-man clone, usable in mode 4. Uses the speaker for funny sounds. Fun to play for a bit.
Minesweeper (1992, Softhouse Ltd, 48K)
Loads fast, controls are a bit unintuitive but remappable. Usable in modes 1, 3 and 4. It's minesweeper.
Samurai Warrior: The Battles of Usagi Yomiji (1988, 48K)
A cuuuuuuute game that looks neat. Runs in mode 4.
Elite (1985, 48K)
I can't get this game to load at all, sadly.
[top]
all you never wanted to know about the NSC800
[top]
It all started with a seemingly simple question: Who made the first CMOS Z80 ?
From what i knew back then, there were three contenders:
- Z84C00 from Zilog, who only discontinued it recently
- TMPZ84C00 from Toshiba, who only made CMOS Z80s
- µPD70008 from NEC, who developed a CMOS Z80 at the same time as a CMOS 8086/8088 (with additional features)
What i concluded is that NEC and Toshiba both released their version somewhere around 1984, and Zilog announced
theirs in their 1985 databook.
While searching i did find a Japanese document that described the lineage of the Z80 chip and mentioned a chip that somehow managed to skip my radar until now.
aside: compatibility between the various CMOS Z80s
The Toshiba and Zilog CMOS Z80 both have a lower power sleep feature which puts the CPU in a µA range power consumption
when their clock is stopped provided a specific sequence whereas the NEC one does not, and may not like its clock
being stopped according to the datasheet.
da NSC800
Enter National Semiconductor with their NSC800, announced in 1980. It's a CMOS microprocessor (using technology that's comparable to HC logic) that's entirely
software compatible with the Z80. It is obscure enough to lack a Wikipedia article
and instead is only summarily mentioned in the Z80 page.
It's unclear what NS wanted to achieve by half-cloning two of their competitors using then-new technology but the
result wasn't as successful as the later CMOS Z80s proved to be.
Part of it's obscurity is certainly due to its many, many caveats:
- It's not pin compatible. Instead it has a very similar signals to Intel's 8085, with some being inverted, but it gets worse;
- It has a similar timing to the Z80, but the multiplexed bus shenanigans are done by the chip running at double the speed;
- The chip was proposed in 1, 2, 2.5 and 4 MHz variants and nothing faster, slower ones seem to be the most common;
- Its clock can be stopped, but only in certain conditions that need additional circuitry.
For those caveats, the chip provides some features that were lacking on the Z80:
- The refresh register is a full 8-bits instead of 7 and so are the refresh cycles, this is mostly useful for DRAM-based systems;
- There's three additional hardware maskable interrupts; RSTA, RSTB and RSTC that maps to new restart addresses 0x3C, 0x34 and 0x2C;
- There's an integrated clock generator with a divided by 2 clock output;
- There an active-high reset output that's intended to be used with the peripherals NS developed;
- Being CMOS, it needs an order of magnitude less power and doesn't produce sensible heat. Additionally, a power save (PS) pin can place the chip in a lower power state.
It's also of interest that this chip was produced for a very long time (up until
at least 1997), long enough that the latest datasheet is available as a proper PDF
that's not just a scan.
using the thing
Using that chip in lieu of a Z80 is not as simple as one might think by skimming through the datasheet.
The timing is similar but not identical, the IO/M line for instance is asserted at the same time as the
address and thus can't be used as a trigger as with the Z80's MREQ and IORQ. Regaining such signaling can be done by ANDing
the RD and WR signals and gating the IO/M line with the result.
The clock driver is of the finicky kind and can have trouble starting up if the resistor and capacitors
aren't just right.
For what it's worth the four 2.5MHz parts i've got all happily will run at 4MHz
and more at 5V.
Implementation of the new maskable interrupts is done via a IO-mapped write only register (ew) at address 0xBB,
that also includes a normally set flag for INTR
miscellaneous info and some speculations
Early NSC800 documentation mentions the possibility of running the chip at up to
12 volts for more performance, while later documentation gives a 2.4 to 7V range.
It seems perhaps the higher voltages caused issues either with the chip itself or with
designers using parts that didn't like the higher voltage signaling.
There's a pretty interesting report from the NASA website that takes a look at three samples of the ceramic NSC800 and goes into details about how the chip works.
Of interest is the mention that each of their samples contained a different die revision, the last one also being a size shrink.
The naming scheme suggests that there was a
bunch of them on the 1980-1983 period and the siliconprawn die shot of the chip is yet another die revision.
[top]
unsorted hyperlink dump
[top]
here's an unsorted collection of links to websites containing mainly technology-related stuff
some may also contain NSFW stuff so viewer discretion blah blah
some of them are also dead links so you may want to access them up using the wayback machine
http://radioc.web.fc2.com
http://pc88pc98.web.fc2.com
https://kikb.web.fc2.com
https://nxstation.web.fc2.com
http://singlevalve.web.fc2.com
https://retrocomputerpeople.web.fc2.com
http://soyuketech.blog.fc2.com
http://kyoro205.blog.fc2.com
http://saved9821.blog.fc2.com
https://diarymodoki.blog.fc2.com
http://xsonarprofessor.web.fc2.com
http://pinsroom.fc2web.com
http://sandy55.fc2web.com
http://mineko.fc2web.com
[top]
simpler breadboard computers using battery-backed SRAM
[top]
Typical bradboard computer designs include two types of memory arrays for the CPU to read that have different properties: a read-only memory (ROM) containing the program and a random-access memory (RAM) containing the program variables.
The ROM (typically EPROM, EEPROM or NOR Flash) isn't usually writiable or re-writable, even though some types are to some extent. This is partly because the writing signaling of those isn't suitable for temporary storage and the number of write cycles those can withstand is limited.
The RAM (typically SRAM (*1) ) doesn't allow for keeping the data when no power is applied to it, which is a problem when you want to remove the chip for programming.
There's nothing preventing applying a separate isolated power source directly to the SRAM to allow for somewhat long-term storage, and thus significantly simplify the wiring and cost of a breadboard computer.
(*1): Unless using a Z80, which can interface easily to a pseudo-static RAM (XRAM/PSRAM).
alternatives
commercial modules
Some memory manufacturers (Dallas, ST to name the big ones) made and are still making memory modules that consist of a low-power SRAM chip, protection circuitry and a lithium button cell. Those modules are unfortunately quite expensive new and some sellers put a shipping restriction on these due to the lithium cell.
Also, those modules protection circuitry can have a significant start-up time when powered-on which should be taken into account if using them as main memory.
It it also noteworthy that some of these modules integrate a real-time clock (RTC) for timekeeping applications.
FRAM
Ferroelectric RAM (FRAM) is a type of memory that keeps its contents without the presence of power and has most of the properties of SRAM. It is roughly an order of magnitude more expensive than the equivalent SRAM new.
A constraint of these is that they don't support subsequent reads without reasserting the Chip Enable (/CE) signal, that is, you can't leave that singal low on the breadboard computer.
how-to
The minimal setup consists of an SRAM chip, two diodes, a power source (for example, a CR2032 in a holder) and a high value resistor (typ. 100Kohms).
A way of wiring it is to solder the negative lead of the power source to the VSS of the SRAM, the positive lead of the power source to the VCC of the SRAM through a diode.
Solder the resistor between a Chip Enable (/CE or CE) signal and either VCC or VSS so that the chip stays unasserted.
Finally, on the breadboard, add a diode to isolate the 5V rail from the battery backed SRAM.
Here's some notes on caveats you may encounter:
low-power SRAM
You want to be sure that the SRAM chip can be safely maintained at a low voltage/amperage if using a power source like a lithium cell.
A clear indicatior of that is a -L or -LL marking on the chip, though other CMOS SRAM can also have suitable characteristics.
In any case, it is advised to check the datasheet of the particular used chip.
Old NMOS/PMOS SRAM (most 2114 chips, early 16Kx8 SRAM) aren't very suitable for that.
programming SRAM
The TL866 series of programmers supports the following commercial modules from Dallas which algorithms can be used to program battery-backed SRAM:
- DS1220, for programming 16Kx8 SRAM (typically 6116)
- DS1230AB, for programming 64Kx8 or 256Kx8 SRAM (typically 6164, 6264, 62256) (*2)
(*2): There is a DS1225 module which would be suitable for 6164/6264 except that pin 26 isn't wired on those, and the TL866 doesn't assert that pin as a result. See the "funny scripts" section for examples on how to handle those using the DS1230 algorithms.
protecc the SRAM contents
You need a suitable circuitry that'll ensure that the breadboard computer won't do spurious writes at power-on and power-down.
This can be accomplished, for example, with voltage watchdog chips such as the TL7705, MCP100 or a simple microcontroller with brown-out detection.
the easy option: 6x64 SRAM
The 6164/6264 and compatible SRAM are well-suited for that approach due to the presence of an active-high Chip Select (CS2) signal.
On those, this signal can be wired directly to the /RESET signal to ensure protection of the stored data.
SRAM without positive logic enable
On SRAM without a positive logic enable, you can combine either the Write Enable (/WE) or Chip Enable (/CE) signal with the reset signal using an appropriate logic chip. Make sure that the logic chip is able to assert high the signal for long enough to actually protect the SRAM's data. A pull-up resistor can help with that.
data retention
You can expect data retention figures of more than 20 years with a -L rated 6164/6264 and a 220mAh CR2032.
funny scripts
Here is example shell scripts that can be used to program a 6164/6264 SRAM with the DS1230AB algorithm of the TL866:
#!/bin/sh
# read a 6164/6264
minipro -p "DS1230AB(RW)" -r /tmp/8ko
dd if=/tmp/8ko of="${1}" bs=8K skip=1 count=1
exit 0
#!/bin/sh
# write a 6164/6264
dd if=/dev/zero bs=8K count=1 | LC_ALL=C tr "\000" "\377" > /tmp/8kff
cat /tmp/8kff $1 > /tmp/8ki
minipro -p "DS1230AB(RW)" -w /tmp/8ki -s && exit 0
exit 1
[top]
"art"
[top]
Here's some random stuff i've drawn (hover for a brief description):
writing pc-98 disks with an ibm pc
[top]
Disclaimer 0: This assumes you're familiar with the NEC PC-98 family of computers. For information on this, I would recommand you to read this post on Wyatt's Blog.
Disclaimer 1: This is only useful if you don't have a flux writer (like a greaseweasle for example).
Disclaimer 2: You can also write a floppy by using your PC-98 itself, if you can easily transfer data to it.
crash course
The designers of the PC-9801 architecture (that is, the people at NEC) initially chose a simple approach for dealing with Sony's then new 3.5 inch
(90 millimeters) diskette format: they didn't.
That is, in the PC-98 world, a 3.5 inch drive can behave the same way as a 5.25 inch one. This had the main consequence of most games and software being distributed on what is commonly called the "1.2 MB format" (in reality, 1232 KiB).
This is different from the one used in the IBM PC world, which is exactly 1200 KiB (more on that later).
Since the interfacing was initially identical, the other consequence from this is that the spindle motor of those early 3.5 inch PC-98 drives rotated at a speed of 360 RPM, to match the speed of the 5.25 inch drive.
When the people at NEC later decided on adding support for the concurrent DOS/V format (which rotates at a speed of 300 RPM), they used a way to allow the drives to change speed on the fly to allow both formats to be read (it is unclear if this originated from NEC, as others Japanese computers of the era used the same approach).
3-mode floppy drives
The industry standard way of changing the speed of the spindle motor of a 3.5 inch floppy drive is by using pin 2 on the 34-pin interface (this pin is usually called "density").
In this regard, most floppy drives are not created equal, as only a fraction of those can actually change the rotation speed of the spindle motor.
Here is an exaustive list of drives (made by testing units that I have) with the various states of support for that feature:
Full support without any modifications:
- NEC FD1231T
- NEC FD1231M
- Mitsumi D353M3D-5000 (probably other variants)
- Teac FD-235HG (A103-U5 variant, probably others)
Support with hardware modifications on some exemplaries:
- Sony MPF920 (put solder on pad marked SH1 on the PCB)
- Alps DF354 (put solder on pad marked either MS2 or SW2 on the PCB)
Unsupported (may be possible with extensive modifications:
- Panasonic JU-257A606P
- Newtronics (Mitsumi) D359T7 (this one is hell to disassemble, so i didin't)
aside: 3-mode IBM compatible motherboards ?
A lot of people who messed with the BIOS setup of their computer in the 2000s will remember an option that was named "3-mode floppy support" in it.
Well, this option was meant for allowing Japanese users of Windows to have a way of reading and writing (but not formatting) their PC-98 floppies in the era when both types of machines were common.
The way it worked was by a custom floppy drive interface driver (some were supplied in the japanese releases of windows, some others were pre-installed by the OEM) that changes the way the operating system talks to the Super I/O chip on the motherboard.
Since it's very limited in its functionality and it's very hard to setup properly (tried on different motherboards, it does not want to work), I decided against using that, and preferred another method.
an imperfect but easy way of writing disks
"if you force 360RPM via hardware, couldn't you make it treat the drive like a 5.25" drive and have it work?"
This idea from Wyatt was the missing piece in the puzzle to solve this (very specific) problem.
The ingredients you will need for this recipe are:
- A 3-mode compatible 3.5 inch floppy drive
- A IBM compatible machine with a floppy interface
- A Windows 2000 or later installation that works on this machine
- Some images in the D88 format (if not, you can convert them with the tools here)
- The SAMdisk utility and the fdrawcmd.sys floppy driver
hardware preparation
Short pin 2 of your floppy drive to ground. Using a soldered wire is preferred, but you can also use a jumper (or switch) and extend the others floppy pins by soldering a male header with a female one like this:
Before doing modifications, double-check that the ground point you're using is actually connected to ground. Some drives for example does not connect pin 1 to ground, which makes the jumper method useless.
software usage
In the BIOS setup of your computer, modify the drive type of the one you installed to "5.25 inch, 1.2MB".
Install the fdrawcmd.sys driver using the instructions provided on the website, and copy the SAMDisk executable to a known location.
Then, you can test if your drive modification was sucessful by using the following command (with a floppy in the drive):
SAMdisk rpm a: (or b: if the drive is the second one)
If everything worked fine, the software should report a speed of approximatively 360RPM.
To write a disk, use the following command:
SAMdisk [disk_image.d88] a: (or b: if the drive is the second one)
You can also image a disk with the following command:
SAMdisk a: [disk_image.d88] (or b: if the drive is the second one)
See the documentation on the website for additional options.
additional thoughts
Since the fdrawcmd.sys part of this software is open-source, it should be possible to write a piece of software that would handle the many formats that the PC-98 floppy images uses.
[top]
books
[top]
Here are some (most) of the books that I've read, ordered by reading date.
Electronics books and mangas are excluded from the list, I have too many of them to list and I don't remember when I first read them.
I've written the English titles when available.
childhood:
- Microsoft Windows 95, 1998 New Edition, Warren Bates
- Building a PC for Dummies, Mark L. Chambers
- UNIX for Dummies, 4th edition, John R. Levine, Margaret Levine Young
- Linux for Dummies, 4th edition, Dee-Ann LeBlanc
- MS-DOS 5 utile, Daniel Rougé
adulthood:
- The Lord of the Rings, J.R.R. Tolkien (vol. 1 only)
- Introduction à Ada, Pierre Le Beux, Second Edition
- Sword Art Online, Reki Kawahara (vol. 5 and 6 only)
- The C Programming Language, Brian Kernighan, Dennis Ritchie
- Haruhi Suzumiya, Nagaru Tanigawa (12/12 vol.)
- Curiosities of Lotus Asia, Jun'ya Ōta "ZUN"
- Shakugan No Shana, Yashichiro Takahashi (1/22 vol.)
- Kino's Journey, Keiichi Sigsawa (16/23 vol.)
- Higehiro, Shimesaba (2/5 vol.)
- The CMOS Cookbook, Don Lancaster, Second Edition
- The TTL Cookbook, Don Lancaster
currently on the reading stack:
- Structure and Interpretation of Computer Programs, Second Edition, Harold Abelson, Gerald Jay Sussman, Julie Sussman
- The Apothecary Diaries vol. 1, Natsu Hyūga
Some notes:
All of my computer science books came from thrift stores.
Availability of light novels in a language other that Japanese can be abysmal. Kino and Shana only have the firsts volumes officialy translated in English, have long been out of print, and will probably ever be.
[top]
wanted software
[top]
I'm currently looking for a copy of the following software. If you have any information on it, please get in touch.
- NEC PC-UX or PC-UX/V for PC-98
- Any complete copy of any version (CD and floppies) of Debian(98), the PC-98 version of Debian.
hyperlinks
[top]
Here is a curated list of useful weblinks. More will be added later.
Miscellaneous:
archive.org, endless source of documentation and software.
J-Card Template, for audio casettes.
Hardware:
Bitsavers, lots of databooks here.
Retronik, databooks from French companies.
List of 7400-series integrated circuits
List of 4000-series integrated circuits
List of AMD Am2900 and Am29000 families
Caps Wiki
XDevs, manuals for instrumentation.
Circuit Simulator Applet
The GIICM, ASCII pinouts of chips.
PC:
minuszerodegrees, info, software on XT, AT, and ISA cards.
IBM AT 80286 BIOS, source and docs.
Ultimate Retro, info on motherboards, including BIOS database.
Macintosh:
Apple Macintosh before System 7, manuals and software.
Resurrecting my Macintosh Plus · tomek's blog, includes a PS/2 to Mac Plus adapter.
Macintosh SE Hardware Designs
a gcc-based cross-compiler for classic 68K and PPC Macintoshes
A 1:1 Recreation of the Macintosh Classic logic board
A collection of old world Macintosh ROM files.
TI99/4A:
The TI-99/4A Tech Pages
Tool for decoding TI-99/4a Cassette Tape recordings
Action game for the TI-99/4A home computer
[top]
this website
[top]
I had this really dumb idea of creating a webpage that would be contained in only one file.
Here are some random thoughts and obstacles I ran through while doing this:
This will absolutely backfire one day.
There is no menu to design.
Images. They are encoded in base64, and I had to make compromises on quality to keep the file sizes small and thus the html file somewhat readable:
-Mostly JPEGs in low quality (favicon for example is so small PNG is more efficient)
-Monochrome images
-Smallest resolution acceptable
Here is a 4KB JPEG example.
One compromise I didn't make was to use arhitmetic-coded JPEGs. stb-image.h and old browsers hates them, and the size loss wasn't that interesting.
As a side-effect, this webpage lacks colour. Except links.
this page was spellcasted at time 1770411022