Shop OBEX P1 Docs P2 Docs Learn Events
Zork for propeller — Parallax Forums

Zork for propeller

unixoidunixoid Posts: 17
edited 2012-09-12 12:14 in Propeller 1
Hi all,


I discovered propeller recently and decided to do a small project to get familiar with it.




It seemed that noone implemented Z-machine to to run Zork and similarinteractive fiction games yet (I only found the catalina version on the forum, but that requires extra hardware).

So attached is a simple Z-machine which I call ProZ [noparse]:)[/noparse]



It it writen in Spin and runs on one cog using standard Keyboard and TV_Text/VGA_Text driver (but could use any terminal output).

Zork data files are about 100K in size so they won't in memory. I am reading them off an SD card using fsrw.

Zork game file can be downloaded from http://www.infocom-if.org/downloads/downloads.html

It should not be hard to use a different storage that has at least 128K instead (hydra EEPROM etc).



Smaller game files which fit in memory can run in a standard demo board set-up with no extra storage.

E.g. here is a couple of nice little games:

http://www.ifarchive.org/if-archive/games/zcode/moonglow.z3

http://www.ifarchive.org/if-archive/games/zcode/catseye.z3



Give it a try and let me know if it works for you or if you encounter any bugs.

This version is configured for demo board with TV driver and SD card on base pin 0.



Some implementation notes:

1. Only version 3 of the Z-machine specification is currently supported. This is the version Zork trilogy uses, but many later games use versions 5-8. It may be possible to add version 5 support, but others may be too difficult to fit due to the memory limitations...



2. Z machine specification assumes that the whole game file is loaded in memory and can be accessed quickly. With an SD card this is not possible so I have to use virtual memory by accessing it one page at a time. This makes the large game a bit sluggish due to constant paging (though definitely playable). Perhaps a more clever caching algorithm can be used.

There also seems to be no way to seek to a particular location with fsrw so I have to read the file from the beginning each time I need to fetch some data.



3. Game file name is defined at the end of the file (storyFile). Alternatively you could load the file direcltly into the mem array provided it is under 12K (see commented out code). There are a few constants at the top of the file defining memory, stack and cache page allocations. The ones that are there work well with Zork I. They may need to be tweaked for other games.



4. User interface is somehwat limited. You can enter text from keyboard and do basic edits using backspace key,but that's about it.



5. You can save and restore games. Game is saved in savegame.bin file on the SD card.

Post Edited (unixoid) : 8/3/2010 6:27:55 AM GMT
«1

