I have been converting Riven screenshots posted by Cyan, and eventually
wondered how much of the game could fit on one 140k floppy disk.
As expected, the answer is not much. It was then expanded for
multiple disks.
Legal Note
This product contains trademarks and/or copyrighted works of Cyan.
All rights reserved by Cyan.
This product is not official and is not endorsed by Cyan.
Current Status
Disk01: You can walk around a small part of Dome island right after arrival.
(10% of disk used)
Disk39: You can walk around the temple on Dome island and take the maglev.
(95% of disk used)
Disk40: You can arrive at Jungle Island via the maglev and poke at the orb.
(75% of disk used)
Disk41: You can walk through the tunnel and bother the sealife.
(90% of disk used)
Disk43: You can walk around the logged forest near the cart.
(60% of disk used)
Video
Video capture of v0.05 disk40/41/43 on an actual Apple IIe Platinum:
(note I did edit it slightly to cut out some of the extra disk
loading times)
Video capture of v0.03 disk39 on an actual Apple IIe Platinum:
Screenshots
Some screenshots captured with AppleWin emulator.
Disk01:
Disk39:
Disk40:
Disk41:
Disk43:
Was having fun making props for the video:
Technical Discussion
So how does this all work? I'll spare you an extensive
Apple II hardware overview,
except that it's a 1MHz 6502 processor, we'll assume 48k of RAM, and
that's about it. It has "hi-res", "lo-res", and text modes, but they
are simple (weirdly interleaved) framebuffers,
so no fancy sprite or other hardware that you
might find on other 8-bit systems. One thing it does have going for it
is by 1980 or so you could assume people would have at least one
fast floppy drive (much faster than the ones found on other 8 bit systems).
The game engine is a variant of the one I put together for Apple II Myst.
It's fairly simple, it has a data structure for each location, these locations
you can face up to 4 directions N/S/E/W and have background graphics
for each direction. For each direction you can optionally link to another
location (which is how you walk places). Each location also lets you
have one trigger where you put an action callback triggered by clicking
on a square-shaped region of the screen.
Drawing the pointer is just doing a simple hi-res software sprite.
The graphics are two images, a sprite and a mask,
to allow for some transparency.
I cheat a bit and only allow horizontal positions in multiples of 7 pixels
as that immensely simplifies the code (the hires screen is stored 7
pixels [well, technically 3.5 if you're doing color] per byte with one
bit for palette).
I use ZX02 compression on all of the graphics. Hi-resolution graphics
are 8k uncompressed, but they compress down to roughly 4k depending on
the complexity. See here for
some notes on tradeoffs when generating hi-res graphics.
Due to how I have the engine set up the 32k area from $4000 - $C000
is available for the code and graphics data, which means
roughly 7 or so backgrounds
are available before you run out of room. Apple II supports page-flipping,
but I don't use it here as that would take up an additional 8k of RAM
for the extra page. The window-blinds like transition between images isn't
a special effect, it's a weird side effect from the memory interleaving
inherent in Woz's design of the system.
The movies are done in lo-resolution mode. The movie from the game
was captured and images dumped at 5fps, and then I hand roto-scoped them
(which took forever). Lo-res graphics are 1k, but with ZX02 compression
they are often about 200 bytes or so depending on complexity (and at times
I intentionally left out details so they'd compress better. The longer
movie is 137 frames. Optimally it would be 20 or so longer, but I stopped
when I hit 32k. I could have played games where I pre-loaded extra data
to the language card (16k memory expansion) but in the end I was tired
of rotoscoping. We do use page flipping here, which possibly will make
things run poorly if you have an Apple IIgs because most of those
systems have a bug where the designers forgot to support lo-res Page2
in hardware and have to use a slower software workaround.
The interior of the maglev is a separate overlay that is copied on top
of the backgrounds. The handle-movement animation at the beginning is actually
flipping between a series of overlays.
I originally meant to use sprites for this, but
in the end compressed overlays (all 8 are compressed in one big blob
that is decompressed at $2000-$4000) ended up being quicker/easier.
I use Qkumba's "qboot" disk routines. This is a bootsector and a few pages
of disk code that can load contiguous areas from disk into RAM. By skipping
having an operating system it frees up at least 8k of space on disk, as well
as running faster than code that has to seek around to catalog tracks
and track/sector lists. It was a challenge getting this going though because
I had to load the stage2 boot loader up to $1000 to be out of the
lores-page2 range and so had to fix up a lot of places in the code and
it's always dangerous messing with qkumba's deep magic.
In the end there's probably still around 6k or so of free space on the disk
scattered around but I didn't think it was worth padding everything down
to make it contiguous.
System Requirements
Any sort of Apple II should work (II/II+/IIe)
Should also run on IIc or IIgs but not tested as much
Note: the movies use page2 of lo-res graphics which is broken
on some models of IIgs, and the software workaround will
be slow
If you don't want to use an emulator / don't have an Apple II at home, you
can in theory play disk39 in a browser at the internet archive here:
riven_hgr at Internet Archive
Frequently Asked Questions
Are you going to implement the whole game?
Famously I say no to this question and then go on to
implement things. This time it's more of a laws-of-physics thing
more than lack of time. It would take literally hundreds of
disks worth of images to implement the full game.
What if you did things in lo-res mode like the
Myst demake?
Riven is still an order of magnitude larger, we'd be looking at
years of work and 30+ floppy disks.
Yes. What I enjoy is writing things that would have been
technically possible back in the day. For a VCS port it would
have to fit in 32k or less of ROM and you wouldn't be able to
fit a lot of Riven in that much space.
Could this version of Riven had been created back in the day?
So if you had a time machine and took a floppy with this version
of Riven on it back to 1980, it would work just fine on an Apple II+.
This does not mean it could have been easily created back then.
I take advantage of a lot of modern technology. I write the code
on a modern Linux machine, with lots of code comments (and so what
would have been at the time a lot of disk space).
Even the low-end coding environment I use (plain text console
nano editor) would have been revolutionary at the time.
I cross compile
and test in an emulator which is a fairly quick turnaround.
People did sometimes cross compile back in the day from larger
machines, but this would have been expensive. Also back then
Apple IIs weren't cheap, so having even a second one of them
for testing would have been considered extravagant.
The images would have been another problem. The Riven graphics
were made with 3d workstations and raytraced on large machines,
this would not have been possible in the early 80s. You possibly
could have hired artists to do photo-realistic graphics from scratch,
but again the tools were fairly primitive. Also the disk space
issues comes up again, there are hundreds of images, and PNG and
GIF and JPG didn't exist yet so you'd need storage for them.
I also take advantage of ZX02 compression, but it can take up to
a minute to compress all the images on even a relatively fast
machine I have now, this would have been hundreds to thousands
of times slower on vintage hardware.
Why are the graphics so ugly? No one would be able to play
this without knowing the original.
Then this is not for you.
I'm not sure why some people think this is a productive or
helpful comment.
How do you make the graphics?
I have a complicated process where I take screenshots, shrink
them to roughly the right size, and reduce the colors using GIMP.
I'll then hand-paint over it with some dithered patterns. I will
manually touch things up, and sometimes it will take a few attempts
to get something that looks reasonable.
It would probably have gone faster if I were using a proper
pixel-art tool, especially one that lets different layers have
different pixel sizes. It also didn't help the version of GIMP
I was using had a bug where it would crash if you tried to
cut-and-paste an area that was much wider than tall.
Why are the colors mostly blue and orange?
It'd be a bit much to get into the horrible reality of Apple II
hi-res graphics, but essentially the "easiest" way to attempt
things is 140x192 graphics
in blue/orange/black/white and this seems to be the best
approximation of the colors in Riven. You can throw purple and green
into the mix too, but there's color clash issues and often adding
in the extra colors doesn't really help.
Aren't there automatic conversion tools that will make much better
looking results?
I aesthetically like the dithered orange/blue look.
The auto tools sometimes I think are too dithered. They also
don't compress as well (though I should run tests to fully
verify it) which matters when you're trying to fit on a floppy.
Why are the movie sequences lo-res?
It would be hard to get a good framerate in hi-res, and would also
take up a lot of disk space. I sort of had some existing
lo-res movie code from my Second Reality port. Finally, I thought
it was a nice callback to how the original game would lose some
resolution when it switched to quicktime video.
Could you fit more data with a better compression routine?
Believe it or not there is *extensive* work out there on trying
to find the best compression for 8-bit computers. You can find
a lot of details on this in various sizecoding/demoscene forums.
I'm using ZX02 because
I've used it before, it compresses well, and it is relatively fast
and low-overhead to decompress. I'm sure there might be something
else better these days but it can be exhausting keeping up
with the state of the art here.
Is there any significance to the disks being 39 and 40?
I wish I had a clever reason, but it was mostly because I was
looking for a plausibly high number that I could easily
draw the Rivenese version with ASCII art.
Why limit yourself to 140k? Can't a double-density
5.25" disk hold more than that?
(360k on an IBM PC?)
It's easy to get lost in the low-level details of how
floppy disks work.
The standard Apple II format eventually settled on was
35 tracks of 16 sectors, each 256 bytes. The Apple II drives
were single-sided so this works out to 140k without flipping
the disk. IBM PC drives were eventually
double sided, and also could manage 40 tracks which gave them
a bit more room. Some Apple II drives could also read more than
35 tracks but there was no guarantee this would work.
But I head on the Apple II drives you can directly poke the
stepper motors and such for all kinds of fancy effects.
Can you get more space that way?
Yes, but writing code to do this is a huge pain.
The most famous fancy format is RWTS18 by
Roland Gustafsson (notably used on Apple II Prince of Persia).
This did advanced things to have 6 sectors of 768 bytes per track,
for a total of 157k or so.
Why not use that? I don't know
if there are tools to create the proper images.
One reason to stick with 140k images is that all Apple II emulators
can handle them, wheras if you try to do something fancier you
need to use .WOZ or some other format and that's not as widely
supported. Also my build system uses a bunch of custom tools
I wrote to generate disk images and I'd have to re-write things
to deal with the larger sizes.
Why do you include the "disk bootup" scene in your video?
That can't even be a machine you'd want to play on as it
obviously has a "Monitor ///" display which is monochrome
black+green.
I include the Disk ][ boot noise as the rattling sound it makes
triggers distantly forgotten memories in a lot of Gen X people.
(The noise is the drive
finding track 0 by repeatedly seeking down a bunch of times
and slamming against the stop because Woz saved money by not including
a track 0 sensor).
Did you play a lot of Riven back in the day?
My high school friends went in together and
got it for me relatively soon after
the release in 1997. (I guess it was 1997? I vaguely thought it
was when I was still in high school, but I graduated in 1996).
Anyway it was the 5 CD version and I played it on my family's
AMD K5 windows 95 machine (as I was already Linux-only on my
own computers by this point).
It was possibly the first "real" boxed game I actually owned,
most of my life had been shareware
up to that point.
(What about Myst you ask? My best friend
is the one who owned Myst, I had to go to his house to play it).
Adjusted for inflation possibly one of the more
expensive gifts anyone has gotten me.
Development Notes
25 June 2024 -- v0.05
Spent way more time than necessary getting an updated version done by
the Riven remake release date. you can now go through disks 40, 41, and 43
which means arriving on Jungle island, poke the orbs, scare the sealife,
and walk up to the minecart.
Some of the graphics are a bit more rushed than I'd like but I really wanted
to get a video up.
21 June 2024
Added some sound effects when you poke the orbs.
19 June 2024
Updated the code so you can actually switch between floppies when
prompted and it will continue with the game. It seemed like a pain to
try to do ASCII art for every possible D'ni number (and some didn't
map well at all to it) so I went and did the silliest thing possible
and wrote a 512-byte lo-res routine to draw any possible D'ni number from
0 to 624. This involves having BCD (binary-coded decimal) but instead
whatever the base-5 equivalent is.
And then, to be more rediculous, I ended up noticing it looked like the
masks from my lovebyte 2024 plasma demo so I ended up throwing together
a demoscene demo from it. Due to popular demand you can see that here:
D'ni Counting Demo.
18 June 2024
Add beginning of disk01, the start of the game (after the first set
of cutscenes). The graphics are a bit muddy at the start sadly.
Also updated disk39, you can now flip the maglev back (essentially just
playing the flip movie backwards).
17 June 2024
Work on the build system, redid things so disk40 has the proper contents
(should be arrival at maglev station).
16 June 2024 -- v0.04
With all the current Riven hype I thought maybe I could add a few more
disks worth of walking around. So I have the beginnings of disk40
(near the cart on Jungle Island).
This involved a major re-work of the code to make it as generic as possible
so I didn't have to cut and paste everything for each new disk.
I also moved a lot of common code to the loader, which freed up enough
space on disk39 that I can hopefully add a few more images.
28 May 2024 -- v0.03
Tired of rotoscoping, more fit than I could have hoped for.
Time to release! Also moved from QLOAD to QBOOT for that little extra
bit of space, though it was a huge challenge remembering how the
qkumba magic worked.
26 May 2024
As expected the rotoscoping of the maglev is taking forever.
I started out trying to be too detailed, as there are lots of neat
details in games like this that you only really notice when stepping
through frame by frame. But anyway
for both sanity and compression reasons you'll notice I started being
a bit looser with the conversion.
23 May 2024 -- v0.02
Have the walking-around stuff more or less finished, depending on
disk space. Also have the first movie (the maglev rotation) done.
In the end just used zx02 compression as it gives better disk usage
than the box-drawing stuff. What's left is mostly the longer movie,
maybe moving to a QBOOT implementation (frees up 16k or so of disk space),
and the actual main reason I was messing with this, trying out enhanced
IIe keyboard handling.
16 May 2024 -- v0.01
The nearing of the Riven release had me thinking about it a bit.
I was wondering if I could re-use my Second Reality lo-res animation
code for one of the maglev scenes. And of course if I do that I might
as well have some of the game leading up to it.
