Places to order parts

In my previous post I referenced Futurlec as a place where you can order parts. Note that they are slow, but they are inexpensive and they have some very unique items. I really like their "LCD8X2", which is the smallest LCD display I have found so far that can still display 16 characters on two lines, and is controlled by a normal HD44780.

If I needs parts quickly, I usually go to Jameco, which is around the corner of my work place. They are more expensive, but they have very good service: you can just walk in, and walk out with your parts within 15 minutes. If you order them over the phone, they can even make them ready for pick up.

For the actual PIC microcontrollers I used to use Glitchbuster, but unfortunately they disappeared. I currently still have a large amount of them from winning the grand prize of the Microchip innovation competition but dread the moment that I would actually have to order more, as none of the websites I mentioned so far carry a good assortment. I might just order them directly of Microchip's website.

Finally, for all sorts of odds and ends, like soldering irons, solder, wirewrap wire, and various PCB, I tend to visit the local Radioshack. Do not buy parts here, as they are very expensive, and inferior in quality. Just look out for those things that will make your life better.

3D LED cube

Of course I will be continuing with the ZX-jen project, but I'm also working on a display consisting of 4x4x4 LED. I ordered 10mm big LED and will soon put them together. Using a grid with two LED (opposite polarity) per crossing you can control 72 LED with 12 lines, but I think it is wiser to control two groups of 32 LED with 8 lines each, for a total of 16 lines. This way the control of each group can be done with a single PORT, allowing all LED to change at the same time without intermediate values, which could cause the display to blink LED that should remain off. This could still happen, but is a lot less likely with the new configuration. I'll write more once the LED have come in, I used Futurlec for the order, which is notoriously slow, but has nice products for an inexpensive price.

MIDI module

At some point I found this box, and decided to turn it into a MIDI module. MIDI is a bit obsolete nowadays, but I still have a keyboard and an pseudo-analog synthesizer that use it, so I thought to create something. So far it can play Beethoven, but it can't record yet. This is something I'll still need to work on, but after my recent experience with the GPS module, this should be a lot easier.

At least it looks nice, though a few lights would of course make it more interesting.

Acey Ducey working

"Soon" was a bit later than I thought. The first thing that became troublesome was the encoding of strings as {length,character,character,character,...}. Parsing strings like that requires making sure the length is always kept correct, and given the large number of different parse routines for skipping digits, skipping characters, skipping whitespace and various other tokens the length rarely was correct. Instead of hunting down this error I thought it was more robust to change the encoding of strings as {character,character,character,...,0} which is the usual way strings are encoded in C. This means that 0 can no longer be used as a character, but since this was not something you could input on a keyboard anyway it wasn't very relevant. Of course, changing the code this way was not entirely insignificant, but fortunately everything was structured well enough so the switch was done in an hour or so.

The next issue that I ran into was the keyboard input. The keyboard handling is currently done without an interrupt, disabling and enabling the keyboard using the clock line whenever character input is required. This worked well. However, I also want to check for the "Esc" key during program execution, so the user can interrupt the program if so desired. In order to do this I occasionally release control of the clock line and look if a character comes in. If it does, I read it and checked whether it was "Esc". This worked well, however, if keyboard input happens for a normal reason during execution (in this case, to enter the bet of the player) the last scan code ("Enter key released") will be stalled due to the clock line being pulled low, and will appear as the next character. The routine checking for "Esc" finds this scan code, and assumes that the user entered something and will wait for input, but obviously the user just released the "Enter" key and no characters are forthcoming. This means the program seems to hang. I fixed it by having two versions of the getKeyboard routine (using a status bit), one in case I do want to wait until input takes place, and one which will return after the first scancode has been recognized.

But after that, the Acey Ducey game from the classic computer games website started working. Of course, there were some bugs in this BASIC program, and some minor conversions that were needed, but in general it works, as you can see from the screen shot. Typical conversions include adding % to indicate that the variables are integers, adding LET in front of assignment statements, using RND(number) instead of number*RND(1) and splitting the PRINT part of an INPUT statement, as well as a PRINT statement that prints both constants and variables. Finally some of the constant strings needed to be shortened in order to fit the screen.

