features.h corrections

Bug reports (if you don't/won't have a Github account)
Post Reply
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

features.h corrections

Post by RobertK »

As I have mentioned already, features.h is a very helpful addition for cross-development.

Here are a few corrections, more will follow.

pacman and myvision: __HAVE_KEYBOARD should be 0 (I wouldn't regard the MyVision buttons as a keyboard)
vz and z80tvgame: __HAVE_ONEBITSOUND should be 1
gal without subtype: __HAVE_ONEBITSOUND and __HAVE_PSG_AY should both be 0
gal with subtype __GALPLUSHIRES__: I think that __HAVE_ONEBITSOUND should be 0 (as 1-Bit sound does not seem to work), only __HAVE_PSG_AY should be 1

Two more questions/ideas:

1. I wonder why there are no flags indicating the supported console types? Or is there some other way for querying this?

2. Can we somehow find out whether virtual joystick support (games.h) is already implemented for a specific target?
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

And two more findings:

m5 and svi: __HAVE_ONEBITSOUND should be 1
User avatar
dom
Well known member
Posts: 1554
Joined: Sun Jul 15, 2007 10:01 pm

Re: features.h corrections

Post by dom »

Hi Robert,

I've taken on board those corrections - thank you for them. I think the intention originally was for HAVE_KEYBOARD to mean whether fgetc_cons() was functional. I've now split those apart to make it clearer.

Regarding the console types, I thought about this originally but didn't include them because they are switched based on compile flags rather than passive library features. For example, for +zx in features.h both ansi and gencon flags would be defined so what would you do differently?

For reference, -clib=ansi can be detected using __CONIO_VT100

> 2. Can we somehow find out whether virtual joystick support (games.h) is already implemented for a specific target?

Refresh my brain, what do you mean by virtual joystick? Keyboard input? Which sort of keyboard input? Single direction/multi-direction? I have a hunch that:

- HAVE_KEYBOARD -> joystick available
- HAVE_KEYBOARD + HAVE_INKEY -> multidirectional joystick available

But that's quite messy...
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

dom wrote: Sun Dec 12, 2021 5:39 pm Refresh my brain, what do you mean by virtual joystick?
Polling a joystick - either a physical one or a key set - using the joystick() function from games.h. On a system where this is not implemented yet, we get a "symbol 'joystick' not defined" error. So it would be nice to have a feature flag for that too in order to use kbhit() and getch() instead.
User avatar
dom
Well known member
Posts: 1554
Joined: Sun Jul 15, 2007 10:01 pm

Re: features.h corrections

Post by dom »

Ah okay, consider that one added. I may have missed a few, but the ones that are marked, definitely have it!
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

Hmm, I checked a few that don't have it yet, and many of them are marked with __HAVE_JOYSTICK = 1. The CPC is one example.

Here is what I did in Mastermind RK:

Code: Select all

#if defined(__ABC80__) || defined(__CPC__) || defined(__SORCERER__) || defined(__KC__) || defined(__MULTI8__) || defined(__NASCOM__) || defined(__PC6001__) || defined(__OSBORNE1__) || defined(__SPC1000__) || defined(__EINSTEIN__) || defined(__TIKI100__) || defined(__Z1013__) || defined(__MZ2500__) || defined(__FP1100__) || defined(__ACE__) || defined(__P2000__) || defined(__X1__) || defined(__KAYPRO83__) || defined(__ATTACHE__) || defined(__QC10__) || defined(__PC88__) || defined(__DMV__) || defined(__LASER500__) || defined(__ZX80__) || defined(__SMC777__) || defined(__PASOPIA7__) || defined(__EXCALIBUR64__) || defined(__RC700__) || defined(__BIC__) || defined(__HEMC__) || defined(__HGMC__) || defined(__KRAMERMC__) || defined(__BONDWELL12__) || defined(__BONDWELL2__) || defined(__PCW__) || defined(__GL__)
	#define GAMES_H_NOT_AVAILABLE 1
#else
	#include <games.h>	// for virtual joystick control
#endif
I believe that all these should still be marked as __HAVE_JOYSTICK = 0.
User avatar
dom
Well known member
Posts: 1554
Joined: Sun Jul 15, 2007 10:01 pm

Re: features.h corrections

Post by dom »

All the ones marked with HAVE_JOYSTICK do link so there might be some other reason why you're not using joystick(). Taking the CPC for example:

Code: Select all

games.h:
#ifdef __CPC__
#ifdef DEFINE_JOYSTICK_TYPE
        const unsigned char *joystick_type[] = { "Joystick 0", "Joystick 1", "QAOP-MN"};
#endif
        #define GAME_DEVICES 3
#endif
and here: https://github.com/z88dk/z88dk/blob/mas ... ystick.asm
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

Try compiling snakes.c for the CPC like this...

zcc +cpc -lndos -subtype=dsk -create-app -DJOYSTICK_DIALOG -DSPEED=300 -o snakes snakes.c

...and you will get a "symbol '_joystick_type' not defined" compiler error.

I always thought that joystick handling simply is not yet implemented for these targets, but maybe there is some other problem?
User avatar
dom
Well known member
Posts: 1554
Joined: Sun Jul 15, 2007 10:01 pm

Re: features.h corrections

Post by dom »

Ah right, now I understand. I'm added a test for joystick_type being defined and quite a few failed at that point.

So I've fixed all those up, so with luck...
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

Joystick is now available on the CPC and the Bondwell 12/14 (I've tried these two), but it's not working yet, only "left" seems to be working.

One more features.h correction:
Bondwell 12/14: __HAVE_ONEBITSOUND should be 1
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

A little off-topic, but I'll use this thread to report errors I found in the platform list while I was checking features.

Memotech MTX and Sega SC3000: Sound "PSG (+ 1 bit)" should be replaced with "PSG". 1-Bit sound does not work and is not available according to features.h.

Laser 500: Sound should be "1 bit", it is available according to features.h and works fine.

I haven't tested PSG sound yet on those three targets.
User avatar
dom
Well known member
Posts: 1554
Joined: Sun Jul 15, 2007 10:01 pm

Re: features.h corrections

Post by dom »

For targets with a SN76489 PSG, Stefano added emulation for the one bit sound API. It's not perfect, but can produce some recognisable effects.

It does look like I was inconsistent regarding it in the features.h list - m5 is marked as having it for example. smc777 genuinely has a beeper as well as the PSG so will use the beeper rather than the PSG for effects.

That does leave a bit of puzzle though, is that distinction needed: hardware beeper vs 1 bit sound API available (somehow)?
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

From a developer's point of view, I would say: __HAVE_ONEBITSOUND should indicate that bit_fx(), bit_fx2() and so on work and produce recognisable sounds, no matter what hardware is present to generate these sounds.
dom wrote: Mon Dec 27, 2021 12:03 amm5 is marked as having it for example.
On the Sord M5, 1-Bit sound is working fine, while on the SC-3000 and the MTX it only makes terrible continuous noise.

If they all share the same SN76489 chip, then there could be a problem with these two target?
User avatar
dom
Well known member
Posts: 1554
Joined: Sun Jul 15, 2007 10:01 pm

Re: features.h corrections

Post by dom »

RobertK wrote: Mon Dec 27, 2021 12:39 pm From a developer's point of view, I would say: __HAVE_ONEBITSOUND should indicate that bit_fx(), bit_fx2() and so on work and produce recognisable sounds, no matter what hardware is present to generate these sounds.
That sounds like a good solution.
RobertK wrote: Mon Dec 27, 2021 12:39 pmOn the Sord M5, 1-Bit sound is working fine, while on the SC-3000 and the MTX it only makes terrible continuous noise.

If they all share the same SN76489 chip, then there could be a problem with these two target?
On the MTX the chip is latched so you have to read from that port after writing to the SN for something to happen, I can definitely believe that that's not working correctly for bit_fx routines, the SC-3000 to me (using takeda) is noisy, but there are some recognisable patterns underneath: not as clean as intended of course.

At this point I'm happy enough to to just mark the working ones and "quietly ignore" the slightly broken ones.
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

The problem on the SC-3000 is that e.g. bitfx(0) sets off some terrible continuous noise that only stops when another working sound pattern is played.
Some sounds like bitfx(4) or bitfx(6) seem to work correctly, and bitfx4(1) is quite recognisable.
dom wrote: Mon Dec 27, 2021 4:35 pmAt this point I'm happy enough to to just mark the working ones and "quietly ignore" the slightly broken ones.
No problem, the ones with working sound are great already.

P.S. Here are two corrections to the "Monochrome Graphics" column of the platforms page: Sega Master System should have "256x192", and the Genius Leader "240x100 (6000 SL)".
User avatar
RobertK
Well known member
Posts: 253
Joined: Mon Feb 26, 2018 12:58 pm

Re: features.h corrections

Post by RobertK »

RobertK wrote: Sun Jan 09, 2022 10:52 pmBTW, i think that __HAVE_ONEBITSOUND on __BONDWELL__ is still not defined, I still have to use a workaround to activate sound.
This is fixed now, thanks.

Here is one more issue on the Platforms Wiki page:
Sony SMC-70/SMC-777: the "Monochrome Graphics" column should be:
80x50, 160x50, 320x200, 640x200
Post Reply