I have searched and searched and couldn't find any older posts of what I was looking for, though I swear I had seen something kind of recently.

As my Text Editor (here viewtopic.php?f=2&t=7898) is basically done, I want to use it for something: A "high level" programming language. Just for clarification, I want to program this high level language on the 6502 or 65816 SBC itself, not on a PC!

My first thoughts were BASIC or C. I have written a few TinyBASICs before, and I am very fluent in C. But I would rather not use BASIC if I had another option, and C seems *way* too difficult to implement. I know Gordon has BCPL and Garth uses Forth, which I'm not entirely opposed to, but I would need some convincing to use them. I looked into Pascal a bit also.

Are there any other options? Are there other topics on the forum that I just missed somehow? What programming language would you use *on* a 6502 or 65816 SBC?

Should I just make something up myself? Or perhaps a super-set / macro language that would be more 'mid-level' instead of 'high-level'? I wanted to include the ability to type assembly code in-line without much hindrance, and perhaps I can do what I want with just a few keywords like IF and WHILE?

Any ideas are welcome, thank you!

Chad

Hi!



You could por my FastBasic IDE to your SBC. FastBasic is an structured BASIC, with procedures with parameters, without line numbers and with a full IDE in native 6502.

This is an example source for calculating PI: https://github.com/dmsc/fastbasic/blob/ ... int/pi.bas

Have Fun!

having a native modern marco assembler would also be amazing.
one that doesn't have archaic limits and allows you to place labels and instructions wherever you want (no required whitespace), has support for include files, can handle actual complex macros similar to ca65, and can do math for constant/literal values, etc.
being able to assemble into object files and then having a seperate linker program would also be sick.

ca65 would be a pretty capable option, but it's designed for modern systems so it assumes C's normal data types to be a specific width, and compiling it for the 65816 would be possible but it would eat up a lot of RAM. (i've tried it myself and all files do compile with Calypsi C except for scanner.c which throws an internal compiler error, so i can't say how large the final binary is, but if i just go by object file size, it would be around 600kB)

xa would also be an option, but similar to ca65 it assumes int, long, etc to be a specific width so it's not well suited for porting to another architecture. (i also tried compiling it and it did technically work (164kB executable, oof) but the warnings about data type widths when shifting and using malloc make me think that it wouldn't function as it currently is.
replacing data types with the <stdint.h> variants and having a full library (newlib nano maybe?) plus headers with File IO and time functions would make both functional. but even then you could still run into memory issues as the programs assume you to have GBs worth of RAM instead of only a few hundred kBs.

maybe something written from scratch would be best, still in C or another higher level language for easy porting, as assembly is horrible for porting because everyone uses a different assembler with different syntaxes.

as for having a native C compiler, it should be possible, i know that the Apple IIgs had a C compiler (ORCA-C) written in Pascal. so one option would be to get ORCA/Pascal running on your system and then try to port ORCA-C over to it. the ORCA/Pascal github has no instructions on how to build it, so i guess you just have to wing it?
or you could take the source of an existing C compiler (i know there is a tcc and lcc-1.9 port for the 65816) and use a C cross compiler to either directly port one of them to the 65816, or compile it to some form of inbetween bytecode VM to save on program size and memory usage in exchange for making it run a lot slower, if only i could get myself to sit down for once and actually write a target for vbcc to generate assembly for my SW32VM since it was kind of designed for stuff like this.
but either way would likely require quite a bit of tinkering with the source code.

