See the Apple II version for a more
complete 8-bit Peasant's Quest experience.
Inspiration
I was working on finishing the Apple II PQ and saw a CGA coding jam
was happening and though "how hard could it be to port it".
There have also been many hints of a DOS/CGA heritage for the game, with
with Strong Bad's "4 of 12: World Games"
episode which had a CGA Kerrek, but also the original
Peasant's Quest Preview video saying the system requirements were
maximum 286/CGA.
Legal Note
This product contains trademarks and/or copyrighted works of
homestarrunner.com.
All rights reserved by homestarrunner.com.
This product is not official and is not endorsed by homestarrunner.com.
Current Status
Major work remaining:
Only 12 of the locations are currently implemented
The dialog isn't fully hooked up in the left-most
locations
Most special screens are either incomplete or not implemented,
for example the inventory, load/save, and map
It's possible you might get stuck if you have bad luck walking
into a collision zone
No sound or intro, or game-over screen
Videos
Promo for the initial release.
Most of the video captured with MartyPC emulator running at normal
original IBM PC speeds.
Screenshots
Note: these were captured with the DOSbox emulator.
System Requirements
Presumably any sort of IBM PC with CGA display.
I've only tested with various emulators.
How can I play it?
You can download the image below and then try running it on a real machine.
This actually hasn't been tested.
You can download one of the images and run it on an emulator.
It is known to work in both DOSBOx and MartyPC
(you can run MartyPC in your browser)
The controls are similar to the real game, with arrow keys controlling
the walking and typing text for commands.
If you want to change the color palette try control-B or control-Y
Implementation Details
I never really liked DOS, and while I spent some time in the 1990s on
the platform it was in the 386/VGA era, not 8086/CGA. I did write some
games back them but mainly in VGA mode 13h in Turbo Pascal.
So this is bringing back a lot of ancient skills (and ancient bad
habits tripping up my C coding, like the whole = vs == mess).
A few notes for the curious:
I didn't actually code the game in the Turbo Pascal editor.
I do all of my development in Linux using the nano editor.
I modified the .nanorc to give proper Pascal syntax highlighting.
To build the code ``make'' copies the source files to a directory
then launches DOSBox with a script that runs the command line
TPC.EXE Turbo Pascal 6.0 compiler
Graphics were captured from the flash version of the game running
in a browser, edited with the GIMP, then I have various
command line tools for manipulating to the right formats
The code is mostly regular Pascal (though poorly written as I have
a lot of C habits these days). The zx02 decompression and
sprite routines are in inline 8086 assembly language for speed.
The text printing routine is just the standard BIOS routines, I was
too lazy to implement my own and it seems to more or less
work this way
Mini-faq
Q. Are you going to make the full game?
A. Videlectrix #1 will be very annoyed if I do that
before finishing the Apple II version.
Q. Was it hard to write this?
A.
Yes.
Mostly because I am targeting an original IBM PC.
The CGA graphics have a lot fewer restrictions than Apple II,
but the colors are so ugly!
Also so much slower, the PC is full
of all kinds of wait states and refresh. Apple II the graphics
framebuffer is same speed as normal memory and Woz handles
RAM refresh for free.
The one upside is for a PC you can assume 640k of RAM
(even though that's a bit anachronistic) which is available
without bank-switching. So I can allocate 16k for a priority
buffer w/o a second thought, while on Apple II I have to instead
try to cram that into a 1k region.
Q. So how did you draw the graphics?
A.
Took screencaptures from the ruffle/flash version on the website,
did the best I could with the GIMP.
Q. Did you decompile the Flash version of the game?
A.
No. (Later on I did a bit mostly to look at some of the graphics
assets for reference. I don't use any of them directly nor
do I look at the code, mostly because I find the actionscript
[or whatever it's called] to be pretty incomprehensible).
Q. Is CGA capable of more colors?
A.
Yes, there's both composite output mode
(see the
Area 5150 Demo for this taken to the extreme)
and also the 160x100x16-color
mode which might be interesting to try.
However stereotypically
when people think CGA they think of either the
cool-ranch cyan/pink/white palette or the chipolte taco
seasoning green/red/yellow palette.
Q. Did you use AI to make this?
A.
No, I hate the current crop of AI and want nothing to do with
it. I am also judging you if you are using it.
Q. Why aren't you writing this fully in assembly language?
A.
I actually have relatively OK x86 assembly skills, but
I find it exhausting to write. I have been spoiled
by 6502 assembly and it's hard to go back.
Just doing the minimal inline assembly made me remember
all kids of complicated 8086 horror and corner cases
that I am glad I
don't usually have to deal with.
Q. Will this run too fast on a newer machine?
A.
I am limiting the framerate by waiting for the CGA vsync
which seems to keep things at a constant speed.
Do be aware that Turbo Pascal itself the CRT unit has
issues on machines faster than 200MHz or so where a
timer calibration causes divide by zero
("Runtime Error 200"). There are programs that will patch
this, I probably should do that as part of the build
process.
Development Notes
5 April 2026 -- Version 0.02
Finally got a more or less interesting release out the door.
The big hold up was priority (i.e. the ability to go behind objects).
In the end went a different route than the Apple II port, and was
extravagant and waste 16k on the lookup table. Lets you have much
more fine-grained objects, while wasting vast amounts of memory.
30 April 2026 -- Version 0.01b
This semester was over-the-top busy so made very little progress.
Finally had some time and got the common dialog working.
Then loadable dialog. Then got level transitions.
Decided to keep the data in a separate file on disk and using
the WAD format for that (as a joke at first, but turns out
it is a good one to use).
Getting close so the slow load-time of the pascal zx02 decompressor got
to me, so re-wrote that in 8086 assembly. Ran it on Linux/32-bit
first then converted to 8086 DOS. Am out of practice with 8086
asm so got caught by things, like MOV not modifying the zero flag,
then trying to use OR to set zero only to find it modified
the carry flag. The last issue that needed fixed was ret was
retf by default when I wanted retn, but after that it worked.
16 January 2026 -- Version 0.01
I had some code floating around to convert a CGA-style PNG file to something
Turbo pascal could load. I made this as a joke to load a static
image of the Kerrek scene. For some reason I began ramping things
up to show a few scenes from the game and as always things got
out of hand.
Other DemakesBack to the VMW Software Productions Page
