Thomas

In order to fill the void in the days between Christmas and New Year’s Eve 2013, we began experimenting with a 65C02 on a breadboard. This little experiment would later evolve into an actually working 8bit computer. 10 years and some significant amount of focus creep later we had build this cool little 8bit machine with the specifications found here.

The amount of new stuff to learn to design a new computer out of “old” or “retro” components was massive. We went about it as rather electronics noobs who only had basic knowledge about anything. We did not have a lot of experience with circuit board design. We did some assembly coding on the C64, but nothing as big and complex as a FAT32 filesystem, let alone some sort of an operating system, albeit a rudimentary one.

Our FAT32 driver now supports byte-wise writing of a file. Reason enough to continue reworking the file handling of our EhBasic port that we started here to finally having the SAVE command write ASCII source files.

The basic idea is to open a file, redirect the EhBasic output vector to our new kernel call “krn_write_byte”, then trigger the LIST command internally. The listing being output by LIST will then be written to the opened file instead the screen. Finally, once LIST is done writing, close the file and return.

This one really is a tough one to debug. At first, we suspected the VHDL code for the CPLD as the main error source, as VHDL is not our strongest suit. In fact, the decoder/banking logic is the first thing we ever really did in VHDL (apart from a few simple decoder equations the first days we were playing with GALs).

As it turned out, the VHDL was not the main problem. It sure was quite buggy and the RDY-generator had problems, but overall it was not too far off. Marko even managed to run a memory check over the entire 512k RAM, proving that even the banking logic works. Furthermore, he was able to clock the new board at 16MHz, which is another breakthrough, as a bonus.

Since our implementation of FAT32 now supports reading a file byte for byte, a little rework of the file handling in our version of EhBasic is in order.

In the past, we only could read or write a file as a whole, relative to the location in memory where the according pointer pointed to. We used this in EhBasic to save and load BASIC programs by dumping and reloading it’s binary representation from memory. While this works well, this approach has the major disadvantage that the saved program will be incompatible with other versions of EhBasic or even with our own when the token list is changed, which happens when adding new commands.