If you check out the guy's web page, at the bottom he links to two PDF documents that go along with this system. The user manual explains how to operate the machine and presents some technical information, while the second document gives 10 sample programs to help learn about the machine. I spent last night manually typing in the hex form of the programs, which was fun, but by program 9 they were getting big enough that this was getting annoying. The keyboard is just a bunch of soft buttons with a sheet of some kind of sticker paper on top, so it's really about as good as a membrane keyboard. So it's good enough for playing around, but it really isn't good for any real programming.
So today I actually figured out how to upload a program. This wasn't difficult; the user manual explained the process well enough. But the computer expects the uploaded file to be in Intel or MOS hex file format. I wasn't familiar with either of these, but a quick Google search turned up what I needed to know. Both are a text file format to encode binary data in hexadecimal form. They're very similar formats, differing only slightly.
Here's an example of the Intel hex file format of a simple program from the book that I ran through the assembler:
The format is actually pretty simple once you break it down. If you're curious I recommend checking out the Intel HEX Wikipedia entry. The above, however, is just 14 bytes that are loaded into memory at address $0200 (hexadecimal value, or 512 in base-10); the second line is the end-of-file record. As I said, the MOS hex file format is very similar. The only difference is that it starts with a ';' instead of a ':', and the record type (the fourth byte, with each two characters comprising one byte) isn't there. Also the end-of-file line has a slightly different format.
Now the webpage for this kit includes a download with the TASM assembler, which is an older shareware assembler that, as near as I can tell, isn't available for sale anymore. But the problem is, I think it's a 16-bit DOS app. When I run it under Windows 7, it says it's incompatible. I did run it under DOS in VMWare and got a simple little program to compile, but obviously this isn't a long-term solution. By the way, the irony that a DOS-based assembler is not usable for a guy who's into retro computers (including DOS-based machines) is not lost on me. All I can say is that I would be happy to do the development in DOS except for two things: I don't have a serial port to upload the program available in my DOS environment (VirtualBox under Mac); and it would just be clunky to have to transfer my program from DOS to an environment where I could upload the program.
With TASM eliminated, I'd really like to use a modern assembler, something that is cross-platform and still supported. I looked and didn't find any 6502 cross-assemblers that would directly output Intel hex file, so I decided I'll just have to convert my assembled program into Intel hex as a second step in my build, which means I can use any assembler. So which one? I've used the assembler with cc65 before, but I wasn't thrilled with it. cc65 is great for C programming, but less great for assembler, though it's a completely functional assembler. I looked at several, and decided to try KickAssembler.
Now as a 6502 assembler, KickAssembler seems very C64 oriented, especially since it only generates either a simple binary file or a C64 compatible PRG file. But for my purposes the PRG should actually do nicely. It's about as simple a format as one could imagine. The first two bytes indicates the starting address; the rest is just the raw binary. I searched for a utility to convert a binary to Intel hex, but didn't find one I liked, so I decided to write one myself. So the PRG really does work very well, since it contains all the information I need and nothing more.
So what are my plans with this little board? Here's a rough projection of what I'd like to do (though given my record of being distracted, it's not likely I'll actually finish all this):
- Write bin2ihex
- Build an emulator using C and Qt (emulators are so much easier for testing/debugging)
- Write a new monitor that uses the serial port
That's obviously a good bit of work, especially the new monitor. I would like to do an interpreted environment like BASIC, but not BASIC as I'm not really a fan of that language. Maybe Forth or else some other simple language.
I'll keep posting as I progress.