Page 1 of 2

zzt for graphing calculator

Posted: Mon Mar 28, 2011 12:31 am
by dct4w
Has anyone thought of porting ZZT to a graphing calculator (like the TI-89)? Perhaps modifying the DreamZZT source code?...

The interface would have to be a little bit different... maybe the side bar would fade in and off the screen at the press of a button to give more space. Also, the screen would have to scroll because of the small screen resolution.

There are sound programming libraries for the TI-89, and it's possible to connect headphones to the I/O port.

Porting ZZT to a graphing calculator seems in the spirit of ZZT- simplicity in graphics and sound, and in a format convenient to nerds (such as engineering students in class).

I don't think I'm going to attempt this project, because working on anything related to ZZT has always sucked me into obsessive spiral, and I have a lot of things going on in my life right now. But still, I think it's a cool idea...

Am I crazy, or is this a good idea?

Posted: Mon Mar 28, 2011 3:41 pm
by Commodore
I've thought of doing something like this for c64 but came to the conclusion that it would have to be abbreviated. Due to display and memory restrictions. That is if you didn't want disk access every time you move to a new board.

I think the idea would be to do something like ZZT but not necessarily a clone. Keep it on one screen, none of that funny scrolling stuff. Commands that reference color would be pointless etc.

Posted: Mon Mar 28, 2011 5:41 pm
by Smilymzx
Commodore wrote:I've thought of doing something like this for c64 but came to the conclusion that it would have to be abbreviated. Due to display and memory restrictions. That is if you didn't want disk access every time you move to a new board.

I think the idea would be to do something like ZZT but not necessarily a clone. Keep it on one screen, none of that funny scrolling stuff. Commands that reference color would be pointless etc.
In my opinion, A PC with a 80286 (or the newer of the processors) is as far as you can get if you want to make a new ZZT,

6502 and Z80 ''demakes'' technically will not happen, But ARM (used on the DS and DSi) on the other hand might work, just look at Kev's port of (sorry to say this) Megazeux for DS!

Posted: Mon Mar 28, 2011 7:21 pm
by Commodore
I think a "demake" or whatever is entirely possible. The problem is memory. In the space of one load on c64 64k you could maybe hold 14 boards assuming a thin 4k a board and 8k code. Of course there's on the fly packing/depacking you could use to get more. Or use a combination of world files that link with passages. (disk access... ugh)

As always the only things preventing these things is time and effort.

Posted: Tue Mar 29, 2011 12:44 pm
by asiekierka
ZZT only needs a 8086+ CPU. From the portables, the HP 100LX/200LX offers that, get one on eBay. Warning: they're not the cheapest.

