PIC32/6502 Blinky Robot

The PIC32 robot from my 2022 Project Goals is finally finished! Building it was a fun way to learn about the MIPS architecture and programming the PIC32. It was also a chance to work on a 6502 emulator that will be useful for other projects.

As far as robots go, this is not a very useful one since all it does is blink its eyes every few seconds. The interesting part is how it does the blinking. Rather than switching the LEDs on then delaying a while before switching them off, the robot runs several layers of emulation with the innermost emulated system blinking the LEDs as fast as possible. All the layers of emulators within emulators combine to produce enough overhead to slow the blinking down to a rate that is visible.

Tali Forth 2 on Linux

When people on IRC have questions about Forth or I can't remember how a particular word works, it's nice to have a Forth handy to try things out on. For this, I usually open Tali Forth 2 in a browser window on my website. Even though it's a 6502 Forth running in a JavaScript 6502 emulator rather than a native x86 Forth like Gforth, it works just fine for experimenting. Since most of my programming is on Linux now, it seemed like a good idea to have a way to do my tests in a terminal.

There were several choices for getting Tali Forth 2 running on Linux. One of the easiest ways is to use an existing emulator like Py65 since Tali Forth 2 comes with a pre-compiled binary ready to be emulated. However, this was less interesting than using one of my own emulators. Another option was the JavaScript 6502 emulator running on my website. As mentioned in the post about my 6507 calculator, this also runs in a terminal thanks to node.js. Another option was to extract the emulation engine from my 6502 Interactive Assembler, although it seemed this would be time consuming to untangle since the emulator was not designed to work without the assembler. In the end, it was the most convenient to use the 6502 emulator written in MIPS assembly I've been working on for another project using the tools mentioned in my post about MIPS development in Linux. As mentioned in that post, a binary compiled for MIPS will run right from the Ubuntu command line as if it were native thanks to QEMU and also have access to the terminal through Linux syscalls. Going with this emulator was also an opportunity to double check my MIPS code emulates the 6502 correctly.

6502 Interactive Assembler

One of my 2022 Project Goals is a PIC32-based robot which emulates a 6502. While working on the emulation, I kept having to look up details about address modes and flags, so I made a Python program for Linux called i65 to look up information like the addressing mode, size, cycle count, and flags for 6502 instructions (GitHub link). It can take an instruction name or addressing mode as an argument and displays information for any instructions that match.

If the program is started without any arguments, it waits for input and shows all instructions that match what you type until it's narrowed down far enough to show the full information. The Kowalski 6502 simulator has this, and I wanted something similar for Linux.

2022 Project Goals

Though I haven't made many posts in the past two years, I have been working on projects slowly but surely. As time passes, I realize how important it is to focus on a small number of projects so that some of them eventually get finished. For 2022, I'd like to pick exactly which projects I want to finish. Hopefully this will motivate me and help me focus!

Main projects

6507 Graphing Calculator
This project is still going after 18 months of work. While I haven't made any progress on implementing the new firmware features I mentioned in my last post on this, I have been working a lot on a subproject for verifying the calculator's floating point routines. Like many projects, this took a lot more time than I expected. Hopefully, I'll be done with this subproject soon so I can post about it. I've also been working on a way to make nice plastic keys for the calculator.

PIC32 Robot
This is an idea I've had for a long time for a simple "robot" built using a PIC32 microcontroller. It's a really interesting project that shouldn't take nearly as long as the calculator projects. It will be a good opportunity to get familiar with PIC32s which I want to use for a future calculator project. Hopefully, I can devote a little bit of time to this and still have time to finish or at least make good progress on the 6507 Graphing Calculator this year.

Other projects

Tiny Calculator
Since the 6507 competition began in 2020, I stopped working on this calculator. In the unlikely event that I finish the 6507 calculator this year, I'd like to return to this project and make some major changes. First, the floating point routines need to be redone using proper guard, round, and sticky like I learned how to do for the 6507 calculator. The existing Tiny Calculator firmware doesn't round in a conformant way and instead uses 32 decimal places to try to mitigate the rounding errors. Also, the routines use 9's complement as TI shows in their documentation for BCD subtraction. It became clear after writing most of the firmware that this wasn't the right way to go, but I didn't have the heart to rewrite everything. My plan now is to take as much as I can of the existing firmware and write a library of BCD floating point functions that use 10's complement with 12 decimal places and proper rounding then call those functions from C to rewrite the Tiny Calculator firmware. I'd also like to find a better solution for the keys and case.

