3D VDU commands not registered with mdfs.net

[rtrussell]

As far as I can see, the proposed 3D VDU commands haven't been registered at Jonathan Harston's site. Jonathan coordinates extensions to VDU etc. to ensure that they don't result in any compatibility issues.

[stevesims]

hi @rtrussell - thanks for the comment

to be honest, I hadn't thought to register for an account and make edits to add in Agon's extensions to the VDU system.

in the currently released versions of the VDP, most of Agon's extensions sit under VDU 23,0 with higher-value register numbers (over &80) as per the suggestion given on Jonathan's site. this mechanism lets much of the Agon VDP system work, given the Agon's rather unique architecture - for instance, the audio system is managed using a whole mass of commands under VDU 23,0,&85. as there are no similar extensions documented for other platforms it feels like it probably wouldn't be appropriate to add all of these commands to Jonathan's site - perhaps it might be appropriate to just add in a link to the Agon VDP documentation.

(of minor note here is that the Agon VDP's VDU 23 system does not use fixed-length commands - they are all variable length.)

there are only three extensions that the Agon has to the VDU command set that I can think of that sit outside of VDU 23,0

firstly Agon has a more extensive set of commands for bitmaps/sprites - these sit under VDU 23,27. unfortunately the original author of these commands did not quite follow the way that Acorn's "sprite" API had worked - although that has now mostly been resolved. the extended commands would probably not be appropriate to add to Jonathan's documentation, although a link to the Agon documentation for them might make sense

secondly is support for a "fill path" PLOT command. this is implemented in the plot code range of &D8-&DF. this is a block documented as "reserved" - which felt like it was probably OK to use, since Acorn aren't going to be using it. 😁 I implemented this feature in such a way that felt to me to be sympathetic with the rest of the PLOT system, although it is not something I would expect to see implemented elsewhere

thirdly there is a feature called "hexload" that uses VDU 23,28 which is used to facilitate transferring programs from a computer attached to the VDP's USB serial port to the eZ80. (in hindsight I would have placed that command under VDU 23,0, but that ship has sailed - this feature was integrated before these console8 VDP releases.)

as of right now the 3D VDU commands are very much in the experimental phase. they currently are implemented with a set of commands under the Agon's "buffered commands API" (VDU 23,0,&A0), and have not appeared in any official release. the commands for performing 3d drawing probably should be moved to a different command block under VDU 23,0 if/when it becomes part of a release. some might argue that this feature could use VDU 23,29 - but as it relies on Agon-specific features that probably isn't appropriate

the "buffered commands API" is a unique feature of the Agon VDP system - it provides a mechanism for storing and managing blocks of data in memory attached to the VDP. given the Agon's architecture where there is no shared memory between the VDP and the main CPU, and all commands/data has to be transferred to the VDP over a serial link, this is necessary for many features. buffers are used on the VDP for storing all sorts of data, such as stored sequences of VDU commands, bitmaps, sound samples, and fonts. the experimental 3d graphics system uses buffers for its models. this approach isn't necessary on other platforms

[rtrussell]

(of minor note here is that the Agon VDP's VDU 23 system does not use fixed-length commands - they are all variable length.)

It isn't of "minor note", it isn't allowed! If you think about it, it can't be: you have chosen previously 'unused' VDU codes so that your VDU stream will be ignored (treated as a no-op) by all existing decoders, but they will assume a VDU 23 command is 10 bytes long (they all are) and treat the 11th byte as the start of a new command!

So unless you have been careful to ensure that your 'variable length' commands appear to a decoder as a sequence of valid fixed-length commands, the whole exercise of choosing 'unused' codes has achieved nothing, because only the first ten bytes of a variable-length VDU 23 command meet that criterion. :-(

To implement 'variable length' commands what you would need to do is 'packetise' them as a sequence of individual VDU 23 commands, each 10 bytes long, with perhaps a bit used to signify 'first' or 'not first' in the sequence. This is exactly the kind of thing that Jonathan would have alerted you to had you consulted him at the start.

secondly is support for a "fill path" PLOT command. this is implemented in the plot code range of &D8-&DF. this is a block documented as "reserved" - which felt like it was probably OK to use, since Acorn aren't going to be using it. 😁

Acorn won't be using it, but I might well be for my BASICs and so might Michael McConnell for use in Matrix Brandy (indeed I think we both have requested and received new allocations of PLOT codes). That's precisely why there has to be a central repository of such allocations, so that the various ongoing - I won't say competing - developments in BBC BASIC don't accidentally tread on each others toes when allocating new PLOT codes.

as of right now the 3D VDU commands are very much in the experimental phase.

Which is good, because you've got quite a lot of work to do to bring them into line with conventions that have been established for more than 40 years, to no small degree because of Jonathan's rôle in maintaining the beebwiki.

[stevesims]

Whilst I appreciate that strictly speaking variable length VDU 23 commands are not allowed, that ship has sailed. This was a decision taken long before I got involved in the project, and has been a reality of the Agon platform for at least the past 18 months.

Fixing VDU 23 would result in almost all non-trivial Agon programs breaking.

Even if this somehow could be fixed, doing so within the constraints would result in serious performance degradation. The Agon only has a practical link speed to its VDP of under 750kbit/second, so every byte counts. (This is under 1500 bytes per frame.) Adding in extra zero bytes to pad out short commands, and extra bytes for packetising longer commands would have a major impact - possibly as much as 25%, depending on the application. Some of the more advanced Agon programs we have wouldn’t be practical, or in some cases even work, with that penalty.

If I were to release firmware that made the Agon’s VDU 23 work “correctly” hardly anyone would install it, and it would be the death knell of this firmware branch.

I can’t really see this incompatibility as a big issue. It just means that programs written for the Agon that use these VDU commands can’t be run on other versions of BBC BASIC. They can’t be run anyway and I would not expect any other version of BBC BASIC to want to implement any of Agon’s rather esoteric VDU 23 command set. There are better, easier, and more effective ways of providing equivalent functionality on other platforms, and a significant proportion of Agon’s commands just wouldn’t be relevant.

As for the new PLOT codes, I did check beebwiki and the documentation for your versions of BASIC before picking the codes I used. Currently the “implementation“ list on beebwiki does not list any PLOT codes beyond those in RISC OS.

I wasn’t aware that there was a way to request plot codes as this is not mentioned on the beebwiki site for VDU 25. Could you please let me know what the procedure is to do this?

[rtrussell]

Whilst I appreciate that strictly speaking variable length VDU 23 commands are not allowed, that ship has sailed.

Nobody can force you to comply with pre-existing standards, but unless your VDU stream is fully compatible with the long-established conventions there is no point in it having any compatibility at all. You might as well start completely from scratch with a completely different encoding.

After all, within your 'variable length' VDU 23 sequences you are effectively embedding completely non-standard VDU commands anyway, because the 11th byte in each sequence is the start of a new command. If by that point you're sending 'binary' data it could be anything.

Even if this somehow could be fixed, doing so within the constraints would result in serious performance degradation.

Splitting variable-length commands into 10-byte 'packets', each of which is a 'valid' VDU 23 command, only 'wastes' two bytes out of every 10. For example you could request that VDU 23,20 and VDU 23,21 - which are currently unused codes - be allocated to Agon as 'first packet of a group' and 'second or subsequent packet of a group' respectively. Then each packet has a 'payload' of 8 data bytes, an overhead of 25%.

I would not expect any other version of BBC BASIC to want to implement any of Agon’s rather esoteric VDU 23 command set.

On the contrary, because my versions of BBC BASIC do fully support 3D rendering (Direct3D in the case of BBC BASIC for Windows and OpenGL in the case of BBC BASIC for SDL 2.0) I was indeed going to investigate the possibility of providing some compatibility with the Agon.

There is a degree of elegance in encoding 3D commands into the VDU stream, both from a performance perspective (it makes sharing the processing load between multiple cores or CPUs easier) and when mixing 3D rendering with, for example, textual output which I currently can't do at all.

I wasn’t aware that there was a way to request plot codes as this is not mentioned on the beebwiki site for VDU 25. Could you please let me know what the procedure is to do this?

It's a Wiki: you can edit, as well as read, its contents! So the procedure is to register with the Wiki so you can make the changes you propose (preferably in draft form, unless they're trivial like fixing a typo). If you're unsure of exactly what change you want to propose you can use the Talk pages to discuss it.