Python

[Dustym]

Is/was there a version of Python for the Model 1 ever available.
I've just been asked and I have no idea!!

 

[ldkraemer]

oops, I was searching for Pascal.

Larry

 

[BartH]

Python was developed in the late 80's at the CWI in The Netherlands, its first release was Python 0.9.0 in 1991. This was well after the heights of the Z80 so no contemporary Python implementation for the TRS-80 has ever existed. There are a few lightweight implementations as PyMite and Python-on-a-chip but none for the Z80.
The other way around is easier to find: there are quite a few Z80-emulators written in Python!

Bart

 

[Dustym]

Thanks Bart, I couldn't recall it from 'in the day'. I quest it was a bit late for the trs-80 range

 

[Zare]

There is nothing 80s in Python. Its development was throughout the 90s. The language that made an impact was Python 2, a 21st century language.
Python 2 does not run on 16 bit platforms.

 

[Agent Orange]

There is nothing 80s in Python. Its development was throughout the 90s. The language that made an impact was Python 2, a 21st century language.
Python 2 does not run on 16 bit platforms.

The other day I was going thought a shoebox of old CD's and found a folded cardboard like guide for "Shanghai", a Mahjongg type game. I did a deep search and could come up the matching CD. I then went online and found the game on some site and downloaded it to my XP gamer (32-bit). As the game was installing, there was a pop-up for a version of Python, which needed an okay, and evidently was part of the game's setup. So the install process continued and it ran as I remembered from long ago. First time I've ever encountered anything visible concerning Python. Hope your coffee didn't get cold reading this.

 

[krebizfan]

Micropython does run on at least one 16-bit microcontroller. https://github.com/micropython/micropython/tree/master/ports/pic16bit I think even Micropython is too large for the Model I.

 

[danielbooneamerica]

Micropython does run on at least one 16-bit microcontroller. https://github.com/micropython/micropython/tree/master/ports/pic16bit I think even Micropython is too large for the Model I.

More the reason to upgrade to TRS-OS and its guest operating systems TRSDOS 6 and soon to come a newer 24 bit version.

Built to take advantage of eZ80 24 bit addressing and can tear into micropython with power to spare.

Join the millions that have upgraded today!

Daniel Paul Martin

Personal, work and research site.

danielpaulmartin.com

 

[Eudimorphodon]

Built to take advantage of eZ80 24 bit addressing and can tear into micropython with power to spare.

Really? Is there an eZ80 port of MicroPython you've tried?

Texas Instruments makes a "Python Edition" of the TI-84 Plus CE calculator, which is based on the eZ80... and it runs a weird fork of CircuitPython on an ARM co-processor instead of running it on the eZ80. Early versions of their "python app" did this externally with a silly dongle.

Supposedly the root cause of this situation is limitations with the available C compilers for the eZ80, but, *shrug*, not my circus, not my monkeys.

 

[MrImprovement]

The ABC language was a precursor to Python, it was worked on by the same author as Python, Guido van Rossum.

Early Python info, the early days: https://reinout.vanrees.org/weblog/2018/04/25/origin-of-python-abc.html

The original inspiration for Python was as a systems administration language, that is, it would be used the same as bash or perl.

 

[Chuck(G)]

I can't even begin to imagine what degree of "glacial" a Python for a 2 MHz 8080 would be. Heck, it's glacially slow on a 184MHz F4 ARM in comparison, to say, C. (see my results for MicroPi on the "Pi day" thread.)

 

[Eudimorphodon]

I can't even begin to imagine what degree of "glacial" a Python for a 2 MHz 8080 would be.

I think personally I mostly find the idea of using a language that depends on massively wasteful quantities of white space on a limited memory microcontroller mildly bemusing. Say what you will about BASIC, but if it’s a tokenizing interpreter you can at least pack it pretty tightly.

 

[Chuck(G)]

That's true--and quite often, on 8 bit systems, a good compile-to-p-code could give a compile-to-machine code version a run for its money.

 

[Zare]

Perhaps the question was merely trivia.

 

[Chuck(G)]

Perhaps the question was merely trivia.

Aren't most things here?

 

[Zare]

True true

 

[doshea]

I think personally I mostly find the idea of using a language that depends on massively wasteful quantities of white space on a limited memory microcontroller mildly bemusing. Say what you will about BASIC, but if it’s a tokenizing interpreter you can at least pack it pretty tightly.

