News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_zhulien

CPC Drivers

Started by zhulien, 02:24, 04 December 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

zhulien

Hi Everyone,


I have started this new thread to allow open discussion and information of driver support for various hardware in the CPC from an AMSDOS point of view primarily but also from a custom software point of view.  This is to try create a 'driver standard' as opposed to everyone making totally incompatible drivers.


There are several goals I have set, but everything is open for discussion. 


For developers (hardware or software) if you do want to participate in real-time chat when we are online, I have created a Google Hangouts Group for CPC Driver Dev.


I also for the time being have created a driver summary spreadsheet for notes within Google Docs.  This I expect to move to a Wiki or Git at some stage, or website.


Message me your gmail email address if you want access to the spreadsheet or to be added to the Hangouts group (specify each or both).


For those who can access the spreadsheet, here it is:
https://drive.google.com/drive/folders/1Xvirgaep8dHFQUSaQxa5aQRV_SIbAfbR


For those who want to join the group yourself, click here:
https://hangouts.google.com/group/uNRT2FVnpjyHtKRX7

GOALS

https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=140035230

zhulien

#1
System API / System Drivers:


To facilitate drivers on the CPC, we need some system parts.  This will consist of a System API and some System Drivers.


System API Spec - https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=2035439011


The System Drivers are not so much hardware drivers directly but more device collections and abstraction for which drivers register themselves with.  Once registered, a software developer can then use it by requesting it from the system in a uniform way.


System Drivers - https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=1779988149




Hardware Drivers:


Hardware Drivers are custom written drivers for bits of hardware.  At the moment there is a short list, but I see it would eventually lead to non-hardware drivers such as FileSystems too.

Hardware Drivers - https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=0


The Drivers are used by software using the Driver's API, this is consistent across all drivers as well as the System Drivers.

Driver API - https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=1738599617




Driver API Usage:


Driver APIs can be called in a similar way to a CP/M API. 


eg:



LD B, DRV_TEXTSCREEN   ; get the driver version
LD C, API_GETDRIVERVERSION   
CALL SYSTEMENTRY   


But a second method like AMSDOS will also be available for faster access via a jumpblock.


For drivers that require custom APIs, there will be a facility for that too.




Driver Creation:


An important aspect of this project must be that drivers have to be quite easy to develop.


Example here - https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=1284550688

zhulien

First Review-able Driver Specs are now above.  Any input much appreciated from software / hardware developers.  I am happy to elaborate on any questions you have.

biged

