I had a somewhat similar idea for FE3, extending the CBM BASIC to show 480K free at the start-up prompt. It would at least have involved extending most internal data-structures to 24-bit address pointers (bank + 16-bit address), variables then need 8 bytes instead of 7. The string garbage collection would need a significant speed up by the use of back-descriptors, like in BASIC 3.5 and above.TLovskog wrote:I have been thinking about beeing able to use the massive (relatively seen) amount of RAM for speeding up BASIC execution, in terms of how you store variable. The goal to reduce the searching for strings etc by the BASIC. It would need ~200 KRAM to have each variable stored at a location defined directly by the first to letters, even if the strings are at maximum 255 characters. However, arrays will mess that up a bit.
Did you take a look at Waterloo BASIC? That's exactly what it does: the tokens of all new keywords are followed by a 16-bit address, the target, when the command diverts control flow. It has be thought out well enough so one can easily dispense with GOTO and GOSUB.Same BASIC as above had a JIT compiler to pre calculate and create a table of GOTO/GOSUBS etc to speed up execution. [...] And even more truth ... it wasn't that great speedup ... But if you do not test, you never know.
For the external memory blocks, you could have the external CPU inject the data from file at the right place without any assistance of the 6502.I have added some trickery in the FPGA hardware to be able to inject code into the VIC at running speed, which means that it could go down to 30-50ms for a 8k block
But with the internal memory, you surely need the 6502 have to execute code like 'LDA #byte:STA target' / 'LDA source:STA I/O_register' in an unrolled loop with that code injection to simulate DMA?
No worries.The idea with going public with projects is to have a little pressure to put some action to the words. That said. This is a hobby project with a tight budget and very loose time plan.