Jupiter ACE

[Steve(spt)]

The Jupiter Ace archive team are now looking at using Z88dk. We might need some help to get us started.

So far the synthdemo.c code works fine, and Adv_a, on EightyOne emulator which is our perfered one, other that a real ACE.

Is it OK to post our silly question and request for help using Z88dk?

Kind regards.
Steve

[dom]

Go for it!

[stefano]

I'm very happy to get a feedback from ACE lovers, and even a bit bewildered hearing that the advanced sound functions are working correctly. They're just inherited from a common portable base and I couldn't test them, at the time: I stopped specific tests when I got the graphics Mandelbrot function ...

[RobertK]

While we are still waiting for any questions, I will use this as a general Jupiter Ace thread...

Two issues:

1. The games.h virtual joystick "Cursor" has Up and Down swapped. This can be tested with WIP\compile_deepspace_Ace.bat in the current Deepspace package, this will produce an ultra-blocky (useless) Ace version, load it with 0 0 bload ds.bin

2. What is the status of sound support for the Jupiter Ace? According to features.h, there is no sound support at all, but the platforms wiki page says that there would be 1-Bit sound (which does not work).

[dom]

We might be waiting a while!

1. That's funny: although the ZX keyboard was copied, the cursor directions were changed

2. One bit sound does work, however 81 emulates it incorrectly. I recently corrected it so that the diaphragm is driven by in/out on port 254 (to match the hardware), rather than just an out on port 254. So, sound does work in Mame - as proven by this game: https://gldm.itch.io/jupiter-ace-pac-man

I have however forgotten how to configure mame to use more than 3k of memory which is a bit of a limitation on testing - if you know can you let me know!

I've just updated the repo with the feature change + key switch around.

Edit: mame jupace -ramsize 16K does it....

[RobertK]

Cursor control and features.h are fine now, thanks!

That sound problem of mine was indeed an emulator issue: I just noticed that I was using an older version of the 81 emulator in which sound was working only once, after the first hard reset you wouldn't even hear the loading sound anymore. In the current version 1.25, sound is always working correctly, same in MAME.

[RobertK]

I've noticed some non-standard behaviour with cpeek() on the Ace. I must say that I'm new to UDG and cvpeek(), so it could be that I'm doing something wrong.

Here is a simple test: I'm defining five UDG characters, printing them on the screen using putchar() for character codes 128 through 132, and then cvpeeking each character and showing that result on the right.

That should give us the same character codes that we just used for putchar(). However, on the Ace in 64x48 mode it shows codes 0 through 4.

Ace_cvpeek.jpg

So I thought that the UDGs are defined in that area as well, and I tried putchar() for codes 0 through 4, but that didn's show my characters.
Nor do they appear when using 17 to 23, as the wiki target page would suggest: "64x48 uses UDGs/character codes 17 to 23".

In case that it should be helpful for testing: my test program cvpeektest2.zip is here:
https://drive.google.com/drive/folders/ ... q6EqH_3zMr

[dom]

+ace has got 128 characters available for redefinition. Once you reserve 96 for the font we're left with 32. These sit at character codes 0 - 31.

The 64x72 graphics mode uses all 32 slots to provide the various pixels (and redefines them). The 64x48 mode uses characters 17-23 for providing the pixels (using the definitions setup by the ROM).

What this means is that when a UDG is printed (using code 128), the vpeek returns code 0. This is a little annoying and I should be able to make it better.

I'll also support add support for inverse as well since that is available on the machine.

[RobertK]

Thanks, I've added a workaround in my game for now by simply adding 128 to the cvpeek() result if it's not 32 (Space), and now it's working fine.

[RobertK]

64x72 low-res graphics (-lgfxaceudg) is currently broken.

My grtest.c should look like this, compiled with z88dk nightly 2023-11-19:

grtest_Ace_64x72_ok.jpg

This is what it looks like with the current nightly:

grtest_Ace_64x72_not_ok.jpg

Code: Select all

zcc +ace -lgfxaceudg -create-app -vn -pragma-redirect:fputc_cons=fputc_cons_generic grtest.c -o gt.bin

64x48 mode is still ok.

[dom]

That was silly of me - I checked the regular graphics mode to see if it would conflict with the UDG changes I made, but didn't check that one.

It's now good for me.

[RobertK]

Thank you, both modes are working fine now, and the cvpeek() workaround is no longer necessary.