I've asked several times before about porting old operating systems to the 65xx architecture.

But what about a current one, that is getting more and more attention in the world of microcontrollers?

I'm talking about MicroPython, and I'm asking the experts if the 65816 could have its own port.

Edit: MicroPython isn't an operating system...

Because Python is so wonderful?

But serously, why not? Any CPU is capable of running code written for it, and '816 is pretty fast and flexible.

Could '816 have a MicroPython port? Yes, if someone ports it. Maybe you should!

But there are much better languages out there.

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

I suspect we're looking for a simple, easily learnt, high-productivity language. I imagine any language I name would have some disadvantages.

In fact, maybe also a popular language, which cuts things down a lot.

From what I understand (and note that I'm not a fan of Python so this may be inaccurate or biased), MicroPython compiles into a bytecode which is then interpreted on the target system. Typically you might run the compiler on a separate system but it is possible to do some development on the target via a command line interface.

So on the target you need to write the bytecode interpreter/VM and provide all the back-ends it needs to function.

Note that MicroPython has no notion of banked memory, so you need to make the 64K banks completely transparent to the run-time. A Python program can and may allocate large chunks of RAM ( > 64KB ) and just iterate over it, so the VM needs to be aware of this.

There has been a port of MicroPython to a 16-bit PIC controller, so it may not be outside the reach of someone who wants to do the port but almost all the others are ARM or RISC-V. (Although I think there is a generic one written in C that may be a start, but it's not going to be efficient).

I have done a port of another language (BCPL) that compiles to a bytecode, and again, this language has no notion of a banked memory system and will happily allocate 300KB of RAM for some applications and expect it to be linear, addressed via a 32-bit pointer.

So, what about a port of MicroPython?

It's probably possible on the '816, so go ahead - do it yourself, or wait for someone to do it for you, or pay someone to do it for you because it's not going to happen by magic.

Cheers,

-Gordon

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

It's not so small that the runtime would fit in 64k, so the build of micropython would - if I understand correctly - need to be partitioned into bank-sized chunks with long calls between them:

If I read that correctly, then the run-time is 256KB - that's 256KB of compiled MicroPython, compiled into its bytecode. The run-time only needs 16KB of RAM to run, so 'HelloWorld" Will just be a handful of bytes on-top of that 256KB?

(Or is the run-time configurable as to just how much run-time you need?)

So the bytecode interpreter/VM still needs to be written and that will need to "linearise" the RAM that the run-time library lives in along with the data - just in-case someone decides to calculate Pi using the arbitrary precision integers and starts with a 100,000 digit number...

In a way that's not much different to my BCPL system - the bytecode VM interpreter is 16KB of '816 ASM, it needs a few dozen bytes of zero (direct) page, but to run a BCPL program there is some 48KB of run-time libraries and the command line interpreter which is all compiled BCPL. MicroPython has much more though - list handling, long integers and so on and that's what's increasing the size of the run-time (I guess).

It's still do-able on an '816 with 512KB of RAM though. (Which my Ruby board has and maybe if I had any enthusiasm for Python I'd look at it, but I've not, so I won't)

-Gordon

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

Yeah, I'm finding it quite hard to see how much executable code is needed and how much of the 256k is bytecode. The '816 is quite suited to interpreted (or bytecoded) languages because, as noted here and elsewhere, the program space is somewhat demarcated into banks whereas data space is (or can be) flat.

It looks like there is a python compiler in there, so cross-compilation is needed for bootstrapping but optional thereafter.
http://docs.micropython.org/en/v1.9.3/p ... ained.html

Also perhaps of interest, an explanation of a 500-line python bytecode interpreter (aka vm):
http://www.aosabook.org/en/500L/a-pytho ... ython.html

From asking around in #micropython on IRC, it seems the minimal port is 100% C and then it's up to whoever is doing the port to convert parts of it to bytecode as they see fit.

The documentation mentions "frozen bytecode" which is generated on another system and then runs from flash on your embedded system: http://docs.micropython.org/en/v1.9.3/p ... ained.html

The new trend in graphing calculators is to run micropython. Casio came out with it's new FX-9750GIII a few months ago which runs micropython on a 59MHz SH4. I got one for $39 not long ago and unlike the top of the line TI and HP models, it also allows native code execution. I'm very impressed.

So.... Given that there is some interest in MicroPython and based on my experience of writing a bytecode interpreter for another language that compiled to a bytecode I would suggest that it's possible on an '816 with (say) 512KB of RAM.

The question is: who is going to write the bytecode interpreter/VM for MicroPython?

I'm available for hire, but my rates are not low for this sort of work...

-Gordon

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

I would try to know first if it's worth it. How a 816 could compare to a PIC in terms of performance when running that VM machine?

I doubt very seriously that anyone is implementing micropython in assembly on any platform. The C port might work if you're ok with losing a lot of performance.

Well it seems that the virtual machine that reads and executes the bytecode needs to be programmed in assembler, doesn't it? Or could it be programmed in C?

Also, there is also this feeling that most of the current CPUs, are not "efficient" in terms of how they execute code: they run fast because of the higher and higher speed and / or number of cores, but not because the internal engine that actually executes the instructions has been optimized enoguh.

In another words: would a good, optimized MicroPython VM written in assembler for the 816 be slower per se running at the same clock speed that a PIC counterpart?

_________________
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?

Well, after reading that thread you linked to, it seems that Bill Mensch/WDC won't be that interested in getting something like MicroPython or whatever else working on the '816 architecture anytime soon, then.

This could be done by some individual or company that should have a very good reason to have a '816 doing the work instead of PICxx or ARM based MCU that would have a lot more flexibility and community support.

Speaking of mickeymouse, I for one am pretty happy that there is a steep gradient separating this community from the Arduino/RaspberryPi mikeymousketeers trying to outdo each other on theytube.

I've done a bunch of AVR assembly, and it's actually not too bad if I remember correctly (especially after trying to use the PIC). But it is possible to have tools that are too easy to use. I don't know anyone in the Arduino crowd who knows the names of the AVR registers. Twiddling IO pins from dumbed down C++ (as if it was not dumb enough) is fun, and there is always a bigger 'duino when your 'sketch' won't fit... Then get a Raspberry Pi. Glue a bunch of LEDs to a baseball cap and make an 'instructional' video. Big fun.

It was a great relief to find a community of people who build and write thoughtful code, and often design their own machines. The level of technical discussion here is not matched anywhere else. I am pretty happy we don't have MicroPython, or any other 'easy-to-use' IDE.

I know from experience that sometimes it is pretty hard to figure out how to get something done, but getting Forth to work (and learning amazing intricacies along the way) and using it the way it was intended is so much more joyful than figuring out which library to import from 50 megabytes of crap that updates itself daily.

Enough of kindergarteners. Screw MicroPython. Or not.

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