• Please review our updated Terms and Rules here

It's DONE!!! Paku Paku -- new DOS game!

This game isn't CPU tied (other than the joystick) right? I should be able to run this on my 486 boxen just fine, I'd imagine..
 
Raven said:
This game isn't CPU tied (other than the joystick) right? I should be able to run this on my 486 boxen just fine, I'd imagine..
Click to expand...

I reprogram the PIT to increment a user counter that I check against (using a divider to 120 times a second), as such the game should be properly throttled on pretty much anything... take a gander into TIMER.PAS... I like constants with meaningful names on them.

The game logic updates every six user timer ticks on level one, every five timer ticks on level 2+, and when it goes really fast late game it's every four ticks. I use those ticks to implement time-slicing of the game logic to spread out the longer routines around the things that have to update every tick (sound and keyboard)... Tick 0 draws the sprites, tick 1 reads joystick, tick 3 handles game logic for the next sprite update. Ticks 4+ are left empty and thanks to the overflow method I use for the timer can pick up the slack should the first three run over their alloted time, causing only a minor disruption in the audio (barely noticable)

Originally I was running the external timer update at 4khz as I was thinking on doing a Covox-type soft-synth, but ditched that as there's no way a 4.77mhz machine can keep up with that and gameplay.

But bottom line, it's properly speed throttled on everything faster than 4.77mhz.

I always found it strange the lack of this on many PC games -- back when all there was is the original 4.77mhz PC I can see programmers not thinking "what if there are faster machines" -- but that we still had new games coming out with broken/incomplete speed throttling as late as the 386 being commonplace just blows my mind.

The PIT isn't THAT complicated! It's funny because you still hear people saying things like "The early PC's lacked accurate timers" -- BULLCOOKIES!
 
Right, its not running right on my 5160. The graphics comes up garbled as if it is trying to run at a resolution my monitor won't handle.

What resolution does the game try to run in when it detects EGA? I have a 256k EGA Card and an NEC V20 CPU.

It does run if I use the /SAFE switch.

also VidTest.exe returns 0x00 No Display, but the game exe says that it detects EGA.
 
Try running "paku /debug"? That'll pause the initialization screen so you can see what video card you've got installed.
 
EGA's are a odd mix -- I've tested five different cards and had three testers -- and of a total of nine machines 6 worked proper, and 3 others just flaked out -- whcih is why I put the "safe" switch on it in the first place.

I'm not sure why some EGA's reject it -- though two of the three cards that didn't like it so far were ATI. I have a small program that dumps the appropriate CRTC data for 'real' mode 2. Lemme see if I can find that again and we can see if your card outputs anything. The Offending cards all reterned a empty BIOS data area for "real" mode 3, meaning that the card itself probably woudln't work with a CGA monitor either. (no 640x200 mode 2, no 80x25 with a CGA plugged in)... either that or they disable that support when a EGA monitor is plugged in, something a real IBM EGA doesn't do.

The "resolution" it tries to set is "real" mode 2 80x25 text mode, which is 640x200 (as opposed to the mode 2+ 640x350 default) -- the mode the EGA uses when connected to a CGA display. This mode SHOULD function properly on a EGA display since the 640x200 16 color mode works just fine so we know the monitor can handle the timings.

Oh, and vidtest would return 0x00 on a 5160 as that uses the PS/2 / VGA only BIOS detection routine. Since that's pre PS/2 and pre-VGA, that BIOS call doesn't exist... I created that specifically to test telling the difference between a VGA and MCGA.

Apart from being squished vertically with the black stripe across the bottom, everything else checks out ok in /safe, right?
 
Last edited:
deathshadow said:
Apart from being squished vertically with the black stripe across the bottom, everything else checks out ok in /safe, right?
Click to expand...

I would have not noticed the squishing or the black line if you had not pointed it out. So it yes, it runs fine with the /SAFE option.
 
deathshadow wrote:

System Requirements
4.77mhz or faster 8088
128k of RAM (67,584 bytes free in DOS)
CGA,Tandy/PcJr, EGA or VGA video