PIC32 Calculator
This is another project I have thought about for a long time. This should be much simpler to tackle than my other calculator projects since I won't be writing the firmware from scratch. If I'm able to finish my two main projects this year, this is another one I'd like to start working on.

Linux for Embedded Development

A little over a year ago, I bought a new Casio FX-9750GIII graphing calculator. It really appealed to me for several reasons so I decided to buy one even though my days of collecting calculators are mostly over. One of the main things I like is that it comes with Python which has become one of my favorite programming languages. Another interesting thing is that the processor speed was doubled to 59MHz over the preceding FX-9750GII making it as fast as the FX-9860GII and the FX-CG50. Amazingly, there is a port of Xcas for it, so you can run the same Computer Algebra System (CAS) used in the HP Prime, TI-89, and TI-Nspire. The styling of this one has changed back to the standard rectangular design which is much better than the awkward and ugly rounded design Casio used for some of the preceding models. All of this is very impressive and it only costs $39! Best of all, it can run programs written in C and assembly like previous Casio models. Other modern calculators like the HP Prime, TI-Nspire, and TI-84+ CE don't allow native code execution which is why I've stayed away from them. The catch with the FX-9750GIII is that the GCC toolchain put together by the community only runs on Linux. It took quite a bit of work getting the toolchain installed on Ubuntu in a virtual machine since I didn't have much experience with Linux. A few months ago, I moved everything over to an old server that someone donated. Below are some things I've learned while doing more and more of my embedded projects on Ubuntu.

Virtual Machine
At first, I installed Ubuntu Server on VirtualBox so I could use the GCC toolchain for the FX-9750GIII. It took quite a while to install and then some more work to get things like networking and a shared folder with the host to work. The GCC toolchain turned out to be very problematic to install which was not entirely due to my lack of experience with Linux. Thankfully, the maintainer of the toolchain put in a lot of work helping me get it working on the Planet Casio forum. One of the first problems was trying to get the scripts working without understanding how the various types of shells work in Linux which is very different from the Windows command prompt I'm used to using. There is a package called GiteaPC that the maintainers put together that is supposed to install everything, but this didn't work for me at first either. Other problems were beyond my control such as not being able to update CMake to the version the toolchain requires. For this, I had to update Ubtuntu from 20.04 LTS to 21.04 which does not have long term support. CMake also had problems finding the PATH variables. Eventually, I did get the toolchain running, though it failed when trying to install it again sometime later since the maintainers had changed the toolchain's structure so it no longer built correctly. In the end, I did get GiteaPC working, again with the help of the maintainers, though I have to say the weeks-long process of just getting to Hello, World was pretty awful. All of this led me to reinstalling Ubuntu several times on VirtualBox.

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. 

New Project: 6502 Assembly Optimizer

This is another project on the list of open projects from a few months ago. The goal is to improve 6502 assembly code used in the firmware of a graphing calculator project. The first step is to manage how local memory is used, since the current options are not that great. One option is stack-based addressing in zero page, which monopolizes the X register. This is one cycle slower than hard coding a static address in zero page and mostly prevents the use of the X register for anything else useful, leading to less efficient code. The other option is assigning each local variable to its own address in zero page, which is very wasteful. With only 256 bytes, you run out of room pretty fast. This project assigns zero page automatically by determining which functions call each other (call graph pictured above) and assigning memory so that functions which never overlap share the same memory. In this test code, 38 bytes of local variables fit into only 19 bytes of zero page. Here is a graph where each row represents one byte of zero page and each block one byte of local memory in a function:

Depending on the shape of the call graph, it might be possible to fit a large number of variables in a small amount of zero page.

6502 Calculator Emulator: Website

 Yesterday I finished setting up a website to host my 6502 calculator emulator: www.calc6502.com. So far, it's just running EhBASIC to test that everything works. Getting the website going with AWS was a lot easier than I thought it would be! It's about as straightforward as possible with S3.

