Add new VDP command to generate a random number

[rewk]

It would be nice to get an hardware generated number provided by the VDP.

That would use https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/random.html

I don't know how it should be implemented in the MOS, though.

[breakintoprogram]

Hi, could you give me a specific use-case scenario for this?

[rewk]

This was from a Discord discussion. It appeared that having a good source of random numbers would be useful in game development.

It was a topic around this message: https://discord.com/channels/1080130527908069467/1080274292622762085/1100057158520938517

[HeathenUK]

The main use case that comes to mind for me is in simple AI mobile pathing. That said, in C and ASM we can probably generate a reasonable pseudo-random number locally on the ez80...

[stevesims]

so as I see it, generating random numbers for use inside your game code is something that's best done ez80 side, as @HeathenUK says.

a VDP command that generate a random number and sends it back to the ez80 would be rather slow and inefficient, purely in terms of the comms delays, and we should be able to do a good enough job purely on the ez80 side.

having said that, with the addition of the buffered commands API the situation has changed a bit. it is now possible to run logic on the VDP side.

there are already enough commands as part of that API to implement a rudimentary random number generator on the VDP.

the buffered commands API however is not necessarily fixed in stone :D and there is the possibility to extend it's current functionality. specifically the "adjust" operator could be extended. see AgonConsole8/agon-vdp#52

[breakintoprogram]

@stevesims maybe a happy compromise would be to use the ESP32 random number generator to provide a seed for the eZ80 (read BBC BASIC) random number generator.

[stevesims]

@breakintoprogram yep. :grin:

I expect I'll add some extensions to the buffered commands API soonish - it's currently fairly capable, but a few enhancements could quite greatly up it's utility. there's also potential to open up a whole load of fun things by integrating these buffers with the bitmap system.

adding in an ability to read data out from buffers on the VDP and send them over to the ez80 could be a cool addition and that could provide a mechanism for exposing a VDP-based random number generator back to the eZ80.

one related I had thought of putting in the buffered commands API docs was to block out a chunk of buffer IDs to reserve them for OS usage for exactly this kind of thing. thinking about it, using buffered commands is potentially a way to help implement ENVELOPE support in BASIC (once there's a more sophisticated volume envelope type available that can do Acorn's funkier ADSR thing). the difficulty in implementing ENVELOPE is mostly around Acorn applying envelopes to individual notes, whereas the system I implemented applies envelopes to channels - some short VDP-side functions may help with that.

blocking out buffer IDs wouldn't have any actual restrictions - it'd just be a documentation thing - a "please don't use these numbers" so we have a "safe" range of IDs we can use for command sequences and buffers, should we decide we ever want to use them in MOS or BASIC (or some other "OS" piece). "assigning" 256 IDs to MOS, and another 256 IDs to BASIC still leaves the user with over 65000 IDs to play with.