With specs like those I would have been able to run that on my dream CPC machine, sadly the powers that be which only criticise the 8088 processor are missing out!

I had thought I had the slowdowns with joystick enabled dealt with on 4.77mhz machines, but there can still be occasional lag at certain points in the game. It's not a gameplay breaker, but it's not as smooth as a 7.15mhz or faster machine will deliver. Leaving joystick disabled it runs just fine on the slower clock speed.

Nothing to do with the way the Input Routine has to receive the return codes from the Joystick. If it's working fine from the cursor key from the keyboard, then it won't be that.
 
CP/M User said:
Nothing to do with the way the Input Routine has to receive the return codes from the Joystick. If it's working fine from the cursor key from the keyboard, then it won't be that.
Click to expand...
Actually it has EVERYTHING to do with how the PC joystick interface works.

The problem stems from IBM cheaping out on the original game card and not putting a real analog to digital converter in there. Instead all there is for parts is a capacitor and a comparator. To read the position of the analog joystick you output $FF to the joystick port, which discharges the capacitor. The Joystick's pot is wired between the capacitor and power changing how fast the capacitor charges back up -- the comparator fires changing the value at the joystick port when the capacitor is fully charged.

So to read the joystick you send $FF to discharge, and then run a tight loop with interrupts disabled waiting to see how many times your code loops until the capacitor is charged. The number of times you loop is the joystick position... as such, it takes longer to read 'right' or 'bottom' than it does to read 'left' or 'top'...

Basically to read the joystick the code is this:
Code: 
positionX:=0;
port[$201]:=$FF;
repeat inc(positionX) until (port[$201] and $01);

positionY:=0;
port[$201]:=$FF;
repeat inc(positionY) until (port[$201] and $02);

So when X is zero, the X loop takes less time to run, when Y is zero, the Y loop takes less time to run.

My joystick position code uses ASM and decrements CX -- that way I can leverage "loop" so that if no stick is plugged in the system doesn't go off to never never land.

Code: 
function joystickPosition(stick:byte):word; assembler;
asm
  mov  ah,1
  mov  cl,stick
  and  cl,$03
  shl  ah,cl
  mov  cx,$3FFF
  mov  dx,stickPort
  mov  al,$FF
  cli
  out  dx,al
@testLoop:
	in   al,dx
	test al,ah
	jz   @done
	loop @testLoop
@done:
	sti
	or   cx,$C000
	not  cx
	mov  ax,cx
end;

Killing the interrupts makes the result have less "jitter".

It's 'cute' because while it makes the analog joystick interface really cheap to make, it is also inaccurate, inconsistent across systems, the values returned change based just on the speed of the machine you're running it on, can change just because the capacitor warms up during gameplay, etc, etc... There's a reason as soon as USB came along the PC joystick interface went the way of the Dodo.

The TRS-80 color computer was similarly afflicted, though nowhere near as badly as the PC. On their version of the interface they use the 6 bit DAC to output a reference voltage, which the comparator then returns if that reference voltage is higher or lower than the voltage returned by the stick... so to read the position you have to compare against every voltage the DAC can output. (best done with divide and conquer though many people just looped like on the PC)

Honestly, the PC version is such a flaky piece of trash, it's a miracle anyone was able to write games that worked with it in the first place.

CP/M User said:
With specs like those I would have been able to run that on my dream CPC machine, sadly the powers that be which only criticise the 8088 processor are missing out!
Click to expand...
Yeah, even if you could port it those 8 bit registers just wouldn't be fast enough to keep up with the code... I was playing with the 160x200 PCJr/Tandy modes which are similar to the 160x200 of the amstrad -- and that drags the game performance down even further.