I think in some ways that's fair, but in other ways it's not fair: if you were to compare Python and C source from the same person, I think you'd find the Python code had less "wasted" characters because it doesn't have the braces; the C code would still have the indentation because otherwise the code wouldn't be readable. It'd still have the indentation, right??

Okay, I get that the difference is you don't need to install the C source onto your microcontroller, but with Python you most likely would because I don't think there's a standard way to do compilation (not that I've spent much time learning about that).

 

[lowen]

Okay, I get that the difference is you don't need to install the C source onto your microcontroller, but with Python you most likely would because I don't think there's a standard way to do compilation (not that I've spent much time learning about that).

Python internally compiles to a bytecode that is then run on a bytecode virtual machine. You can precompile python code to a '.pyc' file that is quite a bit smaller than the '.py' source. See https://docs.python.org/3/library/py_compile.html for more information.

 

[jrd]

Darn you guys, you revealed my secret project! I wanted to spring it on the world and amaze everybody, but you let it slip!

Actually, I don't have any Z80 Python. It's only in my head. But I have been thinking deeply about what it would take to make a least a limited interpreter. Yes it would be very slow and crammed: probably needing lots and lots of overlays and all 4 disk drives online. Forget any bytecode: due to it's object-oriented nature Python's bytecode doesn't really gain you anything since the "instructions" are very elaborate for anything bigger than integer math. It would have to be more like threaded functions like Forth.

I do see a path to attack the problem. Ignoring the whitespace issue, Python needs plenty of lists, tuples, and dictionaries. There actually is a Z80 language that has a good chunk of the pieces you need: Lisp. Specifically, MuLisp and it's MuMath derivative. I've taken apart both the CP/M versions, and the TRS-80 MuMath, and I'm still amazed at how much that system really contains. The only difference between MuLisp and MuSimp/MuMath are the text of keywords (FIRST vs CAR), and having the MUSIMP.LSP & MUSMORE alternate language files already loaded. I've patched a version of TRS-80 MuMath back into MuLisp. It has many more list processing functions than the other Z80 Lisps. Parsing is configurable on the fly, with adjustable operator precedence. It even has BigInts built-in! And all of it was already available, buried inside the obscure 32K & 48K TRS-80 MuMath. In 1980! For only $75!

(Sorry, I'm raving again.)

Anyway, I've imagined (as a first cut) writing a Python-ish parser language in MuLisp, and see how many features can be crammed in. It can't handle meaningful whitespace, but we could do the slicing and tuple enforcement, and objects & methods as MuSimp partly does that anyway in associative arrays. Like Basic everything is global, so you'd have to hide intermediate objects as they're created. And MuLisp is very slow: could be 50 times slower than Microsoft Basic! (Rule of thumb on the Model I is a empty integer FOR loop is 500 per second. The equivalent MuLisp (LOOP __ ) is only about 10 per second! The disadvantage of BigInts.)

Only after experimentation could a real Python-80 be written in assembly from scratch. I have ideas, but would take me years. Maybe someday after I retire.

 

[doshea]

Python internally compiles to a bytecode that is then run on a bytecode virtual machine. You can precompile python code to a '.pyc' file that is quite a bit smaller than the '.py' source. See https://docs.python.org/3/library/py_compile.html for more information.

Thanks, I forgot about that. I was aware that they're used as a cache for imported modules, but this stackoverflow question explains how you can compile the main executable scripts too, and then run them via the interpreter. Unfortunately that has the small drawback that you now have to run python3 foo.pyc instead of (if your file had a #!/usr/bin/env python3 or similar line) just ./foo.py.

Lisp

I don't really know anything about Z80s and TRS-80s, but when I wanted an open-source interpreter I could extend that would run natively on Windows 3.1 (not just a DOS one) recently, I found that the Python interpreters available for that platform (all of which were Python 1.x) seemed to all be a bit too big and have dependencies I didn't want. I thought to myself: what small interpreted languages were popular back then? I figured Lisp and Forth (perhaps people here might have had some other/better answers, I'm not an expert there), and from hunting around I found XLISP-PLUS, and although its Windows 3.x support had been inadvertently broken in its most recent release, I fixed that (and one day I'll get around to posting that on GitHub hopefully!). I guess I had the benefit of having some previous knowledge of Lisp from using Emacs, but I think it's a nice, powerful language in its own right, and I'd be tempted to just try to add some modern niceties to it rather than try to change its syntax. Perhaps though it's a terrible language to use if you don't have an editor that helps you match up the parens?