deathshadow
Veteran Member
- Joined
- Jan 4, 2011
- Messages
- 1,378
Just thought I'd share a bit of a progress report.
As some of you may remember, I am still working intermittently on Paku Paku 2.0 -- which is using a whole new codebase to try and get it up to full speed on a unexpanded PCJr.
I was playing with FPC's new 16 bit DOS support, and while that's turned into a massive dead end from a lack of sensible documentation on their part, a ridiculous 16k base RTL, it being a technological dead end and the people on their forums wondering why I'm even asking the things I'm asking... It's the wrong tool for the job and it looks like unless I'm willing to pay someone, nobody is even willing to talk about handholding me through making sense of the train wreck that is their codebase. (most of that wreck being that it's mostly processor agnostic and implements a slew of things like unicode a 16 bit DOS programmer could give a flying *** about)
BUT it included a "TINY" model for building COM files and got me thinking along new lines. While I'm not going back to TP3 to do it, TINY would mean that everything is a NEAR call unless you say otherwise... HRM.... Near calls smaller... near calls faster...
UNITS CAN NEVER BE NEAR CALLS! AHA!!!
While some of my routines have to remain FAR -- since I call them as procedural variables -- the whole codebase can be switched from units to includes... but with all the linked .obj files from NASM, the assembly went tits-up face-down.
I took a guess and went "wait, are the EXTERNAL being loaded as NEAR?!?" -- Sure enough that's what's going on... and I just poured over EVERY joe-blasted book I can find on the subject including the Borland manuals, and NOWHERE is that mentioned. It's like they don't ever expect you to do an EXTERNAL in your actual main .PAS!!! EVERY book and tutorial on the subject ONLY says +6 and retf... when this is quite clearly now working with +4 and ret.
Easy enough to fix on the ones that HAVE to be far using {$F+} or the FAR keyword, but it means I can also speed up my ASM on stuff that doesn't have to be far... and that's pretty much the ENTIRE sprite, font, and back-buffering system.
2.0 is far from playable -- ghost collision works, but no player killswitch yet just eat... but this change has knocked a good 6k off the executable (units apparently have a pretty hefty overhead in addition to the far calls, you'd think each one got its own code segment), and even better -- a measurable 6.5% speed increase on an unexpanded PCJr.
I expected a speedup, but not that big a speedup. STILL not enough to perfectly run the fastest level speed flat out, but it's so close you wouldn't notice unless you had it side-by-side...
... and that's really the hurdle I was waiting for before pressing on to finishing the scoring and death logic.
ALSO a big surprise, is that my needed maximum stack is now under 1k... with units it was 2k or crash city (even with stack checking on)... So... having units present uses 1k of stack for... something?
Still gonna try and push it a bit further on shrinking it down and speeding it up, but this is the most progress I've made on this since I switched to using BCD for the scoring code. (which provided a big speed boost too).
Gone from a 48k executable down to a 42k one, and dropped the memory footprint from 61k to 57k in one afternoon. I might make it in under my 64k target after all.
My REAL target is 80k for the disk version, but I like to Mr. Scott my estimates... Ach laddy ya didnae tell 'im how long it would REALLY take?!? MAYBE if I can keep the executable down I could someday make a Jr. cart of this...
Still trying to decide if I'm going to axe MIDI support. It was cute to include for 1.6, but it's not exactly a 'must have' IMHO... Though I could just still be soured on the whole idea after my FB01 went POOF, finding out the M$ GS wavetable won't let you set the pitch-bender range, and the fiasco of trying to program for the IMF without an IMF in hand...
Buy hey, I've got Innova SSI 2001 and PS/1 support working. (ok, PS/1 is kind of a DUH, it's just Jr at a different port). Still trying to put together some information on the mockingboard PC, but those make the SSI 2001 look common.
Oh, and does anyone have a adlib flat square wave patch (or even a clean sine wave) that doesn't sound like the same tinny crap that ALL OPL FM patches sound like? Seriously, WTF? It's sucktastic when CMS, JR, Tandy, and PS/1 sound BETTER.
But then to my ears CMS/Game Blaster ALWAYS sounded better. Adlib music always made me want to punch someone in the face. (sorry Fat Man, but like everything else Yamaha FM, it was more like flat... man...) There's just this tinny... off sound to it. Like a flanger reverb set wrong or something... You know, like Phil Collins singing voice.
Still, not bad progress for one afternoon/evening with a 3 hour power outage figured into the mix... First time I've really touched the codebase since November.
As some of you may remember, I am still working intermittently on Paku Paku 2.0 -- which is using a whole new codebase to try and get it up to full speed on a unexpanded PCJr.
I was playing with FPC's new 16 bit DOS support, and while that's turned into a massive dead end from a lack of sensible documentation on their part, a ridiculous 16k base RTL, it being a technological dead end and the people on their forums wondering why I'm even asking the things I'm asking... It's the wrong tool for the job and it looks like unless I'm willing to pay someone, nobody is even willing to talk about handholding me through making sense of the train wreck that is their codebase. (most of that wreck being that it's mostly processor agnostic and implements a slew of things like unicode a 16 bit DOS programmer could give a flying *** about)
BUT it included a "TINY" model for building COM files and got me thinking along new lines. While I'm not going back to TP3 to do it, TINY would mean that everything is a NEAR call unless you say otherwise... HRM.... Near calls smaller... near calls faster...
UNITS CAN NEVER BE NEAR CALLS! AHA!!!
While some of my routines have to remain FAR -- since I call them as procedural variables -- the whole codebase can be switched from units to includes... but with all the linked .obj files from NASM, the assembly went tits-up face-down.
I took a guess and went "wait, are the EXTERNAL being loaded as NEAR?!?" -- Sure enough that's what's going on... and I just poured over EVERY joe-blasted book I can find on the subject including the Borland manuals, and NOWHERE is that mentioned. It's like they don't ever expect you to do an EXTERNAL in your actual main .PAS!!! EVERY book and tutorial on the subject ONLY says +6 and retf... when this is quite clearly now working with +4 and ret.
Easy enough to fix on the ones that HAVE to be far using {$F+} or the FAR keyword, but it means I can also speed up my ASM on stuff that doesn't have to be far... and that's pretty much the ENTIRE sprite, font, and back-buffering system.
2.0 is far from playable -- ghost collision works, but no player killswitch yet just eat... but this change has knocked a good 6k off the executable (units apparently have a pretty hefty overhead in addition to the far calls, you'd think each one got its own code segment), and even better -- a measurable 6.5% speed increase on an unexpanded PCJr.
I expected a speedup, but not that big a speedup. STILL not enough to perfectly run the fastest level speed flat out, but it's so close you wouldn't notice unless you had it side-by-side...
... and that's really the hurdle I was waiting for before pressing on to finishing the scoring and death logic.
ALSO a big surprise, is that my needed maximum stack is now under 1k... with units it was 2k or crash city (even with stack checking on)... So... having units present uses 1k of stack for... something?
Still gonna try and push it a bit further on shrinking it down and speeding it up, but this is the most progress I've made on this since I switched to using BCD for the scoring code. (which provided a big speed boost too).
Gone from a 48k executable down to a 42k one, and dropped the memory footprint from 61k to 57k in one afternoon. I might make it in under my 64k target after all.
My REAL target is 80k for the disk version, but I like to Mr. Scott my estimates... Ach laddy ya didnae tell 'im how long it would REALLY take?!? MAYBE if I can keep the executable down I could someday make a Jr. cart of this...
Still trying to decide if I'm going to axe MIDI support. It was cute to include for 1.6, but it's not exactly a 'must have' IMHO... Though I could just still be soured on the whole idea after my FB01 went POOF, finding out the M$ GS wavetable won't let you set the pitch-bender range, and the fiasco of trying to program for the IMF without an IMF in hand...
Buy hey, I've got Innova SSI 2001 and PS/1 support working. (ok, PS/1 is kind of a DUH, it's just Jr at a different port). Still trying to put together some information on the mockingboard PC, but those make the SSI 2001 look common.
Oh, and does anyone have a adlib flat square wave patch (or even a clean sine wave) that doesn't sound like the same tinny crap that ALL OPL FM patches sound like? Seriously, WTF? It's sucktastic when CMS, JR, Tandy, and PS/1 sound BETTER.
But then to my ears CMS/Game Blaster ALWAYS sounded better. Adlib music always made me want to punch someone in the face. (sorry Fat Man, but like everything else Yamaha FM, it was more like flat... man...) There's just this tinny... off sound to it. Like a flanger reverb set wrong or something... You know, like Phil Collins singing voice.
Still, not bad progress for one afternoon/evening with a 3 hour power outage figured into the mix... First time I've really touched the codebase since November.
Last edited:
