Self-hosting 65xx systems ... (Languages, OS, etc.)

[BigDumbDinosaur]

barnacle wrote:

It strikes me that most first-systems as pointed out earlier have a big issue: 6502, [check], serial i/o, [check], video of some flavour, [maybe], keyboard input [maybe], file storage, [um]... for my mind a system needs three of those four components (serial i/o is nice to have but not absolutely necessary if the others are there).

...and of those four components, the “human interface” (keyboard and video) and mass storage vary wildly.  Serial I/O, the TIA-232 form at least, is standardized and should work no matter whose system is being used.

[drogon]

dourish wrote:

When I was a kid, I wrote myself a Pascal compiler for my BBC Micro. It used the exceptional structured programming features of BBC Basic to implement a recursive descent compiler producing an intermediate p-code, which was then executed by a runtime virtual machine interpreter. (I don't remember whether I also wrote a translater for the p-code to native code.) Sadly, the disks that held that code have (at best) been stuck in my parents' attic for decades and are surely lost to the ravages of bit-rot.

Now that's just jogged my memory of another BBC Micro project - a Book: The BBC Micro Compendium by Jeremy Ruston... It was banned/withdrawn before publication but I manage to persuade my local computer shop to sell me one a day early.... Inside as well as an annotated disassembly of BBC Basic (why it was banned) there were compilers for 2 languages - one a forth-like thing called Froth and another - SLUG - Structured Language of Universal Greatness.

I think they'll be well worth a re-read when I get back home soon...

(There's a few pages of chat about the BBC Basic disassembly inside it here, but not of the other parts of the book: https://stardot.org.uk/forums/viewtopic.php?p=206035 )

-Gordon

[BigEd]

(Book available online here)

[CronicBadger]

commodorejohn wrote:

One of my oneathesedays projects which I haven't touched in a million years is to come up with some kind of uber-simplified object-oriented system (ala Smalltalk, but CLI-oriented - so, ala GNU Smalltalk, I guess) which could run on a reasonably-specced 8-bitter.

For the past five years I've been intermittently working on a little vanity project that touches on this. It's a modular application framework that provides useful (to me) features including:
- Objects: User-definable functions, handle-based creation and deletion of instances of the function. Data and parameters can have default and inheritable values.
- Reactive Finite State Machine: Uses hierarchical nested state charts that have inheritance, internal and external actions, guards on those actions, etc.
- Domain Specific Language shell with built-in shared features such as loops, call-backs and pattern generation.
- Decision Tables: Nested and linked, caching, actions, column/row short-circuit, call-backs, absolute and indirect evaluation modes.
- Tabular iterator/evaluation: Point the variable-step iterator at a user-defined handler/transformation routine and multi-dimentional data tables. Trades speed for extreme compactness.
- Lots of other esoterica such as array and record management systems, general memory allocation, x-windows style nested windowing system for text and bitmap graphic modes, pattern-code generator, multi-dimensional deque shifter and comparison system...

Whether or not I ever finish it is an entirely different matter.

[BillG]

When I began work on an implementation of an interpreter for LUCIDATA Pascal P-code on the 6502, I had hopes that the compiler would work when it was finished.

The interpreter can currently run every program I can throw at it except for the compiler itself. It uses a couple of undocumented instructions nothing else uses plus I suspect there are errors in the execution of some of the P-codes. The 6502 interpreter includes a debugger - I need to implement that in the 6800 interpreter so that I can watch the compiler execute in parallel on both processors.

That would be my first tool for native development on a 6502. I have another project to convert the 6800 FLEX assembler to assemble 6502 instructions executing on a 6502; it is about half finished.

[commodorejohn]

CronicBadger wrote:

For the past five years I've been intermittently working on a little vanity project that touches on this. It's a modular application framework that provides useful (to me) features including: [...]

Nifty

Quote:

Whether or not I ever finish it is an entirely different matter.

Story of my life XD

[drogon]

BillG wrote:

When I began work on an implementation of an interpreter for LUCIDATA Pascal P-code on the 6502, I had hopes that the compiler would work when it was finished.

The interpreter can currently run every program I can throw at it except for the compiler itself. It uses a couple of undocumented instructions nothing else uses plus I suspect there are errors in the execution of some of the P-codes. The 6502 interpreter includes a debugger - I need to implement that in the 6800 interpreter so that I can watch the compiler execute in parallel on both processors.

That would be my first tool for native development on a 6502. I have another project to convert the 6800 FLEX assembler to assemble 6502 instructions executing on a 6502; it is about half finished.

Now... Interesting as that's sort of what I did with BCPL - I had a working compiler (written in BCPL) and a working run-time system (Linux) and a full description of the bytecode, so in theory all I needed to do was write the bytecode interpreter/vm and Bobs your uncle... And actually it more or less was. I started by compiling 'Hello World' then writing the bytecodes for that program and going from there, trapping unimplemented instructions, writing then, running more/bigger programs until I achieved the 'holy grail' of compiler-test program and running the compiler.

I had a quick look at Lucidata Pascal - the 'bytecode' is more like a 'word' code - in that every opcode appears to be 32-bits wide - it's a shame there appears to be some undocumented ones though.

It might actually be a vehicle to getting a Pascal working on my system, who knows...

Cheers,

-Gordon

[BillG]

drogon wrote:

I had a quick look at Lucidata Pascal - the 'bytecode' is more like a 'word' code - in that every opcode appears to be 32-bits wide - it's a shame there appears to be some undocumented ones though.

I documented what I know here:

https://github.com/BillGee1/P-6502

[drogon]

BillG wrote:

drogon wrote:

I had a quick look at Lucidata Pascal - the 'bytecode' is more like a 'word' code - in that every opcode appears to be 32-bits wide - it's a shame there appears to be some undocumented ones though.

I documented what I know here:

https://github.com/BillGee1/P-6502

Thanks.

-Gordon

[drogon]

drogon wrote:

Now that's just jogged my memory of another BBC Micro project - a Book: The BBC Micro Compendium by Jeremy Ruston... It was banned/withdrawn before publication but I manage to persuade my local computer shop to sell me one a day early.... Inside as well as an annotated disassembly of BBC Basic (why it was banned) there were compilers for 2 languages - one a forth-like thing called Froth and another - SLUG - Structured Language of Universal Greatness.

There is a recent interview with Jeremy Ruston here:

https://www.infoq.com/presentations/bbc-micro/

-Gordon

[GlennSmith]

Hi all,
A quick update from very hot SW France:

• - I have completed a build of a "RP6502" (the Rumbledethump picocomputer system) which works very nicely

• - I have started to port the PLASMA (resman) system to the said rp6502 platform to try it out. More news on that soon.

• - In so doing, I discovered the rake "maker" that uses the Ruby language (I hate cmake), and I've written some very simple Ruby code (a Rakefile) that allows me to do all of the compiling and linking for the rp6502 rom image

I'll post my findings about PLASMA (it would be nicer to call it "Plasma" - no shouting!) once I get a working interpreter going on the rp6502, but I find the language quite easy to get used to (the Plasma VM is written in Plasma) and so far I like it.
TTFN

[BigDumbDinosaur]

GlennSmith wrote:

A quick update from very hot SW France:..

Probably not nearly as hot as it will be in Death Valley this afternoon.    The forecast is for a high of 116º F (45.5º C). 

Quote:

I'll post my findings about PLASMA (it would be nicer to call it "Plasma" - no shouting!)...

Historically, many operating systems and languages were all capital letters.  I “grew up” with FORTRAN and COBOL.  Back in the day, Ken Thompson’s and Dennis Ritchie’s favorite operating system was “UNIX,” not “Unix,” etc.  C came from B, which came from BCPL, etc.  So, referring to Plasma as PLASMA is historically acceptable.

Speaking of which, what are you using for mass storage?

[rwiker]

BigDumbDinosaur wrote:

Historically, many operating systems and languages were all capital letters.  I “grew up” with FORTRAN and COBOL.  Back in the day, Ken Thompson’s and Dennis Ritchie’s favorite operating system was “UNIX,” not “Unix,” etc.  C came from B, which came from BCPL, etc.  So, referring to Plasma as PLASMA is historically acceptable.

Most of those were acronyms, which are normally written in uppercase. Unix is probably not an acronym, although it was trademarked as "UNIX". PLASMA is an acronym, and this is also the way that the creator writes it.

In recent years, the preferred form is capitalized: Fortran, Basic, Cobol, Common Lisp. That might make sense for PLASMA, too, but you would not be able to write it like that on Apple ][ and Apple][+ computers, since they do not have lowercase

[BigDumbDinosaur]

rwiker wrote:

Unix is probably not an acronym, although it was trademarked as "UNIX".

According to the authors of THE UNIX PROGRAMMING ENVIRONMENT (Kernighan - Pike, Prentice-Hall 1984), “UNIX” is a pun on “MULTICS,” which was the project that Ritchie and Thompson worked on before the latter got started on what would become UNIX.  I dimly recall from a lecture or some such thing that “UNIX” was originally spelled “UNICS.”  In the referenced book, both “MULTICS” and “UNIX” are consistently upper-case.

Quote:

PLASMA is an acronym, and this is also the way that the creator writes it.

In recent years, the preferred form is capitalized: Fortran, Basic, Cobol, Common Lisp. That might make sense for PLASMA, too, but you would not be able to write it like that on Apple ][ and Apple][+ computers, since they do not have lowercase

Preferred by whom?    Cell phone users who are too lazy to properly spell words?    BASIC, for example, is an acronym that has always been rendered all upper-case.  Ditto for COBOL and FORTRAN.

[GlennSmith]

Quote:

(BDD) Speaking of which, what are you using for mass storage?

That's the neat thing with the rp6502 - the pico is providing the mass storage on standard USB Keys/Drives (std FAT filesystems) via an API that is completely integrated with cc65. I'm doing some donkey-work to provide the interface layer inside the Plasma compiler in native 65C02 assembler.

BTW - how do you guys get the "BDD says" title into the quote banner ?