Since the last post, I've made a lot of tweaks and improvements to the emulator. One big difference is caching the color values for the screen pixels to avoid accessing an array within an array. This brought draw time down from 150-280ms to 15-70ms. Before that, typing was noticeably laggy. The new version also has the option to follow the program counter and memory accesses in the bottom two panes that were hard coded to 0xC000 and 0xFF00. You can also select which page to view there if you don't want to follow along. There were a few bugs to work out too. The assembly listing was totally blank after loading EhBASIC since the code started at 0xC000 and the emulator was treating those addresses as labels. Lines like LDA <#CharTable were being corrupted since the < was being treated like an HTML tag until it was replaced with &lt;. After that was fixed, I added a feature to scroll the listing to the currently executed line when single stepping. The last change was enabling access to peripherals from any addressing mode so PEEK and POKE work correctly. Before that, the emulator only checked direct addressing for peripheral access to save time.

Last night I got a text-based mandelbrot program from Gordon Henderson's website going. It worked fine after adjusting the screen height and width. Then I tried using POKE to change the color of the characters:

New Project: 6502 Calculator Emulator

In my post about Open Projects, I mentioned this project, and now I'm officially announcing it. This is a JavaScript based emulator of the 65C02 processor that runs in the browser. My plan is to write assembly and load the assembled binaries into the emulator where I can test them. Eventually, the page will be hosted on a public site where other people can try the software for the 6502 calculator I'm working on and report bugs.

Before I started on this project, I looked at a lot of other browser based emulators hoping I could use one of them. Some are unbelievably slow, working at way less than 1MHz and would not work well to test the calculator code that will eventually run at at least 10MHz. All of the emulators I looked at also lacked bank switching. The calculator will probably need several hundred kilobytes of memory which none of the emulators provide. The last reason is being able to map the peripherals into memory how I like and have them resemble the actual physical calculator I'll build when the software is finished.

The slower emulators I looked at do the emulation and interface in one thread as far as I can tell. Doing the emulation in a second thread with a Web Worker is a huge performance increase. In my emulator, the emulation thread performs a set number of instructions then checks in with the interface thread to get keyboard input and relay new screen contents. Setting the number of instructions to 1,000,000 yields around 70MHz performance, which is five times faster than the actual chip. It also makes typing a little unresponsive, so I set it to just 100,000 which is a good balance between responsiveness and performance of around 20MHz.

The emulation code ended up fairly compact. This is my first JavaScript project, and when I showed it to someone asking for advice, he said it looked like low-level C code. Each addressing mode has its own function and each operation (ADC, AND, ORA, etc) has its own function. The functions for the instructions themselves are very short since they are mostly combinations of those two types of functions. Rather than a switch statement, I use the op codes to index into an array of functions, which is probably a lot faster. This is how I would do it in C and it works in JavaScript, although the guy who was helping me pointed out that there are higher level structures in JavaScript that you could use instead. Banking works by splitting the first three 16k segments into banks (minus the first 200 bytes for zero page and the stack) and leaving the fourth segmented unbanked since it will always be EEPROM.

The first thing I tried when I got the emulator working was the test suite by Klaus Dormann. It passed after a few modifications, mostly to memory address wrapping. Then I mapped two banks of RAM to a simulated 256x128 video output where each pixel is represented by one byte. The final calculator might be black and white or have less color resolution, but I'll use this for now. I made a simple font which is copied to the display memory pixel by pixel. This didn't look especially impressive, so I found a much better looking one online to use instead. Next I added support for transparent backgrounds.

I got EhBASIC running after a couple days of fighting with it. The first command entered would work and the second would fail with "Syntax Error" depending on what the command was. I tried all kinds of things to find the problem, including stepping through the code to evaluate input, before I tracked it down to a location in zero page. It looked like one of the bytes there holding interrupt information was somehow corrupt since the error was thrown after it was evaluated. The source listed a handful of zero page bytes as free to use, so I put the pointer for updating the screen there. As it turns out, the byte is not actually free! Everything worked fine after I moved the pointer somewhere else.

Open Projects

After starting on my 7400 Calculator project, I thought about how many projects I have open at the moment. Like a lot of hobbyists, I seem to start more than I finish. Most of these are not abandoned, since I do plan to get back to them someday. I decided to take stock here of how far I am and what is left to do. There are two projects here I have not posted about: 6502 Optimizing Assembler and 6502 Calculator Emulator. There isn't really enough yet to write about, but I might as well mention them since I have been working on them now and then for a while. They would also be good for the github page I want to set up and list when I apply for jobs. My plan is to finish most if not all of these projects before I start on something else. Otherwise the list might keep growing without finishing any of them.

