Pacman++ is now available (finally)

[JohnCG]

Hello, it's me again. I downloaded the updated files. I used my CF7+. Ran the install files and everything installed and the game ran fine. I got to screen 7 before dying with 3 Pacman. You have created an awesome very playable version. Great job!

[Cheung]

3 hours ago, HOME AUTOMATION said:

Ha-ha, second place I checked!

That's it,.good job!

[Cheung]

35 minutes ago, JohnCG said:

Hello, it's me again. I downloaded the updated files. I used my CF7+. Ran the install files and everything installed and the game ran fine. I got to screen 7 before dying with 3 Pacman. You have created an awesome very playable version. Great job

Thanks, glad it finally worked for you. How are the load times, particularly between new mazes?

[JohnCG]

Using my CF7, about 10 seconds. Using my PEB about 15 seconds. Being all solid state circuitry the CF7 is going to be faster.

[Cheung]

Thanks, that's faster than I would have guessed

[Cheung]

On 8/12/2024 at 6:58 PM, Tursi said:

The game looks and sounds really good, btw! I bet we can get the data on the cart

I'm sure it can be done, I don't know how Rasmus and others would have been able to make some of the games they have without the data on cart, but I don't know how to do it and my inquiries haven't yielded much information that would enable me to accomplish such a thing. It of course would be the ideal configuration, the program AND the data both in the cartridge binary.

 

Could you describe the steps needed to accomplish this? Can the data be peeked from the cartridge?

[+OLD CS1]

1 hour ago, Cheung said:

I don't know how Rasmus and others would have been able to make some of the games they have without the data on cart

They are programming in assembly language.  There are ways to take your level data and what-not and apply a compression to them for your game.  I believe the XB compiler manual has some ways to implement putting data into your program without the traditional methods of taking up space in your program.

[Cheung]

50 minutes ago, OLD CS1 said:

There are ways to take your level data and what-not and apply a compression to them for your game.  I believe the XB compiler manual has some ways to implement putting data into your program without the traditional methods of taking up space in your program.

Yeah, I'm not sure it would fit even when compressed. The XB program already has the compressed music data and it only has about 100 bytes leftover before it's assembled and compiled.

[Tursi]

2 hours ago, Cheung said:

I'm sure it can be done, I don't know how Rasmus and others would have been able to make some of the games they have without the data on cart, but I don't know how to do it and my inquiries haven't yielded much information that would enable me to accomplish such a thing. It of course would be the ideal configuration, the program AND the data both in the cartridge binary.

 

Could you describe the steps needed to accomplish this? Can the data be peeked from the cartridge?

As OLD CS1 said, generally they are programming in assembly.

 

I guess I don't count as a developer capable of such things, but nonetheless I've done it for other programs in the past and mapped out this one too. We'd extend the cartridge to a few more banks and replace DSRLNK with a simulated function that reads the data from cart instead. 

 

I have looked into your code, and it looks like it copies to RAM and runs there entirely, so /technically/ yes, if I am correct, you could use CALL LOAD to change pages and CALL PEEK to read the data. That would actually be a pretty cool approach... to change page you just access a memory location correlating to the page you want (so >6000 accesses the first page, >6002 the second, >6004 the third, and so on. >6000 is 24576 in decimal). Once the right page is selected, you can CALL PEEK to the same range to access the bytes. You'd have to set up the ROM in advance for testing, of course.

 

But with only 100 bytes free I don't think you'll have enough space to code that, unless you moved more data to the spare pages of course.

 

My plan was to just write a replacement DSRLNK and replace the hook - I did this for a number of programs a few years ago to move them from disk to cartridge. Unfortunately I didn't get around to the DV80 version (I see I started it for Major Tom), but it's straight forward enough. I'll probably get it done on the weekend.

 

[Cheung]

27 minutes ago, Tursi said:

But with only 100 bytes free I don't think you'll have enough space to code that, unless you moved more data to the spare pages of course.

Reworking/eliminating the current disk loading would probably yield a couple more hundred KB and moving the sound effects/music out of the program would probably get another couple hundred. But I'm thinking more for what I'll be working on next, Satan's Keep, which should be pretty expansive, Zeldaesque game requiring loading data from outside of the program.

[Tursi]

7 hours ago, Cheung said:

