Posting this as a placeholder in case anyone feels brave.

Elsewhere Scot mused

which prompted me to have a look. It turns out there are a couple of miniature pythons, although they are both a bit large for a 64k address space and have not, I think, yet been ported to 6502. They are C projects - is cc65 up to the task? I don't know.

PyMite requires roughly 55 KB program memory, initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM.

Micro Python takes around 75kb of ROM and can run in as little as 8kb RAM

I think PyMite puts only the execution engine on the target - you compile your python source down to bytecode on a more capable host. With Micro Python, it looks like you get the full interpreter on the target.

There's also PyNES, which has a game-writing library, not sure if it's good for general python. There are a couple of video presentations too (which I confess I haven't yet watched).

Python is not something in which I'm interested, but I do have to wonder if the best approach for running it on 65xx hardware is to "port" it to assembly language. I've yet to meet a 6502 C compiler that emits succinct code. Even the output of WDC's C compiler tends to be somewhat corpulent. Of course, the "port" would probably include a lot of tedium...but that's to be expected.

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

Is the goal of this project to produce something useful, or just a a proof of concept?

One way to squeeze a miniature Python into a 64K address space might be to use a byte code VM at the expense of performance. If I recall correctly Sweet16 code is considerably more compact than native 6502 code at 1/10 the speed of native code. So have a C compiler target a bytecode VM, then having a C compiler target that VM might be a way to port it.

On my part, merely musing on what might be possible.


I think PyMite is like this: the 6502 part is only the VM, with the upfront compilation done on the more powerful host. (Python bytecode article.)

To know whether the 6502 need only be the execution environment, or also the host, is a question for the user! As Python is a much bigger language and almost infinitely harder to parse than Forth, it's certain to be more of a challenge. The payoff would be in the programmer productivity. But you'd have to ask why do this on a 6502...

Not on the 6502 forum!

Having this be a demonstration project greatly increases your range of options. There's a project called the worst Linux PC ever: http://hackaday.com/2012/03/28/building ... x-pc-ever/

It boots Linux on an AVR running an ARM emulator attached to external memory. If someone can shoehorn Linux on an eight bit microcontroller then Python on a 6502 should be possible.

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

Agreed!

If you want a scripting language on 6502, maybe start with Lua instead.

Why?

Because of fools like me.

I am the kind of guy who gets thistles in his garden, or moles, or whatever, and looks around in his shed to see he has none of the proper tools. But a can of gas. And a lighter. This has potential. But how to not burn down the entire property? Aha! A garden hose. I envision a solution.

So, having made a reasonable beta-test "Technopoly / 6502-opoly" game, I am thinking of ways to perfect it.

In keeping with open source and FOSS, and GPL GNU/Linux etc principles, and the original game of Lizzie Magie (not to mention the 1970s guy who fought Parker brothers in Court; or the circa 1990s Microsoft employee who made a "anti-monoply", technopoly game, too), I have decided the plan of the physical game should be open and free. Completely.

Plus I prattled on and bragged about it here for about a decade now. It would be hard to keep it a secret.

But I recently (in the last 4 or 5 years) noticed there are SBCs (Single Board Computers) for sale at WDC. Cheap and / or reasonable.

I should design a board into each of my boards. No reason for a board game to be boring. Lets put the 'tech" in technopoly!

But, in addition to plopping an SBC in the middle of the physical board; I am interested in commericalization of a fully computertized version of the game (s). The design of my game has 352 IPS (intellectual properties) instead of 22 physical properties. Its more like real life. Too many things out there to monopolize them all!!! And a hassle to keep the cards organized and hand them back and forth. Computer "windows" and a computer game, makes more sense for such complexity (no "clean up time afterwards! OR annoying time to "set up" a new game, from the last set of people who didnt put everything away properly; or lost the pieces!)

So, thus, my gasoline and garden hose analogy. I can't code. Barely an assembly language / machine language guy. Putting together my "Ben Eater" 6502 kit, right now. But I cobbled together two or three python (pygames "plugins" or "libraries") "monopoly" snippets of code, from on-line, and academic sources, and have a reasonably functional board, with pieces that go around and land on squares.

Pretty neat for a guy who is competent in 0.5 high level languages.

So. It probably runs on a raspberry pi. I have pi zeros. I think I ran it there once? But right now just coding on a Windows 10. Some editor. Notepad ++ maybe?

But I think my system is glitchy there? So I shuffle the files over on a flash drive to run on my Linux computer instead. (Both windows and linux computers are Dell latitudes; 6420 and 6520). A sturdy, no frills machine. Both of them. I think.

I should github the whole thing. In case I have to move this year. Which I might have to.

Or at least start posting some files of the pieces and boards on this forum somewhere. And the intial rules. While I beta test.

But anyhoo. garden hose. gasoline. I see a job that needs doin, and I get innovative with tools I have no business using.

But python on 6502? I like the idea. In case its the only language I ever learn.

But if I can get the physical game working, and a good python version of the game, too, next step is to try to write an android version.

Upload to an app store.

Make a BO-Zillion dollars !!!!!

But first? Make a playable game, that is fun.

Oh yeah? My Byte Dice !!!! I lost them in Vermont !!!! Now that I have landed in Vancouver, and I have some spade bits... I should find some extra wood and some pennies. But Canada outlawed the penny!!! I'll have to use Nickels !!!!

Inflation.

You just can't get good byte dice for 8 cents + sweat and electrons anymore. 5 * 8 = 40 cents Canadian. or 30 cents Uh?Murican ...

I think its a neat idea. Not sure how useable it would be just due to sheer limited resources. You may find yourself out of memory pretty quickly.

After I made a CC65 target for my SBC a couple of people on discord made a comment about how the compiled code is bulky and slower than ASM. I mean, of course it is. But that's often the trade off of a higher level language. Quicker development -> bulkier slower code. I was able to whip up a game of snakes in 20 minutes in C, that ran at full speed and was under 6k in size. If I wrote it in ASM would it of been faster? Yes. Would it of been smaller? Yes. Would of it of taken me a lot longer... ...yes.

I'm relatively new to 6502 but I've been programming in multiple languages for years, it always irks me when someone complains that Language A is better than Language B. It's relatively objective if the language you use, fits your design criteria and runs your application within spec.

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

I looked into Python for the 6502 before settling on Forth for my system. The options that BigEd listed are the ones I found in my search. The power of Python is in its multitude of libraries. It'll hard to replicate that for the 6502. I like a challenge but that is a steep hill to climb.

Python implementations are big because the language is interpreted. The interpreter includes all of the features of the language whether they are used or not.

Many trips around the sun ago, I joined a makerspace where I experimented with the Arduino and began to learn Python. I thought Arduino is popular and Python is popular. Why can't we program an Arduino in Python?"

I set out to implement a Python compiler. Yes, a compiler. By not requiring an interpreter implementing the entire language, we have a fighting chance to get some programs to run on the microcontroller of the Arduino.

Initially, I had concerns around the 2K bytes of RAM in the Arduino. Because a Commodore 128 was on display at the makerspace available for me to use, I chose the 6502 as the initial target.

The list of features currently implemented:

Dynamic typing
Types: integer, string, True, False, function (partial)
Automatic memory management (using reference counting)
Variable precision integers
Integer operators +, -, *, //, %, &, ^, |, <<, >>
Variable length strings
String operators +, *
Relational operators ==, !=, <, <=, >, >=
if else elif
while else break continue
print function, including sep and end keyword arguments
input function
hardware access functions: peek, poke
randint function
int function
hex, oct and bin functions
str function
exception handling
find method for string type

The negative is that it is a cross compiler running on a PC clone. You cannot interactively write a program on a 6502.

That's an impressive list of features!