Tiny Calculator

80%

A few weeks ago, I put a lot of work into the interface code, which ended up taking more time and effort than I imagined. Like in my RPN Scientific Calculator, the interface code takes up a lot of space compared to the math routines. So far, I can enter numbers and do addition and subtraction, but I still need to fix the sign of the result. For the rest of the calculations, I need to write a lot of checking code for things like scaling angles before applying trig functions and avoiding inputting negative numbers in logarithm functions. Two weeks ago I made some major progress with the keypad, which I will post about soon. Posts related to Tiny Calculator

Pocket Calculator

20%

This project kind of stalled because I got busy with other stuff and also because I hit a few hardware problems that I did not solve. The LCD would work when the speed of the SPI clock was set very low and it would continue to work once I turned the speed up to what the LCD is rated for, but if I turned the calculator off, the LCD would not work again until I set the speed back to very slow. The LCD also did not work when I fully closed the case. Eventually, one of the very stiff ethernet wires I was using broke right off. I will need to rewire the LCD with different wire and start over on the emulator I was working on. Posts related to Pocket Calculator

Programmable RPN Calculator

95%

The last time I worked on this calculator in 2015, I considered it finished other than labels for the keypad. One thing I figured out in the meantime is that the key reading is not entirely reliable since two of the pins on the LPC1114FN28 are open drain, which I did not account for. It also seems that I did not write the key reading code correctly, so there is a chance of shorting pins when you press two keys at once. These probably won't take long to fix, then I will make labels for the keypad, which should be easy now that I have done it for my Tiny Calculator. Another thing that might be helpful is to review the source code and make sure all of my checking code is correct. Posts related to Programmable RPN Calculator

7400 Logic Calculator	30%
This is my latest project and I have been doing a lot of work on it, so I am still really excited about it. I might try to finish some of the projects that are close to done before I return to this to get them out of the way. Posts related to 7400 Logic Calculator

6502 Graphing Calculator

???

In summer 2015, I put this calculator together very quickly to try to get it ready for Makevention that year. Not suprisingly, it did not work at all since I was in such a hurry putting it together. I'm not sure it would be worth it to resurrect this project, but I would like to at least return to it and figure out why it didn't work. One possibility is that the LCD was damaged when I was trying to drive it with an MSP430 since the wires I used had metal connectors that kept shorting to each other. Another thing I noticed when I pulled the board out a few weeks ago was that the EEPROM is not a modern CMOS chip but something older that uses 140mA and has a slow 250ms access time. The latches to drive the LCD are 74LS874s, which I now realize consume way more power than HC chips. There could also be other problems like the CPLD. In any case, it will be fun to try to figure everything out. Posts related to 6502 Graphing Calculator

6502 Optimizing Assembler

25%

This is a project I started to practice my Python skills and have a concrete project to talk about in job interviews. My plan is to analyze assembly files (not compiled binaries) and make optimizations based on a few simple assumptions. This will should be able to shave a few cycles off of unneeded instructions, which is especially useful when you are using macros. It will also be able to manage zero page much better than just assigning fixed addresses to each function or sacrificing the X register for use as a slow pseudo stack. Posts related to 6502 Optimizing Assembler

6502 Calculator Emulator

40%

This is a 6502 emulator written in JavaScript that will let me test calculator firmware in the browser without having to upload it to a physical calculator. The emulation works at over 50MHz currently and passes Klaus' test suite. The input and screen output work, as well as memory paging like the real calculator will have. Now I have to find a way to speed up screen drawing, since I think this is the source of lag when typing. Then I will need to start writing the firmware for the calculator. Someday I will host it on a website so that other people can help me find bugs. Posts related to 6502 Calculator Emulator

Calculator Processors

Most of the microcontrollers and processors I have looked into using have been for my calculator projects. That's one of the main reasons I did my microcontroller comparison a few years ago. Recently, I have gotten interested in other chips I could use for calculator projects, in addition to the 6502, 6800 family, and 8051 chips I was interested in before.

