cyborgar / petaxian Goto Github PK

It hangs in the joystick pull_info() routine, because that contains a STP instruction for unclear reasons.

STP locks up the CPU :
"STP stops the clock input of the 65C02, effectively shutting down the 65C02 until a hardware reset occurs (i.e. the RES pin goes low). This puts the 65C02 into a low power state. This is useful for applications (circuits) that require low power consumption, but STP is rarely seen otherwise. "

As the game runs fine on the official emulator, I think the official emulator doesn't process the STP instruction accurately.

I suggest removing the STP instruction there, as I guess it was a mistake/typo to put it in there in the first place?

Hi!
Pretty impressed with how this is coming along!
I decided to scan through the code for a bit to see how it's built. There are a few things that I noticed that you can perhaps try to improve a bit more:

base_c64.p8:

@($d020) = $c
you can use c64.EXTCOL = $c

clear_screen()
you can probably use txt.clear_screen() or txt.fill_screen()

base_cx16.p8:
same about clear_screen()
if not, I think the y loop is off by 10 (30 should be 40?)

enemy.p8:
I think the move_xxx() assembly code can sometimes be optimized a bit more by using
inc a/ dec a instructions rather than adc 1 / sbc 1 .
These inc a/ dec a are new for the 65c02 cpu

petaxian.p8:
wait_dticks() can be replaced with sys.wait() i think.
line 102 and 208: "may need to find a better timer" maybe you can use sys.waitvsync() ?

Various files:

while (..) -> you can omit the parenthesis for the while condition

while 1 { } -> you can use repeat { }

txt.setcc() -> you use this a LOT, which is fine ofcourse
but it is a bit inefficient this way because on every call it's going to
calculate the memory addresses to change, which involves a multiplication by 40 on the C-64
(done via a lookup table so it's not that terrible).
However I THINK if you're looking for a big speedup, writing customized routines
that set the characters for the moving entities could potentially give a significant
performance boost if you do this in a way that doesn't require recalculating/repositioning
the memory location for every individual character.

There are several tiny subroutines that you may want to declare as inline.
Experiment with this as it doesn't always yield a performance increase and
often blows up the code size.

Joystick issue at start:
I noticed this too and for my work-in-progress game I have the loop at the start that checks
for fire button to start the game, as follows:

    sys.wait(30)
    repeat {
        ubyte joy = lsb(cx16.joystick_get2(0))
        if joy and (joy & %11110000 ^ %11110000)
            return
    }

it tests for the value to be non-zero as well. (this is not required afterwards anymore)
note: use cx16.joystick_get2() if you don't need that single status byte it drops, because it works around a kernal bug that has to be fixed still, where the joystick status can get corrupted when a system irq takes place during the call.

I've noticed you're using byte arrays for screen text output. If it's just text you're printing,
you can perhaps also just use str with screencode-encoding @"hello"

As an eye-catcher :)

Hi, the old Commander X16 forum has moved to https://cx16forum.com/forum/

the old download section is gone but there is a new one replacing it.
Since there have been extensive updates to the roms and the emulator since most of the uploads were done on the old forum, it was decided that the old uploads were moved into an "Archived" section because many were incompatible.

Authors should re upload a new version of their software in the appropriate topic if the software is tested to run fine on new ROMS+emulator.

Unfortunately, Petaxian is still among the archived games:
https://cx16forum.com/forum/viewtopic.php?p=25182&hilit=petaxian#p25182

Would you consider rebuilding a new version of it and re-uploading it on the games topic , so that Petaxian will be easily visible again?

this should read
uword @requirezp enemyRef

because the file contains some assembly code that uses zeropage indirect on the enemyRef pointer.

