6502.org

I'm a 6502 developer but I'm looking for a BASIC to install on my SBC (65C02, 1MHz).

I know EhBASIC is popular here but I've only tinkered with it in the past. I'm not very familiar with it. However, BASIC is BASIC right?

I have 32K EEPROM chips and my memory mapping is pretty flexible at the moment.

My initial idea for ROM mapping would be something like:

256 bytes for "Woz-type" monitor
8K for BASIC
~4K for custom ROM routines related to my hardware (sounds, fonts, etc.)

So I'm looking for something that is relatively easy to map into that scheme.

Any recommendations appreciated.

Thanks!

I've been toying with the idea of porting BBC Basic to either Apple ][ or my CHOCHI boards; the source code is available for that (although in a form that requires RISCOS to build). This is probably much more fiddly than getting EHBasic running, but BBC Basic has a number of interesting features.

Note that somebody has already done something similar: http://sprow.co.uk/bbc/minib.htm.

BBC Basic, in and of itself, should not require any modifications to run on any 6502-based machine, unless it is desired to change its base address from the $8000 used in the BBC micro. In BBC Basic, all accesses to the machine's hardware (Screen, keyboard, sound, tape, discs, i/o, etc.) are made via operating system calls and so BBC Basic will run on any 6502-based system that provides these operating system functions. Even the memory area available for Basic to use is determined by the operating system.

Full details on all the operating system functions (And there are a LOT of them...) were given in the BBC Micro User Guide. If you were prepared to write an operating system that duplicated the functionality of the BBC Micro's MOS on your own hardware, you could then run BBC Basic on your hardware with no modifications to the Basic interpreter!

Agreed - BBC Basic doesn't need much support, and it's a very good Basic, with an assembler and support for structured programming. In fact with read and write you get quite a long way. There's also HIBASIC which loads at B800 (and, I think, needs a 65C02) which give more room for the user. But BBC Basic is 16k in size. I think even EhBASIC is more than 8k - for an 8k Basic you probably need one of the MS Basic flavours.
See http://www.pagetable.com/?p=46

The BBC BASIC looks pretty intriguing. I might have a little trouble using it, however, because I plan on having 32K RAM and 5-6 I/O devices. I just need to figure out my mapping strategy.

Which of these BASIC's are good (easy) to extend or alter? I plan on using a TMS9918 and AY-3-8910 chips in my design so it would be great to have BASIC commands to work with them.

If you don't need floating point, then the Apple I Basic might be an interesting case - it's very small.

Certainly later revisions of BBC Basic added more commands, but it's a tokenised Basic, so 128 is about the most you could have. Without the source, you'd be patching the binary, but that's not impossibly difficult. In fact a new disassembly would be quite an asset - the present disassembly into BBC Basic syntax isn't convenient for cross-assembly.

For BBC Basic, you have the MODE, VDU, COLOUR, GCOL, MOVE, DRAW, SOUND commands, all of which send their parameters off to the OS to interface with the hardware. You'd need your OS to handle your chips, and provide the interface which Basic expects.

For extending BBC Basic, this might be worth a read:
http://www.benryves.com/journal/3393553

For the BBC OS's VDU commands, see
http://central.kaserver5.org/Kasoft/Typ ... /Ch34.html
It's worth noting that the Beeb's OS is also 16k - there's a lot in there.

As mentioned before, there's 2 options for BBC basic, they are both 16k images though. They both expect to find the OS vectors in the top part of the memory space running up to the hardware vectors. And at least 4k of ram in low memory running up from 0000

The normal rom is mapped in to 8000 to BFFF so you could put your I/O above that before the start of the OS rom.

The other option is HiBasic which expects to be located at B800 to F7FF, whilst it's usually ram loaded on a BBC 2nd processor it is romable. Since it checks the available ram with the OS on start up, it doesn't have to be supplied with the 46k available on 2nd processor.
so there would be room between the ram and rom for I/O

HiBasic only leaves 2K at the top of memory for the OS, though there's nothing to stop you splitting the OS and putting the rest into rom lower in the memory map.

Since the OS does the talking to the hardware BBC Basic itself needs no alteration. You don't need to provide a full implementation of the BBC's MOS either, just the bits you need. Likewise extending the VDU system to make use of the 9918's sprites ought to be possible too.

I think HiBasic 3 will run on any 6502, whilst HiBasic 4 needs the 65C02.Though I've only ever used HiBasic3 on the W65C02.

Grant Searle's site has a version od 6502 Microsoft basic and source code, the basic is just under 8k, but doesn't really leave enough space for the OS, so you'd probably need to go with 16k.

No doubt the most useful BASIC was BBC Basic. But the most used Basic was probably Microsoft Basic: variations are available for the KIM-1, OSI / UK101, Commodore, Apple, and others. Michael Steil made a version of the source code available that compiles into any of the known variants.

Check out his website and his github.

===Jac

I looked into the Microsoft BASIC. I think that might be the best fit for me because I have the source code and can create directives for my 65C02 computer.

The memory layout I've decided is:

$0000 - $7FFF RAM (32K)
$8000 - $BFFF I/O (6 devices)
$C000 - $FFFF ROM (16K)

So if I start BASIC at $C000 and it's 8k (or a little more) then I should be good. This would allow space for some custom stuff I want to do.

Thanks for all of the suggestions!

Not at all.  The first BASIC I used was what came with my HP-71 hand-held computer, plus especially the math module and the many LEX (language extension) files added by the user groups.  For example, you can have many BASIC files in memory at once, and they can call each other, or BASIC subprograms, with local variables and environments nested as many levels deep as you want (until you run out of memory), handle complex numbers natively, and have interrupt support.  After that, GWBASIC, and even Rocky Mountain BASIC were huge disappointments, very decrepit by comparison.  I have not used Lee's EhBASIC, but after having a good look through it years ago, I was very impressed with the quality of what he accomplished, considering the memory limitations of the '02.  (I have about 360KB of memory in my HP-71, so I can't expect Lee to do as much with the '02.)

Do you really need 16K for I/O devices?

If you're building your own computer and using TTL gates for decode, and aiming for simplicity, that question becomes "do you need any less than 16k for I/O devices?"!

For anyone who's relatively new to this great sport— I'm sure no one needs 16K for I/O, but doing it this way makes the address-decode logic much, much simpler, and requires only five gates (in two ICs) and only two levels of gate delays, and it allows up to ten I/O ICs.  Hence Ed's comment, "that question becomes 'do you need any less than 16k for I/O devices?'!"  It is very common for beginners to make it more complex, and the primary disadvantage is that the maximum speed the system will operate at is reduced a lot.  See the addres-decode page of the 6502 primer.  Actually, if you can go for 32K of ROM, 16K of RAM, and 16K of I/O, you can do the entire address-decoding scheme with a single 74xx00, with a gate left over for something else.  (This is shown further up the same page of the 6502 primer.)

Ah, ZX-Spectrum one-bit address decoding. I /really/ hate that, but for single-purpose embedded systems it makes a lot of sense.