The main two criteria I have are an external memory bus and through-hole package. Right away, this eliminates most modern microcontrollers, since almost all of them with an external memory bus are SMD only. In theory, I could use a chip without an external bus if it had a few hundred KB of RAM for data and a few hundred more KB of RAM or flash for program space, but I haven't found that in a through-hole package. Another point is that I would like the ability to load programs from an SD card, which is impractical if I need to have the chip reflash itself every time I load a program. Through-hole parts are more convenient to solder, and I would like to do a few more projects with them before I try to start making surface mount boards.

Modern microcontrollers

• AVR - None of the ATmega series has an external bus. Some of the ATxmega series do, but they don't come in through-hole packages.
• PIC - For a through-hole part, the PIC32 series is very impressive at 50mhz with 64KB RAM and 256KB of flash, but even this is not enough for what I am planning. The chip requires a separate programmer, and the compiler offers limited optimizations unless you pay, which is absurd in 2018 compared to its competition. It does have something called PMP, which offers a sort of data bus, but it can only address 12 bits, since the DIP part only has 28 pins. 
• MSP430 - This chip worked well for my RPN Scientific Calculator, but it also lacks an external bus.
• Propeller - This is an interesting chip but like the others, it lacks an external bus and does not have enough flash or RAM. The one interesting possibility is doing several calculations in parallel, although I don't know how I would use that for a calculator.
• Zilog - They have some nice chips, including some processors with external buses, but I would like to use something different than what the TI-83 and similar models use.
• LPC1114 - I really like this chip, and I am using it in my Pocket Calculator, but it also lacks an external bus, and it seems that it is no longer manufactured.

BCD Addition Speed Test: 6502 vs 8051

12345.6789 + 9999.99999 packed BCD on 8051

A few years ago I decided to revisit the microcontroller comparison I had done to see how much of a speed up I could get recoding my BCD addition routine in 8051 assembly. At the time I was surprised that it was 3-4 times faster than the C version. That original BCD routine, which I used for my RPN Scientific Calculator, uses unpacked BCD characters arranged with the most significant bytes first. For the calculator I want to build with a 6502, I wrote a new routine that stores the least significant bytes first in packed BCD. This takes advantage of the 6502's decimal mode to quickly add packed BCD bytes and avoids having to shift all the bytes when an extra byte has to be added for the final carry. It turns out that the 8051 has an instruction, DA, to correct the result of BCD additions from their binary result back into BCD, so it is easy to do packed BCD for it as well. To compare the speed of the two chips for use in a calculator, I translated the 6502 packed BCD routine to 8051 assembly and ran both versions in their respective simulators.

6502 BCD Multiplication

In preparation for the 6502-based calculator I am planning on building, I started thinking about the best way to do BCD multiplication. One of the reasons I was interested in working with the 6502 is its built in BCD mode. This works great for add and subtract but the chip does not have any sort of multiply or divide, BCD or otherwise. (Some of the 6800 family I was researching before do have hardware multiply, as does the 8051.) There are several routines that can make BCD multiplication faster, so I tried some of them on the 6502 to see which one works best.

To test these I used the Kowalski 6502 Simulator, which is neat because you can assemble in the simulator and then single step or run the program and see which line is being executed. Another convenient thing is that an input/output window is mapped into memory starting at at $E000. I also like the help window which automatically gives you information on op codes when you type them. On the other hand, the included macro system is extremely primitive and you can't do much with it, especially compared to the excellent macro system in CA65. It has a lot of other shortcomings and is fairly buggy, but I don't want to complain since it is free software. After I got frustrated at the lack of basic macro functionality, I tried assembling with CA65 and loading the binary into the simulator. The diassembler seems to work well but of course there is no way for the simulator to know label or function names. For these multiplication tests I decided to just make do with the simulator since I don't need much macro functionality. In the future, though, I will go back to using the 6502 trainer I made before.

To run the tests I made a loop that multiplies all combinations of BCD numbers $00 x $00 to $99 x $99. The Kowalski simulator has a function to count cycles, so I used that to find the time of an empty loop. For each test I recorded the cycles it took, subtracted the loop overhead time, and divided by 10,000 to get average cycles per calculation. After I was done, I went back and used look up tables for operations like shifting by 4 and halving numbers to speed things up a little. I also tried checking for 0 and 1 as arguments to skip the rest of the calculation, but this was not faster. In the table below, the table size column takes into account all the space the tables take up, including unused padding bytes inside the table. Here are the results in the order I did the tests:

	Method	Cycle average	Code size	Table size
