IRC Forth Chatbot

After putting in a lot of work on the 2023 Project Goals for my presentation at HHC 2023, I decided to take a break and work on a few other things for a while. One of those things is a chatbot that connects to IRC and runs Forth code it receives from users. My inspiration for this is the geordi bot which evaluates C code and also runs on IRC. Testing short programs and showing the results immediately is really useful to demonstrate language concepts. Although my Forth chatbot was a really fun project to work on and taught me a lot about several different technologies, I decided not to finish it in the end.

The chatbot is split into two parts. The main program is a Python script that connects to IRC, handles communication, and runs the terminal interface that manages the bot. The second part is a shared library written in C that the Python script loads and calls into to run the Forth code submitted by users. The library is written in C to maximize performance.

6507 Graphing Calculator: Forth Virtual Machine

As my last post explains, my goal for 2023 is to finish enough projects to give a presentation at HHC 2023. One of the biggest jobs will be finishing the 6507 Graphing Calculator I've been working on the past few years. The latest stage of the project was rewriting part of the firmware in Forth to save space, which turned out to be a failure.

When I last worked on this project, the firmware had reached 9.3K which well exceeds the calculator's 8K EEPROM. This wasn't so concerning since it seemed plausible at the time to implement a tiny Forth core and shrink the firmware by rewriting parts of it in Forth. Also, some parts of the existing firmware, which is all written in assembly, could be improved to save space. With this plan in mind, I started implementing a preprocessor in Python that scans all of the project's assembly files for Forth code and converts it into bytes to embed in the assembly source code. The Forth core uses token threading so each Forth word in the source produces just one byte rather than two as in direct and indirect threading or three with subroutine threading. The Forth system is initiated with a BRK instruction which jumps to the software interrupt handler and begins interpreting the bytes following the BRK. This saves two bytes for every invocation of the Forth system over using JMP or JSR. One of the tokens in the Forth system is assigned the same number as the BRK op code and increments a counter when executed. A corresponding token at the end of each function decrements the counter and switches from Forth back to assembly when the counter reaches zero. With this setup, the program can jump from assembly or Forth to a function written in Forth and continue executing seamlessly. 

7400 Logic Calculator: Revisited

In January, I made a post about my 7400 Logic Calculator project coming to an end and my ideas for improving it. After thinking about the project again this past week, a lot of new ideas came to me for fixing most of the problems with the last design. The new design also incorporates a lot of the ideas from the last post. As I explained in another post, my plan is to focus on a short list of projects for 2022, so I decided to document my ideas for the new design rather than restart the project.

Architecture

The new design is a 4-bit architecture rather than an 8-bit architecture like the last version. One thing that complicated my ideas before was trying to figure out how to drive the ALU with a register and another source, latch the ALU output, and write it to the correct place. The new design handles this by using two 74HC670s as 4-bit register sets feeding the ALU directly to avoid the complication of having the ALU on the bus so other sources can drive it. As a result, anything that goes through the ALU needs to be loaded into a register first, which is not a big sacrifice since the two 74HC670s provide eight 4-bit registers. Latching the ALU output also simplifies the design since an instruction only needs to read or write to the ALU but not both in the same instruction. A 74HC574 latch can optionally be trigged to capture the carry bit of the latched ALU output so it can be fed into the next ALU operation.

Other than the ALU and set of four register pairs, there is a 74HC193 counter that supplies the bottom four bits of the address for an 8K SRAM. This register is named X. The next eight bits are supplied by a 74HC574 "RAM pointer." It's a little unconventional to address the memory this way since it splits it into 256 pages of 16 bytes each. However, 16 bytes is the right size for holding floating point numbers, so the memory can be seen as holding 256 objects with the RAM pointer specifying which object. As a bonus, an instruction can trigger the clock input on the X register to count up, saving a few cycles when stepping through memory.

The next part of the system is a 32K EEPROM to hold the program along with four 74HC193 counters to act as the program counter. This is a pretty standard setup. The RAM pointer and X register combo mentioned above drive the EEPROM address through pullups when the program counters are disabled, so constants can be loaded from the program through a 74HC574 latch. Another latch captures instructions from the EEPROM, and a 74HC244 buffer transmits keypad input to the bus. There is also a control signal for an LCD which is connected directly to the output of the two register sets.

