*EDIT*Jalecko wrote: ↑05 Sep 2020, 11:53 Ok so i figured out how that works but could it be possible to make a gt1 file that asks the promicro a list of all the available software
When you select it then the arduino could run a altered babelfish sketch that first resets the gigatron then opens the loader and then writes the requested software to ram.
I had a re-think about this and the piggy back method probably would work, the SD card loader would still need to be stored in ROM, (just like any other vCPU menu application), and it could hand off control to the normal loading mechanism once it had communicated with Babelfish as to it's intentions.
The SD card loader needs to be in ROM so that you aren't forced to upload the SD card loader through Babelfish from a host PC each time you want to query the SD card from the Gigatron. i.e. For me the entire purpose of this is to detach the Gigatron from a host and have the Gigatron be able to query and access the SD card reader itself in a stand-alone fashion, (which is what I assume you were asking for in the first place).
*EDIT*
The Gigatron is now capable of sending data to the Arduino and having Babelfish act on it to send commands to Babelfish to list and/or load .gt1 files from SD card would be doable from vCPU code; but there are a number of non trivial issues that would need to be resolved first.
TLDR: It is possible, but it would require a re-write of the current loader and it's loading mechanism and therefore a ROM firmware update; there is no place in the default memory map that a new SD card loader could be hidden that current vCPU software doesn't overwrite. The only safe place to store and execute an SD loader is in the same video ram area that the current loader is using.
The current loading mechanism works in the following way:
1) The loader, (which is vCPU code that is run from the main menu), is loaded into video ram and executed; it uses variable space from 0x30 to 0x38 and stack space from 0xC0 to 0xFF, so no vCPU code may use static data in these address ranges, (currently only Tetronis and Bricks use static data in zero page that I am aware of, but they have been modified to avoid these address ranges https://github.com/kervinck/gigatron-rom/issues/41).
2) The loader also uses a buffer within video ram for receiving Arduino data, (you can visually see the data being loaded).
3) There are a number of programs that load data directly into video ram, (i.e. static data at load time), usually images and graphics data, e.g. Pucmon disables some scanlines and uses them for code.
4) Currently all vCPU software must avoid the areas used by loader's code/data/vars, (both zero page and video ram), otherwise the loader will be potentially overwritten mid load and cause mayhem and havoc.
5) There is no area of memory other than those that I have described that is safe from vCPU code/data, i.e. current applications can and do load into every nook and cranny of the memory map. So there is no memory available to hide, store or execute a new loader.
6) The only real solution is to modify the current loader and allow it to be able to send commands to Babelfish for SD card directory listings and .gt1 files. This would require a ROM firmware update as the vCPU code for loader lives in the firmware ROM, (it is copied to video RAM and executed when you choose the loader menu option).
Using a .gt1 file, (vCPU code), as you suggest as a piggy back loader mechanism on top of the current loader would work only when the application you were trying to load did not clash with the new loader. i.e. you have to store the new loader in memory somewhere and then execute it. The problem is that there is nowhere left in memory that is safe from loaded/loading vCPU code/data.