1	Repeated additions	1,596.23	34	0
2	Repeated additions, minimize loops	1,236.66	48	0
3	Shift/add	284.80	67	0
4	4x8 lookup table	101.00	65	10k
5	4x8 lookup table, byte aligned	97.00	61	14.8k
6	Russian peasant algorithm	267.79	66	0
7	Quarter square table (half table)	115.33	85	816
8	Quarter square table (full table)	118.00	78	1,632
9	Quarter square table (BCD to bin to BCD)	86.00	51	1,816
10	Quarter square table (BCD to bin only)	60.00	34	792
11	Half squares	113.60	126	200
12	Simulated ROM lookup	31.00	20	46k

Descriptions of methods below:

6502 Address Decoding

For the 6502 graphing calculator I started working on two years ago I wanted to use an ATF1508 CPLD to do the address decoding. In another post, I wrote about how difficult it was to get this chip going. For one, the program I found to generate SVF files for it is 16-bit only. At the time I was running it in a virtual machine, but I don't have my Windows XP disk any more. If I keep using the homemade setup for it I had before, instead of buying a programmer (which is expensive), I think I might be able to run the program in a DOS emulator without Windows.

6502 address decoder with SRAM

Another way I was thinking about doing the decoding is with a 32k 12ns SRAM. For each address, the SRAM would act as a lookup table for the chip selects and other signals that the CPLD normaly does. This would not be as fast as the 7.5ns of the ATF1508, but it would still be very fast. One way would be to hold the 6502 in reset and cycle a counter through all 16-bits of the address space copying information from an EEPROM to the SRAM. After a certain amount of time, a timer would fire to disable that EEPROM and the counter and enable the SRAM, EEPROM, and 6502 of the main system. I'm not sure I got all of the signals exactly right but I made this schematic to illustrate approximately what I was thinking. The disadvantages of this setup is that the extra SRAM consumes 160ma, which would be a lot for the battery-based calculator I want to build, and the extra space the counters and second EEPROM would take.



Another way I thought about was disabling the main SRAM on startup but directing all reads to the EEPROM and all writes to the address decoding SRAM. This would let me write the whole lookup table into that SRAM with the 6502 . A transparent buffer would separate that SRAM from the data bus and prevent it from being written to further after a timer fires. If I got everything right, this would require more glue logic, but it would get rid of the counters and extra EEPROM of the last design.

A third way I thought of is to skip writing the memory decoder SRAM and use an EEPROM. Unfortunately, that would need 45ns or so to do the decoding, which is a lot slower than a CPLD. One alternative I found is 8k 25ns NVRAM, which stores its value permanently in an EEPROM but loads its content into SRAM when it turns on. This would give me 8 byte resolution, so I would probably lose less than 200 bytes of address space for peripherals. Also, if I drive the SPI clock with the NVRAM then I could set it low for one 8 byte stretch and fill that stretch with NOP instructions. Then to pull the clock low for a given number of cycles, I would just have to jump to the corresponding NOP in that stretch of memory.

On the 6502 forum I found a really great page on 6502 bus timing. If I understand the timing correctly, the 6502 needs up to 30ns to output its address and then the address decoding logic can go to work (either 12 or 25ns in this case). After that, the 74HC670 I have in the diagram will need 16ns up to nearly 40ns in the worst case to drive the high bits of the 512k SRAM. If I can get away with only two windows into the SRAM then it would only be about 6ns max if I replace the 74HC670 with a buffer and 74AS244. In order to avoid accidentally writing to wrong addresses, those delays will have to propagate before the clock goes high and the glue logic brings the WE\ of the SRAM low. This would allow me to run between 5 and 10MHz, depending on the combination. This is a lot less than the 14 MHz maximum the W65C02 I am using is rated for but it might work until I get the kinks out of working with the ATF1508.

6800 Family Tree

