In the three weeks since my last 6502 blog I have been busy both with hardware improvements and software development. On the hardware front, a more useful clock has been added, an LED and four buttons have been added to reflect Ben Eaters finished 6502 system and the LCD has been put on the board. I have also developed a rudimentary hardware error diagnosis procedure.
I have enhanced the vasm/sketch/batch file so a single click can compile and download a new 6502 program and provided some subroutines to write to the screen and use the LED.
These are described in a little detail below.
Subroutines
So far we only have a couple of 6502 assembly programs: one that writes to the screen then accepts input and the other which writes an LCD message. Assembler is a pain to write so we put everything into subroutines which we can easily re-use in other programs. In due course we will put the most commonly used into ROM as library routines. We can immediately add some subroutines based on code we already have:
init_acia setup the terminal for i/o
putc write a character to the the terminal
getc read a chacter from the terminal
putstr write a string to the terminal
Simplified compilation
Previously (see 6502:serial console:software) I simplified my code development cycle to two steps: (1) compile a program and format the executable as input to a sketch; (2) upload the sketch. Although this beats the pants off removing and replacing an EEPROM all the time it is still tedious.
I found that you can actually use many Arduino IDE functions from the command line using arduino-cli. I installed it in a folder next to my assembler and tinkered with its configuration file (arduino-cli.yaml) to locate files in line with with my IDE (which uses the portable scheme). My hardware wasn't recognised automatically in the Windows environment and I had to search a bit to work out that the required platform is arduino:avr:mega.
Once files are in the right place and a batch file links the commands together it is very easy to compile an assembly program and upload the executable in a sketch as a single operation. This makes software development a lot easier as I forget about the environment and click on a compile icon to build and load a new program version.
I also arranged to save compiled sketches, including executables, as HEX files in the program folder so that I can easily load and run one using a batch file. I have a batch file for each commonly used program so I can switch between programs easily.
TikTokClk
Ben's 555 clock is a very good learning project but I find it cumbersome in practice. I set up an Arduino nano to provide a clock pulse on a GPIO output. Initially I used the serial monitor and delayMicrosecond() function to control the output speed or single step mode.
Once this was working I made it much more useable by adding two buttons to the nano. One button is used for single stepping. The other switches between a selection of clock speeds (10Hz, 100Hz, 1kHz, 10kHz). delay and microSecondDelay aren't very good so I used the micros() function to tell me how many microseconds since the last tick and transition the clock output at the end of an interval.
Button debounce is a nuisance so I used a simple Arduino ButtonDebounce library to control them. I found this very effective. You need to make sure your main loop executes quickly and include a button status update method for each button. A callback then takes control when a valid press or release is identified leaving you to specify what happens next.
As I didn't want to connect the nano during operation I set up 3 LEDs to indicate the speed. I used D13, which has the builtin LED attached, as my clock output so I can always see if the clock is running. It is possible to see individual clock pulses at 10Hz, but after that the LED is continually lit.
Hardware Revision 5
Now that we have a more compact clock I can remove the Ben clock and add the LCD screen to the same breadboard segment. I also added 4 buttons and an LED connected up to the remaining 5 VIA pins. These are shown on Ben's 6502 photo but I haven't seen them discussed on his videos yet.
By the way I subscribed to Ben's patreon. His tutorials have been massively informative and fun so I thought it only right to give something back. He arranges it so you don't pay per week/month/quarter, you only contribute each time he releases a video, so I will continue to benefit as I contribute to his costs.
As I now have a good hardware build, I tidied up the wiring, to remove those long wires which always seem to get added as a design moves on. I also purchased an FTDI cable so that I don't have my FTDI board sticking out. With the buttons I use and the LCD and LEDs all at the bottom of the board I think Hardware rev 5 looks good.
What other hardware could I need? Well an SD card would be good and some sort of integral graphics screen would help, but at the moment I feel they are luxuries. I am happy I have a good environment with rev5 to write assembly programs with ample input / output facilities.
Diagnosis
When making changes to the hardware or even in normal use, it is possible that a bad connection will prevent the hardware from working. There are proably 100 wires and 200 pin connections currently in the design. A trial and error approach to fixing problems is often doomed to be a long and frustrating series of failures.
We keep the Arduino Mega attached to our 6502 system (primarily for downloading programs) and it is also vital for low level debugging. Whith the 6502 clock stopped (i.e. in single step mode) we can use the eeprom-write sketch to test writing and reading the ROM, that is to say that we can check that ROM connections are working.
We also need to check the program in ROM is the one we expect. If a different program is loaded, the 6502 may not be doing what we expect. We can check the assembly listing output file against the executable loaded into ROM.
Next we check that 6502 boot sequence, stepping the processor and using the eeprom-monitor sketch. This shows values loaded and after a reset it should be possible to see the reset vector FFFC and FFFD loading start address 8000. Stepping a bit further will show us whether the stack is being used properly (i.e. RAM is working) as the first subroutine is executed.
If the ROM, RAM and 6502 are ok the problem may lie with I/O. Either a screen output program (using ACIA) or an LCD output (using VIA) should work so they can be checked independently.
This scheme should allow a failing component to be identified and individual pin signals can then be checked with an LED as necessary.
LED Flash
In practice it is a little more difficult. We have to write a byte to portA each time we change a bit, so if we are controlling the LCD with portA bits 5-7 we need to keep bit 0 as previously set so the LED is in the same state. I thought that setting the pin as an input might preserve its state but the signal is turned off. Consequently the LED bit has to be ORed with LCD bits before writing them.
TinyCAD
Having finished hardware rev 5 I should update the hardware schematic for Arduino Nano, LCD, LED and buttons. I am learning the TinyCAD package so I can provide a better representation. As the diagram becomes more complex the chances of errors increase. As yet my skills have not advanced far enough for a complete schematic.