Reworking/eliminating the current disk loading would probably yield a couple more hundred KB and moving the sound effects/music out of the program would probably get another couple hundred. But I'm thinking more for what I'll be working on next, Satan's Keep, which should be pretty expansive, Zeldaesque game requiring loading data from outside of the program.

You only have 32k right now... am I misunderstanding where you are finding hundreds of k?

 

Anyway, the task won't be too hard. I'll include a write up of what I did with the ROM.

 

[Cheung]

7 hours ago, Tursi said:

You only have 32k right now... am I misunderstanding where you are finding hundreds of k?

 

Yes, of course you are. Hundreds of bytes, I miswrote.

Edited August 16 by Cheung

[Cheung]

This should be the last update for the files for this game unless we're able to get the data on the cartridge binary.

 

I found a bug where it looks like the extra life is occasionally not rewarded - hopefully this has fixed the problem.

PACMAN++.bin PMINSTALL.bin PMRES.dsk

[globeron]

js99er.  need to play with E,S,D,X   (arrows does not work)

 

Nice game, I like it with the different screens and acts in between! 

There is a bit kind of movement with shocks (or not smooth, like in Munch-Man to go fast) and I thought maybe it is the emulator and tried Classic99 and MAME as well, but it is the same.

It looks with JS99er, Classic99 the score is not saved (maybe only disk read access), but in MAME I set the disk to write access and the score is saved and loads after a reset.

 

 

Edited August 18 by globeron

[Cheung]

28 minutes ago, globeron said:

Also when loaded the high score is not saved on .dsk ?  (then I restart js99er.net, the high score is still there, but after a reset also the high score is gone and had some issues

Thanks for the comments.

 

I think that has something to do with JS99er, seems to save the scores with Classic99 for me.

 

If by "shocks" you.mean not smooth movement - that is because if the movement was only one pixel at a time, it would be too slow. Compromises had to be made to make it a reasonably enjoyable game to play.

Edited August 18 by Cheung

[globeron]

7 minutes ago, Cheung said:

Thanks for the comments.

 

I think that has something to do with JS99er, seems to save the scores with Classic99 for me.

 

If by "shocks" you.mean not smooth movement - that is because if the movement was only one pixel at a time, it would be too slow. Compromises had to be made to make it a reasonably enjoyable game to play.

Got it, it is very well done!  
 

I am going try to add it to the Retrobat system (based on MAME),
but normally these are .rpk / .bin format only and not depending on a .dsk file, but I like the High score saving part.

 

[Cheung]

10 minutes ago, globeron said:

23 minutes ago, Cheung said:

Thanks for the comments.

 

I think that has something to do with JS99er, seems to save the scores with Classic99 for me.

 

If by "shocks" you.mean not smooth movement - that is because if the movement was only one pixel at a time, it would be too slow. Compromises had to be made to make it a reasonably enjoyable game to play.

Expand  

Got it, it is very well done!  
 

I am going try to add it to the Retrobat system (based on MAME),

@mizapf had created an rpk file earlier in this thread. It doesn't have the latest Pacman++.bin file so it would probably need updating.

 

https://forums.atariage.com/topic/370835-pacman-is-now-available-finally/page/2/#comment-5515959

[Tursi]

7 hours ago, Cheung said:

This should be the last update for the files for this game unless we're able to get the data on the cartridge binary.

 

I found a bug where it looks like the extra life is occasionally not rewarded - hopefully this has fixed the problem.

PACMAN++.bin 32 kB · 7 downloads PMINSTALL.bin 64 kB · 5 downloads PMRES.dsk 180 kB · 6 downloads

The downside being that this undoes the last 12 hours of work on that front... the files are completely different. Would be okay if they were just slightly changed.

 

I'll see what I can do after I get the first pass working, but I will not be doing iterations

[Cheung]

2 hours ago, Tursi said:

The downside being that this undoes the last 12 hours of work on that front... the files are completely different. Would be okay if they were just slightly changed.

 

I'll see what I can do after I get the first pass working, but I will not be doing iterations

I think the only one that's changed is Pacman++.bin

[Tursi]

40 minutes ago, Cheung said:

I think the only one that's changed is Pacman++.bin

Yeah the diff just looked really weird. It was okay when I dug into it. Next post.

[Cheung]

1 minute ago, Tursi said:

Yeah the diff just looked really weird. It was okay when I dug into it. Next post.

I could get you the assembly file if that would have helped any

[Tursi]

Writing a DSRLNK replacement to read variable records from ROM was a little more intricate than I expected, but wasn't too bad. But linking it into the program was tricky.

 

I originally wrote it on the assumption I could find 450 bytes somewhere to stuff the code and data, but it just was not meant to be. Numerous attempts to reduce available string space so I could do that failed.

 

I ended up going back and rewriting the code so that all data could be stored in VDP instead. I used the memory above 37D8 because, now that it's not using disk, I knew that was safe to overwrite. 

 

There were a couple of gotchas. Since the high scores were in VRAM, accessing them as a file meant that all records would need to be copied from VRAM to VRAM. And since the rest of the files were in ROM and so was the code, it was necessary for READ to become a scratchpad function so that it could safely switch ROM banks.

 

Since I first wrote the code assuming all data was in RAM, I cheated in a couple of places - copying data into scratchpad RAM before processing it. I also backup and restore scratchpad RAM so as not to impact the original program. All this impacts speed a little, but watching the heatmap it's clear that much more time is spent by the compiled XB processing the records.

 

The High Score table was a bit of a thing, cause it's written to update it. I ended up special-casing it. It's stored in VRAM instead of ROM and written directly. I patched the display to "TODAYS HIGH SCORES" to reflect that it doesn't save anymore.

 

The two character filenames made life a lot easier, since I could use a single register to compare filenames.

 

I then needed to work out what would go where. I doubled the ROM size from 32k to 64k, giving plenty of space. I laid out the data files and moved my new code to the last added page, giving lots of space again.

 

The final trick was figuring out where to patch in. I patch my init code (which sets up VDP) at the first instruction that runs in low RAM (right after the program is copied), and after some poking around, I found a decent entrance to DSRLNK, which I now completely hijack.

 

All my previous hacks worked with program images only - which are a simple single call to DSRLNK and a single memory copy. But with those plus this one reading and writing records, it's not that far from a proper ROMFS. It's feasible to create a tool that can pack a disk into a ROMFS for programs to access... although except for converting from disk to cartridge I don't think there's much value over just directly accessing the data if you are already writing for cart.

 

Anyway, the update freaked me out a bit, cause a quick binary diff showed everything looked different. But fortunately after unpacking and testing, everything I was worried about was in the same place and I didn't have to change my build sequence.

 

So, here you go! Not as easy a task as I expected, but it was fun.  (Full source for the patch and very rambling notes included.)

 

 

 

pacman++_rom_version.zip

Edited August 18 by Tursi

[Cheung]

8 minutes ago, Tursi said:

So, here you go! Not as easy a task as I expected, but it was fun.  (Full source for the patch and very rambling notes included.)

 

Wow, sounds super complicated but I'm sure everybody will appreciate the single binary, especially the batocera and Mame folks. I'll let Vorticon know also so he can add your binary to TIGameshelf instead of the hodgepodge I sent him. Thanks again and well done.

Edited August 18 by Cheung

[Cheung]

5 hours ago, globeron said:

I am going try to add it to the Retrobat system (based on MAME),
but normally these are .rpk / .bin format only and not depending on a .dsk file, but I like the High score saving part.

Hey, don't know if you're following the thread but @Tursi was able to get all the data on the cartridge and have the game load it directly. You can download the zip file he provided or just grab the binary here:

 

https://forums.atariage.com/topic/204941-ti-gameshelf/page/7/#comment-5517827

 

[globeron]

Note: to use keys E,S,D,X  in the emulators the CAPS-LOCK need to DOWN (to use capital letters). 
         (in Retrobat with Pad2Key you can map the keys to use a Joystick mapped to E,S,D,X)

       
        Or when selecting the Joystick in Pacman++ game itself (option 4 configure)
        (then CAPS-LOCK need to be "up" position, otherwise you cannot move upwards)


1. Rom only version by Tursi works perfectly in Retrobat / based on RetroArch(LibretroMAME) or Mame64

pacmanplusnosave.rpk

  and the image and video files (to be used in Retrobat -> in the roms/ti99/images and /videos directory) 

pacmanplus.zip

 

 

2. and for the orginal version (which requires the disk to save the high scores) it also works in Retrobat by using a Batch file (and under the Windows roms)

    (used a separate directory C:\GAMES\ti99 and also assume that C:\GAMES\mame directory is here with the respective mame version)

 

     See the batch file in the .zip for details:ti99pacmanplus.zip