Oops, yes I meant 512bytes, thanks for pointing that out.

Looking over bootBasic, I see that it makes a lot of compromises in deference to code size. You could certainly never call it a full-featured BASIC. But I think the way it's written would suit porting to 6502 reasonably well, and some of the more obnoxious deficiencies could be remedied in the process if desired.

The 6502 obviously doesn't have MUL and DIV instructions, but simple subroutines for these are easily added, and the 8088's bank of 16-bit registers can easily be substituted by the 6502's zero-page facility (as its designers intended). And, instead of calling to the PC BIOS to handle terminal I/O, small subroutines to interface to a UART (or a VIA for I2C or SPI) would also not take up much space. Speed is not critical here.

The memory management is made trivial by the provision of only single-character variable names (so you have a fixed set of 26 available), no string variables (only inline constants), a maximum line number of 999, and a maximum line length of 19 characters, with the position of a program line in memory being a direct function of the line number. So about 20KB of RAM is dedicated to the BASIC program. One could play around with these limits a bit to suit available RAM, but in practical terms memory management code is completely eliminated. These limits are objectively reasonable for a "toy" language implementation, anyway, as is the limited selection of BASIC statement types, arithmetic operators, and other keywords.

One interesting enhancement would be the implementation of two-character variable names, with the second character being optional and alphanumeric. This would allow for 26*37=962 variables, which still permits a fixed allocation of a reasonable 2KB RAM for variables.

A much more serious limitation is the lack of comparison operators to go with the IF statement. The example code shows testing for equality by subtraction, since zero is treated as "true" and nonzero as "false" (precisely the reverse of the C convention). Adding less-than, greater-than, and not-equal operators wouldn't increase the code size by much, and I think they would fit into the existing code structure. BASIC traditionally uses a single equals sign as a compare-equal operator as well as an assignment operator, so implementing that may require special-casing in the expression evaluator.

There is also no provision at all for subroutines. BASIC's GOSUB and RETURN statements are not exactly a great mechanism at the best of times, but they shouldn't be very difficult to implement - certainly easier than PROC and FN. A software stack would be needed, alongside the hardware stack used by the 6502 itself. Again, zero-page makes that easy.

Thank you Chromatix for the useful Bootbasic assessment.

I am the OP for this thread and the background is I am wanting to make a Toy Tiny basic system that could have been made by a 6502 student hobbyist in 1975, so minimal parts count (ROM, RAM) bitbang Serial IO, 8 bit latch parallel IO, teletype UI.

The Bootbasic functionality, although limited, does fit the simple requirements above (although poke/peek for IO would be needed). Since Bootbasic is <512bytes of 8086 I was hoping a 6502 port would fit into 1kbyte of 6502 including vectors & bitbang serial i.e. 1975 2708.

I agree that better comparison operators would help, as would a single gosub/return stack, and wonder if one way of reducing RAM usage is by tokenizing the basic keywords, like ZX80.

However in the spirit of the requirements above, as soon as any enhancements go over 1kbyte then Tom Pitmans Tiny Basic is probably a better starting point to optimization for under 2kbyte (inc vectors & bitbang IO) as it is full(er) fat with all of the above.

But if anyone is up for porting bootbasic, It would be really cool to see it running on a 6507...

I don't have a very clear sense of how 8088 code density would compare to the 6502. It's possible that a direct translation would result in a doubling of code size. I'm reasonably confident, however, that the enhancements I mentioned can be realised within 2KB of 6502 code. PEEK and POKE should also be very straightforward and compact to implement, or maybe using part of BBC BASIC's indirection syntax (ie. make it just another assignment statement, not a separate named keyword).

Targeting a 6507 would require a more sophisticated approach to memory management, I think, because the complete address space available on that chip is only 8KB, whereas implementing the "trivial" memory management in bootBasic requires a relatively generous address space that is only sparsely utilised. BASIC is usually written using sparse line numbers (eg. incrementing by 10 with the occasional edit inserting a 5), so adding routines to handle a program packed contiguously into memory would probably be required. Finding a given numbered line would require a linear scan rather than just a calculation - though that could still be optimised by aligning fixed-length lines, or providing a length byte for a skip list. Conversely, I think tokenisation would probably just increase the code size without making memory management easier. This is the kind of design decision that you have to get right at the outset.

The Apple I would make an interesting (and era appropriate) target for this, with its exceedingly simple "glass TTY" I/O interface. The output was an 8-bit latch with a busy flag, which could typically accept 1 character per video frame. The input was a cleverly decoded ASCII keyboard. The software required is about as simple as you can get. One of Woz' early masterpieces.

Great discussion points!

