Author Topic: CPC Drivers  (Read 1230 times)

0 Members and 1 Guest are viewing this topic.

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
CPC Drivers
« on: 03:24, 04 December 19 »
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
« Last Edit: 02:10, 10 December 19 by zhulien »

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
Re: CPC Drivers
« Reply #1 on: 02:10, 10 December 19 »
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
« Last Edit: 02:13, 10 December 19 by zhulien »

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
Re: CPC Drivers
« Reply #2 on: 09:37, 18 December 19 »
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.

Offline biged

  • CPC464
  • **
  • Posts: 12
  • Country: gb
  • Liked: 13
  • Likes Given: 12
Re: CPC Drivers
« Reply #3 on: 10:31, 18 December 19 »
(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.)

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
Re: CPC Drivers
« Reply #4 on: 07:17, 20 December 19 »
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

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
Re: CPC Drivers
« Reply #5 on: 12:31, 21 December 19 »
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.


Offline shifters74

  • CPC664
  • ***
  • Posts: 52
  • Country: gb
  • Liked: 37
  • Likes Given: 21
Re: CPC Drivers
« Reply #6 on: 11:26, 22 December 19 »
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

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
Re: CPC Drivers
« Reply #7 on: 09:54, 23 December 19 »
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?

Online zhulien

  • 6128 Plus
  • ******
  • Posts: 539
  • Country: au
    • 8bitology
  • Liked: 224
  • Likes Given: 170
Re: CPC Drivers
« Reply #8 on: 07:25, 13 January 20 »
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).