After about two years away from electronics, I have some time for my projects now that I am almost finished with my degree. Lately, I've been thinking about a lot of things and I want to start some new calculator projects and pick up where I left off on some other projects. One thing I have been thinking about is working on a simpler 6502 based calculator than I was working on before to get more experience working with the chip. I think the 6502 graphing calculator I was working on did not turn out very well because I rushed through everything too fast trying to get ready for Makevention in 2015.

Along those lines I recently got curious about other chips I could use to make a calculator. The last time I was curious about that I compared some of the microcontrollers I was interested in to see how fast they compute. One of my plans now is to do some other comparisons, which I think will be more useful. This time I want to compare processors like the 6502 as well, so I looked at other chips that would be fun to use. One group that I have been interested in for a while is the 6800 family like the 6809 and 6309. I could not find a family tree on the internet, so I started making one myself. When I was almost done, I found this tree in a document about the 6804:

New Project: Logic Tool

Since my plan to make a wireless breadboard did not work out, I decided to use the MCP23S17 shift registers I bought for it to make something similar. It is similar to a logic analyzer but shows information in real time rather than recording a short period of time at high resolution. It has female headers for 64 pins but so far I have only soldered 32 of them in. As time gets closer to Makevention, I'm trying to save time however I can to get my last few projects working.

With 64 pins I will have enough to monitor all of the lines of my 6502 project. Unlike a logic analyzer, I can

also switch any of the pins to be outputs. Now I am doing this with a simple GUI I made that shows or controls the lines with virtual LEDs. This saves me from hanging loads of LEDs on all the lines of my project. Later I would like to add other forms of input and output that I can drag and drop to the dark gray area in the middle of the form. This could include buttons, sliders or hex readouts like I had for my 6502 Virtual Project. At the moment, only the LEDs work and I am using them to drive the address and data lines of the 6502 socket for my graphing calculator project. This lets me check the control signals of the CPLD fairly quickly.

In the end I think this project will work out better than the plan I had for the Wireless Breadboard. When I tried the breadboard I was going to use with another project, it showed a big voltage drop across the rails. I did not know this could happen and it would have been unfortunate to build the whole project and then find out the board was not very good.

New Project: 6502 Graphing Calculator

One of the last things I want to make progress on before Makevention in a few weeks is a graphing calculator I have been planning for quite a while. It will use a 65C02 and is the main reason I started on my 6502 Virtual Trainer last year. Most models of Texas Instrument's graphing calculators use a Z80, which was a competitor to the 6502 in the past. Those models have a 6 or 15MHz clock. The Z80 needs roughly three times more cycles than a 6502 to accomplish the same task, so running this calculator at 5MHz should be as fast as one of those calculators at 15MHz. At the maximum speed of 14MHz, it should be nearly three times as fast. Interestingly, Hewlett Packard did produce several non-graphing calculators like the HP-35S, which used a 8502 chip based on the 6502. Later models of TI calculators used the Motorola 68000 and the latest use ARM processors. These will certainly outperform anything I could make with a 6502. My hope is to make something in power between the Z80 and 68000 series with a few added features.

So far I have finished most of the decoding logic in the ATF1508 CPLD I have been working on. It has 57

IO pins and I have managed to use them all without finishing all the functionality I need. My plan is to use a 512KB SRAM chip with the first 2KB of address space always mapped to the first 2KB of the SRAM. The next two 30KB chunks of address space will point to two windows in the SRAM controlled by the CPLD. This will let me copy large chunks of data between two parts of the SRAM without changing the window between copies. Hopefully 30KB is enough for any single program the calculator will need to run. The last 2KB will be the EEPROM. This is hopefully enough space for a small bootloader that will copy firmware from an SD card and into the SRAM banks. The peripherals like the keyboard and LCD are mapped into the last few bytes of the first 2KB of SRAM.

For the LCD I found a fairly cheap 3.2 inch 320x240 color LCD on eBay. It is the perfect size for a calculator like this. It was also easy to get working with an MSP430 and some shift registers. The only downside is that I did not get an SPI version and I do not have enough CPLD pins to drive the 16 bit data port. The good news is that the LCD seems to expect 3v signals, so I will need some shift registers for level shifting anyway, which frees up a lot of pins. I don't think I will be able to finish very much more of this project for Makevention but I would like to get it drawing to the LCD from a program stored on an EEPROM by then. If I do have extra time, I will work on getting it to read a keypad.