BASIC

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

BASIC

Post by at67 »

This is long and there is no TL;DR that would do it justice, so if you're not in the mood, best to just ignore it.

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 :twisted:

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.
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: BASIC

Post by monsonite »

Hi at67,

Firstly, thank you for opening up the discussion regarding a BASIC for Gigatron.

For many of us, traditional BASIC - with line numbers, was our first introduction to computers and programming - about 35 to 40 years ago.

Having the Gigatron boot to a ROM based BASIC, would be a major boost to the user experience, and would be perfectly in keeping with the mid/late 1970's nostalgic appeal of this project.

If I remember correctly, some of the early BASICS started out at about 4k bytes of code, and were later extended with additional functions such as floating point math, graphics and sound to 8K or 16K bytes.

One way to approach this would be to produce a new version of the ROM, that maintains the vCPU and GPL compatibility - but sacrifices the pre-loaded images and game storage area of ROM to hold the BASIC interpreter.

Having switchable ROMS on a small adaptor board would be one possibility.

I am hoping that a standardised keyboard interface will appear in due course - a simple dongle/adaptor with ATtiny or similar that converts a PS/2 keyboard format into the serial protocol required by the 9 way D-type Gigatron port.

Marcel's demonstration of "TV Typewriter" is certainly one of the building blocks needed en-route to having a screen editor, monitor program etc, needed to support the BASIC interpreter.

There are other interpreted languages, for example FORTH, that have small ROM footprint and could possibly be used to give the Gigatron a stand-alone programming environment. So as not to dilute this discussion - I'll raise these in another topic.


regards


Ken
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: BASIC

Post by marcelk »

