High-level programming languages *on* the SBC

[floobydust]

drogon wrote:

floobydust wrote:

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.

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.

Quote:

Also note that DOS/65 has an editor, macro 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.

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

All good points... and agreed, too many solutions and the "not invented here" mentality, which has been a 6502 stumbling block from the start. Still, the 6502 has maintained it's popularity despite all of it.

Sadly, it's near impossible to track, much less determine how many have ported (any version) of DOS/65 to their systems. My Github page still has numerous hits and downloads pretty consistently for the DOS/65 versions out there, but no way to tell if anyone has actually ported it to their system.

Re: Ben Eater. Well, an interesting idea... but that would require him adding some sort of block storage device to his breadboard system, write some level of BIOS for it and port the code over, plus some level of testing. From my end, I don't feel the need to have others wanting to use any of my designs and/or code. I simply make all of it available and answer any questions that come up from interested parties. I've no desire to make any $$ from it, as this is strictly a hobby for me... I'm retired at this stage and just enjoy spending part of my free time in the 6502 world... and then there's all of the other parts of life, of which there are far too many, but I do enjoy keeping busy!

[floobydust]

BillG wrote:

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.

Yes, sorry for the false hope on this one... at some point it would be nice to have macros and cmos support... hopefully I (or someone else) might get around to it.

And yes, Richard has different naming conventions, but they do work out... there's also the SIM module which does a fair amount to bridge to whatever hardware one might have, and is very specific to matching up to PEM.

At some point, I'd like to get a system design completed to run Fuzix... but that will be quite far out in the future...

[BigEd]

I'm not sure I'd emphasise not-invented-here so much... it does exist, but also
- it's harder to make software portable than not
- most people have a favourite system and don't know so much about other systems
- it's harder to make something modular, when it's your first effort and you're figuring things out
- most projects are done for one's own satisfaction, or for one's own learning - it's harder to make educational projects than personal projects

It would be good, of course, if more 6502 software projects had a clear internal API for functions like reading and writing, standard i/o or files. It would be good if they had some configurability of how they use zero page, and of which area of the address space will be RAM.

But once a project is dealing with banked memory, or memory-mapped screens, it all gets less portable.

[plasmo]

I've ported DOS/65 to CRC65. I plan to port DOS/65 to 65ALL as well which is similar enough to CRC65 that the initial port (serial port user interface) should be straightforward. What complicate the porting is the addition of 65ALL's video display and PS2 keyboard; PS2's scan code and VT52 support will make SIM bigger. The video display also need 4K video memory, so TPA is likely to lose 6-7KB which will put it in mid 40K range. That, in turn, will put pressure on the size of editor/assembler/high-level program.
Bill

[sburrow]

drogon wrote:

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 ...

I had to go look up what "not invented here" meant. Now I see! I am a *big* NIH person, personally. A lot of the solutions that were posted have some type of licensing involved. I'm ok with some of those, but I'm a strict anti-copyright kind of person by nature. So I do tend to re-invent the wheel every time, but that's just my nature and I won't be changing anytime soon. It has nothing to do with 6502-land, it's just a "Chad" thing.