6507 Graphing Calculator: Update

After a few months of progress, a demo version of this project is on my website. You can try out all the functionality of the calculator in your browser since it runs on my 6502 emulator. Below are some updates since the last post.

Software The functionality of the calculator is close to complete. The Forth system is basically done and supports these new structures: IF/ELSE/THEN, DO/LOOP, BEGIN/AGAIN, and BEGIN/UNTIL. The only part missing from the Forth system is a way to look at the words and variables. Most Forths have a word called WORDS for this. My plan is to have a very simple list-based browser that will let the user delete words and will handle garbage collection. Logical operations like AND and OR have been implemented as well as CORDIC-based functions like SIN, COS, and TAN.

The firmware running in simulation is now a little more than 9KB, which is too big to fit on the calculator's 8KB EEPROM. The CORDIC routines especially take up a lot of room. I'll need to shave at least 2KB off of the firmware to get everything to fit and have room to implement the last few remaining features. My previous plan was to rewrite parts of the firmware in Forth. Now, I plan to also implement a byte-based virtual machine for floating point registers which should make the firmware much smaller and hopefully not sacrifice much speed. 

Features I plan to add to the firmware:

• Word browser with garbage collection
• Simple graphing
• Improved numerical output on the stack display
• New words: ATAN, ACOS, ASIN, MOD, ^, E^, LN

Hardware
There haven't been many updates to the hardware part of this project. The voltage regulator is a switching boost converter that generates 5v from three lithium AA batteries. These have good battery life for high current drain applications like this and also don't leak and damage the device the way alkaline batteries can. The boost converter will let me use the batteries down to a fairly low voltage, whereas a buck converter with four AAs would stop working when the batteries hit 1.3v and still have a lot of charge left. Picking the right capacitors and inductors for the regulator was a little tough since the exact ones listed in the datasheet have been discontinued. The few I picked to try seem to work but the voltage is too high when I run the regulator on a breadboard, so I'll have to wait until I solder it down to the circuit board to be sure.

Website The new page on my website for the project has the firmware running in my 6502 emulator with documentation for the project below it. Some of the documentation sections, like the word list, took quite a bit of HTML and CSS to arrange, so I made a simple markup system to generate the pages. The information for the pages is stored in a markup text file that is easy to read and edit. A Python script reads the file and generates all the HTML files which would have taken a very long time to write by hand. I'm not sure what tools people generally use for this type of job. The system I made was a fun sub-project and really saved a considerable amount of time.

There were also a few small updates to the 6502 emulator that the calculator firmware is running on. One is a check for indirect jumps where the low byte of the address is 0xFF. There is a well known bug in the original NMOS 6502 where those addresses are calculated incorrectly. It turns out that the new check I added to the emulator is not really necessary since assemblers do their own check, but I'll leave it in for now. The HTML layout of the emulator pages is also more modular and cleaned up so it's easier to add new projects that use the emulator.

Conclusion

Now that this project is at a stopping point, I'm going to shift my attention to a new project that I'm working on for my resume. This won't take as long to build as a calculator, so hopefully I can shift back to this project when that was is finished.

New Project: 6507 Graphing Calculator

Despite the decision in 2019 to finish up some lingering projects before beginning anything new, I did start working on a new calculator project. One of the members on the 6502 forum organized a contest about a year ago for projects using the 6507 processor, so I decided to make an exception and build this calculator as an entry. Most of my free time in 2020 was spent working on my Robot Game project before making a lot of progress on this project. Rather than a series of progress update posts like my other calculator projects have, this is one long post about the project so far. Some of this information is already available in the 6502 forum post on the project. 

Contest

