First off I've got a version 2.0 coming sometime soon that addresses a lot of the problems. It has a new timer codebase, uses coded sprites, and has a lot of other enhancements -- NO promise on a release date for that though as I've got a few other things planned.
There is a bug in the timer code, where I was setting 0xFFFF with an even divisor instead of 0x0000 with using fractions. That's where that drift comes from -- BUT, beware that in emulators (and on real hardware) that some timer drift is pretty much a GIVEN as soon as you actually start using the PIT for timing control. It's why the system timer on real PC's would ALWAYS go off from the separate RTC if you ran pretty much any game that didn't use "flat out execution" as it's runtime model. It's also why a separate RTC on things like the AST Six Pack were desirable (on top of the convenience of not having to enter the date and time every time the system booted). A lot of people made BAT files back in the day wrapping certain programs just to resync the PIT to the RTC. Remember PIT time drifts -- when you say "DOS RTC" that's NOT a RTC... what the PIT does drifts. Wasn't even consistent between 5150's made on the same assembly line since it was fed off a CRTC crystal that wasn't exactly precise either.
NOT that I've ever heard of IBMulator, and am surprised to see PCem even mentioned in this day and age given that development on that stopped what, five years ago? I don't remember it being the most accurate or even useful of emulators... unless things have really changed on that front.
Either way I'm surprised you singled out Paku Paku for this, given how many other DOS games have the same affliction -- at least most of the GOOD arcade games do. Usually it's only the sloppily written ones like Round42 or PC-Man that don't create these problems. Any game or sound software that latches onto the PIC typically creates all kinds of crazy timer drift... See most Sierra games. (where if you left Thexder running for a day, the system time would lose almost two minutes when usually most systems ran three seconds fast a day!)
On the PCJr version 1.6 should run fine if you've got the extended memory and run it from that, and don't try to us the joystick. There is a version floating around with the stick fixed for the Junior, but it screws up joystick code on the 1000. (for all the similarities there are some big differences between Jr/1k as well... differences that explain why the T1K was WAY more successful)
Apart from the quirky joystick support and the bottom 128k of memory on the Junior being too slow to run much of anything from, there should be no other major Jr issues with 1.6. 2.0 will fix most of those, though currently it's still falling short on available processing time for the fastest of the levels it will be playable and faster than the 'middle' speed -- and there yes, the PIT will end up screwed up just because the Junior is too damned slow to even try and keep up with interrupts. (A LOT of that can actually be blamed on how pretty much everything like keyboard input is software handled through the blasted NMI)
The joystick code for the new version got a pretty hefty revamp. The old routine read each axis independently without disabling interrupts. Worked great on a 5150 and tandy 1000, but the Junior wastes so much time screwing with serving interrupts (since it has no DMA and no dedicated keyboard controller) and has such painfully slow lower memory (since it's sharing it with video) you're lucky if the analog stick reports a range of 0..15, with a jitter of 10. Disabling interrupts helps (though introduces even more PIT timer jitter the likes of which ppgrainbow was complaining of)
Reading each axis individually has it's own issues -- like the fact that the PC joystick interface is one of the most cheap-assed lazy designs ever. You discharge a bank of capacitors by writing to the port, then that cap is charged by voltage run across the variable resistor in the joystick until it hits 'charged' and trips. To read the stick position you loop until the bit on the port for the axis you want gets set. Laughably this means that left or top takes less time (less resistance == charges faster) to read than bottom or right. For real laughs, this means reading two axis independently can take anywere from two or three loops each, to several hundred loops each -- which on really slow systems can speed up or slow down the program --to the point of 30% frame rate drop on Junior running flat out JUST to read both axis when stick is bottom-right!
My new joystick code actually reads all four axis at once (masked for missing axis) by masking the port value for the axis that exist, shifting it right and then doing an ADC to a register, then looping until we've looped too many times or all the axis capacitors are charged (or the mask says it's charged).
[code]; procedure stickUpdate;
pProcNoArgs stickUpdate
mov dx, 0x201
mov cx, stickLimit
xor ax, ax
mov bx, ax
mov di, ax
mov si, ax
mov ah, [stickMask]
push bp
mov bp, bx
cli
.loop:
in al, dx
and al, ah
ror al, 1
adc bx, 0
ror al, 1
adc di, 0
ror al, 1
adc si, 0
ror al, 1
adc bp, 0
or al, al
loopnz .loop
sti
mov [stickData], bx
mov [stickData + 2], di
mov [stickData + 4], si
mov [stickData + 6], bp
pop bp
retf[/code]
This means that it only takes as long as the highest value of any one axis, to read all four -- this is twice as fast maximum for reading the two axis of one joystick, four times faster for two sticks / 4 axis.
Sadly it returns a range of 2..12 on a real unexpanded Junior, but since I'm just turning the analog stick input into digital inputs, that's more than sufficient particularly since the jitter on that routine is zero; though again PIT jitter ends up all over the damned place thanks to having to disable interrupts.
I'm probably axing the midi support for 2.0 -- it was cute to do, but the overhead is a bit much to have the difference between doing sound FX via midi and via native cards. (I also got really pissed at it when trying to implement IMF support, which is so poorly shittard documented I wanted to track down the people responsible for it at IBM and smack them across the face with a wet trout)
To mitigate the loss of MIDI I'm adding PS/1 Audio (which is just tandy/jr audio on a different port) with auto-detection, SSI-2001 Innovation sound (basically a C64's SID on a PC card), there have been MAJOR fixes to the CMS sound support that should work on ALL implementations of the Phillips SA 1099 chips on all manner of sound blasters, game blasters, even the ATI FX cards that supported it. The Junior/Tandy sound stack has had it's overhead greatly reduced, and PC Speaker sound now uses a two voice arpeggio which sounds way better than the priority based system I was using. Under the hood adding new sound cards
The program is also going to a monolithic executable, so no more massive directory filled with files -- there will be THREE files, the executable, the high scores table, and the readme -- the laugh being the final target executable should come in at around 48k with a memory footprint well under 80k -- meaning one can easily run it on a 128k DOS 2.0 machine. Version 1.6 was borderline on 128k systems and despite having less functionality was 37k of executable and 13k of .DAT files -- spitting distance in total file size... even more of a laugh though is thanks to cluster rounding, the single executable though larger, will consume less disk space and load faster.
A GREAT deal of the assembly language has been moved out of using the in-built assembler in turbo pascal to being built in NASM. I'm pretty much using TP as the glue and to keep things like game logic simple, but doing anything heavily time based in ASM; significantly more-so than I was in 1.6/earlier. Originally there's a 1.7 codebase that contained a lot of the fixes for things like the issues mentioned in this thread, but I kicked that to the curb and started over with a clean codebase as certain (what I now consider rookie) mistakes led me to think I'd be better off doing so. Version 1.0 was created in a week as a demo of showing that EGA and VGA could do a 100% compatible with CGA mapping 160x100 graphics mode; version 1.2 took two weeks to take that demo and make it far more playable without flickering by adding back-buffer -- all the versions after that were mostly patches and hacks to improve it without seriously going back to basics... Like a great many things you can only limp along using outdated testbase code for so long before it's time to start over from the ground up. Version 1.0 through 1.2 was basically my "ET" for the 2600. 1.6 is like the modern patches to try and make that dreadful game less dreadful. The new version, I'm taking my time and starting over doing things right so that it's a proper professional release, instead of a glorified tech demo. Funny since the "demoscene" and I usually get along like sodium and water... see why development of the C64 version is pretty much over.
A number of major improvements have been made in how the map is stored in memory and drawn to screen -- these improvements means the "level end flash" is fast enough that even on an unexpanded Junior the "top to bottom" redraw is barely noticable. The map also takes WAY less memory as I took a lesson from how UTF-8 encoding works, and applied to to an RLL encoding scheme customized for the visual appearance of the game map.
The menu marquee has also been greatly optimized, which combined with some sync routines greatly reduces CGA snow. There's just too much going on at non-refresh based intervals to eliminate the snow in its entirety, but it will be far less of an annoyance than it was in previous versions.
Game logic also got greatly tweaked and takes far less time to run - whilst also being less code. The difficulty has gone up a bit thanks to these changes which bring it more inline with how the real game worked -- though as always the 3/8ths reduction in pixel density makes things like ghosts and player actually moving at different speeds remain impractical to implement without it looking like sloppy jerky garbage.
So, there are changes coming. I was hoping to have all this done by the beginning of this past March, but from February to July I ended up spending a great deal of time under supervised medical care that pretty much ended up deep-sixing a lot of my little side projects like this one. Medication induced Parkinsonism, Seizure disorder, non-24 sleep-wake syndrome, type 1 diabetes despite my best efforts at avoiding it after nearly a decade as type 2, stroke... good times.
*** SIDE NOTE *** reminded of why I never joined here originally -- having to shove my own custom user.css at these forums to give me legible colour contrasts (seriously #333 on #99B? Have you even HEARD of WCAG?!?), the traditional uselessly undersized fixed metric (pixel measurement) fonts sending me diving to zoom in 50% to even approach usable... The developer ineptitude in terms of accessibility would make one almost think this was phpBB. (that after NeverNoSanity some decade ago I'm shocked anyone would ever trust again)... NO offense, just saying; it's a bit of a laugh when site owners seem determined to make sure users don't want to visit a site... Yeah, I'm one of those elitist web dev jackasses.
... and sorry if some folks think this post was long -- I don't get out of bed to type less than 10k, which is why IMHO the "TLDR" halfwits can go plow themselves.
The only thing from Adobe that can be considered professional grade tools are the people promoting the use of their software.
