Pacman++ is now available (finally)

[Cheung]

Hey all,

   Just wanted to let everyone know that I've finished coding for Pacman++ and it can be downloaded right here. Some things worth mentioning are that while the game itself is in cartridge format, it also requires the use of a disk drive (I know, boo!). The supplied DSK file (below) needs to be put in one of the computer's drives (I think it checks drives 1-8 for the disk and craps out if it isn't found).

 

The game uses only the keyboard, so no joystick. also, it's only one player. I had to make the not so hard decision to either have sound and intermission scenes or joysticks/2player since I only have about 250 bytes free for the XB program as it currently sits.

 

Anyhow, it's only been tested on  Classic99 so don't be too surprised if load times are a bit slow on real hardware. I tried to minimize this as best I could by loading new levels during dead spots when the maze is competed and the intermission. So somebody let me know how bad the loading is on real metal.

 

Another strange anomaly (at least for Classic99) is that for unknow reasons, the game gets a very noticeable performance boost starting on level 9. I don't know why, I didn't program it to do that and there isn't anything in the program itself that should effect performance starting at level 9. Would be nice if it started on level 4 or so but, beggars can't be choosers. Oddly, this performance boost continues even if you start a new game (so all previous levels will now be faster too).

 

Here's the new video showing the boost in performance:

 

 

PACMAN++.bin PMRES.dsk

Edited August 12 by Cheung

[Cheung]

14 minutes ago, Cheung said:

while the game itself is in cartridge format, it also requires the use of a disk drive (I know, boo!). The supplied DSK file (below) needs to be put in one of the computer's drives

You guys are going to feel silly for not following instructions.

[+mizapf]

This is a suitable MAME RPK. However, I noticed that it only loads for the HFDC. The TI Disk Controller as well as the CorComp, the BwG, and the DDCC-1 make it exit to the Master Title Screen. You hear the floppy motor starting, but no head activity. It is readable by a catalog program, though.

 

Do you access the files other than via the standard DSRs?

 

pacman++.rpk

[Cheung]

The resource file is read using the standard Basic/XB commands that were then compiled to ML.

 

I can provide the cartridge binary for the resource generating files. I was unable to include them on the game cartridge because the program I used can only have up to 4 memory banks on the cartridge and he game uses all of them.

Edited August 12 by Cheung

[Cheung]

The DSK file was generated using TiDir, using the default 2nd option which I think was DSSD (double sided single density?)

 

 

[+mizapf]

That's OK. The files are readable (with e.g. DM2K) on the mentioned disk controllers, but the module startup ends in a reset unless I use the HFDC.

 

It won't be easy to debug compiled code, though. Maybe you can send me the source BASIC program.

[Cheung]

13 minutes ago, mizapf said:

That's OK. The files are readable (with e.g. DM2K) on the mentioned disk controllers, but the module startup ends in a reset unless I use the HFDC.

 

It won't be easy to debug compiled code, though. Maybe you can send me the source BASIC program.

This is what the disk initialization looks like, which is where I assume it's failing.

 

680 I=0

690 ON ERROR 690 :: I=I+1 :: A$="DSK"&STR$(I) :: IF I>8 THEN END
700 OPEN #1:A$&".PD",INPUT :: OPEN #2:A$&".PS",INPUT :: OPEN #3:A$&".PG",INPUT :: OPEN #4:A$&".LV",INPUT
710 OPEN #5:A$&".TX" :: RETURN

 

an input will look something like this:

 

2570 INPUT #1:DC :: INPUT #1:M :: INPUT #1:DT :: RETURN

 

 

Edited August 12 by Cheung

[Cheung]

Here's the cartridge binary that installs the resource files to disk. You'll want to run Part 1 first and then Part 2.

PMINSTALL.bin

[+mizapf]

One difference between the controllers is that the HFDC is the only one to support DSK5 ... DSK8. However, I assume that it should not get this far when it finds the files on DSK1.

[Cheung]

3 minutes ago, mizapf said:

One difference between the controllers is that the HFDC is the only one to support DSK5 ... DSK8. However, I assume that it should not get this far when it finds the files on DSK1.

It would stop looking once they are found. It might have something to do with the building the file name: A$="DSK"&STR$(I) ... OPEN #1:A$&".PD",INPUT

This would always crap out if I ran it as XB for some reason andI would have to hardcode the values in. It worked fine for Classic99 once compiled.

Edited August 12 by Cheung

[+mizapf]

You are opening five files in parallel. Isn't that limited to 3 by default (check CALL FILES)?

[Cheung]

11 minutes ago, mizapf said:

You are opening five files in parallel. Isn't that limited to 3 by default (check CALL FILES)?

I thought that the documentation stated many more could be opened.

Edited August 12 by Cheung

[+mizapf]

Which documentation?

[Cheung]

The XB Call Open documentation.

[Cheung]

58 minutes ago, mizapf said:

You are opening five files in parallel. Isn't that limited to 3 by default (check CALL FILES)?

What's CALL FILES? it's not  a valid XB command.

[+mizapf]

The Extended Basic manual tells you to pick a number up to 255 for the OPEN statement, but it does not say whether there is a limitation of the number of concurrently open files. This is a limitation of the disk controller system. See e.g. https://ftp.whtech.com/datasheets and manuals/Hardware/Texas Instruments/PHP1240 Disk Controller Card/ti floppy controller card manual.pdf, page 36 (lower half).

 

The CALL FILES subprogram is not part of Extended Basic or console TI BASIC but is added to the system by the disk controller ROM. The HFDC allows to open more files, so this may be the reason why they behave differently.

 

Note that Classic 99 may not have these limitations, if I remember correctly.

[Cheung]

it says the number is limited to 3 for TI Basic and that CALL FILES can only be used in TI Basic and must be followed by NEW. So not sure if it applies to a compiled program.

[+mizapf]

It is not a limitation of Basic, but a matter of reserved space in video RAM. For three files, the usable video RAM end is >37D7. A compiled program will very likely get into the same trouble, unless the compiler reserves more video RAM space automatically. I'm not familiar with compiling BASIC (never done that, in fact), but I guess not.

 

Machine language programs have the same limitation. For that reason, a subprogram in the controller (similar to the CALL FILES) is offered that must be called in the machine language program. The NEW operation in BASIC is necessary to update the BASIC pointers; it is of course not required in machine language.

 

I could be wrong, but I would expect you won't be able to write your program in the way you did, opening 5 files in parallel.  This may probably only run on for the HFDC controller on the real iron, and on Classic 99 (and js99? Don't know).

 