If you have a fast phone/console, get Bochs or DOSBox on it. In case of the DS, get DSx86 (warning: ZZT's color palette is wrong but i already bugged the author about it) or DreamZZT DS (if you want good speed but not good compatibility)

@Commodore keep in mind you have to either remove the KERNAL (to get an extra 8KB) or rewrite it (will probably give you more code than needed). Also the IO ports (take 4KB) and the $0400-$07FF area for the screen (1K). Also, if you use the KERNAL, there's some areas between $0000 and $03FF used, but they probably won't make a real difference.

Posted: Tue Mar 29, 2011 9:16 pm
by dct4w
Interesting comments. Thanks for the information!

@Commodore It seems like it would be nice to have the option of mini-ZZT worlds (worlds made specifically for the calc. version) and also originally-sized worlds, so that you could automatically play all of the classic ZZT games like Enigma, Chronos Wars, Merbotia, etc., etc. That would be what would make it worth it to me. The only annoying thing would be that since ZZT was designed to be one screen, some games wouldn't work or at least would be difficult to play. I'm fascinated that you've looked into this for the c64.

By the way, DreamZZT code seems to be pretty buggy... Is there a better source code option out there?

Posted: Wed Mar 30, 2011 4:01 am
by q2k2k
i actually tried making levels like that back in math class when i was bored
it didn't work out as well though, ended up making the same level every time for every tile of empty space that was walkable in that tiny screen. no scrolling effects.

it was more of a program to test movement

Posted: Wed Mar 30, 2011 2:01 pm
by Commodore
@asie yes removing the kernal and basic roms would probably happen. If you didn't need any of its routines, and you probably wouldn't unless you wanted to steal its disk access routines. What you do need will take those precious few KB though. 2k for character set, and 2k for the screen ram and color ram (meaning a minimum of about 2k if a board is the size of the screen.)

I'm imagining object code would be represented by pairs of characters or single characters. The problem is the more commands you add the bigger the code side of the program gets. things like text would eat up your memory very quickly. I also imagine labels and object names might have to go and instead you send commands to objects by object number and line number to start execution and use branches a la machine language.

?k
?k
?k
?k
af+2 :align false
!k
?o
j-7
:s
x20:1
d

?seek
?seek
?seek
?seek
#if not alligned #do
#shoot seek
:do
?opp seek
#restart
:shot
#send object20:do
#die

If you can't tell I've been thinking about this a lot. What better than to combine the two things I love?

Posted: Thu Mar 31, 2011 12:57 pm
by asiekierka
dct4w wrote: By the way, DreamZZT code seems to be pretty buggy... Is there a better source code option out there?
There's Tyger, and from what I've heard it has fantastic compatibility. It's coded in Python, though.

Posted: Fri Apr 01, 2011 11:40 pm
by Quantum P.
@Commodore: I wonder if it would be worthwhile to use a full-blown compression format, like DEFLATE or something similar. It would make the program more complicated, and you'd probably have to write your own simplified version in bare assembly in order to get the decompressor as small as possible -- but it might let you eke out more space, especially when it comes to text.

Huffman coding might interest you, if you haven't heard of it already. If some bytes are more common than others, you can squeeze the really common bytes into fewer than 8 bits (the tradeoff being that uncommon bytes take more bits to represent).

Posted: Sat Apr 02, 2011 12:15 am
by Commodore
currently exomizer is the standard for compression, but it is a cross-cruncher (compresses on PC, decompresses on c64) Not sure what the best native c64 compression is but I'm not sure I have the aptitude to write one myself.

Edit: After a little research it seems that run length encoding is the fastest way to compress since any more complicated schemes can take hours on the actual machine.
C=Hacking wrote:Regarding compression times, a char/RLE packer typically takes the time it takes to read a file twice, as they usually feature two passes -- one for determining the bytes to use as controlbytes and one to create the packed file. Sequence crunchers like TimeCruncher typically took a few hours, and CruelCrunch as much as ten hours.

Posted: Mon Apr 04, 2011 3:46 pm
by Quantum P.
C=Hacking wrote:Sequence crunchers like TimeCruncher typically took a few hours, and CruelCrunch as much as ten hours.
Yikes. Maybe I don't fully understand the technical constraints of the C64, but that seems excessive. Perhaps the crunchers are geared toward crunching every last byte out of the data; it may be possible to do a more sloppy compression job but still get something better than RLE.

Posted: Thu Apr 07, 2011 6:39 am
by Commodore
I've given it some thought. Juggling the memory would be a pain in the editor. Better to scale it back more. Smaller rooms. Fewer unique objects. To make up for that I was thinking about global objects all the rooms can share. Program your own tigers. All the possible rooms exist in memory but are empty. The key would be squeezing versatility into a small package.

Posted: Sun Apr 10, 2011 3:27 pm
by Quantum P.
Yeah, scaling back would make development much easier. Keeping versatility shouldn't be much of a problem, though; all you really need is the core of ZZT-OOP and the terrain-and-object model.

In order to fit a ZZT-compatible system in 64K and do it well, you'd need to have some kind of memory management system. For example, you could divide object code into 512-byte chunks, and you would only load each chunk as you needed it. If you keep the 64 most recently used chunks in memory (32K total, plus some small overhead), then you could potentially go many boards without reading from disk. Objects with lengthy programs only load the active portion of their code into memory, and #ended objects don't need their programs loaded at all.

Downsides: The game may pause if a dormant object starts up, or needs to load the second half of its program. #send message:all causes the whole board to load, unless you keep an index of who has which labels. Doing this efficiently requires either complexity, reorganization of the ZZT file format, or both.

So yeah. Scaling back is a good idea.

Re: zzt for graphing calculator

Posted: Tue Oct 04, 2011 2:35 am
by Saxxon
I think it'd be necessary to tokenize ZZT-OOP in order to make it small (for example #IF = 0x01 etc). There's no way it would fit well in its native format. Also, ZZT's RLE has quite a bit of repetition even on high detail boards, you could probably use LZ-type compression. Would mean increased load times but LZ is simple enough that you could implement it on pretty much anything. For better results, compress all the tiles together and all the colors together instead of interleaved tile/color.