Skip to main content

A source file one byte long

T

hanks to a comment I saw recently, I went down the rabbit hole that is HQ9+.

From Simple English Wikipedia:

"HQ9+ is a joke programming language made by Cliff L. Biffle in 2001.[1] It has four "operations":

 H: print "Hello, world!"
 Q: print the program's source code (sometimes called a quine)
 9: print the lyrics to 99 Bottles of Beer
 +: add one to the accumulator (the value of the accumulator cannot be accessed)"


My first goal was to run this on my RC2014. Rosetta Code has a version for 8080 to run on CP/M. The 8080 is a predecessor of the Z80. The Z80 is backwardly-compatible, but in order to assemble the program, many of the instructions must be altered*. Perhaps there are tools to do this, but I enjoyed doing it by hand. My Z80 version is here.

I expected this to work in direct mode, ie type H and see Hello, world. I may alter this program so that it works that way.

However, as it stands, hq9+.com is called from the command line and takes the name of a source file as a parameter. Maybe the Quine command makes more sense this way.

For example, your source file may be called test.hq and contain two bytes, HQ.

D>
D>hq9+ test.hq
Hello, world!
HQ
D>

The documentation for the 8080 version says that the accumulator can be read at memory location 0252h. This may or may not be the case with my translation, it would rely on my program being the same length as the original. I haven't yet checked. Note that if you do access the memory location of the accum: label, this isn't the z80 accumulator or a copy of it, but a variable in memory. Reading it after running the program would seem to go against the original principles of the language.

It's very cool passing in a source file consisting of a single byte:





* The instructions are equivalent, it's their mnemonics in the assembly source file that must be altered.



Comments

Popular posts from this blog

ZX81 reversible internal 16k upgrade

T his post is an upvote for Tynemouth Software's  ZX81 reversible Internal 16K RAM upgrade . Their instructions are easy enough for even me to follow and don't involve cutting tracks. This is the ZX81 I've had out on display and used whenever I wanted to. It's an issue 1 and was probably a kit judging by some very untidy assembly. It has a ZX8-CCB  composite video mod and an external keyboard fitted. On board it has two 1k x 4-bit chips.  The ZX81 originally came with 1k on board. Thanks to a trick with compressing the display in ram, that was enough to type and run a small program but you soon felt the limitations. Back in the early 80s, the solution was a 16k ram pack which plugged into the back[1] and this is the way I've been using this particular machine. These ram packs are notorious for 'ram pack wobble'. Even if fastened into place, you can still randomly find your work disappearing. This is a very reliable solution using a more modern 32k chip (half

Driving NeoPixels with Z80

I 've long been thinking about a version two   RC2014 LED matrix module . I've had a matrix with a MAX 7219 on a module. It's a nice enhancement. But there's only so much you can do with a single-colour LED array right? Wouldn't it be cool to have RGB LEDs?  At Liverpool MakeFest I saw a wall-sized ping-pong ball NeoPixel display and picked up some NeoPixels with the intention of making one. Possibly driven by my RC2014.  I enjoy learning about protocols and have had some SPI devices working with the RC2014 - bit-banging SPI works really well because it doesn't care about timing. NeoPixels really do care about timing though. From Adafruit's web page about their 8x8  NeoPixel matrix: If there's one thing I want to get across in this blog post, it's don't just accept what you're told . Question everything. Learn about what's going on and find out why you're being told something isn't possible. Get creative with workarounds. I'

Making new ROMs for the Vic20 / Vicky Twenty

M y Vicky Twenty is very nearly complete.  As things stand, the board and every single component is new*. The processor and VIAs are newly-manufactured (W65C02 and W65C22).  Obviously the Vic1 chip isn't manufactured today, but there is 'new old' stock about. I have been able to buy a Vic 1, date code 1987 (which seems very late). It obviously hasn't been in a computer before, passes the acetone test and works. The same goes for two of the ROMs - character and BASIC. But I haven't been able to buy a new-old Kernal ROM (901486-07). I am able to borrow one - all of the boards I have, have this particular ROM socketed. I don't know whether all of this indicates that the Kernal has proved less reliable than the other two. I recently bought a TL866 for another project. Of all the retro-computing hardware things I've had to learn to do, making ROMs has been one of the simplest. So far, everything has been very easy and worked first time.  I'm not sure that it&