This is what happens in Extended Basic, actually:

[Cheung]

30 minutes ago, mizapf said:

The Extended Basic manual tells you to pick a number up to 255 for the OPEN statement, but it does not say whether there is a limitation of the number of concurrently open files. This is a limitation of the disk controller system. See e.g. https://ftp.whtech.com/datasheets and manuals/Hardware/Texas Instruments/PHP1240 Disk Controller Card/ti floppy controller card manual.pdf, page 36 (lower half).

 

The CALL FILES subprogram is not part of Extended Basic or console TI BASIC but is added to the system by the disk controller ROM. The HFDC allows to open more files, so this may be the reason why they behave differently.

 

Note that Classic 99 may not have these limitations, if I remember correctly.

Seems to run on JS99er with no issues.

[Cheung]

4 minutes ago, mizapf said:

Machine language programs have the same limitation. For that reason, a subprogram in the controller (similar to the CALL FILES) is offered that must be called in the machine language program. The NEW operation in BASIC is necessary to update the BASIC pointers; it is of course not required in machine language.

Do you know what that program is and how is it called? is there a memory location I can write to?

[Tursi]

Do you need 5 open files at a time? That's a pretty large count. Mizapf is right - it won't "just work". CALL FILES is actually a part of the disk controller, not part of any particular BASIC (so BASIC and XB can both use it the same way). it reduces the amount of VDP RAM available to make room for the extra file buffers.

I don't think I ever considered limiting the number of open files in the Classic99 DSR, since I don't use the buffers. You might be the first one to try this. But I /always/ recommend enabling the TI disk controller emulation and testing before shipping a disk product. Sorry for the confusion there. I confirm that Classic99 also resets using the TI Disk Controller. Debug log shows it opens DSK1.PD, then DSK1.PS, then DSK1.PG, then fails to open DSK1.LV (because of the 3 file limit). The ON ERROR makes it loop around and start trying again - but all attempts fail because the first three files are still open. After DSK8.PD fails, it exits back to the master title page (due to IF I>8 THEN END).

You can't trivially call CALL FILES from a running program, since it changes the VDP memory layout. That's why the instructions you read said you had to enter NEW after using it. Assembly programs have full control of the machine so can do it with some careful work, but a compiled program is sort of between worlds - Senior Falcon would need to add it to work for you.

 

I'd propose two alternative plans... one is to simply read one file at a time. It won't be any slower and depending on your read loop might be faster. If the first file opens successfully you can be sure you found the right disk and any further error is a real error, and not the file being on another drive.

The other would be to pack the five parts of data into a single file, so that again you only need to open one.

 

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

 

The default keys are interesting - you selected right beside the TI arrow keys (ESDX, you picked WASZ). If you move over to ESDX it will be more intuitive for TI users. Also worth noting a real TI doesn't have a TAB key, that maps to FCTN-7 which I selected for its use in Editor/Assembler as a sort of tab. Oddly that's "AID" on the default keyboard strip. Space to select might be more common, not sure... 

 

As for the speedup at level 9... that is a bit weird. I can't see anything in a cursory examination of the program, but just from listening to it, it sort of sounds the same speed as after you get a power pill? (Am I imagining that? Or maybe there's a bug in that check?)

 

[Cheung]

24 minutes ago, Tursi said:

Do you need 5 open files at a time? That's a pretty large count.

No, I'm just being lazy. I can limit it to three by juggling the Scores file.

 

As far as the speedup goes, it's definitely way faster, like more than 30% if I had to guess. You definitely notice it when you're playing. Not sure what could cause it.

[+OLD CS1]

An option for seeking the files is to search for a specific disk name, and let the disk controller(s)'s DSR(s) do the heavy lifting.  If you name the disk "PACMAN++", then you would be able to look for the disk by opening "DSK.PACMAN++.filename".  If that open fails, then the disk is not inserted in any drive supported by the system.

 

EDIT: Assuming "+" is a valid volume name character.  YMMV.

[SteveB]

On 8/12/2024 at 10:50 PM, Cheung said:

I thought that the documentation stated many more could be opened.

Not when compiling. From the Compiler docs:

 

 

[Cheung]

19 minutes ago, SteveB said:

Not when compiling. From the Compiler docs:

 

 

Seems to work when compiled using other numbers - #4,#5,#6