Comments

  • RaymanRayman Posts: 13,798
    edited 2010-08-02 16:52
    Great idea! I used to play that on my dad's Kaypro back in the 80's...

    It's actually useful to look at the code to learn how to program games, in general, too.

    I'm guessing this is for TV, right?

    Now, if only somebody could get Nethack to run [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

    My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • rokickirokicki Posts: 1,000
    edited 2010-08-02 17:23
    Hmm, fsrw has had seek in it for some time. Are you sure you're running a recent version?

    But this is exciting, no question about it! This needs to be put on Rayman's little LCD screen boards.
  • unixoidunixoid Posts: 17
    edited 2010-08-02 17:44
    Rayman, I tested it with both TV and VGA. Both work OK although they have slightly different resolution and I find TV to be a little more suitable.
    There is no way to scroll up so the printout of long descriptions stops after every page asking you press a key.
    I also tried higher-resolution VGA modes and they look really nice, but unfortunately they require too much memory.
    I wonder if there is a way to tweak the VGA driver to deliver resolution higher than 32x15?
    The standard high-res VGA tile drivers are way too big and only worked for me with very small game files.

    rokicki, I found seek support in the fsrw 2.6 (I think it is the latest), but it seems to be limited to the single 32K cluster only (?). Or maybe I just don't understand how it works...
    But I am actually using the older version of fsrw as the new one is too big anyway [noparse]:)[/noparse]
  • potatoheadpotatohead Posts: 10,253
    edited 2010-08-02 17:58
    This is really cool!! Thanks for doing it.

    It's also motivation to get the binary loadable TV text drivers done. Soon, we will be able to fetch them in binary form from the SD card, into a 2K COG start buffer. From there, launch them, and once running, use that buffer for other stuff, like probably spooling game files. Should only have a memory footprint of a few K for the font and screen data. up to 80 characters, if desired...

    I love IF too. Can't wait to give this a go.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • trodosstrodoss Posts: 577
    edited 2010-08-02 18:02
    @unixoid,
    Sounds great! Definately going to give this a try.

    Baggers had created a 40x30 TV Text using half height ROM font
    obex.parallax.com/objects/452/

    Maybe the same could be done with VGA (using Kye's newer VGA driver)?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits


    Game(s) Mythic Flight
    Utilities Font Editors (AIGeneric, Potato_Text, etc.)
  • unixoidunixoid Posts: 17
    edited 2010-08-02 18:18
    potatohead, I was thinking of tweaking the drivers to load the assembly code from unused buffer space in EEPROM (which is wastefully filled with zeros).
  • unixoidunixoid Posts: 17
    edited 2010-08-02 18:20
    trodoss, will check out 40x30 text on TV. This may work...
  • ericballericball Posts: 774
    edited 2010-08-02 18:21
    Great job! I also coded up a Z3 interpreter (serial I/O, game in memory) in SPIN a while ago. But the project hit the back burner before I put in the virtual memory / SD interface. I also considered doing a RAMBlade version. Let me know if you're interested in my source.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-08-02 18:34
    You can definately seek on the older fsrw. See ZiCog for how this is done. We use an 8MB file which must be contiguous and we locate the first sector then just feed the sector plus offset into the getsector (cannot recall the name but it is fairly easy to find in ZiCog).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • unixoidunixoid Posts: 17
    edited 2010-08-02 18:35
    Virtual memory is the tricky part. This is by far the worst bottleneck at the moment when playing a big game and sometimes
    the game pauses for a second or so while doing extensive memory paging.

    I use a very simple algorithm which loads data from SD card one page at a time and only keeps track of which page is currently loaded
    and loads a new one if necessary. In a single turn in Zork it may reload the page hundreds of times.
    Most likely a more advanced caching scheme that keeps track of several smaller pages will deliver better performance.
    A lot of research has been done on virtual memory paging in OSes and there is a number of paging algorithms out there (FIFO, Random, LRU...).
    But I did not venture there yet.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-08-02 18:52
    Great work!

    I spent a LOT of time playing Infocom games many years ago...

    Try using my VMCOG - add two $1.25 32Kx8 SPI RAM's and you have 64KB more memory. More if you use more /CS signals, and you can use a 74HC138 to decode 8 /CS lines from three Propeller pins.

    The current version is limited to a 64KB VM, but there will be a new version soon that will support MUCH bigger VM's.
    unixoid said...
    Virtual memory is the tricky part. This is by far the worst bottleneck at the moment when playing a big game and sometimes
    the game pauses for a second or so while doing extensive memory paging.

    I use a very simple algorithm which loads data from SD card one page at a time and only keeps track of which page is currently loaded
    and loads a new one if necessary. In a single turn in Zork it may reload the page hundreds of times.
    Most likely a more advanced caching scheme that keeps track of several smaller pages will deliver better performance.
    A lot of research has been done on virtual memory paging in OSes and there is a number of paging algorithms out there (FIFO, Random, LRU...).
    But I did not venture there yet.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
    My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
    and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
    Las - Large model assembler Largos - upcoming nano operating system
  • unixoidunixoid Posts: 17
    edited 2010-08-02 18:54
    Cluso99, thanks for the idea. I checked ZiCog code and it looks fairly simple. This does rely on the file being in contiguous sectors, but should be more efficient than reading the file from the beginning...
  • unixoidunixoid Posts: 17
    edited 2010-08-02 19:09
    Bill Henning, yes adding RAM will make a huge difference.
    Extra 64K RAM may be a tad too small for Zork.
    Game files are 94K (roughly 12K dynamic plus 82K static).
    We only need extra memory for the static part so we'll be 18K short.

    I think extra 96K of EEPROM will work best for this project (unlike SD card, you can do random access to EEPROM)
    so this should fit nicely in HYDRA. I don't have one to experiment with, but folks are more than welcome to try.
    All static memory access is done through getByte method which can be modified to work with any kind of storage.
  • BaggersBaggers Posts: 3,019
    edited 2010-08-02 19:26
    Nice work unixoid [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • RaymanRayman Posts: 13,798
    edited 2010-08-02 19:39
    I think you can do fast random access with rokicki&lonesock's FSRW. It's so much faster than eeprom, I have to think that's the best approach...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

    My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • lonesocklonesock Posts: 917
    edited 2010-08-02 20:03
    In this thread (near the bottom), sssidney modded the latest FSRW code to be read-only...that might shrink the size enough to be useful for you.

    Jonathan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    lonesock
    Piranha are people too.
    (geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")
  • unixoidunixoid Posts: 17
    edited 2010-08-02 20:15
    Rayman, do you mean random access to clusters (vs position within a file)?
    Or is there an easy way to do random access to files? Cluso99 offered a way to do that (which is a somewhat hacky).
  • unixoidunixoid Posts: 17
    edited 2010-08-02 20:23
    lonesock, thanks for the pointer.
    Yes, I do read only access most of the time (except when saving the game where, obviously, write access is required).
    So ideally I could use a bare minimum driver (no FAT32 or directories) that has both read and write with seek support only for reading.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2010-08-02 21:45
    I did some CP/M stuff with Infocom games a year or so ago..
    I suspect that the Zmachine files here (Not the executables) would be compatible with your project.

    Nice Job!

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Feature Projects: PropellerPowered.com
    Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
  • RaymanRayman Posts: 13,798
    edited 2010-08-02 21:55
    unixoid said...
    Rayman, do you mean random access to clusters (vs position within a file)?
    Or is there an easy way to do random access to files? Cluso99 offered a way to do that (which is a somewhat hacky).
    No, random access to any position in the file...

    It's not particularly optimized for speed, but should still be much faster than eeprom...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

    My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • unixoidunixoid Posts: 17
    edited 2010-08-02 22:34
    Oldbitcollector, yes, these may very well work as long as they are version 3 files. I did not do much testing on any files other than Zork files though.

    Rayman, are there any examples of random access to files with fsrw?
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-08-02 22:52
    If you use a 74HC138, the next version of VMCOG will drive up to 8 SPI RAM's for a total of 256K.
    unixoid said...
    Bill Henning, yes adding RAM will make a huge difference.
    Extra 64K RAM may be a tad too small for Zork.
    Game files are 94K (roughly 12K dynamic plus 82K static).
    We only need extra memory for the static part so we'll be 18K short.

    I think extra 96K of EEPROM will work best for this project (unlike SD card, you can do random access to EEPROM)
    so this should fit nicely in HYDRA. I don't have one to experiment with, but folks are more than welcome to try.
    All static memory access is done through getByte method which can be modified to work with any kind of storage.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
    My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
    and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
    Las - Large model assembler Largos - upcoming nano operating system
  • RaymanRayman Posts: 13,798
    edited 2010-08-03 00:09
    unixoid said...
    Rayman, are there any examples of random access to files with fsrw?
    Don't know...· But, it's pretty trivial...· Jusk call seek with the byte# you want and the next read or write will be there (at least as I remember).

    Personally, I just used seek(0) to start reading at the beginning of the file again...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

    My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • unixoidunixoid Posts: 17
    edited 2010-08-03 00:45
    Oldbitcollector, I checked the files from the pointer you posted and they are all version 3 and load fine except StationFall
    (and it also loads with a two-line fix).
    Attached is a snapshot of the Hitchhiker's Guide to the Galaxy running on the VGA monitor.

    Games which came after Zork are more verbose and there is a lot of scrolling. This is where a high-res text mode would come handy.
    623 x 480 - 69K
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2010-08-03 00:51
    Adapt this to Potatohead's 8x8 tv driver and you are in business..

    So who's gonna get the Babelfish with a Propeller first? [noparse];)[/noparse]

    Edit: Project added to Propellerpowered!
    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Feature Projects: PropellerPowered.com
    Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.

    Post Edited (Oldbitcollector) : 8/3/2010 1:03:19 AM GMT

  • RaymanRayman Posts: 13,798
    edited 2010-08-03 00:55
    For VGA, Parallax does ship "VGA_HiRes_text". Might be a better choice for this. I think it only uses 1 cog.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

    My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • unixoidunixoid Posts: 17
    edited 2010-08-03 01:10
    Rayman, rokicki, I tried seek in the latest fsrw and does appear to be working. The warning in the documentation says not to use it on files larger than 32K, but it does seem to be working correctly on game files which are around 100K.
    Needless to say the games are much faster [noparse]:)[/noparse]
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-08-03 02:23
    unixoid: A simple way maybe to check if the file is contiguous. IF not, you can build a sector table, or create a new contiguous file, or warn the user and stop.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • potatoheadpotatohead Posts: 10,253
    edited 2010-08-03 02:31
    HHGTG?? I thought that one required a higher level Z machine! Sweet. I've gotta go and play on this now. I love that one.

    We can get 80 characters on the screen easy enough [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • unixoidunixoid Posts: 17
    edited 2010-08-03 06:15
    Rayman, I took a look at VGA_HiRes_text and it looks like it may work. It is more compact than a tile driver. Though it comes with fonts which take space...
    The smallest resolution it provides is 80x40 which looks really nice, but requires 3.2K for the buffer which I don't have and also there is no API interface similar to VGA_Text (but that should be easy to add).
    So I guess some memory usage optimization is in order [noparse]:)[/noparse]
Sign In or Register to comment.