Yes certainly agree the apple 1 is interesting with its 4kbyte integer basic but costing $666.66 in jul 1976 (over $3,500 in 2023 dollars). So the challenge here is could we have delivered something with similar functionality for a lot less and a year earlier. Hence minimal rom, suggested max 2-4k ram.

so the current bootbasic line number memory management approach is not appropriate for this restricted memory concept - Maybe a linked list is better? The tokenization suggestion was to reduce ram usage.

The test benchmark is a fixed point Mandelbrot basic prog

The Apple I originally had 4KB RAM and 256 bytes of ROM, the latter containing the Woz monitor which was just sufficient to allow experimenting with the machine. That's the condition the prototype was demonstrated in 1975. The hardware was already quite minimal and low-cost for the time, considering that integrated circuits were still a relatively new technology and were priced to be affordable for building minicomputers, not home microcomputers. He used the 6502 instead of the 6800, because it was $100 cheaper. Space was provided for adding more RAM and a connector to extend the system bus; PCB space was relatively cheap compared to the components to populate it.

A large part of Woz' motivation for the "glass TTY" concept was to avoid the expense of an electromechanical TTY, with the user being expected to supply their own ASCII keyboard (which could be hand built as a comparatively straightforward hobbyist project) and a TV for display (already a common household feature at that time). The Signetics FIFOs used for the video display were significantly cheaper than the SRAM or DRAM that would have otherwise been necessary to hold that data. He had designed and built the "glass TTY" well before the computer. At that point he already had experience with building "pure logic" video games efficiently, using about a third of the IC count compared to most other designers.

You can see that Woz was already very concerned about affordability when specifying the default configuration of the Apple I; 4KB was the minimum he could reasonably make Integer BASIC work in. He built the first prototype already in 1975, for his own personal use, and he built it specifically to run Integer BASIC on. He had to borrow a 4KB RAM card (which used 1Kbit SRAMs) because he couldn't afford the DRAMs at first. The machines that were sold commercially had all of the memory chips populated, for 8KB RAM, so that the 4KB BASIC could be loaded from tape (not ROM!) and then there was still 4KB left over to use with it.

Memory devices remained a major cost constraint on home computers' capabilities well into the 1990s, with each advance that reduced RAM cost per kilobyte (or megabyte) mirrored by an almost simultaneous jump in typical installed RAM capacity and, very shortly thereafter, the widespread introduction of software that would immediately exploit that increased capacity. In April 1975, a 4KB DRAM board for the Altair cost $264, almost certainly using the same MK4096 chips as were used in the Apple I. By mid 1978, the price of 4Kx1b DRAMs had fallen to $1.80 (these being the bottom-bin parts with exceedingly slow timings), so a set of 8 could be obtained for a much more reasonable $14.40, and industry commentators were still hoping for further reductions in cost consequent to the anticipated introduction of 16Kbit DRAMs - which in turn were still the device of choice through the early 1980s, until 64Kbit DRAMs arrived and the cost per bit dropped by two-thirds almost overnight. Economy of scale was a real thing, and home computers were a significant part of the competitive demand which enabled it.

