Well... My SBC does also actually works. It uses a '265 with 256K or RAM and 32K of ROM and it does nothing more that booting in default ROM Monitor mode. Does it count?

Also, I was wondering if the MicroPython implementation could be done in a "non-interpreted" mode.

I mean: instead of trying the '816 to read bytecode after it being compiled in a PC and execute it in a realtime VM, why not having a PC that would cross compile MicroPython code directly to assembler?

The programmer could write code in MicroPython, compile it to bytecode in the development PC, use an emulator to test it and then, when satisfied, use a different compiler that would output a binary, that would run optimized on the '816.

I suppose that would satisfy the purpose of writing a program in Python and running it on your SBC (and yes, well done, of course it should qualify!)

I'm not sure I'd exactly call that MicroPython, because you won't have the welcoming command line interface and Python interpreter available.

Check out Cython for something like this.

Sure - you might have to prune the run-time library to get it to fit - or expand the RAM to 512KB.





Probably, but it would increase in size somewhat dramatically. If I did this naively on my BCPL system, then each byte is going to expand to something like 30-100 bytes. That's non optimised (ie. naively) so I'm sure you might save some with optimisation, but it's hard to say how much.

-Gordon

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

Ahhh... I was confusing it with the PiTubeDirect widget - forgot that it was real hardware.

-Gordon

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

There is this "java grinder" project has already has been talked about here, working in the "non interpreted" way I was talking about.

Python is a very popular programming language which has been about since the early 1990's. It's often said that Python is the new BASIC and is popular in schools and universities as it enforces a structured and object orientated approach.

It's used in real-life situations - and e.g. SpaceX use Python to build their test framework for the flight control software.

the Raspberry Pi is called Pi not after 3.14 but after Python and the Pi foundation concentrate heavilly on using Python as the main programming language for their teaching applications on the Pi.

So Python is here to stay and it's not going away.

MicroPython is a slightly cut-down version designed to work on Microcontrollers. (Typically 32-bit ARM, but ports to others exist including Super-H and RISC-V)

There is even a derivative called CircuitPython - https://en.wikipedia.org/wiki/CircuitPython



It's bloated from the perspective of old folks and retro system with limited RAM. It's compact and fast on todays desktop and modern embedded systems. MicroPython is an attempt to run Python on microcontrollers in manner that would enable desktop Python users to learn and use microcontrollers. It's been ported to most modern 32-bit microcontrollers and there are now many systems that boot directly into a running MicroPython application

As for it being a good fit - you may well be right there - but I don't think it's impossible - I really don't think it's a much bigger task than my port of the BCPL Cintcode system to the '816. What would it achieve? A nice warm feeling for the person doing the port and with the right hardware then it might attract newbies to the thought of using a retro system and give them some appreciation of the history behind it. (as an alternative to say, 'look, we went to the moon with a computer less powerful than the microcontroller is in your USB wall-wart charger')

The '816 is still being manufactured, so I'd love to know if the '816 is actually being used in some real-life project today. The small handful of people here building them (and including the Foenix/Neon systems) probably won't account for more than (say) 500 ICs in total, so where are the rest going? Or is it really economical to make chips in quantities of < 100 units now?

-Gordon

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

It seems WDC's core business is not manufacturing but licensing (like ARM does).

Some uses of it: https://www.westerndesigncenter.com/wdc ... ations.php

My guess is that there are still products that need the chip to be manufactured but that new products haven't been designed with it in a very long time.

I was ROFLing at this thought: what if WDC is a sham and we are the only paying customers? Laundry for the cartel? Where are the billions of 6502s, really? Not in anything in my house (not counting my Apple and Atari machines) - I looked. There is a suspicious glob in my multimeter, but I doubt it's a 6502. And I don't have a pacemaker (yet).

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for another excellent contribution to the thread, BDD.

Again, you'll have to qualify what you mean by bloat here. There is a price to be paid for the advantages the language offers and that's not "bloat." On the other hand, if you mean the language is a lot bigger and slower than it has to be to do what it does, I would love to know how you came to that conclusion. I'm sure the BASIC you mentioned is fast, but that comes at a price too.

I know we skew old here, but I think it's a shame that old school engineers seem so dismissive of modern computing. The past is where the nostalgia is, and where I guess we all developed a fondness for the little 6502.

A lot has happened in the past 45 years, in computing, architecture, and languages. I've rolled my eyes at the seemingly unstoppable progression of the language-of-the-week. Each language promises to be better (by some metric) than the last, or be designed to solve a problem or make coding safer, etc.

But, that doesn't mean these things are without merit, and not worthy of study, even just for study's sake. I still like to learn new things. Sometimes that "new" thing is reading up on the Apollo Guidance Computer, and taking a look at the Luminary code that sent us to the moon. Last week I watched a youtube video on the history of the BASIC language at Dartmouth, and that sent me on a journey to learn a little something about the GE DATANET-30 and its instruction set. And recently there was news of the Rust language being accepted into the Linux kernel as an option with which to write kernel drivers, with type and memory safety... so I started to dig into Rust a little and see what it is and what it can do.

C++, Python, Go, Rust, Lua... These languages are MASSIVELY popular. C++ keeps evolving into a better language, in my opinion. Certainly if I need to write some C++ code today, I'm not writing it using the constructs and syntax of what I learned in the 90s. Although I was late to the game with Python, having only started to use it in the past few years, I'm starting to really like it. I tend to use it for little utilities, e.g. do a thing with a file; slap on a header; sign it... or something trivial like that. But even these little utils are a joy to write; and certainly easier to iterate on than with C or C++.

I'll get off my soap box now... but one more thing: When I was a teenager and I first learned about computers, about BASIC and then assembly language, everything I learned was just awesome. It was all new and exciting. I started on a Z80, then a reduced instruction set on a 6502.. then a big step up to a 68000. Each step was a joy... Confusing at first... frustrating... but then immensely enjoyable. Similarly with high level languages. Starting with BASIC with nothing but GOTO and GOSUB, then a BASIC with real procedure call support, then at college Pascal and it's type-ness, then 'C' and its power and direct interface to the operating system. Every journey is a journey of discovery and wonder.

Why would you ever choose to stop?