Dave.

Do you know Lua? Not quite Perl, but usable, and written entirely in C. Small enough to run on an 8 bit AVR microcontroller. So it should be possible to run on a C64 or similar.

Other ideas:

• Forth, used for Open Firmware (a.k.a. OpenBoot) in Sun, Apple, IBM, various ARM systems
• MUMPS, originally designed to run on 1960s hardware. It is a very compact, yet very powerful combination of language interpreter, database, and multi-user, multi-tasking operating system. Learning all of MUMPS takes no more that 10 days if you know Perl, expect to write your first non-hello-world program end the end of day 1. Some of my postings contain example MUMPS code.

Alexander

I agree that FORTH would likely be doable (and maybe even almost easy).

I wonder if you could squeeze sed or awk into such a tiny footprint?

Doubtful, I guess, since both are pretty well tied to regex engines.


Mike

I very successfully built a "truly-compiled FORTH" on a 6502 machine – it actually generated subroutines – and I know that there were several TIL-based dialects for it also. Although the 6502 had some rather unique addressing capabilities, the fact that it only had three CPU registers and that two of them were only for addressing meant that it usually took quite a few more instructions to do things vs. other chips like the Z-80. Not what you want when you've only got 64K.

> Other ideas:
• Lisp
  the macro mechanism allows a modest implementation to develop powerful features.

edit

this "David A. Wheeler's 6502 Language Implementation Approaches" lists many more alternatives.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

This SO article is a good walk down memory lane: https://retrocomputing.stackexchange.com/a/6020/13676. It discusses what portions of the 64KB that could be mapped by a 6502 were used as RAM in an Apple II. There were a few bytes (256) mapped to device channels, and 12KB was the language module for Applesoft BASIC (10KB) and other low-level ROM stuff (2KB).

Keep in mind that contemporary BASIC implementations of the day were often in the 8KB to 12KB range. The slightly earlier generation of the 70s was often 4KB for the language. BASIC implementations were extremely simple; easy to parse, no actual subroutines (just GOSUB to line numbers).

And for architectures that facilitated memory bank swapping, I think you were limited to two banks. And there probably wasn't any shared memory other than the CPU itself that stayed in-place between swaps, so imagine how hard that would be to work with; any state that was needed across banks would have to be copied to both through a series of CPU register transfers and swaps. BASIC, of course, would never have exposed the ability to write programs that could access more than the 64kb of a single bank, without the programmer resorting to POKE/PEEK to do their own manual memory management.

Anyway, those were fun times, but you were a lot closer to the metal, and had a lot less resources to work with. It's one of the reasons that Perl was such a breath of fresh air for me as I first picked it up; coming from BASIC -> 6502 Assembler -> PASCAL -> Modula II -> C -> early C++... then suddenly discovering Perl.

Of course, if you were actually doing perl on an Apple ][, you'd probably want to use overlays, and swap in the overlays from the tape deck :) (Or, if you're lucky, the 140kb floppy...)

Mike

"Uh oh this needs a couple more CPAN modules; where'd I put the x-acto knife . . ."

(Also acceptable would be "where's the hole punch"; and if you don't get that, get offa my lawn you gol durned whippersnappers.)

The cake is a lie.
The cake is a lie.
The cake is a lie.

We decided to search first for a JS engine on the C64, because it's more minimalist.

But what I actually found was a C64 emulator written in JS ... grin xD

Seriously, it depends rather on the available RAM than the processor.

IIRC was the 6502 only able to address 64k, but there are clones which can do more.

(Kind of base-page addressing to switch the 64k blocks by setting an extra hardware register, I suppose)

update

both projects you linked to mention memory mapper for 1 or 2 MB, here you go.

I do vaguely recall there were memory boards for the Apple II's that would map another 64K in to some address space (and the IIc had 128K stock I believe (and wp seems to confirm)).

The cake is a lie.
The cake is a lie.
The cake is a lie.

And Commodore tried to promote the C128 with 128k virtual memory which was managed by an MMU.

IMHO quite expensive concepts as soon as you need to switch between the banks.

I can understand the sentiment that if BASIC could fit in why not a simplified Perl.

But this BASIC was implemented in Assembler, and one of Perl's selling point is it's portability thanks to C.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

"laughably minimal 16K block of ROM"

Hey now, I run several projects, including a full-blown community-based water purification plant on half of that :)

Not using Perl, but I digress...

Not a digression; an example of what is possible with minimal resources. Thank you.

I tend to feel a little defensive when posting on PerlMonks.

I run most of my "Garden Space Program"* experiments on similar contraints. Darn Arduinos with their ming-boggling constraints....

*GSP is a simulated space lander series in my own garden to learn electronics and stuff. See my blog for updates ;-)

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

Darn Arduinos with their ming-boggling constraints....

I really like the SAMD21, an ARM Cortex M0+ found on the Arduino Zero and many clones, e.g. Sparkfun DEV-13664 and Sparkfun DEV-13672. At work, we use the latter as prototype board for embedded systems based on the SAMD21. Chip45 sells various SAMD21 boards with a DIL32 form factor.

One great feature are the six SERCOM modules, that can be used as USART, I²C master and slave, and SPI master and slave, in any combination. DMA is a weak point, it generally works for sending out data, but receiving unknown amounts of data is simply not possible via DMA. This limits USART receive and I²C receive. Also, I²C read-after-write can not be controlled by DMA.

At chip45, I found the SAML21, which I really want to test out. You loose one GPIO pin compared to the SAMD21, and one SERCOM is restricted for better power saving, but get a lot more: A tiny block of configurable logic (think of it as a really tiny embedded CPLD), a second DAC, three OP-Amps, a random number generator, AES accelerator, switchable power domains, and a switching mode power supply in addition to the LDO also found in the SAMD21. The switching mode power supply is also the reason for the lost pin, it is needed for the supply.

A generic difference is that the ARM processors use 3.3V (or less) as I/O voltage, compared with up to 5 V for the AVRs found on the old Arduinos. Also, the ARM I/O pins can't sink/source as much current as the AVR I/O pins (ARM 2..10 mA vs. AVR 20 mA). Both is rarely a problem when driving LEDs or transistors, or when reading switch contacts. Many digital peripherals can also work at 3.3V instead of 5V. For the few remaining ones, you may need a level converter.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Hmm, you could start out with the WDC 65C816, which is a 8/16 bit descendent of the 6502. That one supports up to 16MB of memory and could serve as an intermediate step for your project.