One cute thing about my using such a "low resolution" is it ends up less pixels to shove around per sprite... which is how I was able to get such smooth gameplay on a 8088 in the first place compared to 320x200 4 color games. A 5x5 sprite ends up (with 4 bits 'overscan') 30 bytes to write to memory where the scanlines are at least planar in a 16 color mode. Writing the same code to the CGA ends up needing more logic to handle the 'every other scanline' memory interlace, which ends up taking longer on top of having four times as many pixels to fill AND having to handle shifts across a 32 pixel area width... That's 80 bytes per sprite to send to memory and 640 bytes of RAM per sprite if you pre-store your shifted copies. The other alternative being weighing yourself down with RCR hi16; ROR lo16; LAHF; XOR AL,AL; AND AL,CFMask; SHL AL,CFShift, AND lo16,AX -- for every scanline (ouch).
 
Last edited:
It doesn't seem to like my Zenith SupersPORT very much. I have an external CGA monitor attached. I seem to be getting about the top third of the screen. Everything looks very stretched. It cuts off about halfway through "ESC TO EXIT". I tried /debug and it reports a CGA video card. Suggestions?
 
tomasont said:
It doesn't seem to like my Zenith SupersPORT very much. I have an external CGA monitor attached. I seem to be getting about the top third of the screen. Everything looks very stretched. It cuts off about halfway through "ESC TO EXIT". I tried /debug and it reports a CGA video card. Suggestions?
Click to expand...

I just grabbed my Sharp PC-7000 out of it's box in the garage, which 'under the hood' is basically the same hardware -- and sure enough I not only get everything stretched, but on the LCD blink is still enabled (shades of the PCJr).

Digging deeper the Sharp uses the Chips and Tech 82c425 which is not a true CGA -- It appears thanks to the LCD support they ditched the ability to reprogram the character scanline height to anything less than 8. There is no fix for that, so people with CGA equipped LCD laptops are likely never going to have support for my games.

Though I'm going to play with the extended CT82c425 and CT82c426 registers to see if maybe one of those will straighten things out. I see a second value declaring vertical sync width and scanline totals in the spec... and there's a bit that enables/disables read/writes to the rest of the timing registers -- $3D4 index $DF -- this lockout is probably done so that you don't send values that could fry the LCD since reprogramming the CRTC to non-BIOS values can be risky.
 
Ok, this is a new pair of .exe files (you need the 1_3 master files to run them)

http://www.cutcodedown.com/retroGames/alphaEXE/PAKU1_32.RAR

The first writes the CGA ports one byte at a time in the hope the slower write is what's messing up that zenith -- I make no promises on that as my Sharp is still choking on it, don't expect it to be much different. It appears the scanline reprogram is being ignored on those devices, I have no idea why.

The second .exe was written for PCJr users, though it will also run on Tandy's. It uses the 160x200 16 color graphics mode from those machines instead of the glorified text mode. With scanline doubling it's a hair slower than the textmode version, so I make no guarantees if it will be fast enough on 4.77mhz systems. (my 1000 in "slow" doesn't like it, it's fine in "fast" @7.15mhz). I used scanline doubling instead of making new higher res sprites because that would double the size of the backbuffers and end up being so many memory moves the minimum spec would be an AT class machine -- and what's the point of bothering with Tandy/Jr graphics that needs a 286?

In a way, that is kinda like how the Atari 2600 could theoretically do 320x200+, but all the sprites were generally done at half that... RAM size limits plus bus bandwidth combined to make actually movnig anything oncreen at the max resolution impractical at best.

Looking at the tech manual for that zenith it appears that V6355 has the ability to do the same 160x200 16 color mode as the JR. and Tandy -- though it lacks the BIOS routine to initialize it. (and I'm not sure there's enough RAM present either). Would be cute if I could find a way to make the tandy graphics mode run on that card by reprogramming it directly. I'm downloading the full version of that manual to see what I can see. I'm also going to pop open the Sharp -- I thought it had a Chips & tech since that was the only LCD CGA chip I was aware of, if it's also a V, I'll have a test platform.

Heck, if they included enough RAM it might even be possible to do the 320x200 mode, be interesting if one could make a TSR that latches onto INT $10 to set tandy modes 8 and 9 so these oddball CGA's can run tandy/Jr graphics... though 320x200 needs 32k of RAM so it's unlikely to get that one working.
 
