After lots of coffee I managed to create a sideways ROM version of the hex sprite routine.

For now it responds to OSBYTE &64 as demonstrated in ROMTEST, but for some reason it does not work correctly when calling from a 2nd processor.

Instructions for running on a Master:

>CHAIN "HEXAROM" : loads rom image at &8000 in bank 6
>CHAIN "HEXDEFS" : loads hex definitions (7 of them) at &A000 in bank 6

Press CTRL+BREAK to initialize the rom
*ROMS should display
...
RAM 6 HEXAROM Hex Sprites 01
...

>CHAIN "ROMTEST"

Comments and improvements welcome
To be cont'd

Hmmm, big time headslap

Just looked through the tube application note and noticed the OSBYTE number I used (&64) will not send the Y register across the tube. That's why it does not work correctly when called from a 2nd processor.

And it seems OSBYTE never will work as all numbers above &7F appear to be taken.

Should have thought of that before as I hit the same problem with an OSWORD call a while back.

So OSWORD it is..... Back to the drawing board.

Some comments:
ROM version string must not start with any padding before it's content as you have done, it should be "a.bc" or "a.bc (de Fgh ijkl)", ie "0.01" or "0.01 (01 Jan 2012)". Also, you've got an extra zero byte after the version string. The zero byte at the start of the copyright string is the terminator of the version string. However, you /can/ have additional strings after the version string and before the copyright string, but the copyright string's zero byte terminates the previous string.

If there is no date in the version string, the copyright string should be "(C)year ....." not "(C) ... year" ie "(C)2012 ...." It is better to put a date in the version string, so:

The service handler does not need to save/restore X as X holds the ROM number and is immediately restored by the MOS on exit. Also, you must claim claimed calls by returning A set to zero, you must not restore it. Also, as OSBYTE and OSWORD pass their parameters in &EF/&F0/&F1 you don't even need to save/restore Y either.

As you've realised, OSBYTE less than 128 can only pass X. If you want to pass more than one byte you need to use OSWORD as all high OSBYTEs are allocated. The only spare OSBYTE is 163, but you pass an ID in X, and a parameter in Y, so that still only allows you to pass one byte of data.

On return from OSWORD you should set something in the returned control block so the calling code knows something has happened.

You MUST NOT corrupt external memory. You are trampling over language workspace here. &A8-&AF are reserved for this purpose, but you should preserve and restore them as you may be being called by some other code that is also using them.

The example code above passes the 16-bit parameter in XY+0 and XY+1 and returns a result in XY+2. This saves and restores zero page in the OSWORD handler, but if you have more service routines that use zero page workspace it's more efficient to do the save/restore in the service handler itself.

As for the actual OSWORD number, use http://beebwiki.jonripley.com/OSWORDs as a reference. OSWORDS under 128 all use a 16-byte control block, OSWORDs 128 and above use a varying length control block. It looks like for your needs a short OSWORD will be sufficient. I'd recommend &48 (72) onwards. In fact I'd recommend only a single OSWORD number, if you need additional subfunctions you should do it all through the same OSWORD, you have plenty of space in the control block to indicate the subfunction. The convention is:
XY+0 command
XY+1 result
XY+2... parameters

@jgharston

Tnx for the tips!

I think I'm going to dispense with the OSBYTE altogether, as I want to expose more functionality anyway. I should have at least an AND version of the hex drawing routine to allow "armies" to move over the map using masking.

There's also quite some screen real estate left over on the edges, so I want to have routines drawing half and quarter hexes.

For now I'm going for a high OSWORD as I think at some point I want to exchange map layouts over the tube, which will need some memory for the parameters.

I'd recommend OSWORD &B1, &B3 or &C2, but as long as it doesn't clash with a pre-existing call and you post an outline of your call so people are warned it's being used, it should be fine. People have been gradually creeping up from &B0 upwards. You can't use &E0 onwards as they go via USERV not to sideways ROMs. The conventional layout for the control block for a high OSWORD is:
XY+0 size of outgoing control block - required
XY+1 size of returned control block - required
XY+2 subfunction
XY+3 returned result
XY+4... parameters, word aligned for values, followed by any strings, eg:
XY+4/5/6/7 first parameter
XY+8/9/10/11 second parameter
XY+12/etc.

So, for instance, a command that takes a word and a string and just returns a yes/no result would be something like:

And, OSWORDs must NEVER generate errors, in the event of a fault they MUST return a failure result so the /caller/ deals with it.

That looks great, did you have anything in mind when you wrote it?

Can't beat a bit of old school hex tiles

Bandit Kings of Ancient China

Actually, I was thinking of re-designing the hex drawing routines to work with "quarter" hexes. That way it would be possible to rebuild actual maps from BKOAC (which I yet have to find) in mode 2. Mode 0 would probably look good too.

I got really sidetracked the past few months so not much progress.

Well, I guess I must kick this back to life now.

Holidays coming up in an few weeks, so I'll have to dig up my design scribbles.....

Just a suggestion ...... if you are writing the game in Basic, why not creating a HEXAROM command eg. HEXAGON par1,par2,par3,...... instead of an OSBYTE call?

Greetings
Kees