(I'm following this topic with interest but not sufficiently technical in the Amstrad sphere to contribute. I can say lots about the BBC Micro's operating system architecture, but nothing much at all about the CPC's.)

zhulien

BASIC RSXs added to the spec with an example.  Hopefully this starts to give you an idea of how they can work in a device independent way.


https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=67689476


It should be for example as easy as a couple of lines to send data from RAM to a Speech Synth

zhulien

There is 'the system' which is like a bunch of driver collections, and there are individual drivers.


For most part 'the system' is treated as a driver.


The drivers work a bit like a basic file with the ability to read & write as well as transfer data to and from - but they can also have custom APIs if the standard ones are not sufficient. 


Each driver has from 1 to n LUNS (Logical Unit Numbers).  This can be in the case of RAM, a bank number.  In the case of a display driver, a monitor.  In the case of a drive, a drive number/name.  For now I am opting for 255 LUNS max per device which of course let's us access about 4mb of system RAM, and 4mb of Slow RAM.  It doesn't matter which device we are talking to of a type of device, they are all to be compatible from the basic API point of view, i.e... reading to one type of RAM expansion would be the same code to talk to another - just the LUN might be different.  System RAM I am limiting to be paged between #4000 and #7fff... but check the unresolved issues for ideas - we could cater for 255 LUNS of 64kb instead, but... it is a pain to program for because it is hard to read/write from one 64kb block in another directly. 


When we register a driver with the system, although the driver itself has a LUNS limit, the system also has it's own LUNS limit.  A driver might have max LUNS 2 (e.g. multiplay mx4) for 2 joysticks.  The standard CPC joystick driver also has max LUNS 2.  We can of course communicate directly with each driver with a LUN of 1 and 2, but if both drivers are loaded at the same time and we communicate via 'the system', then we have 4 LUNS meaning a game could use the exact same code to read each joystick and support easily, up to 4 players.


shifters74

Hi zhulien,

what kind of ram and rom overhead does using a driver supporting this format require?

For example CPLINK - code to access the device is a dozen or so bytes for the basic function.   

Your jump tables alone look rather larger

Shifters67

zhulien

There are 2 ways to call it. One is using a function number similar to how cpm requires it.  The other is using a jump block. To get a jump block I am considering an application that wants to use it sets up an area of ram that wants to use it then calls the getjumpblock which basically transfers the jump block to ram.  Of course this method needs ram for the jump block copy but an application can call the function more directly via it if a little more performance is required. The system I plan to make as a rom but perhaps it could be made to work in ram too... from rom will give basic the better advantage.


Not sure I really answered your question?

zhulien

I have added a conceptual boot.bas startup to load drivers from BASIC.  The idea is that someone can tailor their system to the hardware they have installed completely from available luns to device names.  This also shows the linking of multiple mouses to multiple mousepointers.  The hopes are to support 4 joysticks in a uniform way (the user can choose if they want to use the inbulit joysticks or a multiplay), but also up to 4 mouses (it could be 2 real via multiplay, and 2 simulated using joystick / cursors - or perhaps i need to up the max LUNS to 5 so that 3 real mouses could be used + 2 simulated).

zhulien

#9
Added more info (planning for audio drivers etc), restructured a bit, highlighted 2 oddities I came across and yes, started to map out the coding of the main system entry points and jumpblocks. 


The main purpose of this is that people using BASIC or even coding new CPC software can use the drivers in a uniform way without having to write their own - just like you would expect drivers to work.  Drivers will be in ROM (for the RAM ones so we don't page our RAM drivers out) and in banked RAM and since lots of RAM on CPCs is easy to come by now and quite cheap (compared to 1984).

zhulien

#10
I have coded some more of the driver system pseudocode (in the newly added pseudocode tab above) - progress is shown in green above.


I have skipped the jumpblocks, customAPI and sendMessage functions for now - not sure if they will be needed.


The main funcitons to talk to a driver are:


1 - SelectLUN
2 - UnselectLUN
3 - Read
4 - Write
5 - TransferData


The LUN (logical unit number) can mean different things for different driver types.


Some examples:


a multiplay has 2 joystick/mouse ports.  A driver coded could have 2 LUNs which can be configured between mouse/joystick or alternatively it could have 4 LUNs (2 joystick, 2 mouses).  To cater for this, we actually write 2 drivers, a multiplay joystick driver, and a multiplay mouse driver, and load them at startup with a user-configured purpose.


a lambdaspeak has ssa1 emulation, dkTronics speech emulation, other speech, mp3 playback, amdrum playback, pcm sound playback.  Each of these likely would have individual drivers coded for them.


This enables us to have a lists of registered mouses, registered joysticks, registered speech synths, registered sample playback devices for which could be retargeted if they are compatible from a behavioral point of view - this is outlined in the Hardware Drivers tab above.


Some devices allow random access and some serial only.  Random access being a memory driver, or a trackdisc, serial speech device, perhaps even mouses and joysticks since you are just reading the values at a point in time.


Can anyone think of any drivers that are peculiar in the way they could be written or read from?

zhulien

ROMS based driver system vs RAM based driver system?


After some thought on the recent release of UniDOS which I think is a great idea - that can give likely the best compatibility and most 'Locomotive BASIC' like functionality to a DOS as someone would expect it to be.


It makes me wonder, is a UniSpeech, a UniDAC, a UniRAM, a UniBlah... a better way to go for drivers than the ram-based drivers?


Pros of ROM driver system:


- no or minimal RAM usage
- in it's easiest form, the infrastructure is already there with background ROMS, the only real work could be to standardise on the commands or way the drivers in ROM are called so that software can easily use alternate drivers within the same or other ROMS without any software change


Cons of the ROM driver system:


- multitasking would be either minimal or non-existent within the drivers
- potentially need to come up with a more efficient ROM-based way to store drivers than standard RSXs so that drivers can be more flexibly placed in any of the driver ROMS so we don't have too small limits on drivers


Pros of the RAM driver system:


- more easily configurable, editing a startup script changes the configuration
- better suits multitasking



Cons of the RAM driver system:


- it uses RAM




For myself, the introduction of multitasking drivers is a really good benefit that sways towards drivers stored in RAM.  What are your thoughts?

Powered by SMFPacks Menu Editor Mod