Request to try out demo in progress on real hardware
Forum rules
This section is for testing Commander X16 programs and programs related to the CX16 for other platforms (compilers, data conversion tools, etc.)
Feel free to post works in progress, test builds, prototypes, and tech demos.
Finished works go in the Downloads category. Don't forget to add a hashtag (#) and the version number your program was meant to run on. (ie: #R41).
This section is for testing Commander X16 programs and programs related to the CX16 for other platforms (compilers, data conversion tools, etc.)
Feel free to post works in progress, test builds, prototypes, and tech demos.
Finished works go in the Downloads category. Don't forget to add a hashtag (#) and the version number your program was meant to run on. (ie: #R41).
-
- Posts: 21
- Joined: Sat Jan 27, 2024 7:22 pm
Request to try out demo in progress on real hardware
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
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
Re: Request to try out demo in progress on real hardware
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
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
-
- Posts: 21
- Joined: Sat Jan 27, 2024 7:22 pm
Re: Request to try out demo in progress on real hardware
"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
-
- Posts: 21
- Joined: Sat Jan 27, 2024 7:22 pm
Re: Request to try out demo in progress on real hardware
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'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
- Attachments
-
- EXPLORE2.PRG
- (20.58 KiB) Downloaded 29 times
Re: Request to try out demo in progress on real hardware
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.
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.
-
- Posts: 21
- Joined: Sat Jan 27, 2024 7:22 pm
Re: Request to try out demo in progress on real hardware
Thank you for the advice. I have reached out there. /Russell
-
- Posts: 21
- Joined: Sat Jan 27, 2024 7:22 pm
Re: Request to try out demo in progress on real hardware
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
Re: Request to try out demo in progress on real hardware
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?
-
- Posts: 21
- Joined: Sat Jan 27, 2024 7:22 pm
Re: Request to try out demo in progress on real hardware
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.
- Attachments
-
- sample.png (31.34 KiB) Viewed 333 times
-
- PXL_20241129_195954067.MP.jpg (197.33 KiB) Viewed 333 times
Re: Request to try out demo in progress on real hardware
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.
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.