I went looking at some of the DOS/65 stuff just now. It seems like (and correct me if I'm wrong) DOS/65 gives some basic 'assumed subroutines' that any program can use, such as "print character" or "read bytes" or something? It probably also gives a basic structure to how files should be organized. But is that it? Could someone use one of these programs intended for use with DOS/65 but simply modify those basic 'assumed subroutines' to suit their own SBC? Or is that just called "porting"?

So far it seems there is no perfect solution. Perhaps an assembler with some good keywords would actually be best in the end... I know I would not be capable of meeting all of the requirements for Pascal or C, but I can make my own flavor of BASIC without too many folks thinking less of me I suppose.

Thank you all for the responses so far!

Chad

[barnacle]

NIH is a thing here chez barnacle, too... because my aim is not to necessarily 'do' something, but to see whether I can; for me, that's the challenge. As might have been noticed from my construction posts...

Neil

[floobydust]

sburrow wrote:

drogon wrote:

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 ...

I had to go look up what "not invented here" meant. Now I see! I am a *big* NIH person, personally. A lot of the solutions that were posted have some type of licensing involved. I'm ok with some of those, but I'm a strict anti-copyright kind of person by nature. So I do tend to re-invent the wheel every time, but that's just my nature and I won't be changing anytime soon. It has nothing to do with 6502-land, it's just a "Chad" thing.

I went looking at some of the DOS/65 stuff just now. It seems like (and correct me if I'm wrong) DOS/65 gives some basic 'assumed subroutines' that any program can use, such as "print character" or "read bytes" or something? It probably also gives a basic structure to how files should be organized. But is that it? Could someone use one of these programs intended for use with DOS/65 but simply modify those basic 'assumed subroutines' to suit their own SBC? Or is that just called "porting"?

So far it seems there is no perfect solution. Perhaps an assembler with some good keywords would actually be best in the end... I know I would not be capable of meeting all of the requirements for Pascal or C, but I can make my own flavor of BASIC without too many folks thinking less of me I suppose.

Thank you all for the responses so far!

Chad

I think most of the folks out here tend to build their own hardware and also write most or all of their own software, so the NIH attitude is fairly typical on the forum it would seem.

DOS/65: I'll attach the system description that Richard provided with version 2.x (3.x was only a differences doc mostly), but in short, DOS/65 provides the same system functions as CP/M did for 8080/Z80 machines. It also uses the same disk format for data storage. It's more than a collection of routines.... but, similar to CP/M, you do need to do a little bit of work to integrate it to your hardware. There's also a system integration guide that helps with that.

DOS-65 System Description B.pdf

(160.09 KiB) Downloaded 112 times

DOS-65 System Interface Guide B.pdf

(253.12 KiB) Downloaded 109 times

Take a quick scan thru these and lemme know if you have any questions... hope it helps.

On the hardware side, you need a console device and a block level storage device. You also need some simple routines to send and receive characters to the console device (Async works great) and basic block read and write routines for storage. These can be quite small depending on the hardware and are generally referred to as a BIOS.

[drogon]

sburrow wrote:

drogon wrote:

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 ...

I had to go look up what "not invented here" meant. Now I see! I am a *big* NIH person, personally. A lot of the solutions that were posted have some type of licensing involved. I'm ok with some of those, but I'm a strict anti-copyright kind of person by nature. So I do tend to re-invent the wheel every time, but that's just my nature and I won't be changing anytime soon. It has nothing to do with 6502-land, it's just a "Chad" thing.

I went looking at some of the DOS/65 stuff just now. It seems like (and correct me if I'm wrong) DOS/65 gives some basic 'assumed subroutines' that any program can use, such as "print character" or "read bytes" or something? It probably also gives a basic structure to how files should be organized. But is that it? Could someone use one of these programs intended for use with DOS/65 but simply modify those basic 'assumed subroutines' to suit their own SBC? Or is that just called "porting"?

DOS/65 gives a "standard" set of functions which programs can use. It also provides a filing system - a way to store files on disk (which these days is typically CF or SD, etc.)

Broadly speaking it's CP/M for the 6502. (Which does the same thing)
See: https://en.wikipedia.org/wiki/CP/M

The lowest level might be a "monitor" with simple routines for "print character" and "get character from keyboard" level. Other monitors may be more clever.

Some history (in my timeline/experience anyway):

So the Apple 1 had "WozMon" - a tiny utility (250 bytes) that provided print and get characters and utilities to manipulate memory.

Apple II had an enhanced version for more screen manipulation in addition to simple print character, as well as facilities to manage plug in cards, etc. it included a mini assembler and disassembler.

At the same time commodore had their "kernal" - not a "monitor" as such but a set of routines to aid screen manipulation and character entry. That carried on to the VIC20 and C64 range (and now the Commander X16)

Similarly OSI/Compukit/UK101 had a 2K monitor to do the screen/keyboard "stuff" and support BASIC.

There were a few other 6502 systems in the late 70s/early 80s doing their own thing too - Oric and Microtan-65 to name just 2...

Meanwhile Acorn was developing their MOS - Machine Operating System - larger and more feature full - but that's the benefit of being a few years later and full of Cambridge graduates - the Acorn MOS does sophisticated graphics and screen modes, sound, tape and ROM filing systems as well as providing a standard way for applications to access a filing system - which was in separate ROM (or ROMs as there were several different types of filing system including network). For it's time it was quite sophisticated - it allowed for a 16K "language" ROM (e.g. Basic, or a Word processor) and a 16K filing system ROM to occupy the same physical address space - the OS was at a separate address space and as long as you called the OS routines correctly it could switch off the language and switch on the filing system ROMs and return as required. It's probably the most sophisticated of the 6502 monitor/OSs and it's what I modelled my RubyOS on - to the point I can run some Acornsoft ROMs unchanged - e.g. BBC Basic.

Quote:

So far it seems there is no perfect solution. Perhaps an assembler with some good keywords would actually be best in the end... I know I would not be capable of meeting all of the requirements for Pascal or C, but I can make my own flavor of BASIC without too many folks thinking less of me I suppose.

Thank you all for the responses so far!

Chad

when I wrote my TinyBasic, I originally used the routines in RubyOS - it provided not only character in and out, but a means to print strings and get lines of text with line editing and command-line history recall. As I moved it to the '134 system I had to "port" it to use the built-in ROM in the '134 and then I eventually worked out how to turn that off and replace it with my own code - it's not even a monitor, literally 2 routines that hook into the serial port Tx and Rx interrupts which TinyBasic call call for character IO. My 6507 version has nothing - there is just putchar and getchar which bit-bang the serial pins. No interrupts, no buffers, no "monitor" commands...

For a brand new system then DOS/65 may well be a good choice - you will need to port it to your hardware which may involve writing/re-writing the character IO parts and the methods to access the disk hardware, but other than that, you should then get a usable system with some utilities to make it work...

Or... Throw it all away, design your own and off you go...

-Gordon

[drogon]

One other thing I'll add to this - about Filing Systems..

I wrote my own filing system for RubyOS. Nothing special (from my point of view, at least). Multi-volume, Heirarchal supporting long filenames (22 characters) with nothing special about the name (the full-stop dot, is just another valid character). No big deal to me as writing a filing system isn't new to me, and I was writing it in C. It supported the extended attributes that Acorn filing systems need to support - namely load address, execute address as well as length.

It worked well.

The issue was getting files on and off the SD card it ran on. I implemented a serial line file transfer protocol. It works well but needs a custom terminal program running on my Linux desktop (which I have). My grand plan was to write a version of the FS that would run under Linux using FUSE, so I could put the SD card in my Linux systems, mount the volumes and copy files to/from it - mostly for backups and to quickly load up a new SD card if required.

That never happened.

It was also looking more likely it was never going to happen, so I decided on a Plan-B and moved over to using FAT-32 with an off-the-shelf library written in C. It was just a few hours effort to migrate everything over to it and as if by magic I had SD cards I could read/write on my desktop or laptop. The down-side was that I lost the Acorn file attributes, but decided that I'd default (binary) file load and execute address to $8000 - as I've never used anything different on my Ruby boards. I'm sure one day this may come back to bite me, but I'll live with it for now.

The DOS/65 filing system is CP/M compatible. Files are multiples of 128 byte blocks and there is no length attribute - text files are typically terminated with a Ctrl-Z - program files don't really matter as it's no big deal to load all that last sector.

But can the SD/CF/etc. cards be read elsewhere? There are some tools to read CP/M disks under Linux, but I don't know about other platforms. I think now, it's something I'd want to know if I were starting again.

Anyway, just some thoughts to ponder over...

-Gordon

[BillG]

drogon wrote:

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

Logo is good for a simple way to program some graphics.

Pilot is another relatively small language.

[drogon]

BillG wrote:

drogon wrote:

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

Logo is good for a simple way to program some graphics.

Pilot is another relatively small language.

Logo is relatively general-purpose - good at list processing style things. The turtle-graphics were a good teaching/leaning aid though. I've done lots with turtles over the years including writing a Turtle graphics interpreter in Applesoft BASIC...

https://www.youtube.com/watch?v=O6Uc0Ck-LNo

Pilot - I'd forgotten about that, despite starting to write a Pilot interpreter in BASIC. Apple had (I suspect) one of the better implementations of it designed for some CAL (Computer Aided/Assisted Learning) type stuff.

A couple others in the "learning" category - CESIL and LMC.

CESIL: I wrote an interpreter for it a while back:

https://projects.drogon.net/cesil-contr ... pberry-pi/

Same for LMC:

https://projects.drogon.net/lmc/

Not really general purpose though, but relatively easy to implement in a high level language like BASIC (Which I did), or assembler.

-Gordon

[sark02]

drogon wrote:

CESIL: I wrote an interpreter for it a while back:

Now there's a language I haven't thought about in a long, long time.

CESIL was the 2nd "machine language" I learned; the first being Z-80. Had to use CESIL in O'Level Computer Studies in 1983.

Thanks for the memory jog.

[drogon]

Here's another (re-remembered as I've been reading all the Niklaus Wirth recent posts)

Modula-2.

It seems there as an Apple IIgs (so, 65816) version of it back in the day and the sources are all online:

https://github.com/pkclsoft/ORCA-Modula-2

It's all in Modula-2 though, so bootstrapping it might be interesting if building it again for another platform.

-Gordon

[resman]

HLL on a SBC is quite a challenge. Some are too low level, not meeting the HLL requirement. Some are too high level, making the compile process overly painful. I've been working on and off for more than a decade on making PLASMA fit right in-between. It is more of an environment now than just a compiler. As such, it requires a pretty robust file system. So that would be the first order of business to work out. Once done, then perhaps you could decide if PLASMA fits the bill:

https://github.com/dschmenk/PLASMA

Taking concepts from Forth, Pascal, C, and others to create a good, balanced solution. You can cross-compile on modern iron or develop right on the metal. I targeted the Apple II and Apple /// with a (simplistic) port to the Apple I. You can watch a (very unprofessional) video series showing off development on an emulated Apple II:

https://www.youtube.com/watch?v=_JEqbcz ... f4SP2Gw3yU

Dave...

[drogon]

resman wrote:

HLL on a SBC is quite a challenge. Some are too low level, not meeting the HLL requirement. Some are too high level, making the compile process overly painful. I've been working on and off for more than a decade on making PLASMA fit right in-between. It is more of an environment now than just a compiler. As such, it requires a pretty robust file system. So that would be the first order of business to work out. Once done, then perhaps you could decide if PLASMA fits the bill:

https://github.com/dschmenk/PLASMA

Taking concepts from Forth, Pascal, C, and others to create a good, balanced solution. You can cross-compile on modern iron or develop right on the metal. I targeted the Apple II and Apple /// with a (simplistic) port to the Apple I. You can watch a (very unprofessional) video series showing off development on an emulated Apple II:

https://www.youtube.com/watch?v=_JEqbcz ... f4SP2Gw3yU

Dave...

I keep looking at this and I keep thinking I want to give it a go... but it's going to take a lot of time to port it to e.g. my RubyOS system - which has a robust filing system and it's own environment - but do I want another environment on-top of that? I don't think so. What say the DOS 65 people? although replacing COM in the CP/M world is often a thing so maybe there is traction there?

I then wonder if the compiler could target a different bytecode - e.g. the BCPL CINTCODE so I can run it under my BCPL OS on the '816, but I suspect the compiler and language are too tightly tied together - much like the BCPL compiler, language and bytecode is.

But having a bit of a poke around again... I see a couple of things - one is the apple /// version (along with the 1, II, etc. versions) and a BBC Micro implementation...

Now I have a few Apple II, //e, //c systems and an Apple /// (but no external drives for it) so there might be some fun there. I never really got into ProDOS though... My RubyOS is broadly compatible with the Acorn MOS, so there is a possibility it may work on my RubyOS in 6502 mode.... So there might be fun to be had there. No banked/pages RAM though, even though it has 512K - that's for the 816 only right now. Could I implement some banked RAM with it? Yes, but it's a board redesign and an extra GAL. Is it worth it? Not right now. Not to me, anyway.

But under RubyOS the OS is from $C000 upwards and other than RAM used by the OS (more or less the same as a Beeb) the bottom 48KB is free - programs are expected to load and run at $8000 though, but that's not fixed in stone.

If only I had the time...

-Gordon