Comments (7)
This opens up really interesting possibilities, but you need to somehow define the plugin ABI for the downloaded code, so it can do useful things.
- To what resources of the VDP should the downloaded code have access? Should it be able to call functions in in the VDP? It should have access to the buffers where graphics data are stored and it should have access to the audio output.
- How will the downloaded code be invoked?
- How will the downloaded code communicate with the eZ80? This can possibly be done via buffer that the eZ80 can read and write via a VDU command.
- If the downloaded code ends up in dynamically allocated memory, how will it be relocatable or position independent?
It will invoke a lot of design and prototyping before it is ready for release.
from agon-vdp.
Absolutely, some set of expectations would need to be set, or else unassuming code might simply take the ESP32 off in its own direction and the VDP code might either not run at all, or have its data structured stomped on.
My thinking was that the MVP would not have access to the VDP’s functionality directly—that could be added step-by-step when it proves useful. Rather, it would essentially just be a compute API. Later on, a specific API would have to be made for things like manipulating VDP graphics.
For the invocation, it could follow some standard function prototype where it is passed certain information. This could include things like a memory range which it is allowed to use. It would have to be a sort of cooperative multitasking system, where the code is allowed to save state in between invocations, and each invocation is a time slice where it is allowed to run.
For communication, some sort of VDU command like you suggested makes sense to me. Just a raw byte stream that gets ignored by the VDP and forwarded to the specific ESP32 program. A port number could be included to disambiguate, similar to a TCP packet.
Relocating code is definitely a bit tricky. I don’t know if something as fancy as an ELF loader is necessary.
from agon-vdp.
Machine code has to live in flash or in IRAM, a specific area of RAM. I don't know how much of IRAM is already in use by FabGL. In any case we need a specific buffer allocator for machine code
from agon-vdp.
IMHO allowing arbitrary code to run directly on the VDP is not something we should look to add.
This would be a major security issue, and have the potential to allow errant code to brick people's machines.
I see two more practical alternatives.
The first would be to add the ability to store VDU byte streams on the VDP and allow them to effectively be called as functions. This would need just two new commands added to the VDP, one to "store function" and another to "call function".
This approach would obviously be rather limited, but would potentially still be useful. The obvious limitation is VDU commands are a simple byte stream with no flow control possible, and no variables. The lack of variables could potentially be addressed by including a command(s) to alter bytes within a stored function. (Overwrite byte, increment/decrement byte, etc.).
Another alternative would be to add support for a rudimentary programming language to the VDP. Forth would be a good candidate, as it's very light weight and should be fairly easy to implement.
Implementing Forth on the VDP would be an interesting companion to the z80-based Forth interpreter you produced @lennart-benschop 😁
from agon-vdp.
Such Forth for ESP32 already exists: https://esp32.arduino-forth.com/
from agon-vdp.
the VDP now has a "buffered commands API". see #97
this implements all of the rough ideas I outlined in my earlier comment about repayable VDU byte streams, and extends that idea further.
those enhancements were written in such a way as to potentially allow for other language interpreters to be run on the VDP, such as Forth or Lua. the VDU system essentially has become a stream processor, so a language could use it as an I/O stream. before this work was done @astralaster had already experimented with integrating a Lua interpreter, and it's possible that work could be revisited at some point in the future.
the "buffered commands API" goes a long way to providing the functionality that @Serentty originally suggested, in terms of sending graphics programs over the serial link. what is missing from it right now from that request is the likes of callbacks and running a routine every frame.
I have some ideas about how to add that functionality, but it is likely that some other enhancements to the buffered commands API will come first. specifically in this area, and in line with other parts of this general discussion, ways to integrate the buffered commands API and the bitmap/sprite API are being considered and discussed.
for now, "running a routine every frame" can be achieved via sending a VDU command from the ez80 every frame to call a command buffer
from agon-vdp.
Using Forth and Lua is a good idea, the original goal is just to get the ESP32 to run code, the method is not that important.
This should be done in a way were the number of languages could be expanded.
from agon-vdp.
Related Issues (20)
- Documentation for new screen modes added in VDP 1.03RC2 HOT 1
- Make vertical timing of 640x240 modes the same as 320x240 modes HOT 1
- VDU to get a keycode HOT 2
- Documentation for virtual keycodes
- [Feature request] a VDU command to change only a byte in a bitmap, and some other stuffs HOT 1
- vdu 25,80,x;y; do wrong triangles HOT 8
- PRINT TAB() should be relative to text viewport. HOT 1
- Feature Request: the ability to copy from screen/buffer to current bitmap HOT 3
- Help wanted - How to get audio status (audio command 1) ? HOT 5
- VDP crash on real Agon but not on the emulator sending bitmaps data HOT 2
- PLOT 69 does not set the current position. HOT 1
- Key up events rollover HOT 1
- Feature Request: class ProxyWaveformGenerator : public WaveformGenerator HOT 2
- Circle terminal position is incorrect. HOT 3
- [bug] Issue with equal/plus key on French keyboard HOT 2
- When using double-buffered modes, keyboard input is not visible HOT 3
- Feature request: Changing video modes should preserver colour scheme HOT 2
- Feature request: expose the selected FG/BG colours HOT 5
- Agon locks up when POS and/or VPOS is used with VDU 31 HOT 2
- Leave firmware to Steve.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from agon-vdp.