This is an open discussion for the implementation of a BASIC programming environment, I have already produced a number of core elements that such an environment would need, (generic graphics functions, sprites, MIDI, etc), so this is more about the high level functionality required and how to shoehorn it into the current Gigatron architecture whilst remaining as backwards compatible as possible.
Any and all ideas are welcome, although if I get no feedback or purely negative feedback, then I'll just proceed on my own and do what I like
I've been thinking long and hard about this one, we currently have two different programming environments, (three if you count native low level hacking). vCPU ASM and GCL, both have their advantages and disadvantages and both have their places; but as most of you know if the Gigatron is to expand as a user programmable device for more than just the current niche, it's going to need a simpler and more familiar programming environment, (something that appeals to the type of people likely to be attracted to the Gigatron in the first place).
Enter left of stage: BASIC; so how do we go about integrating a yesteryear semi-high level language within the limitations of the current Gigatron architecture?
My pragmatic engineering self would say that a traditional tokenised interpreter, (even the most modest toy), would be impossible to create without rewriting a huge chunk of the current ROM, and still have room left over for user programs and data. But before we get into detailed design, lets discuss what we actually want from a BASIC programming environment:
Functional Specification:
1) Keyboard entry, editing and simple source code execution; (obviously this requires the hardware and firmware for keyboard entry to become available first, lets assume that is a given): I would rate this 9/10 on an importance scale.
2) Backwards compatibility with current code base and programming environment, 8.5/10.
3) Large range of inbuilt functional keywords handling audio/music/graphics/sprites/text/data in a similar if not better way to traditional BASIC's, 8/10.
4) Modern version of BASIC with optional line numbers, procedures and structured loops/expressions/conditionals, (object orientated is out of the question), 7/10.
5) Offline editing and compiling for those who don't want to use the actual device for source code generation, 6/10.
6) Backwards compatibility with current ROM, 5/10 and I personally think impossible, (unless you limit yourself to 4-5 keywords and printing hello world is your goal).
7) Fixed point/Floating point calculations, my current inclination is to implement a mutation, whereby the user thinks they have full floating point calculations but it is implemented internally as a fixed point int16.fract16 format, (to provide reasonable range, precision and speed), 5/10.
8) Compatible with 64K of RAM, 5/10, (should be trivial).
9) Able to use inline vCPU ASM, 4/10, (may be possible depending on implementation).
Detailed Design:
1) Implement as GCL or vCPU code that runs on current version of ROM:
- impossible to produce anything of a substantial nature that leaves anything more than a few bytes for user code.
- would be a toy in terms of functionality and usability.
- 100% compatible with current architecture and ROM.
- no requirement to burn any data to ROM.
- the simplest approach to implement.
- e.g. "Gigatron Basic ver0.666 Bytes Free: 11"
2) Implement as GCL or vCPU code that runs on current version of ROM with SYS functions providing the bulk of processing and functionality burnt into the unused areas of ROM, (hires images):
- possible for a compiled environment, an offline compiler would compile your code directly to vCPU ASM and SYS calls, (for graphics, sound, etc).
- probably impossible for an interpreted environment, unless "Bytes Free: 11" is your goal, as the interpreter would need to live within RAM as a pre-loaded GCL or vCPU ASM module, leaving little to no room for user code.
- could provide good functionality and usability, (as an offline compiler).
- %100 compatible with current architecture and ROM, apart from having to burn SYS functionality into unused areas of ROM.
- requires new data to be burnt to unused areas of ROM.
- estimated few weeks of work to implement a usable demo.
- e.g. "Gigatron Basic ver0.666 Bytes Free: 4566"
3) Implement as native code supplementing or replacing, (most likely replacing), the current vCPU interpreter; the bit banging architecture would also need to be rebuilt from scratch.
- should allow a fully interactive online and offline interpreted and/or compiled environment.
- would provide as much functionality as the limits of ROM could afford.
- maximum space available for user code.
- requires a complete erase and re-write of ROM.
- 0% compatible with current ROM and current code base, (you would effectively have two different ROMS to choose from), one for vCPU ASM/GCL and another for BASIC.
- estimated few/many months/never until completion.
- the most difficult approach to implement, (by orders of magnitude), once the interpreter is done, you then need to interleave the bit banging for the video and audio within/around it.
- e.g. "Gigatron Basic ver0.666 Bytes Free: in your dreams"
These are my current thoughts.
) 
).