OT: Z-Machine for the Intellivision?

[First Spear]

Wow, very inspiring:

 

https://hackaday.com/2019/05/22/zork-and-the-z-machine-bringing-the-mainframe-to-8-bit-home-computers/

 

Although sales would hover somewhere near zero for an Intellivision port, my question is: could a version of Z-Machine be implemented on an ECS-enhanced Intellivision? With 3k of RAM (using the ECS) and lots of ROM storage available (using JLP cartridge architecture), maybe? The text display would also be tricky since the words would have to be pre-rendered to display within available GRAM, but still, just wondering.

 

 

 

 

 

 

[+KylJoy]

Cool idea. I can't make it, but I want it.

[intvnut]

I've ported the Colossal Cave engine to the Intellivision, and I don't see why Z-Machine would be impossible. I don't know how much RAM it needs. If it needs more than what JLP provides, there's always LTO Flash. I think I looked at it once before and concluded it wouldn't fit in what I had at the time. We now have more RAM and ROM space.

 

ZIL itself looks a bit LISP-like at first glance. There are some other languages that also target the Z-Machine.

 

It looks like many of the Z-Machine resources listed on the Wikipedia page have fallen offline. Here's an Archive.org link to one though.

[First Spear]

https://github.com/historicalsource?before=Y3Vyc29yOnYyOpK5MjAxOS0wNC0xNlQwNDowMzo1NCswMTowMM4KzcIl&tab=repositories

 

https://archive.org/details/Learning_ZIL_Steven_Eric_Meretzky_1995

[carlsson]

Regarding memory requirements, you could have a look at the Intellivision's classmate from primary school, the VIC-20. It would seem that some Infocom games can be squeezed into it using 24K memory expansion, though 35K is recommended. That is kilobytes, though of course the way the 6502 addresses memory is different from the CP-1610 so it might only be a hint.

 

The fact that it natively does 22 columns x 23 rows also is somewhat close to the Intellivision's 20x12.

 

http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?f=10&t=4208

 

Edit: Enabling the JLP switch adds 7999 words = almost 16 kilobytes as far as I can tell, but suppose the LTO Flash can overcome this, perhaps by temporarily storing data into flash memory?

Edited May 24, 2019 by carlsson

[intvnut]

Looking through the Z-Machine memory map, it's designed to allow most of the memory visible to the interpreter to be read only. That means it can live in ROM. You only need R/W access to the dynamic portion of memory. As long as a game can fit its dynamic segment in the 8000 words JLP provides (not 7999), the rest can live in ROM.

 

JLP offers up to ~120K words (240K bytes) of game storage through page flipping. Some of that needs to hold the interpreter though. Story files that fit in the remaining space, though, should be workable. Because Z-Machine is an interpreted machine, the mapping between Z-Machine addresses and Intellivision addresses can be as flexible as needed.

 

LTO Flash offers up to 1MB (512K words) through page flipping. It also supports Intellicart-style bankswitching, which offers 128K bytes of RAM. There is also a special LTO Flash specific mapper that's more flexible than either of those that allows mapping arbitrary portions of the external RAM into the Intellivision space dynamically in 256 word chunks. (I'm not intentionally hiding it; I just haven't gotten around to finishing the documentation, and nobody's expressed interest in a pure LTO-Flash-only game yet to drive it.) None of those requires resorting to storing data in the JLP-style flash save area.

 

There is also expansion room in the flash filesystem to allow hanging additional data forks off of games, so if there was enough interest, I could add support for that as well. It would require extending the firmware and the GUI, but it would not be a change to the on-disk format.

 

I've meant to release the LTO Flash wire protocol and file format docs for awhile now. I had been pushing for a 4/15 release date, but obviously didn't hit it. I think I'll just release what I've got. Perfect is the enemy of the good, I suppose.

[Zendocon]

This is an interesting topic.  I was just thinking about a port of DunNet (a 1982 text adventure game bundled with emacs and written in LisP).  Since the TutorVision has 4x the GRAM, all the text could be drawn in a "mini-font" that blits pixels to memory, which then is loaded into pages of GRAM that refresh one frame at a time.  Each of the 240 cards on screen would have its own dedicated GRAM card.

 

Since the ECS has 2K of onboard memory, and since you would need a keyboard anyhow, the 1,920 bytes of RAM that would be pushed into GRAM could just come from there.  The Intellivision's onboard memory would be sufficient for the variables that DunNet itself needs.  Then, with procedures to save and load games to/from an Aquarius Tape Drive, there would be no need for JLP.

 

The only thing missing would be "wizard mode", for those of you who have played through the game and know what that is, since it's just a port and would not still be written in LisP.  I wouldn't mind taking on such a project.  But it begs the question, who would actually want it - and who has a TutorVision and an ECS to play it on?

[intvnut]

The TutorVision and ECS are mutually incompatible, due to a ROM clash at $2000 - $2FFF.

 

You'd need an INTV88 without the full TutorVision EXEC.

[First Spear]

Something else on the topic, for posterity. 

 

 

https://hackaday.com/2019/09/16/upping-the-story-telling-game-with-dialog-and-the-a-machine/