Identify cards

[Neurox66]

Is it possible to identify the expansions attached to the CPC? 
Such as M4 boards, SYMBiFACE ,LambdaSpeak,ULIfAC and so on?

Thanks,
Paolo

[d_kef]

There isn't a single uniform way.
Usually it is enough to query a status register ( Symbiface/X-Mass, USIfAC/ULIfAC) but for M4 you need to query the interface's ROM.

d_kef

[GUNHED]

Is it possible to identify the expansions attached to the CPC?
Such as M4 boards, SYMBiFACE ,LambdaSpeak,ULIfAC and so on?

Thanks,
Paolo

Of course! Every expansion can be identified by reading and checking a port I/O address. Just have a look at the documentation of the desired expansion. In FutureOS the configuration bytes contain bits indicating the connected expansions. 

[Prodatron]

Is it possible to identify the expansions attached to the CPC? 
Such as M4 boards, SYMBiFACE ,LambdaSpeak,ULIfAC and so on?

Check the attachment.
Inside the ZIP all "-init" files contain the code for detecting the hardware.

[Neurox66]

Thank you Prodatron,
fantastic collection of sources for recognizing cards entered into the CPC.
Quite a bit of work saved
Thanks again,
Paolo

[zhulien]

I'm wondering, can we think of a uniform way and stick all them into an API on a ROM - e.g. 'cards' and it can return a list of identified cards.

I suggest an RSX that returns a string so that it is easy to use from BASIC (in a single RSX).  With an optional parameter which is a characters.

This RSX could use a combination of software checking ports or a config file to return.  Each hardware can have  a user supplied description and a value of yes, no or auto (if supported).  no is the same as ommitting the line, however saves you removing the line... or we could put REM in front, such as in i.e. 2.   The single character card identifier is also like a control-code that can have parameters returned.

i.e 1.

config.txt
R=RAM,auto
S=SSA1 Speech Synth,yes
D=DkTronick Speech Synth,no
L=Llambdaspeak,yes
3=Llambda Speak MP3 player,yes
M=Llambda Speak Midi,no

i.e 2.  below, the auto for RAM is like a commandline parameter to the RAM subroutine, we can use any type of parameters that suit initialisation and/or detection of the hardware below

config.txt
R=RAM, auto
S=SSA1 Speech Synth
REM D=DkTronick Speech Synth
L=Llambdaspeak
3=Llambda Speak MP3 player, speech=SSA1
REM M=Llambda Speak Midi

RSX:

|CARDS,@a$ would simply return a string if any cards are found.  We can treat RAM in a certain way (see below).  If cards A, B and C are all present, then a$ would contain "0100ABC"

|CARDS,@a$, "ABC" would check the presence of cards A, B and C and return the string of which are found from the required list, e.g. if only A and B are found, then a$ would contain "0100AC"

notes:

- first 2 characters is API version that should never change if it is not breaking compatability
- second 2 character s is API revision number that can change when compatability is not broken
- we are not limited to A-Z, we can use 1 to 255 values, 0 being a secondary terminator to cater for both assembly and BASIC.
- not only 1 to 255 to identify a card, a card can have parameters, e.g. if R was RAM (DkTronics compatabile), then perhaps the next sequence of datacould be available banks until a 0 is found.

|CARDS,@a$, "R"  could perhaps return "R" + #c4 + #c5 + #c6 + #c7 + #00 to denote an additional 64k?  Of course if we brainstorm a bit more we can make it compatible with all RAM up to 4mb standard addressing.

If we can agree on something along these lines, happy to start the ROM off for others to make better and/or add to it...

[zhulien]

ps, currently i have started working on a driver ROM that is compatible with UniDOS - because lots of drivers really are good as streams - I will likely put whatever we can design into that ROM also

[andycadley]

I'm wondering, can we think of a uniform way and stick all them into an API on a ROM - e.g. 'cards' and it can return a list of identified cards.

I suggest an RSX that returns a string so that it is easy to use from BASIC (in a single RSX).  With an optional parameter which is a characters.