Even the KIM-1 (which MOS developed as a demonstration platform for the 6502, since they couldn't rely on 6800 based equivalents after the 6501 lawsuit) wasn't available until 1976, so it's not as if Woz was slow to develop his machine. KIM-1 had a larger ROM but significantly less RAM than the Apple I. The smaller RAM was undoubtedly due to the increased cost per bit of SRAM vice DRAM.

A work-alike clone of the Apple I could be built for much less nowadays, using SRAM for main memory and display memory, and EEPROMs or Flash ROMs for the boot ROM and display character generator. The Signetics chips Woz used extensively in the original design are now unobtanium; though FIFO chips are still available, it would be cheaper and simpler to just plug the counter registers into address lines of an SRAM.

I say all this to point out that a computer with 2KB ROM and 8KB RAM would actually be a major upgrade over the Apple I, and could well have been too expensive to be commercially viable (or hobbyist affordable) in 1975.

Looking at that, another important limitation of bootBasic is that it doesn't have FOR-NEXT loops. You have to do IF … THEN <line>, with the aforementioned limitation on what comparisons you can do. With care you can work around it, I suppose.

FOR-NEXT loops would also make use of a software stack, probably the same one as GOSUB. BBC BASIC calls it the "BASIC stack" to distinguish it from the 6502's hardware stack.

Thanks, some interesting context there. I'm not dissing the Apple1 as I appreciate the modular design and video output like TV typewriter, but this challenge is can we get a Pico/Tiny basic into a small Eprom, (1kbyte or 2kbyte) with minimal RAM. I'll ignore EPROMS were more expensive than SRAM in late 1975 in part due to the quartz window.

Back to porting bootbasic, I think we said the basic line management does not account for ragged line ends and assumes each line is 19 chars (+terminator) with max 999 lines, which is where the 20k comes from. So with 2kbytes ram accounting for Page zero and Page 1 stack, this leaves 1536 bytes for program, or 75 lines, which is not a lot but probably enough for the Mandebrot program port.

So it might be fun to port bootbasic to 6502 to see how small it would be, but at the same time Tom Pittman's 6502 tiny basic is more capable and might squeeze under 2kbyte.

Re Mandelbrot, the bootbasic is a minimal basic and so any 'normal' basic program would need porting to make it usable e.g. unsigned 16bit integers, no GOSUB/RETURN, no FOR/NEXT, no CHR$ etc, but the intent is wouldn't it be cool to see a 1975 6502 variant CPU running a BASIC mandelbrot program, and see how long it takes...

Well.. This is a solved problem - we've been doing that for decades now.

However that listing you linked to earlier is interesting as it's using scaled integers. The one I put together for benchmarking some years back is here:

https://unicorn.drogon.net/mandel.bas
Output here:
https://unicorn.drogon.net/mandel.txt

However that does use floating point - the number at the end; 48.21 is seconds running BBC Basic on a 16Mhz 65C02 CPU, but myself and others have used it on various platforms to benchmark (mostly microsoft type) BASICs on 8-bit micros.

I've tried running yours under BBC Basic after converting all variables to integers (I -> I%, etc.) BBC Basic supports 32-bit integers. It's very very slow - I think the main issue is the pixel iteration count being quite large - 200 when you only have 10 "colours" to plot.

So what might be needed is a version that would run with 16-bit signed integers so we could all test it with the various Tiny/Integer BASICs out there including Apple Integer BASIC which is, I feel somewhat neglected these days.

(And as it happens I do have a version that will fit the bill and work in 16-bit integers, however it's currently in BCPL, so I'll make an effort soon to translate it into BASIC suitable for Tiny* systems and other systems that support computed GOSUBs...

Picture of your Mandelbrot running on my Ruby 6502 board under BBC Basic. I didn't time it, but it was several minutes:



Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Another Mandelbrot benchmark! I took your lead and converted simply to BBC Basic, scaled it down by 2x (so a quarter of the points) and reduced max iterations to 20. The run time was 192 seconds (BBC Micro, 2MHz). Then I converted to integer variables, see here, with runtime 174 seconds. There are of course other tweaks and crunches one could do but that's probably OT here. Oh, just one more, together with changing to integer variables, changing from / to DIV gets the runtime down to 131 seconds. Integer arithmetic really is faster!

Thanks, nice to see. Good point that my iterations was too high versus number of 'colours'. Would be interesting to see if anyone can convert to unsigned 16 bit...

So to reiterate this thread is to develop a minimal basic system that could run a mandelbrot BASIC that could have been built in 1975 by a student hobbyist, whereas BBC micro was available in 1981 for £235, equivalent to ~£790 now.

So does anyone have a source for a 6502 Pico/Tiny Basic code that can fit in less than 2kbyte eprom?

The Beeb was £399 when launched which according to the BoE calculator would be around £1,457 today. That gets you a LOT of computing power retro or otherwise...

The BIG issue back then was the cost of RAM. That's why a "4K" Basic existed - the cost of the RAM chips far outweighed the cost of the rest of the system. Even the Apple II could have been sold on day 1 with just 4K of RAM... However it did have a monitor/mini-assembler/disassembler/Integer Basic in ROM...



Shouldn't it be possible in VTL02 ? It's not quite a BASIC, but is programmable...

I did start a project a few months back to create a programmable calculator with line-number entry/editing. My plan was to do it in 6502 assembly, but I decided to do proof of concept in BCPL first - then to make it more accessible to others, I ported it to C. I have almost finished writing a Mandelbrot with it however my plans to write a 6502 version have stalled for various reasons. It should be under 4KB, but it's hard to tell at this stage. If anyone wants to look at it and do the port, then it's https://projects.drogon.net/apricot/

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Here's a little chuckle... The fractal pattern we now know as the Mandelbrot set was first defined and drawn in 1978 and it wasn't until 1980 when Benoit Mandelbrot obtained high quality visualisations...

And while RAM was getting cheaper, high colour displays were still out of the hobbyists reach then, but we can follow in the footsteps of the very first one which appears to have been printed on a teletype.

https://en.wikipedia.org/wiki/Mandelbro ... Mandel.png

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

That correct - hence why it would be so cool on a minimal system rather than a PDP-11

I'm all on board with idea of a minimal basic for a tiny system, and trying to do an integer-based mandelbrot on it. VTL02 is certainly worth a look, if you haven't looked yet. It's wonderful and terrifying.