PROJECT: Z-Machine for Hydra/Propeller
Wes Brown
Posts: 39
I should be getting my Hydra today via UPS. Yay.
I've decided that my first project will be a Z-Machine implementation for the Hydra. For those of you who might not be aware of what the Z-Machine is:
en.wikipedia.org/wiki/Z-machine
Taking a look, it appears that I might be able to write the Z-Machine and squeeze it into 32K of ROM. This leaves me with 96K of ROM for the actual games themselves. Zork 1-3 are about 96K each. I think I will be targeting version 5 of the Z-Machine standards.
Once I've implemented the Z-Machine, I will likely write a streaming decompression driver to run on a COG; this should hopefully let us run more recent interactive fiction, as version 5 files can be up to 256K. But Z-Machine files are already compact, so this may not be achievable with 128K ROM cartridges.
As the Z-Machine is really an early virtual machine, we should not have any problems running these games inside of 32K of RAM, as we can page in objects from ROM.
-Wes
I've decided that my first project will be a Z-Machine implementation for the Hydra. For those of you who might not be aware of what the Z-Machine is:
en.wikipedia.org/wiki/Z-machine
Taking a look, it appears that I might be able to write the Z-Machine and squeeze it into 32K of ROM. This leaves me with 96K of ROM for the actual games themselves. Zork 1-3 are about 96K each. I think I will be targeting version 5 of the Z-Machine standards.
Once I've implemented the Z-Machine, I will likely write a streaming decompression driver to run on a COG; this should hopefully let us run more recent interactive fiction, as version 5 files can be up to 256K. But Z-Machine files are already compact, so this may not be achievable with 128K ROM cartridges.
As the Z-Machine is really an early virtual machine, we should not have any problems running these games inside of 32K of RAM, as we can page in objects from ROM.
-Wes
Comments
Welcome to the world of Hydra programming! Your proposed project sounds like a lot of fun to do.
I was really into the Level9 adventure games back in the day. They worked in a similar way to the Z machine, with a virtual machine and compressed text. And about 28K for the entire file with all code and data. I was quite tempted to have a go at doing an interpreter for that, but it's not nearly as well documented as the Z-Machine is.
Good luck with it. It'd love to hear of your progress as you go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
1) You don't have to do paging. Reading from the EEPROM directly should be fast enough for a Z-machine interpreter and simpler.
2) Plan for the use of both an expansion card and the on-board EEPROM. The Hydra switches to the expansion card for the "boot" area in the first 32K, but the on-board EEPROM is relocated to have EEPROM addresses from $20000 to $3FFFF. You can use 96K from the expansion card plus 96K from on-board EEPROM for a total of 192K for a Z-machine game.
3) Be sure to put together a Z-machine loader to download games. If you're only going to be using the TV output and not VGA, you could wire up an SD card socket for your Hydra on a memory expansion card and run Z-machines directly from a PC-compatible SD card. Have a look at FemtoBasic for directions and code that you can use (download it from the Object Exchange). Alternatively, you could get a Parallax memory stick datalogger and wire it say to the network port using a memory expansion card (so you have +5V, ground, and reset available). That would let you use PC-compatible USB memory stick drives.
This might spark some interest in Andre's suggestion for a beautiful text driver too. If memory is a concern, I've got a small footprint 8x8 text display driver up and running. It's a character mode one, similar to how the old computers did text mode.
http://forums.parallax.com/forums/default.aspx?f=25&m=220192
Right now, the font is ATASCII, but that is in the process of changing to standard ASCII.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Very good point. However ...
Ooo, very nice tip, although it can be a bit awkward to load games, being a two stage process to flash the EEPROM and then the expansion card.
If I do this, then it may be prudent to have a page-in architecture for objects, because I don't think I can address memory stick dataloggers or SD card directly as memory? I have to load it into RAM?
Awesome. Seeing ATASCII makes me nostalgic. I grew up with an Atari 800. Thanks for the pointer, and I'll take a look at this text driver. I may even improve it!
-Wes
Have a look at the Basic_I2C routines from the Object Exchange.· You'll see that all the EEPROM attached to a given pair of pins works like a· contiguous address space.· If you have an expansion board plugged in, the EEPROM appears like a 256K I/O address space.· You pass an address from $00000 to $3FFFF to a read or write routine along with a destination address in RAM and a byte count.· For writing, you're constrained to write up to 32 bytes (usually ... some EEPROMs permit a larger "page" size) within a 32 byte address boundary, then you have to wait for the EEPROM to finish the write operation before doing anything else with the EEPROM.· There are faster routines available in assembly language.
The I/O routines in FemtoBasic combine I2C and SPI access (SD cards use an·SPI protocol) and there's a higher level package that handles the FAT file system stuff so you can have PC-compatible SD cards.
-Wes
I used to play that on my old Commodore 64, one of my favorites...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
I just made a prototype of the SD card reader hardware (used radical eye's driver and stuff from mike green femto basic and menu tweaked by mike park) to test it out. With the SD card and a reasonable resolution of 160x190 with dithering and or palettized mpegish compression (or if worst came to worst 128x128), you should be able to stream video off the sd card at 30 fps as well. What would be REALLY cool, if is someone took the time to go do some video and make a crude laser disk game, you could do something really easy like do some filming at a cemetary then have your actors walk on set, shoot them and or they they don't get shoot and have all the decision points of the video. Anyway, just an idea since video is doable off SD which I am going to finish the design in the next 2 weeks, it will have the SD card interface and a 128K eeprom on there, plus potentially a micro SD and or a MMC card interface, might as well give options if I can, so you can read different media with the card. The only bummer is you loose the VGA simulataneously when using the IO lines, but in most cases after you are done with the IO, you can drive the VGA and it works fine since the chances of the vga signal being the right protocal to talk to the target device that's in parallel with the IO is slim. However, I "might" put a disconnect switch on the IO card, so that from IO control you can disconnect it after you are done then drive the vga without worry you might clobber memory in it or send it commands, we will see.
Andre'
It's only video at the moment, sound is currently being added....
www.propgfx.co.uk/forum/Blah.pl?b-pb/m-1192456487/
Regards,
Coley
The competition can be found here: http://www.ifcomp.org/
Also, on this genre, there are two basic forms:
Turn based, which is the Z machine kind of stuff. Essentially, this is the INFOCOM style of game
,and
Real time, text interactive.
That's a game like Madness and the Minatour, which runs on the CoCo. I'm sure that one is emulated some where, as it's pretty unique and raised the bar for these kinds of games. It's too bad it never saw more attention though.
The real time form, has things happening all the time, and will on occasion print additional messages to your console, depending on what happens and where. An example would be, you just entered a room, the description was printed, or maybe the player typed look, or examine.
While the player considers what they've been told, a message prints "You hear screaming in the next room over..."
That brings a fear and drama element into the whole thing, somewhat absent from the turn based forms. I still remember the first time that happened, having been a turn based player often.
Anyway, I love the genre. Back in the 80's, when we were all computer gaming, these kinds of games saw a lot of attention. At some point, they just went away. Too bad really.
For a while, I ended up owning one of those little HP palmtop things. Got a Z machine up and running on it. Kids would play the heck out of the games, downloaded from both the archive and competition. We played those in the car on a long trip or two. One person running the palm top and acting as an audio console for the rest of us. So, we get the room description read aloud to everyone, then we discuss it, decide what we think should happen, then they input that and the cycle begins again. Great alternative to the usual game of "slugbug".
It's a pretty unique and fun multi-player co-op game form.
Still think they could be a huge hit with the cell phone gaming crowd, particularly if the occasional image were included, and displayed upon entering specific rooms, or for reaching goals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/20/2007 5:37:23 PM GMT
I wonder if I can squeeze a Z-Machine into 496 assembler instructions; how do you guys do larger assembler programs? Separate the functions into COGs and use inter-cog communications? [noparse]:)[/noparse] Or do you use a loader to push ASM at the cogs?
-Wes
I can't see much point in doing any of the Z-Machine in ASM. ASM uses a 4 byte word for each and every instruction. SPIN gives you a byte code, often for an instruction that does more. For the equivalent functionality, SPIN is going to take less space. And although SPIN is slow compared to PROP ASM, it's of at least a comparable speed to the ASM of the microprocessors that the Infocom games originally ran on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 10/24/2007 12:24:04 PM GMT
And you'll keep memory usage low with Spin, which means more for the buffers for the Z-Machine files to use.
I've been focusing on the 8x8 text driver for now -- as this is an engine that revolves around text, I'd wanted as good and nice a text driver first. I will also likely be writing a text handling library.
Thanks for proving my point [noparse]:)[/noparse] Looks good. When you have sound going, hopefully, you will publish the code or at least a binary, so we can load a movie on an SD card and play it with the hydra.
Andre'
Hybrid SD pins are P8-P11, I assume you are going to use the Hydra expansion port for your SD card, let us know the pin assignments and we will post a binary for you to test.
Regards,
Coley
-Wes
Just out of curiosity, what size are the Z-machine files?
I also think the SD might be a good file storage option for your Z-Machine.
SD would actually be a great option for the Z-machine stuff. Typically, they range from 64K to 200K each.
What I'd likely do is target it to reading from EEPROM initially with the 96K Zork as the test VM, and then as it gets closer to release quality, insert in SD drivers. And then people can stuff their SD cards with interactive fiction. [noparse]:)[/noparse]
SD would also make saving games in progress much easier and practical.
-Wes
We're all here if you get stuck or just have questions.
Jim.
You sure about that? When I think about it, I can just address the EEPROM as addressable random memory, right? This way, when I read the Z-machine bytecode, I read it straight from EEPROM.
If I loaded via Serial, then I can only hold a very small fragment of the bytecode in whatever RAM I have left before I'd have to request data from the host computer. I'd have to write a simple host server program that services requests for addressable memory. [noparse]:)[/noparse]
-Wes
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
emulate their behavior without Z-machine methods.
It is interesting about the text compression and I was aware of it but did not use it
in the same way. I discovered the 3 letters in 2 bytes format by looking at the
APPLE II monitor rom with it's disassembler feature, wondering how they stored
all of the 6502 instruction names in the mere 2K program; that was the answer.
Perhaps it is even more efficient to have a dictionary and use bytes as pointers to it.