A 6502 With A Custom Language

The 6502 has a long history with hackers. The Apple computer (the one with no keyboard or even case) had a 6502. So did the Kim-1. [Dolo’s] version is a bit more refined, though. He started it a few years ago in response to one of our contests, but he’s been making improvements to it ever since. In particular, the custom programming language, Dflat, has many improvements lately, including true functions and high-resolution drawing.

The hardware has a CPU running at over 2.5 MHz, 44K of RAM, 16K of PROM, and 16K of video RAM. There’s plenty of I/O, including a keyboard, sound, and joysticks. An SD card provides mass storage and it all goes in a hacked BBC Micro case. You can see an overview video, below.

The hardware is on a breadboard, which is always tough for a circuit this size. However, the really interesting part of this is the structured language similar to Basic called Dflat. As far as we can tell, this has no relation to [Al Steven’s] D-Flat language from the 1990s. This Dflat has provisions for driving the 6502’s video, sound, and other I/O.

The language handles integers and strings and although there are line numbers for editing, they are not used as control targets. It also supports one-dimensional string arrays and two-dimensional integer arrays.

This would have been big iron back in the day, and the breadboard construction is neatly done. If you prefer a Z80, you can breadboard that, too. If you want even more breadboards, there is always this.

13 thoughts on “A 6502 With A Custom Language

      1. Rockwell had a 6502 based microcontroller that ran FORTH, but I remember looking into it and it was just a FORTH interpreter in ROM, not a modified 6502 that better processed FORTH. Around that time, there were some expensive computers which could handle FORTH or such as a native language.

        I gather that the Apple III decoded some instructions externally to handle the larger amount of RAM and such. Around that time there was an article in Byte about doing that, I thought for the 6502 but if not it would have been the 8080 or Z80.

        Of course, around 1980 there were some articles about interfacing calculators to CPUs, to add floating point math. Very slow, I remember my TI-30 churning before displaying the result, but maybe no slower than doing it in software, and you didn’t have to write the floating point software. I was never sure it got to market, but early 6809 literature listed a ROM with floating point routines, a compromised between writing software and using a math processor.

        Michael

    1. Criminy! This is great!

      I did very similar and about the same time and also as a FIG-Forth engine (I was working at Mountain View Press). Too bad there was no easy way to find like-minded people at the time. I did not do anything with op-codes. Instead it was all memory mapped into zero-page, as he mentions in the beginning. This means all the addressing modes can be used.

      Specific locations increment or decrement when read or written. A pointer can increment by 1 or 2 depending on which addresses you write to and result is always read at the same place. Also some hardware assist for NEXT. This cries out to be done in an FPGA today.

      Then I got carried away with a trick that is really useful. I mapped EPROMs into zero-page to do things like ‘instant 8×8 –> 16 bit multiply’. Write the 2 bytes you want to multiply to the 16 bit address of the PROM(s) and read the result on the data pins. I used a pair of 8 bit EPROMs to get high byte and low byte results. Generating the data for the EPROMs is trivial. It was all on a wire-wrap board for an Ohio Scientific system. I wish I could find it.

      Then comes an EPROM with a bunch of smaller tables, like ASCII to HEX conversion, trig functions, upper to lower case, etc. Basically anything that does a conversion or calculation with a lookup table. I have often wished for address and data lines on an Atmega328.

      How fast can a synthesized 65C02 run in a gate array?

  1. My first home-built computer was based on a 6502 chip purchased at the First West Coast Computer Fair. Bought the hardware manual, but didn’t think I needed the software manual (purchased later, of course). Took a month to understand how it knew the difference between instructions and data. Programming in assembly language is a great exercise for anyone wanting to know how computers actually work. Learned that anything longer than one page needed to be a subroutine. All pencil and paper code development. My start-up ROM was just a few diodes to get things started. Programmed using hexadecimal toggle switches. Ended up writing a program to read a polyphonic keyboard to play music along with the music already stored in RAM. Program to do all of that was 19 BYTES. Loads of fun!!! Since then, learned microcode – the stuff that actually converts the assembler to the physical actions of opening and closing switches and moving data inside the CPU.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.