A first BASIC can get away with skipping quite a lot of functionality:
  • Floating point
  • Multi-character variable names
  • Arrays
  • Correct precedences for infix expressions
  • String variables or operations (the Hackaday BASIC batch also doesn't do them)
  • Full screen editing (just do with a line editor at the bottom of the screen)
Space-wise I'm less concerned. BASIC will not be a pure vCPU application that you have to load first, it must be embedded to be meaningful. We can drop some, or all, built-in pictures (they are a ROM filler anyway). During operation not every part of BASIC has to reside in RAM at the same time. The ROM loader (SYS_Exec_88) can swap-in the appropriate sections at the right time:
  1. Line edit
  2. Tokenising (perhaps the lines can be stored as stylised vCPU code...)
  3. RUN (if the tokenised code can indeed be vCPU compatible, this one is trivial)
  4. LIST (if the tokenised code can indeed be vCPU compatible, this will have to be some decompiler)
  5. SAVE (whatever that may do. Display a QR code with the program in it? Beeping the program?)
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: BASIC

Post by at67 »

Good ideas from both of you, I won't respond in detail to them as they are all related mostly to the interpreter; I'll share where my thoughts are on the interpreter down below.

Another idea I had was to forget about the interpreter completely and write a compiler completely in native code; how would this resolve the issue of having to re-write the bit-banging architecture? Turn off the display while the inbuilt native ROM code compiles your BASIC code to vCPU code.

Pros:
- Completely compatible with current programming environment.
- Compatible with current ROM architecture, only unused areas of ROM need to be upgraded.
- Would allow old school coding/editing in crazy low res font with a direct keyboard.
- Doable in a reasonable amount of time, it's much easier to write a BASIC compiler without having to worry about the bit banging.
- The compiler can be written completely in native code, without having to write partial vCPU/SYS code to keep the display running.

Cons:
- Screen goes black whenever you do a compile, (some monitors take forever to re-sync when losing signals and some even shut themselves down after only a few seconds of no sync signals).
- Lose the ability to interactively try BASIC code at a prompt, (although there may be ways around this, i.e. single line compiles).
- Error handling and logging is not trivial, especially if you are waiting for your display to re-sync.
- Did I mention how annoying losing sync and having to re-sync your monitor is, (possible solution may be to just bit-bang the sync signals and output a constant low voltage for intensity whilst compiling to not lose sync).
- Not a great use of available RAM, RAM would be split between the tokenised BASIC input and the resultant compiled vCPU output; the 32K Gigatron has 12,782 bytes free not counting page zero or the 160x120 display itself, (45550 for a 64K system).
- A non trivial amount of native code needs to be written.

Interpreter:
I like the idea of page swapping in and out functionality of the interpreter/editor as required, I also like the idea of tokenising into vCPU CALL's and SYS's.

My problem with the inbuilt interpreter and the inbuilt compiler that I described above is that I just can't visualise a scenario where BASIC is anything but a toy. e.g. to shoe horn editing/interpreter/compiler into ROM and RAM, you will always be making huge trade-offs to the functionality of the language itself, i.e. dropping fixed/floating point, graphics/sound, etc. Now I could probably live with this as a starting point if the code to do this was reasonable, but my other problem is, that I don't think it is...I would guess it's at least a solid month of work, for a risky outcome, i.e. a language that will not only not provide the current feature set we have with GCl and vCPU ASM, but not even come close.

So what I have decided to do over the next week or so, whilst this discussion continues, (I am quite willing to be proven wrong on any points that I have made and be made to realise that it's nowhere near as difficult as I think it is; relative to the result), is continue with an offline BASIC compiler which I have already started.

This offline BASIC compiler workflow will work exactly the same way as compiling for GCL or vCPU ASM does now, (I will probably compile to vCPU ASM and then use the assembler to assemble that code), i.e. edit your code in your favourite editor on your PC, compile/assemble it at a command prompt into a .gt1 file and then upload it to your Gigatron.

The offline compiler will create vCPU code that gets downloaded directly into RAM, there will be no sharing of RAM with tokenised BASIC code or page swapped BASIC editor/interpreter/compiler code. It will also have access to a decent library of SYS calls providing functionality for graphics/sound/midi/sprites, etc. The only drawback is that the SYS calls will need to be burnt into the unused areas of ROM, (which is not difficult and pretty much a requirement of any these BASIC implementations).

The documents I am going to use to choose syntax and functionality are described here:
http://buraphakit.sourceforge.net/ECMA-55.TXT.LPR
https://en.wikipedia.org/wiki/Atari_BASIC
https://www.c64-wiki.com/wiki/C64-Commands

How the language evolves is completely open to suggestion; even though I already have many concrete ideas, I'd prefer to have the language defined as a community, rather than one guy's personal preferences.

Once the offline compiler is out of the way and we have a concrete understanding of it's features and limitations, revisiting the inbuilt editor/interpreter/compiler is the next step IMHO.

I'll post a draft of what I think would make a good starting point, in terms of syntax and functionality.
Marko
Posts: 8
Joined: 24 May 2018, 19:48

Re: BASIC

Post by Marko »

My thoughts, FWIW...

I think the choice of how the BASIC is implemented is pretty crucial, and that really depends on what we're trying to achieve. I love the idea of being able to boot the G and start running BASIC programs, or issuing BASIC commands in immediate mode. It's just what the early machines in the late 70s/80s did, and it would be a great way to demonstrate an "Alternative" way things could have evolved on the hardware architecture front.

But for me, that's a goal a long way down the road. I appreciate the complexity of trying to squeeze even a minimal BASIC into the ROM, while leaving enough useable RAM for program (and sprites and music and and... :) )

If the goal is to try to get more people hacking the unit, with a higher-level (or even just more easily useable) language, then I like the idea of compiling on the Mac/PC and uploading to the G.

One could even use a game port Arduino as flash memory - when the G boots up, the Arduino can take control like the current loader app and fire the compiled gt1 into memory. Store different apps on each Arduino and they essentially become like ROM cartridges.

Again, it goes back to what people want to do with the unit. For me, I think it's more important to let people get code running on it, and the easiest way to do that is for an external compiler.

Marko
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: BASIC

Post by monsonite »

For inspiration today, I chose to read up on the Tiny BASICs that appeared for various microprocessors around 1976 - when both ROM and RAM were very limited in size.

Tom Pittman's Tiny BASIC was produced for 6502 and 6800 and 1802 microprocessors.

He was able to do this multi-target approach fairly readily because he based the BASIC interpreter on a 16-bit virtual machine, which could be ported fairly easily between the various mpu, despite different instruction sets and architectures.

Like the Gigatron vCPU, Pittman's virtual machine had nearly 50 instructions, coded in native assembly language, which were tailored towards the task requirments of interpreting lines of text containing numbers, variables and operators.

The opcodes of the virtual machine combined together would give a "bytecode" listing of about 220 high level instructions that implemented the Tiny BASIC interpreter.

A reasonably well commented listing is here -

http://www.ittybittycomputers.com/IttyB ... B_6800.asm

Using this method, Tiny BASIC could be coded into about 2300 bytes of 6800 or 6502 assembly language.

Wikipedia describes the virtual machine implementation here:

https://en.wikipedia.org/wiki/Tiny_BASI ... al_machine

Full documentation of Pittman's Interpreter - plus an assembler written in Tiny BASIC is here

http://ittybittycomputers.com/IttyBitty ... c/TBEK.txt

What makes this interesting is that this approach is similar to the methods used already to implement the vCPU - and might provide a logical extension to the existing vCPU instruction set.

As stated the instruction set of the virtual machine are tailored towards text handling operations and decision making, and these would be applicable to any program intended to handling text input and display. This would include the likes of a monitor program for displaying and editing the contents of RAM.

The Tiny BASIC core in asm - plus the virtual machine/interpreter could be placed into ROM - thus having minimum impact on the RAM, which would be used to hold the BASIC listing and the editor screen image.

The functions provided by Tiny BASIC could always be extended to include further commands for graphics and sound - as when Tiny BASIC was written, it only expected a teletype or terminal for character input and output.

I suspect that the limitations of the 26 character x 15 line screen, will limit what can be achieved with a self-hosted screen editor for program listing. However there is no reason why the Arduino loader could not be used to send an ascii text file - for loading more complex BASIC programs.

Ken
Last edited by monsonite on 06 Jun 2018, 13:43, edited 2 times in total.
Cwiiis
Posts: 27
Joined: 14 May 2018, 09:04

Re: BASIC

Post by Cwiiis »

I don't have strong feelings about implementation details, but I think the priorities of a BASIC implementation might be important. I really see BASIC as being cool for people building and booting the machine for the first time to play around and experiment, but not useful for creating high-performance applications. Much like it was on older computers, really.

This leads me to think that an offline compiler is an odd choice - if you were writing a high-performance game, is BASIC so much easier to understand that you'd pick it over straight-up vASM/GCL? And let's say it is (which I think would be a reasonable thing to say), if you could pick the language, would you really pick BASIC? It seems like an odd choice if you're writing a compiler, I'd have thought either C or a derivative subset would be much nicer.

That said, some extra system functions for sprites and such would be really great. I'd really like palette-based sprite and tile drawing, for example - given the limited memory, it's a bit of a burdern having even 6bpp - if you had a 4-colour palette, you could use a third of that storage space, for example, and likely not lose much freedom of expression.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: BASIC

Post by marcelk »

These are my current thoughts.
It pays to think this through while at some point building blocks will also just emerge. There is room for multiple developments. I just found back some of our notes of just one year ago, and can only smile of what we were concerned with back then.

One point of view is the feedback from many potential buyers saying that they really need some embedded BASIC to justify buying a kit, because you must be able to "do" something with it when it is built (and sometimes just "show some family member that you can do something with it"). Ok, us calling it a "microcomputer" somewhat automatically leads to this expectation, nostra culpa, but I can fully emphasise with that: despite the Loader, the system is still a bit of a closed system and that could be better. Even a toy BASIC is good enough to let you really interact and do simple things without fooling around configuring external stuff first. It is the hooking up to an external device (not everyone is familiar with that) AND the off-line programming that is a too-big burden for many at this point. And for this purpose an it should also be a BASIC, not a GCL or a FORTH, because of the familiarity. (We can have more than 1 of course. The EPROM is huge.)

We might have to think about storage of programs you typed in, but not too much. I don't see the need for a full development environment as the 8-Bit Guy seems to aspire. (I believe he actually developed Planet X2 on the target C64.) I would never do such a thing myself anymore. Back in the day we had no choice, but today we have better means of doing "real" development. And for offline development I wouldn't use BASIC, but look at C, FORTH, Pascal, etc.

I'm flabbergasted about how small Tiny BASIC is, thanks for the links! It is even small enough to be transcribed... At one point in time we might do this ourselves anyway (but first we must have forgotten how much time we've sunk into this project already ;) ).

One more thing about interpreter implementation: vCPU doesn't need to have a monopoly on machine cycles. I can imagine other interpreters living next to it, and let the video loop decide which one is active at a given time. The vCPU's ENTER address is now hard-coded as operands, but it could just as well come out of a zero-page variable.
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: BASIC

Post by monsonite »

More information about the origins and operation of the Tiny BASIC Interpretive Language (IL) as first defined by Dennis Allison in 1975

http://troypress.com/the-tiny-basic-int ... nd-onions/

and from Tom Pittman in 2006

http://www.drdobbs.com/web-development/ ... /184406381


Ken
emulix
Posts: 3
Joined: 05 Jun 2018, 23:56

Re: BASIC

Post by emulix »

Hello,

could it be possible to add a cartridge on the ROM socket? This cartridge would contains two ou three software switchable ROMs. then the size of the BASIC would not be a problem.
Post Reply