Paku Paku is AWESOME!!!

Paku Paku is AWESOME!!!

@Deathshadow

First of all, fantastic work on this! In particular I especially like the fact that you made use of the heavily under-used (my opinion) 160x100 pseudo-graphic colour mode..

Second, it plays surprisingly well and is quite responsive even on my own Tiny XT homebrew computer. Tandy sound appears to work well using the /tandysound command switch.

Gotta get some pics/video of this game in action and post those here (seriously need to catch up on some sleep first though..).

Once again, AWESOME work man! :thumbsup:


Cheers,
Valentin Angelovski
 
I tried the new version on the Zenith. No change. I also found the amount of video memory in the documentation. It's only got 16K, so the 320x200 graphics mode won't work either.
 
New version release, 1.4 should eliminate the remaining joystick issues on really slow systems like the Jr.
http://www.cutcodedown.com/retroGames/paku_1_4.rar

For people using dosbox or 8mhz/faster machines you probably won't notice a real difference, but if you're on a tandy 1k, jr or original 4.77mhz 8088 machine, it's way better.

Still unable to figure out why the LCD capable CGA cards don't like it though.

Unless something major comes along as a problem, and unless I figure out why some CGA's meant to drive a LCD don't work with it, this is probably the final release of this game.

In other news, I've started preliminary game logic code for my next release which has the working title "Offense Command" which is going to be a bit more robust a redo/mashup of Moonbugs and the old TRS-80 Model 1 "defense command".

I've also been working on some sprites and animations for it:
defense.png


Anyone who's played TRS-80 games should find some of those familiar.
 
Last edited:
Version 1.5 is up in the normal place:
http://www.cutcodedown.com/retroGames/paku_1_5.rar

I've put the readme.htm that's included in the archive up in that directory:
http://www.cutcodedown.com/retroGames/README.HTM

Mostly this is speedups for real 8088's, redo of the code as 1.4 proved that I have NO business trying to use "tools" like CVS, (Another programmer's crutch -- I can't use crutches either) to fix all the things that 1.4 outright broke due to MASSIVE code regressions (some were all the way back to 0.89) on the final build (which bore ZERO resemblance to the private Beta build before it?!?). "Tools" -- only thing about most such software that can be considered professional grade tools are the people promoting their use.

@moderators, could I get the original post edited to reflect the new version? (since it's past the edit limit for my level of access)
 
kiyotewolf said:
I made you a joystick test program.
Click to expand...
Seems a wee bit large for just a joystick test program. What did you build it in? It's almost as large as the executable for Paku Paku!

I usually use an old program called jtuner.exe -- I think it came with LHX; I've been playing with building my own tuner though -- something small and lean to go in my distro's or in the startup for the game itself.

kiyotewolf said:
I must admit I love your concept, "Cardware."
Click to expand...
Old concept actually from the 80's and early 90's. Many old programs from pkzip to Linux were released as cardware.
http://en.wikipedia.org/wiki/Postcardware

I disagree with the claim Aaron Giles came up with it -- jpegView wasn't released until 1991, and I KNOW there was cardware released long before that; I had a crappy game I wrote in TP3 called "defendor" in '86 that was cardware. If you read his page he says he released in it, NOT that he came up with the idea -- I should submit an edit to WK regarding that once I source a few... sources.
 
"Seems a wee bit large for just a joystick test program. What did you build it in?"
QuickBasic v4.5 compiler.
I'm a TP programmer too, but I stopped concentrating on it, and lost my way.

http://www.classicdosgames.com/online/paku_1_5.html
/
Did these get your permission to host your game in-browser with jDosBox?

I didn't know about jDosBox until I scoured the code, trying to find out how they put your game in a browser window.



~Kiyote!

I need to ask you a few questions about how you re-wrote the support libraries to get around the ERROR 200 the speed error, problem.
I know you referenced it vaguely, and I skimmed it, but I had particular questions, but that's later.

Sorry about the later reply, for some reason I don't get notified of forum posts from here.
 
You must log in or register to reply here.
Back
Top