Hi, the next prog8 version will treat 3-letter symbols differently (it's going to prefix them to avoid name clashes with regular cpu instructions in the resulting assembly code).

This means hand written inlined assembly needs to take this prefixing into account.

In convert.p8 there's the tbl array that will now break because it is referenced as such in some assembly code. May I suggest simply renaming its occurences to table to make the code compile again without errors.

In c64/keyboard.p8 there is key which should be renamed to keypress or something as well.

Hi, the next prog8 release introduces a 'bool' datatype and several expressions will now yield a boolean result rather than a straight ubyte.
This allows prog8 to generate more optimal code for comparisons, logical operations etc.
However certain existing expressions are no longer allowed. Compiling petaxian with the upcoming compiler gives:

WARN file:///home/irmen/Projects/Petaxian/enemy.p8:539:5: name 'enemyRef' shadows occurrence at enemy.p8 line 147
WARN file:///home/irmen/Projects/Petaxian/cx16/keyboard.p8:23:5: return type of the subroutine should probably be bool instead of ubyte
ERROR file:///home/irmen/Projects/Petaxian/enemy.p8:430:11: can't use boolean operand with this operator *
ERROR file:///home/irmen/Projects/Petaxian/enemy.p8:431:11: can't use boolean operand with this operator *
ERROR file:///home/irmen/Projects/Petaxian/explosion.p8:75:17: can't use boolean operand with this operator *
ERROR file:///home/irmen/Projects/Petaxian/explosion.p8:76:17: can't use boolean operand with this operator *

The last four are caused by expressions like this: (not explosionRef[EX_SUBPOS] & main.TOPMOST) * 4
I think your intent is to write there: (not explosionRef[EX_SUBPOS] & main.TOPMOST) << 2

The error message is meant to catch silly mistakes of using booleans in arbitrary arithmetic calculations. Bit shifting is okay.

Do you agree with the error message or do you think it is too strong?

Offical r39 was recently released, this requires some fixes for the changed kernal routines.
Also requires Prog8 8.0 to compile. (not officially released yet)

I'm making the required changes in the newr39 branch.

Note that I accidentally committed a change in the main branch which has been reverted again, it was not my intention to directly commit in main. 😞

I've just added a psg library to the upcoming prog8 release. https://github.com/irmen/prog8/blob/master/compiler/res/prog8lib/cx16/psg.p8
Here are the changes I made to the Tehtriz example to use this library instead of poking the vera PSG itself: irmen/prog8@3ec0570
(recently I also added a max volume parameter to the envelope calls)

Maybe Petaxian can benefit from this as well?
The envelope handling is done in an irq so no need to track sound cutoff manually as well. Just set an appropriate attack/sustain/release and let it go.

Hi,

The newer prog8 compiler versions generate smaller and faster code than before (and I think the C64 version is no longer "a bit too slow"? as mentioned in the readme).

But there are a few easy optimizations that can be made in the code I think.

For starters I notice that you do your own number printing routine (binary to decimal conversions).
Prog8 provides some built in routines for this in the library (these are used by prog8 itself as well when using txt.print_uw() for instance).

See the conv module.
You can probably use conv.str_uw(number) and then conv.string_out variable to retreive the decimal string form.

Also repeatedly calling txt.setcc with a list of non-trivial arguments will result (for now) in slow parameter evaluations, so maybe there's a lot to gain there as well if we precalc the arguments? or write a custom routine that's smarter

• the wave counter is a bit weird? or i don't know what it's counting exactly?
• is it on purpose that your ship keeps moving left/right even when you released the key?
• when sitting against the left or right screen border, your ship can't be hit anymore by the aliens it seems

I'm busy updating the prog8 compiler to a new major version (9) and with that, there will be some breaking changes. A guide how to upgrade existing code is in the prog8 documentation. This version of the compiler hasn't been released yet but I thought I should give a heads up.

Also for Petaxian I went ahead and created the "prog8v9" branch that will include the necessary changes to make the game compile again with prog8 version 9. Note that this version can then no longer be compiled with an older version of the compiler.

I happened to see a couple of updates were made in Petaxian! Great!
Unfortunately it now seems something happened to the keyboard controls on the C64: I can hardy move my ship around anymore with the cursor keys.
Using the (emulated) joystick seems to work a lot better.

For 2 sounds in the cx16 sounds module it sets the PSG (max)volume to a value 127 which is out of range, the valid Vera PSG volume range is 0-63

maybe I should document this more clearly in prog8's psg module as well?

The upcoming prog8 compiler version will be more aggressive about removing unused variables (in prog8 code)

There are some variables in cx16/joystick.p8 that will have to be marked as @shared now to avoid assembler errors in the included assembly that refers to them. (prog8 code doesn't refer to them!)

it's the three joy_info variables at the top of cx16/joystick.p8.