6502.org

I'm looking for one for CP/M-65 (which has just got Oric support).

I've found:

- Microsoft Basic. The source code which is floating around was leaked. This means I can't touch it.
- ehBasic: apparently a modified version of Microsoft Basic, so that's out too.
- Altirra Basic for the Atari: a viable candidate... but is written in a very idiosyncratic 6502 assembler dialect which will be problematic to port.
- FastBasic, also for the Atari: another candidate, but this is a line-numberless Basic which isn't very Microsoft compatible (also the build process is really complex as needs a FastBasic cross compiler).
- BASIC-E from DOS65 Basic: not an interactive Basic; this is a compiler.
- CP/M65 (note no hyphen) also has a Basic interpreter, but it's significantly different to Microsoft Basic --- I think, I can't actually find it right now.

Does anyone know of any others?

BASICs come in a variety of flavors, from "tiny" to "business". Do you have a specific set of features you would like to utilize?

ehBASIC is undoubtedly heavily influenced by Microsoft BASIC but calling it a modified version may be a debatable characterization.

I don't understand why you can't touch MS Basic (Nor EhBASIC).

The (MS Basic) sources weren't "leaked" they were deliberately put out there in a form that makes them very usable. The only questionable part would be if you were planning on selling a product that used them, but even then I'd feel fairly save myself selling a system and saying "oh, by the way, if you want a BASIC then download it here..." sort of thing.
BBC Basic. However you'll need a system that supports a lot of the Acorn MOS to run BBC Basic. I have done this on my own systems and should I ever sell them, then see above ...

There is also Paul Robsons Basic - fully open source (MIT License) which AIUI he started to develop for the Foenix '816 project but is not targetting the Neo6502 project...

https://github.com/paulscottrobson/6502-basic

-Gordon

ehBasic IS a modified version of a disassembly of MS Basic.

You just have to look at the sources and compare. It's a slightly annotated disassembly for starters, then compare it to the published MS Basics to see just how identical they are. Sure, Lee added things and maybe fixed a bug or 2, but it's MS Basic by any other name.

-Gordon

I don't think that's true. Looking at the provenance, the sources seemed to show up out of nowhere on some random Korean blog, there's no copyright statement or license attached, which Microsoft's lawyers would certainly have insisted on, and it's not hosted on github.com/microsoft along with everything else. Also, there's no mention of them on Rich Turner's blog, and since he's the person at Microsoft who is dealing with open sourcing this old stuff, it'd absolutely be something he would have a hand in. Compare with the GW-BASIC open source announcement: https://devblogs.microsoft.com/commandl ... -gw-basic/

I have wondered about dropping Rich Turner an email (I've interacted with him mildly before), but perhaps he doesn't officially want to know...

Re BBC Basic: good point --- it's one of the best, anyway! Unfortunately it's in even worse legal limbo. Apparently nobody knows who the rights holders even are any more.

Re Paul Robson's Basic: that looks promising! I'd seen his 65816 Basic but didn't know he was working on a 6502 one. It looks very BBC Basic-ish.
Do you know a good place to get in contact, i.e. a forum where he hangs out?

I have Altirra Basic mostly running and working. Unfortunately I'm a little dubious about it. Atari Basic turns out to be more different to Microsoft Basic than I was thinking; for example, it wants all-uppercase programs (including variable names, apparently?). More worrying is that the floating point support just delegates to the Atari ROM. There's an open source clone of that from the same author, which works, but apparenly Atari floating point is done with BCD and only supports six significant figures!

This last is a problem with anything from the Atari world, as writing floating point libraries is painful and nobody wants to do it. FastBasic does the same thing. This also affects Paul Robson's Basic, which seems to have no floating point support at all currently (it's just stubbed out).

So, hmm. I think the easiest option is to hack up Altirra Basic until it behaves more like what I'm looking for, but I think changing the floating point code will be more work than it's worth...

Hi!
Yes, most Atari languages use the math-pack in ROM. The format is BCD, with up to 10 significant digits, but with a base 100 exponent. This means that numbers from 1 to 99 will all have up to 8 decimal places.

Also, most Atari languages call to the OS for the graphics support, so they all have "GRAPHICS", "PLOT" and "DRAWTO" statements "for free".

But, you will hit another problem: Strings in Atari BASIC are very different from MS Basic strings, they must be allocated (with DIM) before use, to a specific maximum number of digits. Also, there are no string arrays in the language.
I'm the author of FastBasic - it is intended as the most capable and fast BASIC interpreter available for the Atari 8-bit computers in under 8kB - so my priorities are size, then speed, then support for making great games

FastBasic compiles the source code to a stack-based bytecode, executed with an indirect threaded interpreter. The compiler is also an interpreter from a PEG grammar, that generates code directly from the parsing.

Initially, FastBasic was integer only, and this is noticeable as all the variables are integer by default, you must use the "%" suffix to define floating-point variables. But this is a good thing for porting, as to change the floating-point format you only need to touch very few parts of the interpreter, and you can port the integer version without needing to touch the rest.

FastBasic string support is also different than Atari BASIC and also MS Basic: in FastBasic, all strings are "pascal strings", of up to 255 bytes of length, with the first byte in memory storing the actual length. FastBasic supports string arrays, and all the uninitialized strings do not use any memory (they are stored as null pointers).

In your message above, you said that the FastBasic build process was complex - this is because the integrated full-screen editor is also written in FastBasic, so you need a compiler to build the complete package If you omit the editor, you could build the compiler and interpreter without the need of the cross-compiler. Also, FastBasic includes a complete test-suite using an included command line simulator, this ensures that changes don't introduce new bugs!

I can help you in adapting FastBasic to CM/M-65, would be a fun project, but you will need to remove or rework a large portion of the statements:

