Scott Adams Driver

[devwebcl]

Hello,

 

Once again playing with cc65 & Text Adventures I was able to port ScottFree

 

The problem is after compilation the memory left is to small, therefore all the games run out of memory, however there is a small adventure called Cloak Adventure small enough to be ported to different Text Adventure dialects (It's similar to a Hello World )

 

The game can be downloaded from http://devweb.cl/atari/cc65/cloak.xex

As you can see it's a very alpha release, where there is no layout control (as usually in this kind of games).

 

The final idea was to see something with this Parser to compiled and functional in the a8.

 

Regards,

 

Devwebcl

Edited October 19, 2007 by devwebcl

[JamesD]

If you can convert the I/O so that it bypasses stdio you'll save several K of RAM.

You might check to see if any of the other 6502 compilers generate smaller code.

 

You might also try starting with this interpreter instead.

http://www.ifarchive.org/if-archive/scott-...ree/scottzx.zip

Edited October 20, 2007 by JamesD

[devwebcl]

If you can convert the I/O so that it bypasses stdio you'll save several K of RAM.

You might check to see if any of the other 6502 compilers generate smaller code.

 

You might also try starting with this interpreter instead.

http://www.ifarchive.org/if-archive/scott-...ree/scottzx.zip

 

Thanks for the tip, anyway I'm using ScottFree, the one you mention is a version for ZX of it, but I have compared the code and the difference is most about the printing of information (about layout) and load/save feature, but I don't see any improvement about data structure or else.

 

I think the big problem is the atari free memory and perhaps the heuristics of cc65 for optimization, however is great compiler, thus I think the TODO is to implement a compression algorithm for the data.

[Wrathchild]

I'm using the original interpreter (well the one from the value packs)

and relocating it to run from RAM after loading from ROM and that is

fitting fine in 8K. I use CA65 and LD65 to build a cart image and this

also contains the game data for titles 1-12 which is accessed at runtime

as required, a menu to select which game you want to play and the

original script font. A game at runtime can now run in 16K

 

Certainly your overheads of C->asm, use of heap/stack and the

need for support of the runtime libraries when building ScottFree

are probably too great, I tried a similar thing before with the ITF

infocom interpreter for the Atari ST, building it under CC65, for me

I think the approach is to come up with a method of putting segment

code in separate banks and have a 'far' call type way of swapping

between then, say a subroutine/function jump table in RAM.

 

Regards,

Mark

Edited October 20, 2007 by Wrathchild

[devwebcl]

....Certainly your overheads of C->asm, use of heap/stack and the

need for support of the runtime libraries when building ScottFree

are probably too great, I tried a similar thing before with the ITF

infocom interpreter for the Atari ST, building it under CC65,

Do you have a final executable of that porting, or did you have the same

problems than me? (to run out fo memory).

 

I think the approach is to come up with a method of putting segment

code in separate banks and have a 'far' call type way of swapping

between then, say a subroutine/function jump table in RAM.

 

Regards,

Mark

 

Do you know where I can find more information of segments rearrangement

in memory banks? I found something in the compiler documentation, but I it wasn't very clear.

[Shawn Jefferson]

What are looking to do with segment rearrangement, devweb?

 

You could put your subroutine/jump table in LOWCODE (use #pragma codeseg("LOWCODE") ) and that will insure that your jumptable code is below the extended RAM window ($4000), as long as you are using the default linker config. I'm doing that in one of my programs that automatically switches in BASIC (which would overwrite some of the program, not to mention the default display list and screen ram.)

[devwebcl]

What are looking to do with segment rearrangement, devweb?

 

You could put your subroutine/jump table in LOWCODE (use #pragma codeseg("LOWCODE") ) and that will insure that your jumptable code is below the extended RAM window ($4000), as long as you are using the default linker config. I'm doing that in one of my programs that automatically switches in BASIC (which would overwrite some of the program, not to mention the default display list and screen ram.)

 

thanks for the help , I'll take a look to it.

[Wrathchild]

Sorry for the delay in replying, I wanted to experiment a bit

with a cart model switching example which I've posted on the

programming forum for further discussion on it there.

It certainly ain't pretty, but does give some idea as to how

this can be done (in this case using the XEGS model).

 

Regards,

Mark