The contest started in January 2020. The goal is to build something using a 6507 processor, 6532 RIOT, which stands for RAM, IO, and Timer, and a 2KB 2716 EPROM. After some discussion, a larger ROM of up to 8KB was allowed since it would be difficult for most people to program a 2716. The limit seems to apply to the total memory, so I may have accidentally disqualified myself by adding 2KB SRAM to the 8KB ROM. The 6507 and 6532 run at 1MHz and are both NMOS parts, so they consume a lot of current compared to the newer CMOS 65C02. The pair was used together in products like the Atari 2600. The 6507 is a reduced version of the 6502 and has 28 pins instead of 40, so it can only address 8KB of memory rather than the usual 64KB. It's also missing the IRQ and NMI interrupt pins. These limitations make it interesting to work with. The 6532 has 128 bytes of RAM, two IO ports, and a programmable timer, which is a lot of useful stuff to have in one package.

Hardware

The first 2KB of address space is occupied by RAM. Because the 6507 can only address 8KB, the last 4KB of address space is banked for the ROM. The 6532 takes 256 bytes of space leaving 1.75KB in the middle of the memory map that is assigned to ROM. Having a fixed amount of ROM there that isn't banked simplifies handling the banks and initializing the system. Here is the memory map:

• 0x0000 - 0x07FF: 2KB RAM
• 0x0800 - 0x08FF: RIOT
• 0x0900 - 0x0FFF: 1.75KB fixed ROM
• 0x1000 - 0x1FFF: 4KB banked ROM

The address decoding is done with a an ATF16V8C GAL, which is similar to a CPLD, though less capable. The WinCUPL software for programming these is atrocious and crashes frequently, but setting up the design for the GAL itself was pretty simple. The chips can be programmed just fine with the TL866II+ programmer that I use for EEPROMs. According to the datasheet, the ATF16V8C can draw over 100mA, so I also got some lower power variants to try to see if they save power.

The display is a 128x64 monochrome LCD compatible with the KS0108. This is the first time I've used a display like this and it works pretty well so far. The header pins are on the bottom edge of the screen, so it has to be turned upside down to fit the system I'm building. This means the font data has to be written upside down and backwards, which complicates things a little. It wasn't easy to find a completely free 5x8 font, so I made one myself. Later, I experimented with different styles to see what looks best:

The system would not start reliably on a breadboard, and I eventually tracked the problem down to sagging voltage on the breadboard. The problem was actually the jumper wires used to carry the supply current not the breadboard itself. Soldering everything onto protoboard fixed the startup problems and everything worked reliably after that:

There is still a good amount of work to do even though the hardware is pretty far along. The keyboard needs to be soldered and connected to one of the latches. There are a few possibilities for making the labels for the buttons that still need to be worked out. Another big part still missing is the power supply. The first plan was to run the system on four AA batteries, though this would waste a lot of power using a linear regulator or even a buck regulator since a lot of power would be left in the batteries by the time the voltage drops too low to use with a regulator. Instead, three AAs with a boost regulator will allow me to fully use more of the batteries' charge and also use rechargeables, which wouldn't be possible with the buck regulator. My plan is to use a MAX756 boost regulator, though I still need to set it up and test it. One cool thing about the chip is that it has a low battery indicator, which is something I was planning on trying to implement myself. The power supply also needs a way to be switched on and off by software control, so the keypad can have an on/off key rather than a separate power switch. This is really important so the system has a chance to save it's state before powering itself down. The last piece of the power supply system is a way to put the processor to sleep when it isn't needed. This can be done with the RDY pin. Hopefully, the timer and interrupt system of the RIOT can be combined with the GAL and software control to save energy while the calculator is between key presses.

Software

The interface is built around a Forth-style system with an 8 level stack of 8 byte objects. Unlike most Forths, there are three different types: floats, strings, and hex. The floats use 6 bytes for a 12 digit BCD significand and 2 bytes for the exponent and sign. Strings can take up all 8 bytes. Hex objects hold a 16-bit unsigned integer that can be used for memory addressing and come in two types: smart and raw. The raw hex type just stores a single 16-bit number. The smart hex type holds a base address, offset, and calculated sum of the two. The offset comes from any value added or subtracted to the object. This lets pointers be garbage collected since only the base needs to be updated then the existing offset can be applied to generate the sum. Garbage collection is also not a common feature in most Forths, but is definitely necessary for a Forth-based calculator with only 2KB of RAM to be viable. 