The common usual suspect for a first high-level language esp. on small systems would be Forth. (viewforum.php?f=9, of course) One of its strengths is the extremely compact code it tends to generate.
Regarding C, you may want to take a look at my Small C compiler cc64 (https://github.com/pzembrod/cc64 and viewtopic.php?t=6360). It's written in Forth, the compiler size is currenty just under 32k, and it runs on C64, C16/Plus4 and Commander X16.

I didn't realize someone had released the source code to the Apple Pascal. I would have thought Apple had that sealed off in some sort of vault lost to the annals of time. I've been, slowly, and painfully trying to come up with my own toy high level language similar to Pascal that would run on a simple VM that I hope to port to the 6502.

I think it would be a fun goal to get it to be self supporting, but I need to overcome a few challenges with how compilers work first.

I am going to ramble about quite a bit, so please bear with me...

I used Turbo Pascal for CP/M some and for DOS quite a bit. It is very simple as far as an integrated development environment (IDE) goes, but it is very functional and not that expensive to implement.

Borland went on to release Turbo C and Turbo BASIC along with Pascal wrapped in a fancier IDE, but what I really wanted at the time was Turbo Assembler with an IDE, even the simple early one. But I was not prepared to take on writing a MASM-compatible assembler to make my own. There were a few IDEs which used MASM or TASM to do the assembling, but the few I tried were rather clunky.

For a native environment on an 8-bitter, I strongly encourage adopting an interface similar to the early Turbo Pascal, version 3.x or earlier. It is essentially a full screen editor coupled to a small set of full-screen menus. Versions of Turbo Pascal 3.x are now free to download if you want to try it.

Believe it or not, my first attempt to write a compiler was for C. Whenever I begin learning a new processor architecture or programming language, I cannot resist implementing a simulator, assembler, compiler or interpreter to learn the deeper details. This was in 1984 when I decided I needed to learn C as that appeared to be the future of PC programming instead of Pascal. This was good old K&R C which was a bit simpler than the modern dialects. But I soon discovered that C was very difficult to parse compared to other languages. Probably because it was a bit of an accidental invention instead of being designed to be easy to parse - it was literally a high-level assembler for a DEC minicomputer. The project was soon abandoned.

After a few years of pretty intense career building, I had some free time to play with my 680x and CP/M machines. Compared to the PC world, they felt very primitive, largely because I did not have a hard drive on most of them. I wanted to be able to write and debug code for those machines on a PC and take the result to the 8-bitter for final testing. Hence embarking on building cross-development tools.

I later went on to create a series of cross-assemblers and compilers running on DOS to generate code for 8-bit microprocessors. 2024 may finally be the year I feel comfortable releasing these as usable products though I have been using the assemblers extensively for my own development work. They are not written in assembly language though, so there is little chance they can be successfully built to run natively on an 8-bit micro.

I was not a fool to write those entirely in assembly language. Sure, I had a library of subroutines written in assembly language which I called from compiled code - those were largely replaced later when I began migrating from DOS to 32-bit Windows. In the limited spare time I had, using only assembly language was not something I wanted to do.

Anyway, you will need to start somewhere.

A native assembler will probably be needed somewhere down the road, but it is not the easiest way to start.

Either try a subset of Pascal as that is a language designed to be relatively easy to parse or on old-school integer BASIC with line numbers as you can parse and compile it a line at a time. Emitting machine code directly allows you to run and test using only your SBC. Emitting assembly language is not as complex and in my opinion, more enjoyable, but you have to resort to cross-development until you build or acquire a native assembler. If you generate machine code directly, you will need a disassembler to look at the code you are generating.

Consider your first attempt to be a throwaway prototype. Do not let the perfect be the enemy of the good. Get something running. You will learn much in the process and gain the confidence to design and build your ultimate project.

If you know some microcomputing history, you might try implementing PL/M. It is a variant of PL/I, the mainframe programming language, developed by Gary Kildall to write system software for Intel microprocessors. He has a version written in FORTRAN to run on mainframes and minicomputers and he has a version to run on the Intel development system - I do not know whether that is in assembly language or FORTRAN.

Thomas Crosley wrote a PL/M subset compiler which runs natively on a 6800.

http://www.flexusergroup.com/flexusergr ... s/SPLM.pdf

I have begun to disassemble and comment SPL/M, but have not gotten very far. Another member of the FLEX user community also made an attempt, but is similarly bogged down. Both of us have the goal of making it generate code for the 6809. It runs in 20K of memory and parts of it appear to be written in SPL/M.

You are not alone. If you have followed the adventures of David Given implementing CP/M for the 6502, he also wants native development tools.

viewtopic.php?f=2&t=7355

He wrote an assembler in C; it is bigger than he would like and does not have many features, but it does satisfy his requirement of generating relocatable binaries for his operating system.

ORCA/Pascal is not the same as "Apple Pascal" - "Apple Pascal" is a port of UCSD Pascal to the Apple II and boots into its own separate environment.

One of my many projects is to implement LUCIDATA Pascal for the 6502. It runs on 6800 or 6809 FLEX and generates some kind of P-code. The included interpreter runs both the compiled programs and the compiler itself. My thought is that if I can successfully implement the interpreter on the 6502, the compiler can come along for the ride.

I have the interpreter working for everything except memory paging mode (its "virtual" memory scheme) and running the compiler itself. It is able to run every program on the 6502 I have compiled on the 6800 so far. With enough memory, the compiler does not need to run in paged mode so that is not why the compiler does not work yet. There are a couple of P-code instructions which the compiler uses which I have yet to figure out and there seem to be other problems as well. I need to implement a P-code debugger in the original 6800 interpreter so that I can step through the compiler on both platforms.

Got a few previous threads for you:
Compilers for the 6502 running on the 6502
Is Comal lost to time? (mentions DOS65 which "came with editors, assembler, C and Pascal compilers etc" (not to be confused with DOS/65))
PLASMA (language, compiler) for Apple II (at the time of the thread was being ported to be a native compiler) (repository now here)
Apple IIa - a Basic compiler, as a replacement ROM
A C compiler (to a 32 bit virtual machine running on 6502) (hmm, may not be native... mentions HyperC which is/was native, and links to the thread "A new C compiler for the 6502 and derivatives")

Edit: see also
Cowgol 2.0 compiler for the 6502

There have been C compilers that ran natively on the 6502 - Aztec C was the first one I used on an Apple II - no sources online that I'm aware of though.

Comal, Pascal and a small C variant all run on the BBC Micro - along with the built-in assembler in BBC Basic and a 16-bit BCPL. The down-side of these is that you need a fairly good "clone" of the Acorn MOS (Machine Operating System) to host them - and the Pascal was 2 ROMs, so BBC Micro hardware support for that - I suspect the Pascal and C ROMs also do tricks that would make porting them to another system very tricky

(I can run the Comal, BBC Basic and BCPL ROMs directly in my Ruby 6502 system, but some ROMS just won't work - Acornsoft Forth and Wordwise refuse to work - I guess they poke the hardware directly in some weird way and the BCPL ROM won't work on my Ruby816 system while BBC Basic and Comal do)

dFlat by Dolo Mia - something on my ever grown to-do list:
memberlist.php?mode=viewprofile&u=2219
https://github.com/6502Nerd/dflat

Assemblers - I used TED II+ on the Apple II - even after I had a BBC Micro (BBC Basic has a built-in assembler)

And then there's UCSD Pascal - I have looked at this and more or less given up - all the sources are there, but I think the efforts of porting it might take a little longer than I want. It also wants its own filing system on disks, so you need to expose some sort of block interface to the underlying media.

Apple Logo - the sources were published recently (And BBC Micro Logo in ROM, but no sources)

I think one of the issues might be getting a good IO subsystem going - even if you use a serial terminal, you really need a filing system to support a language - and that all takes up ROM space. The Apple II had essentially 64KB of RAM (Who didn't have a 'language card'?) so space for things like UCSD Pascal. The BBC Micro has almost 16KB of operating system, then 16KB Banks of ROMs for languages, filing systems, utilities and so on and 32KB of RAM.

I think the issue is not just getting the source code, but porting it to your platform. A lot of sources have been lost over the years, so have been re-generated from disassembly (e.g. EhBASIC, and BBC Basic) and some may just have too many machine dependencies.

And unlike CP/M for the 8080/Z80 there has never been a standard over the 6502 range - Acorn kept something reasonably familiar over the Atom, Proton (BBC Micro), Electro and Master range - and it had parallels in the '816 communicator and on to their ARM systems.

Apple had some familiarities from the Apple II to the Apple /// then the IIgs, but I don't think it was easy going.

I also don't think there's any traction in us here (or elsewhere) trying to publish a standard either - I suspect we can count on the fingers of one hand the number of people using DOS/65 or whatever the other one is called. Everyone has their own ideas and ideals. Even if I published my RubyOS, I suspect the response might be "oh that's nice, but not for me"... And the Acorn people have real BBC Micros, and the Apple people have real Apple IIs, etc.

(And I fall into that camp myself - I having a collection of BBC Micros and Apple II, IIe, ///s ...)

The Commodore PET people (PET, Vic20,C64, etc.) Another hard lot to please.

There are many others out there - I'd suggest asking to yourself something like "what's their value to me" and "how long do I have to port it"...

I picked BCPL as I was familiar with it from a long time back - the 16-bit variant is still very usable today, but the effort to get the 32-bit version going was sufficiently hard that I have no plans to write any more '816 code and I've enjoyed going back to the 6502 for my TinyBasic projects so much that I will likely stick to it in the 65xx world from now on and am moving on to other CPUs for my BCPL work (specifically RISC-V)

So who knows.

-Gordon

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

Great resources Thanks Gordon!

Edit: another previous thread
viewtopic.php?f=1&t=6137
Writing code on your build (not cross assembling)

I'll just throw this out there as well...

In order to have the development environment running on your local SBC, you'll also need (or at least want) to have a local filesystem and some minimal level of support for applications.

Needless to say, I've spent quite a bit of time working with Richard Leary's DOS/65 code. My current CMOS 3.20 version is contained in 5KB for CCM and PEM and my custom SIM adds 1KB to this. The only additional RAM requirements are for allocation maps, which can easily be 256 bytes per 8MB drive partition. In short, I have a system running with 8- 8MB drives contained in 8KB of RAM loaded DOS/65. The BIOS is another 2KB and low RAM usage for the system itself is 2KB. This can provide 52KB for a transient program area with another 2.5KB accessible by overwriting CCM.

Also note that DOS/65 has an editor, Assembler and BASIC compiler and run time module along with some basic utilities... and all of these are running fine on my 3.20 version. With a little effort, you should be able to get this system running on any 65C02 based system with a minimal BIOS and have a self contained development system for assembler and BASIC programming. Writing an additional high level language would hopefully be easier in this scenario.

Of course, just my $0.02.

_________________
Regards, KM
https://github.com/floobydust

Did you add macro capability? I do not recall that it had that...

Just to add a different data point to this... The filing system doesn't have to be/may not need to be fancy at all - The BBC Micro got by with a cassette tape filing system very well. Even the BCPL ROM could use it - it wasn't fast (but at 1200 baud not the slowest either) but it had a memory pool system where you could keep the source in RAM, then load the editor, compiler, linker, etc. write object to RAM or back to tape and so on.

It managed this because the Acorn MOS filing system had 2 levels of file operations - one was "file at a time" the other was similar to a Posix open/read/write/close mechanism. If you stuck to the "file at a time" method the BCPL (and BASIC, Comal. some word processors, and probably others) did work very well.





It might be interesting to know just how people people have ported DOS/65 to their systems?

And of-course I could say that writing an additional high level language under my RubyOS would be equally easier. It has a great little editor, a good macro assembler (ie. BBC Basic!) and run-time support.... There is a C run-time library for cc65 in 65C02 mode, (which you need to cross compiler, sadly), or native BCPL support for bigger programs needing more data, but no-one is rushing to ask me about it or offering to "take my money" for it ...

And I think that's the crux in our 6502 land. Too many solutions and the "not invented here" Or "it's not like the first 6502 I used" ... I want my X16 ... Ben Eater, etc ...

This is also reflected by the number of people who have ported my TinyBasic (or at least by the number of emails/replies I've had) to their system. I can count with with the fingers of one hand. At least the ones I know about.

If you want DOS/65 traction, then get Ben Eater to do a video on it...

-Gordon

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

Oops! You're correct.. no macro capability... I was thinking the older C64 MASM package, my bad. Edited post to correct.

Also, the assembler does not handle anything beyond the original NMOS opcodes and addressing modes. At some point, it would be nice to update the assembler, but time is limited

_________________
Regards, KM
https://github.com/floobydust

Well darn it, I thought I was going to get to pat you on the back and congratulate you on a job well done.

My recollection was that Richard strove to duplicate the CP/M experience, both for good and bad with the exception of not using Digital Research terminology such as CCP, BDOS, etc.