- Graphics, Plot and Dwawto could be implemented for "generic" framebuffers (see the Atari 5200 port at https://github.com/dmsc/fastbasic/tree/ ... terp/a5200 , this re-implements those).
- Player/Missile (Atari "sprites") support is very hardware specific.
- DLI (Atari raster interrupts) support is also hardware specific (it basically generates the interrupt code on compilation)
- Sound is also hardware specific.
- Pause and Time must be implemented for each possible target.
- All I/O must be converted to CP/M - Atari I/O uses "channels" (a number from 0 to 7), with channel 0 the standard input/output (normally to console), with OPEN/PUT/GET and SPECIAL operations over those.

Porting the Editor requieres that the screen output has "cursor movement" and some control characters, clear-screen and scroll region, and it also hooks on the "break key interrupt" to allow stopping the running program. But as I said, you can initially only port the command line compiler and use an external editor.

The FastBasic cross-compiler supports "targets", it currently can compile for the Atari 8-bit computers (as an executable or cartridge image, and with or without floating-point) and the Atari 5200 game console.

Well, enough advertising for now

Have Fun!

Oh, excellent! I must have misread it as base 10. That's a reasonable amount of precision.

I didn't know about needing to dimension strings, though. That's unfortunate. I only have one more thing to add to make this work, which is file I/O (I'm just doing a very basic emulation of CIO on top of the CP/M I/O system, to avoid going mad), so I'll finish this, but I was hoping for something a bit more Microsoftish.

(I have also just found the 128 variable limit. Sad face emoji.)
I was meaning to drop you a message! Yes, I've been looking at FastBasic. It's very elegant, and I can see a lot of Forth inspiration there (which is not a bad thing). It took me ages trying to find the compiler before realising that the interpreter is actually also the compiler...

I did have a couple of questions here:

- when doing offline compilation, it's essentially just dumping the bytecode to disk with the standalone interpreter on the front. But, the bytecode produced by the IDE will be at a different address than the bytecode used by the standalone interpreter. It looks like the bytecode contains fixed addresses, so how is relocation done? (This is important for me because CP/M-65 uses relocatable binaries. Just writing a chunk of memory out to disk isn't going to work as it may need to be loaded at a different address.)

- the compiler looks like it's single-pass. How are forward references resolved? Does it just not need them --- i.e. with symbols declared on first use and with no procedure parameter checking?

- how are you handling string management, i.e. something like a$ = a$ + "1"? I don't see a heap or a garbage collector.

- it's less of a question and more of a statement, but local variables in procedures would be really nice...
Isn't the standalone compiler also written in Basic? e.g. cmdline.bas.

There does seem to be a fair amount of Atari stuff which needs unpicking from e.g. the editor but I don't think that would be hard. The worst part will be generating CP/M-65 binaries. I did try telling cc65 to produce o65 output files, which I should then be able to convert, but the linker failed miserable with a whole pile of error messages. There is a way around this but it's annoying and I'm not sure I can make it work with your build system, so I might have to hack some other build system up.

I'm also intrigued as to whether it might be possible to use this as the basis for a standard Comal system; it's already very nearly the same language, and it should mostly be a matter of rewriting the syntax files...

Hi!
The compiler simply calculates a "relocation offset" and adds it to any address reference when generating code, see https://github.com/dmsc/fastbasic/blob/ ... s.asm#L604 . To emit relocatable code, all the locations with addresses could be stored to emit the relocation table later.
Yes, the compiler is single pass, but there are two types of forward references supported:
1- When emitting loops, the address of the jump instruction is pushed to a loop stack, and when the loop end is parsed, the address is pop-ed from the stack and patched with the correct destination. This allows this code:
to be converted to (labels are not bytecodes, only addresses stored by the parser)

2- When calling PROCedures, the parser search the address of the procedure implementation in a table, if it is missing a new entry is created, marked as "undefined" and the address of the caller is stored there. When the procedure is declared afterwards, all the undefined entries are patched with the real address. At the end of the parsing, if the table has any undefined entry, an error is produced.

Currently the 6502 compiler does not check that the number of parameters of the procedure matches between calls, bit the cross compiler do count the parameters and errors out on mismatches.
Strings are handled like original Turbo Pascal strings: allocated on first use, and always of 256 bytes. There are internally two types of strings, similar to the C L-values and R-values. An L-value string is a pointer to 256 bytes of memory, but R-values can point to any shorter strings, like string constants or string produced by internal functions (like "STR$" or "CHR$").

To simplify the parser, string concatenation is currently abbreviated as A$ =+ "1" , this simply calls a "string append" function passing the two addresses.
Yes!

The problem is my goal of full IDE under 8kB, and I'm already about 50 bytes over my budget

Also, one big gotcha of the language is that procedure parameters are also global variables, so this code swaps X and Y: At call time, X and Y are pushed to the stack, then at the start of the procedure, both are pop-ed from the stack and assigned to Y and X respectively, so the values are swapped.
Yes, but the code is fairly simple, so rewriting it in assembler is a simple task. The very first versions of FastBasic did that, as the cross compiler did not exist yet.
IMHO, it would be simpler to write a new output format to LD65. I already add the "Atari XEX" output format, and it was fairly simple, so I expect that adding the CP/M-65 format would not be that hard.
Yes, the good thing about BASIC is that many people like it, specially in older 6502 systems, it is a natural fit for the small machines.

What would be difficult to implement in the current FastBasic is functions, because the parser assumes that some registers are not changed inside any expression, and the stack is very small.

Have Fun!

I've done the Altirra BASIC port (see picture). It's now about 11kB, but that does include Avery Lee's mathpack clone and the CP/M I/O translation layer. It's not the greatest BASIC, but it's there and that's better than no BASIC.

I'm going to have to take a break for other projects but I intend to come back to FastBasic. It's definitely something I'd like to have...

<sobs>

Look what I just found: https://github.com/Dietrich-L/CPM-65/bl ... /BASIC.ASM

It's a GPL Microsoft-compatible BASIC! And do you know where I found it? On my own CP/M-65 bug tracker. Somone sent in a link, I replied to the bug, and then promptly forgot about it.

It's so thoroughly compatible that it appears to have the obfuscated "MICROSOFT!" string appended to the end of the SIN coefficients!

Yup. It's just another disassembly and slightly hacked about version of MS Basic - it's quite a well documented one though - maybe even an original? (And the Easter Egg looks like that from the CMB2 variant but there is no actual code - an interestingly while the PEEK and POKE code is identical, the WAIT code is a delay rather than wait for a memory location to change)


Other things I looked at:


Original MS Basic errors:
and the Junior version:
These are essentially identical. The one that I was looking for in particular: UNDEF'D STATEMENT

So either EhBASIC or the other MS Basics at https://www.pagetable.com/?p=46 would be far easier to port, but the important thing is that this, like EhBASIC is an MS derived BASIC so while the sources may be in the public domain the copyright remains the same as the other MS Basics.

-Gordon

Edit: Looks like our posts crossed...

Uh oh.

From the leaked Microsoft BASIC code:
From the link above:
I guess I now know why it's so compatible.