This RSX could use a combination of software checking ports or a config file to return.  Each hardware can have  a user supplied description and a value of yes, no or auto (if supported).  no is the same as ommitting the line, however saves you removing the line... or we could put REM in front, such as in i.e. 2.  The single character card identifier is also like a control-code that can have parameters returned.

i.e 1.

config.txt
R=RAM,auto
S=SSA1 Speech Synth,yes
D=DkTronick Speech Synth,no
L=Llambdaspeak,yes
3=Llambda Speak MP3 player,yes
M=Llambda Speak Midi,no

i.e 2.  below, the auto for RAM is like a commandline parameter to the RAM subroutine, we can use any type of parameters that suit initialisation and/or detection of the hardware below

config.txt
R=RAM, auto
S=SSA1 Speech Synth
REM D=DkTronick Speech Synth
L=Llambdaspeak
3=Llambda Speak MP3 player, speech=SSA1
REM M=Llambda Speak Midi

RSX:

|CARDS,@a$ would simply return a string if any cards are found.  We can treat RAM in a certain way (see below).  If cards A, B and C are all present, then a$ would contain "0100ABC"

|CARDS,@a$, "ABC" would check the presence of cards A, B and C and return the string of which are found from the required list, e.g. if only A and B are found, then a$ would contain "0100AC"

notes:

- first 2 characters is API version that should never change if it is not breaking compatability
- second 2 character s is API revision number that can change when compatability is not broken
- we are not limited to A-Z, we can use 1 to 255 values, 0 being a secondary terminator to cater for both assembly and BASIC.
- not only 1 to 255 to identify a card, a card can have parameters, e.g. if R was RAM (DkTronics compatabile), then perhaps the next sequence of datacould be available banks until a 0 is found.

|CARDS,@a$, "R"  could perhaps return "R" + #c4 + #c5 + #c6 + #c7 + #00 to denote an additional 64k?  Of course if we brainstorm a bit more we can make it compatible with all RAM up to 4mb standard addressing.

If we can agree on something along these lines, happy to start the ROM off for others to make better and/or add to it...

What would be the benefit to being able to call this from BASIC though? 

And having data that doesn't match the fixed format for certain conditions, such as RAM, will create a brittle API that breaks each time something that needs additional returned data added.

[zhulien]

What would be the benefit to being able to call this from BASIC though?

And having data that doesn't match the fixed format for certain conditions, such as RAM, will create a brittle API that breaks each time something that needs additional returned data added.

So BASIC programmers can use the hardware in a friendly way?  How good would it be if Alyssa Database just crashed upon startup instead of not?

What if a BASIC programmer wants to have their program speak regardless of which speech synth they have installed?  It provides an easy way to detect and adapt the logic without issues - just like an assembly program.

[Neurox66]

Thank you for the suggestion Zhulien.
A few months ago I started an ambitious project writing a language similar to basic for our fabulous Amstrad CPC.  Written in HyperTalk/LiveCode and running under macOS and Windows.
My intention was to write a function that returns the presence or not of a specific board example: isM4() , isLambda(), isNova() etc.
I have already made the function that returns what type of CPC you are using and what version of Basic Locomotive you are using.
Obviously I program in my spare time but I hope in two/three months to release a working version. 
Its name is SAM Compiler (Strange And Messy compiler) because the generated assembly source is indeed not the best of optimization
Paolo

[zhulien]

Thank you for the suggestion Zhulien.
A few months ago I started an ambitious project writing a language similar to basic for our fabulous Amstrad CPC.  Written in HyperTalk/LiveCode and running under macOS and Windows.
My intention was to write a function that returns the presence or not of a specific board example: isM4() , isLambda(), isNova() etc.
I have already made the function that returns what type of CPC you are using and what version of Basic Locomotive you are using.
Obviously I program in my spare time but I hope in two/three months to release a working version. 
Its name is SAM Compiler (Strange And Messy compiler) because the generated assembly source is indeed not the best of optimization
Paolo

I think the solution i suggested driven by a config file but reportable via an RSX or ROM call direct would work well for either BASIC or any compiled language, just a matter of your functions calling the ROM.