Hi,
I'm looking to interface a Beeb (Or Master) to some existing hardware I have and fancy a little ROM to control it all and access from Basic, etc. via OSBYTE & OSWORD. I need 3 or 4 OSBYTES and an OSWORD or 2, but which to choose?
I feel the lists at:
https://www.beebwiki.mdfs.net/OSBYTEs
https://www.beebwiki.mdfs.net/OSWORDs
may be the best to use but it's hard to know - especially as I can find others with conflicting data...
Obviously for my own uses I can pick what I want that doesn't clash with existing ROMs I have in the system to-hand but just just in-case I actually get my act together and produce a little kit, I'm wonder what the best plan might be...
What do others do?
Thanks for any input.
-Gordon
What OSBYTE and OSWORD to claim?
- gordonDrogon
- Posts: 91
- Joined: Fri Nov 23, 2018 12:39 pm
- Location: Scottish Borders
- Contact:
Re: What OSBYTE and OSWORD to claim?
The real "BITD experience" would be to expect conflicts and two different ROMs wouldn't work with each other
Rgds
Stephen
Stephen
Re: What OSBYTE and OSWORD to claim?
Yes, there are gaps in that list, i.e. calls that are currently not shown as doing anything so you could grab one of those and, as it is a Wiki, edit it to say what you're using the call for. That is probably a better situation than existed back in the day.
The only thing to be aware of is that, with OSWORD, there is a limit to the set of calls where the tube software, both host end and the clients in second processor boot ROMs, knows (from a built-in table) how many bytes should be transferred. To add new OSWORDs you should adopt the convention where the control block contains this information, i.e. how many bytes to transfer in each direction.
The only thing to be aware of is that, with OSWORD, there is a limit to the set of calls where the tube software, both host end and the clients in second processor boot ROMs, knows (from a built-in table) how many bytes should be transferred. To add new OSWORDs you should adopt the convention where the control block contains this information, i.e. how many bytes to transfer in each direction.
Re: What OSBYTE and OSWORD to claim?
Another possibility is to look through the lists for hardware which is similar enough in function to yours that it could be considered an alternative, then try to make your code as compatible as possible, in the hope that you could experiment with old software. May not be possible, considering how little thought a lot of people put into software interfaces BITD, but fun if it works!
Completed projects: Multiphrom, My own rom board, Extra VIA, iPhone pauser. Current projects:
- Real-time clock: writing code.
Re: What OSBYTE and OSWORD to claim?
The process is to discuss here.
XY+0 sendlen
XY+1 receivelen
XY+2 command
XY+3 status
XY+4.... data
So you can perform up to 256 functions through one OSWORD, 65536 if you use command and status. Similarly, with one OSBYTE you can perform up to 256 functions: A=call, X=function. Bear in mind that there are effectively no two-byte A>7F OSBYTEs left, there are only one-byte A<80 OSBYTEs, where you can only pass a parameter in X and receive a result in X.
It would help if you put a little bit more flesh on your proposal. For an OSWORD call we've been gradually been creeping through the &9x and &Cx range, so one of those is likely. For an OSBYTE mention what sort of subfunctions it expects to do. Eg, is it OSBYTE mynum,handle such as the NetRx OSBYTE. Is it OSBYTE mynum,bitmap. Is it OSBYTE mynum,listoffunctions? It might be that your X parameter works out as something like %0xxxnnnn: do something with nnnn, %1xxxmmmm: so something with m, etc. Eg, X<80: read from device number in b0-b3, X>7F write to device number in b0-b3.
That's probably too many. Can't you make do with one each? The standard layout for an OSWORD is:gordonDrogon wrote: ↑Thu Mar 14, 2024 12:09 pm I'm looking to interface a Beeb (Or Master) to some existing hardware I have and fancy a little ROM to control it all and access from Basic, etc. via OSBYTE & OSWORD. I need 3 or 4 OSBYTES and an OSWORD or 2, but which to choose?
XY+0 sendlen
XY+1 receivelen
XY+2 command
XY+3 status
XY+4.... data
So you can perform up to 256 functions through one OSWORD, 65536 if you use command and status. Similarly, with one OSBYTE you can perform up to 256 functions: A=call, X=function. Bear in mind that there are effectively no two-byte A>7F OSBYTEs left, there are only one-byte A<80 OSBYTEs, where you can only pass a parameter in X and receive a result in X.
It would help if you put a little bit more flesh on your proposal. For an OSWORD call we've been gradually been creeping through the &9x and &Cx range, so one of those is likely. For an OSBYTE mention what sort of subfunctions it expects to do. Eg, is it OSBYTE mynum,handle such as the NetRx OSBYTE. Is it OSBYTE mynum,bitmap. Is it OSBYTE mynum,listoffunctions? It might be that your X parameter works out as something like %0xxxnnnn: do something with nnnn, %1xxxmmmm: so something with m, etc. Eg, X<80: read from device number in b0-b3, X>7F write to device number in b0-b3.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_