Harry Potter

I tried both ports. Maybe I don't have the joy keys set. I'd better try that today.

The latest version now supports up to 128 one-byte tokens and should support up to 190 two-byte tokens. The second-latest version supports up to 64 one-byte tokens and up to 190 two-byte tokens. They are at the same location as the previous versions. BTW, there's a typo in the second-latest version: on the CBM version, there is a line in the printtok() function that reads: [code]if (e>=0xE0 && e<0xF0) prints (tokensa[e&0x1F]);[/code] Remove the upper bound of the condition, as it excludes usable tokens. Upgrading to the latest version helped out my Smir 3, 1 text adventure's database file by about 8.8%. That's in addition to what an earlier version did: about 25%. I ask you to try out these versions of PrintTok. BTW, PrintTok2 is in the works and will include many ways to compress literals and provide automatic compression.

I did and fiddled with the settings, and a game I tried didn't register the key asssignments.

I tried it today, and now .stx files work. Now, I have another problem: how do I emulate a joystick? I don't have a real joystick--okay, I have some at my mother's house bjut never use them--so I need to use the keyboard.

TGB1718: I thank you for the info, but a very recent build doesn't work properly on the laptop. I think it's because the laptop might not have 3D support. I downloaded v. 3.9.4. Does that version have Pasti support?

Oh. Thank you. I'd better Google a later 32-bit version of Steem.

I'm mainly using Steem 3.2, and, after installing pasti.dll, while starting up Steem, it registers that the file was installed, but the files don't appear. I admit that I was wrong about two versions of Steem not working: one actually does work: 3.9.3 Beta 64-bit works, but a later version gives me an exception immediately. I copied the .dll files to the 3.9.3 version, but I saw no difference there. Maybe I'm missing some files in the second install, as I copied what I thought were the relevant files from the first install rather than unpacking them from the .zip file. I'd better try that again on Sunday, when I'm at program next.

I downloaded it.

Thank you. I will Google pasti.dll now.

Thank you. As I mentioned, the n ewer versions didn't work on the computer at my day program. I'll try again today and plan to look for later versions of Hatari soon.

I'm using an earlier version, as two later versions didn't work properly on that computer--I forgot why. I figured out how to get the disk menu in Hatari but could not find the button to switch to a different drive on Windows: it was set to work on Drive C:, but the game images were on a floppy compressed using WinMount which registered the drive as Z:. I have to check the actual versions tomorrow.

Hi! I have some Atari ST games in .STX format that I want to run. A later version of Steem doesn't work. Two earlier versions worked but didn't register the files. Hatari doesn't offer an option to switch drives, and the images are on a different drive than the emulator. How do I get the files to work?

If anybody here has cc65 and wants more memory for AtariXL programs, I have a library called MemXAtari. It provides sections of the OS's memory that are not needed by most cc65 programs and has an option to provide 128k extra memory--I think the chip that handles that is Freddie. Its memory layout assumes you are using DOS 2.0, so, if you're using another DOS, you will probably have to change the memory layout. It uses AtaDisk65 to load in the stubs and the contents of the extra memory, so you may need that. You can find MemXAtari at c65 additions - Manage /memory cfgs at SourceForge.net and AtaDisk65 at c65 additions - Manage /ui at SourceForge.net. BTW, I am attaching a config file for the OP in hopes that he can use it to determine which memory areas might be usable. atarixl_small.cfg

Oh. Sorry!

I'm sorry for not replying yesterday evening. Again, I have some information on extra free memory you can use from another user here, and I'm asking for permission to publish here. Also, the Atari memory map mentions the usable memory. It mentions the DUP.SYS file, whose memory area you should be able to use if you're either resetting on program exit or not exiting your program. You can also use things such as the cassette buffer, memory reserved by BASIC or input areas for the editor. Finally, different DOSes have different setups and use different areas of memory. If you're writing for a specific DOS, you may have extra memory unused by the DOS. If you want to compress your data, I have ideas which should better a compression technique. Does this help?