Thanks for all the vids. I posted a few comments and replies on phreakindee's in regards to the upcoming 1.6 release and how it effects the AI. Compiling the changelog right now, here's a preview of what's different in the version I'm HOPING to go public with wednesday... Friday at the latest.

Added MT32/GM/Midi support
Requires the MIDI device to have a 24 step pitch bend range or allow setting via RPN -- Which "Microsoft GS Wavetable" does not... This is still in the early development stages and doesn't sound all that great yet -- but it shows promise. Will be better when/if I design custom program changes for the MT-32 instead of using the built-in sound banks.

Better EGA and VGA support
VGA now uses BIOS scanline set, works properly on pretty much everything!
EGA sets misc register properly, a few changes to the logic order of loading done as well.

"infinite fruit" bugfix
Added counter of how many have been shown

Fixed AI bugs
random for ghost turn was ignored
random for ignore chase was always taken
death during final 'chase' resumed as 'always scatter' instead of a 250 iteration scatter followed by resuming the chase. Fixing this bug revealed the Final Chase Update Bug.

*** NOTE *** AI bug fixes may have increased difficulty

Final Chase Update Bug
Fixed behavior update procedure being called every timer tick once the 'final chase' was reached. This got rid of late game 'slowdowns' on slower systems... (and sometimes it even hit faster ones!)

Improved sound on/off handling
Can now turn sound off mid-theme and during longer sfx

Better dividing of tasks between audio timer ticks
Should lower CPU speed requirements even further

Removed many FOR, WHILE and REPEAT for recursive object calls
Speedup, lower memory use and simpler logic flow

Rewrote many library functions in ASM
speedup, smaller exe size

Stopped passing sprite pointer on every call
now handled by global pointer "tileSource"
speedup, less stack use

New Joystick Handler
faster, reads both axis at same time

Replaced write/writeln with custom handler
reduced total code size 3%, who knew TP's WRITE was inefficient?

Smaller/simpler graphics 'outtext' routines
removed all the custom number outputs
allows wider use of background erase or transparent

Rewrote 'circling' pixels on menu page
Faster, lower memory use, prevents really slow 8088's from bogging down
(should help jr owners with their slow bottom memory)

Renamed many procedures and variables
Code cleanup, make it easier to find things

Renamed all data files to .DAT (no more .FNT or .TDT)
Actually allowed a bit of code reduction as now all .DAT are handled by one handler object (or inherit from it) -- and it's easier to keep track of when copying files to build the distro. (or making a minimalist floppy)

Moved music config info into external .DAT files
Lowers heap/stack/code size, makes customization easier

Patch files for MT32, General Midi or Custom (see custMidi.txt)

Instrument Data for Adlib

Distribution built with stack checking off
reduced exe size, faster execution. My stack is fine, don't need the compiler second guessing me.

Abandoned PC/JR and Tandy specific video code
Due to bugfixes and better understanding of the CGA implementation on both platforms, the code to try and use the 160x200 video mode is no longer required.

So... basically the past 9 months since the last release weren't completely wasted -- AND I've got two other games in the works, one nearing completion -- the other being... well... It's probably going to have an AT as the minimum spec despite using this same video mode. I don't know why, but I'm really digging how the 160x100 graphics look; It's probably the Atari 400/800/5200 fan in me on that, since PMODE4 was 128x96... and some of the best games for said platform were done using pmode 4 with palette tricks.

Developing this next version has been a bit of a trip -- when I started adding the MIDI code and cleaning up the AI code, the .EXE grew upwards quickly.. 72k...80k... 92k... until I realized it would no longer run on a 128k DOS 2.11 system -- unacceptable. After making all the code tweaks and converting large sections of the library units to assembler I've actually gotten the final .EXE for this version an entire K smaller than previous versions -- and it fits into the same size stack/heap allocation giving it a memory footprint of exactly 65k... so even a 128k DOS 3.2 system has a decent chance of being able to run this new version I'm polishing up for release.