Paku Paku -- 1.6 released 9 November 2011

[Trixter]

No need to patch it, just recompile since the source was included. I've done so and put the result here: ftp://ftp.oldskool.org/pub/misc/Softwar ... KU_16A.ZIP Wasn't sure what to call it, so I called it 1.6a. Amended source and .exe are in there. Tested on a real PCjr to be sure (although it was a 640K jr, so I haven't tested it on stock)

[Vorticon]

That's great! Thanks.
I have contacted the author, Jason Knight, and actually gave him your modifications, and he was going to incorporated them in an upcoming version 1.7 release he's currently working on. He sends you his thanks for the heads up

[deathshadow60]

Just a quick update for Jr users.

I've now got a real junior to play with and have abandoned the plans for version 1.7 in favor of an all new 2.0.

I felt the need to skip to a version 2 number as pretty much all the underlying code is being redone from scratch; coded sprites, RLL and unique key encoding of playfield bitmaps and lookups, and a host of other optimizations that should speed up the game a good deal -- I didn't realize it was so bad on a 128k Junior, and honestly even on one with >128k and the game running someplace other than shared memory you've not been getting the 'proper' experience.

My goal is to optimize it down so that it meets three goals:

1) memory footprint of less than 64k.

2) fast enough to run on a 128k junior

3) completely self contained in a single .exe (though I may make an exception for static texts like help and the exit page as well as the scores.dat and gm.dat files)

Since my C64 version has a 40k memory footprint, I don't consider this an unrealistic goal.

I've also got a more robust joystick routine I'll be using too:

Code: Select all

BITS 16
CPU 8086

%include "turbopas.mac"

%define stickLimit 0x8000

segment CODE

extern stick0x, stick0y, stick1x, stick1y, stickMask

; procedure stickUpdate;
pProcedure 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
   ; using SP for zero inside the loop increases speed ~20 clocks per loop
   mov  es, sp
   mov  sp, bx
   out  dx, al
.loop:
   in   al, dx
   and  al, ah
   ror  al, 1
   adc  bx, sp
   ror  al, 1
   adc  di, sp
   ror  al, 1
   adc  si, sp
   ror  al, 1
   adc  bp, sp
   or   al, al
   loopnz .loop
   mov  sp, es
   sti
   mov  [stick0x], bx
   mov  [stick0y], di
   mov  [stick1x], si
   mov  [stick1y], bp
   pop  bp
   retf
   
%macro asmButton 1
   mov  dx, 0x201
   in   al, dx
   and  al, %1
   xor  al, %1
   retf
%endmacro
   
; function button0a:boolean;
pProcedure button0a
asmButton 0x10

; function button0b:boolean;
pProcedure button0b
asmButton 0x20

; function button1a:boolean;
pProcedure button1a
asmButton 0x40

; function button1b:boolean;
pProcedure button1b
asmButton 0x80


... and yes, I'm using NASM now. I'm also using my own custom macro as their c16 one is kinda... meh.

If even with all these optimizations it's still not fast enough on a 128k Junior, I'll be making a Junior specific version using trixter's tweaked 160x100 mode, as the linear foreground buffer and possibility of page flipping may result in a far faster game. We'll see if I need to resort to that or not. I'm hoping for not as maintaining more than one version sucks.

[jmetal88]

I was about to say, "What do you mean? It runs great on my PCjr!" Then I remembered that, even when running with just the 128k, my PCjr is still overclocked.

[GHiero]

I have a bug to report, the current 1.6 will always choose Adlib sound over Tandy/PCjr. sound, even if the /tandySound switch is used. Not quite as relevant to the PCjr. (unless you have a GameMaster sidecar) as to the Tandy, but still.

[deathshadow60]

I have a bug to report, the current 1.6 will always choose Adlib sound over Tandy/PCjr. sound, even if the /tandySound switch is used. Not quite as relevant to the PCjr. (unless you have a GameMaster sidecar) as to the Tandy, but still.

The upcoming version 2.0 does not have said problem. Whole new audio "stack" written from scratch with a far better approach to handling autodetection, as well as the addition/removal of sound support.

Though it's starting to look like the Jr. will get it's own executable, at least for unexpanded 128k models. In testing I'm coming up 20% short and even going high hog removing the time-slicing from it and making the code harder to maintain by unrolling everything only nets me 5% more... so for the Junior I'm making a separate program that uses Trixters linear 160x100 tweak as that DOES make up the difference quite nicely.