I'm happy that the game is running, but obviously I don't want to enter it over and over again. I therefore will have to devise a way to store the program somewhere, and retrieve it. There are two ways: I can add an additional 24LC512 chip and compress and store the code in there, or I can use the upper part of the current 24LC512 for storage. Currently a program can use lines 1-2047, storing it at the top would reduce this. Of course, an alternative would be to use an SD card for storage, allowing easy exchange with a PC as well. Or a serial interface/USB interface for storing it in a PC.

Apart from this a lot will need to happen with the code. String handling. Array handling. Negative number input. Fortunately it is using much less than 3K so far, of the 4K that is available. So a lot of features are still possible, although I might have to divert from usual BASIC syntax in certain cases. For arrays I'm tempted to use square brackets, for example, to distinguish them from functions. For strings I'll probably resort to the ZX-81 method of treating them as arrays to begin with. And it is likely an array like DIM A%(10) will have element A%[1] overlap with variable B%, as the RAM of a PICmicro is, after all, tiny (less than 400 bytes, of which many are used for processing).

Partial LIST

Partial LIST now works. You can specify a line number, and it will only show the code from that line number. I also limited the length of the list displayed, as there is no way to control this otherwise. I then started implementing one of the examples again, and discovered that the 9 was not handled correctly, which I fixed. Soon the first game will be working...

Subtract

And now subtract works in expressions. Again only a few minutes of coding, but by coding a few minutes a day, I slowly get to where I want to be. The next step will be more attention to the user interface, as showing the entire listing is unacceptable. LIST 10-100 and such commands need to be understood and functioning, or there needs to be a delay between moving back to the top of the next page.

RND

As I'm trying to get the programs at the classic basic games webpage to run on the ZX-jen I needed the RND() function. Unlike the old RND() functions, which return floating point numbers, which would require me to add floating point or at least fixed point methods to my code, I decided to create an integer version of RND() in which the parameter indicates the limit to be returned. So if RND(14) is called, it returns a random number between 0 and 13. It actually accepts an expression between the parenthesis, although since the PICmicro has only 8 depths of recursion it could go wrong at some point. Soon I will be able to show you the first program running under the ZX-jen.

Upon attempting to enter the first program I discovered that I need to implement the - operation, as well as some form of delay, because the screen is small and often scrolls over before everything is displayed. Of course, I can code the delay manually, but then GOSUB suddenly becomes important.

INPUT

I'm pretty sure you'll believe that INPUT now works without me showing a screen shot. INPUT accepts only a variable name (and an integer variable only, even) and causes a ? to be displayed, after which the user can enter a number. The number gets converted and can then be used for processing. It was relatively easy, although I had to distinguish i-nput from i-f. There was one bug: as you know I disable the keyboard while the program is executing, in order to avoid characters getting lost (I know, an interrupt routine to gather keystrokes would work, but that is just postponing the problem, makes the code more complicated to debug, and doesn't use the hardware to its fullest extent, as a keyboard has a built in 15 character buffer). When I called the getSentence() code I forgot to enable the keyboard. So it seemed the system just froze. Easily found, and easily fixed.

Now all I need is an random function and some other easy mathematics and I can start porting simple BASIC games. At that point it will probably become useful to write an inport/export feature that allows me to store the written programs. Of course, I could just take the memory chip out and insert another one, preserving the code that way, but that seems rather involved and expensive. An interface to a PC or SD card might be better.

IF...THEN

Instead of FOR...NEXT I thought IF...THEN might be a much better option. As shown, IF...THEN now works. It can do comparisons <, =, >, <>, <=, >=, and, as a bonus, == (same as =, obviously). As my parser only checks for positive cases and not for negative cases, you can also write IF...GOTO. Because this work was done during the weekend, and therefore during the day, you can even see me taking the picture in the reflection of the television as well as my messy desk on the background. I discovered several things still need to improve: number printing should leave out leading zeroes, and it should handle negative numbers, as these might show up soon. Regardless, this introduces the important concept of flow control into the system which means it might actually start doing something useful in the near future.