zzt for graphing calculator

Discuss how totally awesome Bang! is here.

Moderator: Terryn

What do you think about ZZT for the TI-89?

1. I'd play it.
5
83%
2. Better to write it for a cellphone.
0
No votes
3. Great idea. I'll help!
0
No votes
4. Terrible idea. Why do people keep trying to revive ZZT?
0
No votes
5. Get a life.
1
17%
 
Total votes: 6

dct4w
newcomer
Posts: 8
Joined: Sun Mar 27, 2011 2:09 am

zzt for graphing calculator

Post 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?

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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.
*POW* *CLANK* *PING*

User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 180
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Post 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!

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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.
*POW* *CLANK* *PING*

User avatar
asiekierka
YAHOO: ALL YOUR GEOCITIES ARE BELONG TO US
Posts: 223
Joined: Sat Sep 10, 2005 10:06 am

Post 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.

dct4w
newcomer
Posts: 8
Joined: Sun Mar 27, 2011 2:09 am

Post 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?

User avatar
q2k2k
1 full minit uv 1 secend mesiges
Posts: 74
Joined: Thu Apr 24, 2008 4:19 am

Post 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

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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?
*POW* *CLANK* *PING*

User avatar
asiekierka
YAHOO: ALL YOUR GEOCITIES ARE BELONG TO US
Posts: 223
Joined: Sat Sep 10, 2005 10:06 am

Post 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.

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1427
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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).

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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.
*POW* *CLANK* *PING*

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1427
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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.

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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.
*POW* *CLANK* *PING*

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1427
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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.

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: zzt for graphing calculator

Post 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.

Post Reply