Commander X16

I'm working on converting a demo to the CX16. The CX16 is the first 8-bit computer I've seen capable of handling the requirements: fast enough at 8 MHz, and has screen swapping, extended memory, and a multiplier. So far I've just been developing on the emulator #R48, I was wondering if anyone with access to real hardware can try running it?

It consists of EXPLORE.PRG and EXPLORE.DAT files available on Google Drive https://drive.google.com/drive/folders/ ... sp=sharing. If you're leery of downloading from online, and you want to build it yourself, the GitHub repo is here https://github.com/Russell-S-Harper/EXPLORE. A sample video is here https://youtube.com/watch?v=nCTF3v2hGFo, although the playback seems slower than what I get running it on the emulator.

The demo uses these keyboard and joystick controls:

- escape: pause, press again to resume
- cursor up or joystick back: climb
- cursor down or joystick forward: dive
- cursor right or joystick right: turn right
- cursor left or joystick left: turn left
- space or joystick button: fire missile
- 1: cycle player/NPC, the one that appears stationary is the "focus"
- Q: quit

NPCs, missiles, and geometric shapes (a.k.a. walls) that are orange are below the "focus", and those that are blue are above.

Besides video, sound, and frame rate, I'm interested in confirming if the demo is playable using just the joystick, or if turning and/or changing altitude are too slow (or if I have the forward/back directions reversed!). The joystick has one advantage over the keyboard in that you can specify fire, turn, and change altitude simultaneously, while the keyboard lets you do only action at a time.

If the demo works okay, next step is adding "AI" to the NPCs, although even with just dummy routines, I tend to get clobbered. The dummy routine is to try to match you in altitude, go in a clockwise circle, and fire all the time.

Thank you,

Russell

i am testing now

sound ok

keyboard ok

joystick doesn't work on port 1 or 2

wierd graphic bug, the drawing is not good,i don't have a way to capture i will try to take a picture but it's completely unconsistant

i have send to you a picture

"the_seb" confirmed his hardware is up-to-date w.r.t. versions, so it's likely a difference between the emulator and hardware. I will try to create some minimal code samples to demonstrate the problem. /Russell

Based on the screen shot "the_seb" sent to me, I have a suspicion that differences in the VERA multiplier might be the cause of the messed up rendering.

I've attached a version EXPLORE2.PRG which uses straight C multiplication. The EXPLORE.DAT file is the same. It can't be attached, but it is accessible via Google Drive https://drive.google.com/drive/folders/ ... sp=sharing.

If someone can try out EXPLORE2.PRG and confirm whether the graphics look like they do in the YouTube video https://youtube.com/watch?v=nCTF3v2hGFo, would be much appreciated.

Thank you,

Russell

i see no differences,

if nobody esle here have tested the demo maybe you have to go to the discord where users are more reactive.

there is still a possibility that my x16 have an issue despite all other recent demo work.

Thank you for the advice. I have reached out there. /Russell

MooingLemur and others in the CX16 #general and #video discords confirmed that there is an issue in the way VERA handles certain kinds of lines at 4 bpp. Thanks everyone for your help here! I now have to work on the joystick issue... /Russell

I'm looking at the pull request just out of curiosity. What was the issue? When the "sometimes" increment was horizontal, it advanced a byte instead of one nybble?

In my Google Drive is a program SAMPLE.PRG which draws lines at 4 bpp using VERA FX https://drive.google.com/drive/folders/ ... sp=sharing. Attached are outputs from an emulator r48 (the PNG), and actual hardware (the JPG). The emulator is correct, while it was confirmed there is an issue in VERA. Four octants are affected, those where it is occasionally incrementing or decrementing the horizontal direction by a nibble, while always incrementing or decrementing the vertical direction by 160 bytes. The forward horizontal direction doesn't seem to work at all, while the reverse seems to have a byte instead of a nibble increment.

I see, it was because of how ADDR0's half-increment was implemented.

If ADDR0_INCREMENT is 0.5, and ADDR0_NYBBLE is LEFT (0), then ADDR0_CHANGE is 0.
If ADDR0_INCREMENT is 0.5, and ADDR0_NYBBLE is RIGHT (1), then ADDR0_CHANGE is +1 byte.
If ADDR0_INCREMENT is -0.5, and ADDR0_NYBBLE is LEFT (0), then ADDR0_CHANGE is -1 byte.
If ADDR0_INCREMENT is -0.5, and ADDR0_NYBBLE is RIGHT (1), then ADDR0_CHANGE is 0.

When using ADDR0 to "sometimes" increment ADDR1 (as in line-helper mode), it tries to add ADDR0_CHANGE which is calculated based on ADDR0_NYBBLE instead of ADDR1_NYBBLE, so you get the effect of -0.5 always decreasing by 1 byte, and +0.5 doing nothing. In fact, if you changed ADDR0's nybble to RIGHT instead of LEFT ($9F22 bit 1 = 1), you should get the opposite effect where +0.5 always increases by 1 byte, and -0.5 does nothing.


I'm one of those weird people who really wants to understand why the original implementation was wrong whenever there's a bug like this.