The Forth system is token based to conserve memory. The header of each word describes how many objects of which type the word expects on the stack. The dispatcher can check those objects and prevent stack underflow, which saves a lot of space compared to doing the checks in the word itself. Marking each word and piece of data with a token allows for garbage collection, since every piece of data that is a pointer which may change can be identified and updated when needed. 

So far, the basic Forth system including defining words, tick, and EXEC, and the four basic arithmetic functions for floats and hex objects have been defined. The main functions remaining to be implemented are loops, IF statements, and transcendental functions like sine and logarithms. The firmware is already 6.5KB, so there is very little room to squeeze in a lot of capability. My plan now is to continue writing everything in assembly, even if the firmware overflows the 8KB limit, then rewrite key parts of it in Forth to squeeze it into the available memory.

Floating point

The floating point numbers have a 12 decimal digit significand with guard, round, and sticky digits and rounding to even, which is the same format used by the HP-48 series of calculators. Implementing a floating point package is somewhat complicated and easy to make a mistake on, so a lot of testing is needed to verify the calculations. At first, I included tests in the firmware running in my JavaScript emulator, but this doesn't work well at all for a large file of test data. Next, I ported the emulator to node.js, so I can run the tests in a separate console window. This works by first generating a few million test calculations in Python using the Decimal package configured for the same number of decimal places and rounding style. The calculations are written to a file that comes to about 200MB then directed to the node.js emulator. The firmware running in the emulator reads the file generated by Python and performs calculations on the data there then compares the results to the results in the file and flags any that don't match. This system let me catch several errors in my code that would have been difficult to find otherwise.

Conclusion

Despite the months of work on this project, there is still a lot to do! In the coming months, I'll work on the keypad, power supply, and finishing the firmware, so I can finish the project and submit it to the contest.

Robot Game: 65C02 C, assembly, and Forth Comparison

The last six months or so, I have been working on a project to compare the performance of C, assembly, and Forth on the 65C02. This week I finally finished everything and published the results on my website. A few days later, the project was featured on Hackaday!

To compare the performance between the languages, I made a simple game called Robot Game in Python in order to have something to port. The C version is compiled with CC65 and the Forth version with Tali Forth 2. There are two assembly versions. One is plain 65C02 assembly using the X register as a data stack and the other uses the Assembly Optimizer I have been working on to get slightly better performance by putting locals in zero page at fixed addresses. All four version of the game work in my JavaScript-based emulator and can be played on my website. The source code for all the versions of the game, the emulator, and optimizer are now on my GitHub page.

Porting the four games was a challenge and also a lot of fun! I learned a lot about how C and especially Forth work internally. After I had the games ported, I looked at 28 different tasks the game does internally and compared performance across languages. Here are the results where traditional assembly is normalized at 100%:

The optimizer adds up to 10% performance and 25% in one very short routine. C was about 2-3 times slower than regular assembly in the tests and Forth was usually around 10-20 times slower. One of the really interesting things was figuring out why Forth is so much slower despite Forth fans claiming it's much better than C. 

Optimized MSP430 Assembly in Mecrisp Forth

A few years ago, I got interested in Forth due to its connection to RPN calculators but lost interest because of the huge hit to performance a stack-based system takes on an architecture like 6502. Recently, my interest was piqued again during a conversation in the #Forth IRC channel on FreeNode about Mecrisp-Across, which uses an ARM-based microcontroller board to produce optimized assembly for the MSP430. Because the compiler tries to keep values in registers instead of the stack, it has the potential to reclaim some of the performance lost in most Forths. Some of these optimizations might be useful for a 6502-based Forth, so I tried to understand how optimizations in Mecrisp work.

The first step was getting Mecrisp running on a PC. The author provides versions that are compiled for ARM with Linux system calls, so you can use QEMU for emulation under Linux. Getting this working on Windows was a real challenge. One Debian image I tried emulating with QEMU crashed the emulator outright. Another image booted into Linux but refused to install QEMU complaining about needing the Linux CD in the drive before it would install any packages. Getting Ubuntu working on VirtualBox under Windows 10 and installing QEMU on it wasn't too tough, but the Mecrisp image wouldn't run until I got the right type of QEMU (there are several). The right combination was VirtualBox, an Ubuntu image from OSboxes, and QEMU-user-static.