features.h corrections
features.h corrections
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?
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?
Re: features.h corrections
And two more findings:
m5 and svi: __HAVE_ONEBITSOUND should be 1
m5 and svi: __HAVE_ONEBITSOUND should be 1
Re: features.h corrections
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...
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...
Re: features.h corrections
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.
Re: features.h corrections
Ah okay, consider that one added. I may have missed a few, but the ones that are marked, definitely have it!
Re: features.h corrections
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:
I believe that all these should still be marked as __HAVE_JOYSTICK = 0.
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
Re: features.h corrections
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:
and here: https://github.com/z88dk/z88dk/blob/mas ... ystick.asm
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
Re: features.h corrections
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?
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?
Re: features.h corrections
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...
So I've fixed all those up, so with luck...
Re: features.h corrections
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
One more features.h correction:
Bondwell 12/14: __HAVE_ONEBITSOUND should be 1
Re: features.h corrections
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.
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.
Re: features.h corrections
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)?
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)?
Re: features.h corrections
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.
If they all share the same SN76489 chip, then there could be a problem with these two target?
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?
Re: features.h corrections
That sounds like a good solution.
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.
Re: features.h corrections
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.
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)".
Some sounds like bitfx(4) or bitfx(6) seem to work correctly, and bitfx4(1) is quite recognisable.
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)".
Re: features.h corrections
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
Re: features.h corrections
A few more items:
Mattel Aquarius and Philips P2000: Feature __HAVE_ONEBITSOUND should be set.
GL_TARGET_GL6000: remove Feature __HAVE_ONEBITSOUND. I've been in contact with this forum's user "hotkey", and he recently found out that the 6000SL has a different sound chip (a TI TSP50C0x variant) than the 2000 and 4000 models. He tested Deepspace on his real GL6000 SL: sound wasn't working, as expected.
Note: On the 2000 and 4000 models, 1-Bit sound is supported and working correctly.
On the targets wiki page, change the sound column to "1 bit (2000, 4000)"
Sharp MZ (80,700,800): On the targets wiki page, change "PSG (+ 1 bit)" to "PSG" (1-Bit sound cannot be heard).
Note: Feature __HAVE_ONEBITSOUND is not set, which is correct.
Mattel Aquarius and Philips P2000: Feature __HAVE_ONEBITSOUND should be set.
GL_TARGET_GL6000: remove Feature __HAVE_ONEBITSOUND. I've been in contact with this forum's user "hotkey", and he recently found out that the 6000SL has a different sound chip (a TI TSP50C0x variant) than the 2000 and 4000 models. He tested Deepspace on his real GL6000 SL: sound wasn't working, as expected.
Note: On the 2000 and 4000 models, 1-Bit sound is supported and working correctly.
On the targets wiki page, change the sound column to "1 bit (2000, 4000)"
Sharp MZ (80,700,800): On the targets wiki page, change "PSG (+ 1 bit)" to "PSG" (1-Bit sound cannot be heard).
Note: Feature __HAVE_ONEBITSOUND is not set, which is correct.