Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

6502 Perl

by rje (Deacon)
on Dec 11, 2019 at 20:15 UTC ( [id://11109995] : perlquestion . print w/replies, xml ) Need Help??

rje has asked for the wisdom of the Perl Monks concerning the following question:

Has anybody tried to write a Perl dialect that runs on a 6502 machine?

Because I'm a retro-programmer sometimes, I want a Perl dialect that could have been written in 1982. To be super-particular, a Perl dialect that runs on the X16 ( or the MEGA65 (

TL;DR: Some of you might find this idea stupid. This post has no value for you. Thank you.

To start out, I downloaded and examined Perl 1, Perl 2, and Perl 3, just to see how the language evolved in those first few years. Granted, even Perl 1 is too powerful for 6502-based hardware. I even looked at NQP, which is also far too powerful -- but it was useful for seeing how Perl could be reduced, so to speak.

Aside from the severe constraint of fitting into a laughably minimal 16K block of ROM, it's yet a thought experiment I occasionally wonder about. Some of you might also find the idea diverting.

Even though the end product would be very weak, I still think it could be recognizably Perl.

Here's what I'm pretty sure would disappear.

The shebang (#!)




System, threadlike, and socket-based ops

Here's what I think would maybe still be there.

Arrays and some array ops.

Some file operations.

Sigil-based types.


A subset of control structures (looping).


Replies are listed 'Best First'.
Re: 6502 Perl
by dave_the_m (Monsignor) on Dec 11, 2019 at 22:45 UTC
    For an idea of scale, looking at 17-year-old 32-bit x86 perl binary, just the object file compiled from pp_hot.c is 47k. This file contains just the run-time for the most commonly-used ops in the perl interpreter - i.e. the sorts of things you'd still need in a heavily stripped down perl dialect.


Re: 6502 Perl
by afoken (Chancellor) on Dec 11, 2019 at 22:02 UTC

    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.


    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      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.

        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.
Re: 6502 Perl
by davido (Cardinal) on Dec 12, 2019 at 19:00 UTC

    This SO article is a good walk down memory lane: 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...)


        "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.

Re: 6502 Perl
by LanX (Saint) on Dec 11, 2019 at 21:22 UTC
    I remember discussing with my boss if Perl could ever run in the RAM of a C64.

    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)


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

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

      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

Re: 6502 Perl
by stevieb (Canon) on Dec 11, 2019 at 20:21 UTC
    "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, IC 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 IC receive. Also, IC 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.


        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: 6502 Perl
by cavac (Parson) on Dec 18, 2019 at 16:42 UTC

    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.

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