<2kbyte 6502 Tiny Basic?

[VinCBR900]

Hi,
I spent a while searching and couldn’t find an answer- was there ever a 2k yet tiny basic that would fit into a 2716 including serial Comms routines?

Tom Pittman IL basic seem to have been about 2.5k, and Apple integer basic is 4kbyte as far as I can tell.

I’m looking to make a minimal toy tiny basic system using period part specs.

Cheers, Vincent

[floobydust]

Try this as s starting point:

TinyBasic.ASM

(35.16 KiB) Downloaded 257 times

[barrym95838]

It might be possible. VTLC02 is 16-bit unsigned integer only, and has single-character "keywords", so it's not a valid drop-in replacement for BASIC, but it fits in 961 bytes and gradually shrinking, although the serial IN/OUT and SAVE/LOAD are not included in that total. I have a 959-byte version that hasn't been properly tested yet, and a base version without the "bonus" system variables @ and <, and the "bonus" operators [, ], &, |, and ^ would be about 100 bytes smaller.

[VinCBR900]

Somewhat related, There is Oscar Toledo’s bootbasic intended for 8086 which fits in 512k, but it uses string ops and doc/mul instructions.

https://github.com/nanochess/bootBASIC

But my 6502 is not strong enough to port efficiently

[BillO]

floobydust wrote:

Try this as s starting point:

TinyBasic.ASM

Good lord. Blast from the past. I had meant to tidy that up, but a butt load of stuff has happened between then and now.

I did that version to run on a 6507, but I had the decadent luxury of 4K of ram.

[floobydust]

BillO wrote:

floobydust wrote:

Try this as s starting point:

TinyBasic.ASM

Good lord. Blast from the past. I had meant to tidy that up, but a butt load of stuff has happened between then and now.

I did that version to run on a 6507, but I had the decadent luxury of 4K of ram.

I was wondering if that was you.... in fact, I can't remember where I downloaded it from... it was buried in a directory structure that's been moved between a few different systems over the years as I've built new desktop workstation machines. I haven't tried to assemble it yet, so no idea on the code size.

[Michael]

The v0.2.2 (2011/11/11) LST file I have suggests it's $8000..$88C9 (2250 bytes) with additional serial code and vectors in the $F800..$FFFF range. Does that sound right, Bill?

[BillO]

Michael wrote:

The v0.2.2 (2011/11/11) LST file I have suggests it's $8000..$88C9 (2250 bytes) with additional serial code and vectors in the $F800..$FFFF range. Does that sound right, Bill?

It does.

The only vector I set up was the reset vector.

I need to correct my earlier statement. My original version was written for a 6507 with a 6551 ACIA. This particular version was configured for a modified version of Grant Searle's original 6502 system and has code for a 6850 ACIA.

[BigDumbDinosaur]

floobydust wrote:

Try this as s starting point...

Arggh!!! That source file is full of hard-coded zero page addresses. Why do people do that???

[VinCBR900]

BigDumbDinosaur wrote:

floobydust wrote:

Try this as s starting point...

Arggh!!! That source file is full of hard-coded zero page addresses. Why do people do that???

I think its because it is reverse engineering of Tom Pittman's Tiny Basic as he did not distribute the source. This uses an Intermediate Language approach, and I was wondering if there was a direct form of Tiny BASIC for the 6502 that may have been smaller. For example, Dr Chen's Palo Alto Tiny Basic for the 8080 did not use an IL and fitted within 2kbytes.

[BillO]

VinCBR900 wrote:

I think its because it is reverse engineering of Tom Pittman's Tiny Basic as he did not distribute the source. This uses an Intermediate Language approach, and I was wondering if there was a direct form of Tiny BASIC for the 6502 that may have been smaller. For example, Dr Chen's Palo Alto Tiny Basic for the 8080 did not use an IL and fitted within 2kbytes.

This is correct.

I found a version of the binary for the (expanded) KIM-1 in Motorola Hex format and disassembled that. As you see it there, it was still a early work in progress. At that point I was still trying to do the basic functionality reverse engineering and commenting it. The hardcoded addresses into page zero were on the list. They were not a priority for me to just get it up and going, make it relocatable and understand exactly how it worked. I was getting there though .. bit by bit.

Another thing on my list was to make it smaller, if I could ... and bigger by adding functionality. But I needed to understand how every tiny bit of it worked first.


BTW, I think the original 6800 version is smaller. Fun fact.

[barrym95838]

BillO wrote:

BTW, I think the original 6800 version is smaller. Fun fact.

I believe it. The 6800's 16-bit LDX, STX, INX, DEX and CPX instructions are a big help, at least when you're dealing with a lot of 16-bit objects. That's why I started a 65c802 version of VTL02, but I quickly caught a case of the REP#/SEP# blues and back-burnered it.

[barrym95838]

VinCBR900 wrote:

For example, Dr Chen's Palo Alto Tiny Basic for the 8080 did not use an IL and fitted within 2kbytes.

I'm pretty sure that one is the basis for TRS-80 Level 1 BASIC, the first BASIC I learned. They converted all math to 32-bit floats, added a few screen control and tape control features, and shipped it. I haven't studied the disassembly of Level 1 BASIC in depth (x80 assembly language gives me a headache), but I'm rather confident that the source code listings share a bunch of similarities.

[BigDumbDinosaur]

barrym95838 wrote:

BillO wrote:

BTW, I think the original 6800 version is smaller. Fun fact.

I believe it. The 6800's 16-bit LDX, STX, INX, DEX and CPX instructions are a big help, at least when you're dealing with a lot of 16-bit objects. That's why I started a 65c802 version of VTL02, but I quickly caught a case of the REP#/SEP# blues and back-burnered it.

If you got the “REP#/SEP# blues” you were going about it all wrong. The 65C816 or 65C802 in native mode is a totally different beast than a 65C02 and requires a fundamentally different mindset in order to make best use of it.

I’ve written tens of thousands of lines of 816 code and have never gotten to where I felt I was getting bogged down with REP and SEP. To the contrary, I usually find myself being somewhat sparing with register size changes. In many cases, mainline code starts by setting the accumulator to 16 bits, setting the index registers to eight bits, and leaving things that way for much of the program. If a function needs a different combination of register sizes, it saves as much machine state as needed, changes register sizes, takes care of business and then restores whatever machine state that was saved on entry. If register contents have to be changed to reflect computation results, the registers are pushed in a defined order so the function can rewrite the stack copies as needed (I push the registers “upside down” so .Y is near the top of stack—it facilitates using .X and .Y as a 32-bit “long” pointer).

A key principle in writing efficient and succinct 816 code is taking advantage of the 16-bit stack and movable direct page, especially the ability to point DP at the stack. If done right, code gets smaller and easier to write. Also, it helps to think in terms of your program being a series of functions joined together by small segments of inline code. The inline code’s main job is to pass parameters into functions and then deal with the results. The inline code’s contribution to detailed processing should be small and mostly consist of statements that route execution according to what the most recently-invoked function returned on exit. It’s the same methodology used in well-structured C.

BTW, macros are always your friend, especially so with the 816. I seldom say REP #%00100000 in my programs. Instead, I say LONGA. Also, REP and SEP are handy for clearing and setting multiple status register bits in a single instruction...much faster than using multiple individual instructions.

[Chromatix]

VinCBR900 wrote:

…Oscar Toledo’s bootbasic intended for 8086 which fits in 512k…

Surely you mean 512 bytes, not 512 kilobytes? The latter wouldn't be very impressive, considering BBC BASIC was supplied in a 16KB ROM.