Request to try out demo in progress on real hardware

Talk about your programs in progress. Discuss how to implement features, etc.
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).
Post Reply
russell-s-harper
Posts: 21
Joined: Sat Jan 27, 2024 7:22 pm

Request to try out demo in progress on real hardware

Post by russell-s-harper »

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
the_seb
Posts: 22
Joined: Mon Feb 14, 2022 3:25 pm

Re: Request to try out demo in progress on real hardware

Post by the_seb »

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
russell-s-harper
Posts: 21
Joined: Sat Jan 27, 2024 7:22 pm

Re: Request to try out demo in progress on real hardware

Post by russell-s-harper »

"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
russell-s-harper
Posts: 21
Joined: Sat Jan 27, 2024 7:22 pm

Re: Request to try out demo in progress on real hardware

Post by russell-s-harper »

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
Attachments
EXPLORE2.PRG
(20.58 KiB) Downloaded 29 times
the_seb
Posts: 22
Joined: Mon Feb 14, 2022 3:25 pm

Re: Request to try out demo in progress on real hardware

Post by the_seb »

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.
russell-s-harper
Posts: 21
Joined: Sat Jan 27, 2024 7:22 pm

Re: Request to try out demo in progress on real hardware

Post by russell-s-harper »

Thank you for the advice. I have reached out there. /Russell
russell-s-harper
Posts: 21
Joined: Sat Jan 27, 2024 7:22 pm

Re: Request to try out demo in progress on real hardware

Post by russell-s-harper »

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
DragWx
Posts: 345
Joined: Tue Mar 07, 2023 9:07 pm

Re: Request to try out demo in progress on real hardware

Post by DragWx »

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?
russell-s-harper
Posts: 21
Joined: Sat Jan 27, 2024 7:22 pm

Re: Request to try out demo in progress on real hardware

Post by russell-s-harper »

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
sample.png (31.34 KiB) Viewed 333 times
PXL_20241129_195954067.MP.jpg
PXL_20241129_195954067.MP.jpg (197.33 KiB) Viewed 333 times
DragWx
Posts: 345
Joined: Tue Mar 07, 2023 9:07 pm

Re: Request to try out demo in progress on real hardware

Post by DragWx »

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. :P
Post Reply