Updated 5/12/24

Here's another retro computing project, with a bit of a twist. It's not a replica of a vintage computer, this one is based on modern hardware but contains all the elements of an early home computer: programmable in BASIC, RS232 connectivity, standard definition analog (greyscale) composite video or 16 colour RGB.

The system is AVR-ChipBasic2 which was developed by Joerg Wolfram between 2006 and 2015 to run on a single ATMega644 microcontroller IC with minimal, mostly passive supporting electronics (see link below). A tiny, standalone computer kit based upon the same firmware operating system and similar hardware was also produced as recently as 2023, known as the CB2 Micro by sv3ora (see link also below)

Both of the systems above feature analog RGB colour graphics using a SCART interface which was popular in Europe but seldom seen in Australia so it seems worthwhile to create a new PCB for the system with an alternate RGB interface. Although I have a couple of CRT TVs (and one LCD TV) which include a SCART input I mainly use these for consoles and for testing arcade PCBs on the test bench. It occurs to me that the AVR system would also work with an early RGB computer monitor (Commodore 1084 etc.) or even a standard resolution arcade monitor.

As I've already resolved to design a new PCB for the system, why not add a JAMMA standard edge connector to one side for power input, speaker out and RGB/Sync to connect to an arcade monitor or even run within a JAMMA wired arcade cabinet? I can also include provision to read some of the JAMMA control inputs via the system's parallel port so that games or other programs could use input from joystick and buttons.

So far so good, the only problem is I'm not up to speed with any current PCB design software and usually just build one-off projects on prototype board. This one requires connectors with special footprints as well as the JAMMA style edge connector so is not suited to stripboard construction. Apart from that, designing a PCB will allow multiple boards to be produced rather than just one prototype.

The circuit design is straight from the jcwolfram.de site (link below) so it is only the PCB layout which I'm designing myself. My thanks to Joerg Wolfram for the software design as well as hardware circuit examples. Beginning with the minimal circuit I have gradually found space on the PCB to accommodate many of the optional components and features shown in the examples on his 'hardware' page.

The PCB itself begins as a blank canvas, its dimensions determined by a 56 pin (2 x 28 way) JAMMA edge connector along one side which gives an overall length around 115mm. In the other direction I've set a nominal size of 99mm as I believe 100mm or more in either dimension may cause a jump in price with some PCB manufacturers. If I can fit the required components within that space there will be no need to go beyond that size anyway.

The recommended process for using the PCB design tools (I'm using EasyEDA in this instance) is to draw the circuit diagram, assigning component numbers and interconnections then transfer that to a PCB workspace using included (or created) PCB footprints for each device. Then the component footprints are arranged on the PCB workspace and interconnections routed automatically using a set of design rules for track width etc. That is usually followed by editing where required to address any routing problems or track interference issues.

I can see how this method, especially for complex circuits with many interconnections would make the process quicker and simpler but for such a small circuit with one main component and, being used to manually laying out circuits on prototype board (using graph paper!) it seems easier to place the component footprints onto the PCB workspace and route the connections manually. Next time I will try the other approach, with a larger circuit...

10/8/24

Designing a PCB for the AVR-ChipBasic2 circuit was a great learning experience. I made (and hopefully corrected) a number of beginner errors, since receiving the first batch of PCBs I've noticed a couple of incorrectly marked components on the silk screen layer but hopefully the connections will be correct and the boards useable without needing to go straight to Revision 2.

There are just a couple of minor alterations to the circuit to provide for JAMMA connection including red and yellow LEDs to indicate the presence of +5V and +12V power supply rails, the +12V if present powers an LM386 low power audio amplifier to provide a speaker output with trimpot for volume control. The 8 bit parallel I/O signals have also been routed to Player 1 control inputs on the JAMMA connector and provision added for a bank of pullup resistors to suit the normally open, common ground control panel switches.

The only surface mount component which I've added to the PCB is a micro USB socket so the board can be powered from a common USB phone supply when not connected to JAMMA wiring. As the PCB has not been tested I will populate the circuit in stages beginning with the minimal hardware to operate the ATmega644PA (or 1284P) microcontroller with 20MHz crystal, PS2 keyboard port, AV composite (grey scale) video and low level audio outputs.

I've provided a footprint for a 2 way DIP switch to select 50Hz / 60Hz video standard and combined or separate Horizontal / Vertical sync (combined sync is always used at present). Alternatively a 2x2 pin header can be fitted instead of the DIP switch and jumpers used to select 60Hz video or separate sync.

The other connection initially included is the 10 pin boxed header, SPI connection for programming the Microcontroller operating system. In this case I've found that my TL866 EPROM programmer can also handle the ATmega644PA (or 1284P) ICs so will preinstall the software before fitting the IC to its 40 pin socket on the PCB.

Having done that and powering on with a USB power supply I get - nothing. No sync on the composite input of my NEC TV monitor. As usual I have my oscilloscope handy and viewing the video output there is a signal with what look like sync pulses and even some video information but the frequencies seem completely wrong. Expecting horizontal sync to be around 15kHz, the signal I'm viewing looks more like just a few hundred Hertz.

After some reading I learn that the ATmega ICs are highly configurable with options for internal or external crystal oscillator and clock dividers, selected by some configuration bytes which must also be correctly set when programming. Another attempt, this time setting the recommended configuration into the config programming tab gives a result. Returning the micro controller IC to the PCB, powering on produces the startup dialog and pressing space bar takes us to the desktop screen.

Now we're getting somewhere! The system runs and responds to keyboard input although the 'Y' and 'Z' keys are reversed for the 'DE' keyboard layout (and some other differences) compared to 'US' which is also the standard keyboard layout for Australia. There is a binary program which will change the default layout from 'DE' to 'US' so this is the first issue which needs to be addressed by loading, then running the 'kbd_us.bin' program.

There are 8 slots for programs, either BASIC or binary and the only occupied slot, P5 contains the serial loader program which is used to load or save programs via RS232 to an external computer running terminal software. So the logical next step is to populate the part of this PCB which contains the components for the serial interface.

The RS232 standard which has its origins in the era of electro mechanical teletype machines, specifies a negative and positive Voltage for its 'mark' and 'space' ( 1 or 0 ) states. Although some more recent devices will accept 0 - 5V TTL levels a correct signal should have a range of -3V to +3V or more. To create a negative Voltage the AVR circuit includes a 'charge pump' using an oscillator output from the ATmega IC via 2 diodes and capacitors to create a negative supply of about -4 Volts.

In this photo I've added all of the components between the micro controller and DB9 serial interface connector. It's also necessary to select the 'config' page from the desktop screen, set Serial speed to 2400 Bps, Line end to CR+LF (for Windows systems), Serial In/Out to simple and Serial Input to PD1. The terminal software at the computer end should be set for 2400 Baud, 8 bits, no parity, 2 stop bits and no flow control.

Having made those settings and powering the PCB on the serial loader program attempts to connect to the terminal; it appears to be receiving keystrokes from the terminal (S to request status, Q to quit etc.) but the terminal does not seem to be receiving data from the AVR circuit. Checking the serial port Tx output with my oscilloscope I'm expecting to see a signal which ranges between positive and negative Voltages but the negative component does not appear to be present.

When I exit the serial loader program, pressing space then escape to return to the desktop screen the charge pump circuit appears to run correctly but when the serial loader program runs the oscillator output which is required to generate the negative Voltage is idle. It appears that may be a bug in this version of the operating system so I will try an alternate method of loading the program file from the desktop screen, selecting program slot P1 then CTRL and F3 to receive the program via the serial port.

That works fine and the SETKBD-US- program now occupies program space P1. Pressing F4 to run the program changes the default keyboard layout to US. The program only needs to be run a single time as the default layout has been updated so having done that the program can be removed by pressing CTRL and F4 to free up program slot P1 for another program.

To create a new program the editor can be opened by pressing F1 and BASIC commands typed in but for the moment I'll try loading one of the example programs from the AVR project page, saving the program as a text file then receiving that via the RS232 terminal by pressing CTRL and F3 within the program editor screen. The program loads, can be saved to the current slot by pressing F2 and run by pressing F4.

This program is 'Eatman', a pacman style game and a good example of the system capability as it uses the full program space, about 3k Bytes per program slot. It may be possible to accommodate larger, more complex programs by incorporating cross-program subroutines which are reportedly possible within the AVR-Chipbasic2 operating system.

With a small edit to the BASIC program it should be possible to adapt the game to accept input from JAMMA joystick and buttons rather than keyboard but first, let's add the few components to see the system in colour rather than shades of grey.

12/8/24

My PCB for the AVR-Chipbasic2 computer is working with no major issues so far. The system boots up, accepts input from keyboard, loads programs via its RS232 interface which run with grey scale graphics and sound. The next section of the PCB to assemble and test is the RGB 16 colour output. There aren't many components to add, just some resistors as RGB video is already present at the outputs of the micro controller IC.

In addition to the R, G, B and Sync contacts on the JAMMA edge connector I've placed a 6 pin header for RGB video to suit a 15kHz computer monitor or SCART TV. The main difference between the signals at those points is the sync. For a SCART TV there is no separate input for sync, it uses the composite video input as the sync source for an RGB signal so the sync level only needs to be about 0.3 Volts.

For the JAMMA interface an arcade monitor would normally be connected, just the combined Horizontal and Vertical sync pulses are used and a higher level is also ideal. In this case I have just taken the signal from U1 pin 19 but with hindsight, should have added some resistance between that point and the sync contact on the JAMMA connector. Although the direct connection would work it doesn't provide any protection for the Micro controller IC in the case of a short circuit on the video cabling etc.

So I'm adding a resistor between the IC and the JAMMA sync output, at least 470 Ohms should be OK but I will try 1k Ohm, hopefully the sync signal will still be sufficient for an arcade monitor. The resistor could be fitted to the solder side of the PCB but I've placed it on the component side to remind me, to incorporate that into any future revision of the PCB. I've also cut the original track on the solder side just before the sync contact on the JAMMA connector.

OK, having done that it's time to see the results. I'm using a cable connected to the 6 pin header initially with the RGB input of my NEC TV monitor, the next step will be to test the JAMMA connections. It looks great, the desktop screen springs to life with glorious, 4 bit colour.

With bright colours, the function key assignments along the bottom of the desktop screen stand out nicely. The 5 coloured labels represent Escape and F1 - F4 keys, holding the CTRL key provides a second set of functions for the keys. Adding labels to the keyboard with corresponding colours for the 5 softkeys would help to access the functions easily.

Above is the Eatman game, now showing in colour. There was an issue loading the game from the terminal via RS232 with some incorrect characters received. I think the ANSI formatting of the text file may have been the cause so need to resolve that, meanwhile I just edited the program to correct the errors and saved the changes.

Apart from the example programs on the jcwolfram.de site there are several games and programs available on the qrp.gr site (links for both below) Thanks to sv3ora for the software resources on that site including the original 'setfree' game below.

This one is a horizontal scrolling shooter with a Defender / Scramble vibe. The game is fairly minimal compared to arcade versions but another good example of the capabilities (and limitations) of the AVR ChipBasic system. Pretty impressive for a micro controller IC which was never intended to operate as a standalone system, running BASIC.

The next step will be to populate the PCBs parallel I/O section and test the JAMMA interface.

15/8/24

My first attempt at designing a PCB using EasyEDA, for the AVR Chipbasic2 Micro computer appears to be a success. The core system is up and running, all that remains is to populate the peripheral sections of the PCB and test the various ins and outs.

The parallel I/O uses a bank of 8 x 180 Ohm resistors for current limiting to protect the outputs of the ATmega IC and a DB25 socket connector which was the LPT standard printer interface prior to USB. I don't have a parallel printer to test it with at present but fitted the connector anyway, you never know...

My main reason for adding the resistors is to utilise the 8 bit parallel inputs to detect switch closures on the JAMMA interface for player controls. I've routed bits 7..0 to Player 1 coin, start, Joystick up, down, left, right, buttons 1 and 2. As an alternative to detecting a coin I've included a header so bit 7 can be connected to the 2 player start switch via a jumper link.

To turn a switch closure (to ground as per the JAMMA standard) into a logic level transition a pullup resistor is required for each bit. I've included the footprint for a 9 pin, 8 x 10k Ohm resistor network and routed the common pin to another header so the resistors can be configured either as pull ups or terminations to ground.

I chose quite a high resistance value so the pull up resistors would hopefully not interfere with the data if the parallel data bits are used as outputs. as an extra measure I'll fit a socket for the resistor network so it can be unplugged if required. The pins on the resistor network are flat and not very sturdy so instead of using a turned pin socket strip I'll use a dual wipe 18 pin IC socket which has been cut in half.

Connecting the PCB, this time to my JAMMA bench test lead rather than USB power supply and separate RGB cable, the board powers up as expected. Both +5 and +12V LEDs illuminate although the +12V supply is otherwise unused as yet. To test the JAMMA control inputs via parallel I/O I'll just write a minimal program, saving it to the empty position P3.

In this system DIR stands for DIRection and $00 sets all bits as inputs. the IN statement can read individual or grouped bits, $1FF selects the full byte. The program runs, just displaying the result on screen in a continuous loop, scrolling as each new result is added. Testing each input and combinations the result changes from 255 for all inputs open through to 0 for all closed.

Each input carries a binary value from 1 for bit 0 (P1 button 2) to 128 for bit 7 (Coin1 / 2P start) - all work as expected with no wires crossed. Pressing CTRL-C on the keyboard exits the program. At this stage that is enough just to confirm the inputs are working, later I'll attempt to adapt some of the example programs to use joystick / button inputs and eventually write some new programs which can be navigated using JAMMA controls rather than keyboard.

Next we'll move on to populate another section of the PCB, for the speaker output. This utilises an LM386 low power amplifier IC with minimal external components, a 10k trimpot for volume control and Electrolytic capacitors for +12V supply filtering and output coupling. In addition to the JAMMA connections I've included a 2 pin header for speaker output.

The circuit is straight from the LM386 datasheet, I've included footprints for additional components to increase the amplifier gain but in practice they are not required, the nominal gain of 20 for the basic circuit is ample. At normal level the sound is fine but turning the volume up there is a noticeable hum which doesn't appear to be coming from the power supply, more likely crosstalk from the video circuit.

I'll need to investigate that and see if I can find a way to reduce the hum on the speaker output but for the moment it is OK. I did attempt to avoid any ground loops on the PCB, using a separate ground path for the audio circuit. To see if it makes the symptom better or worse I try linking the audio and video ground tracks together but it makes no noticeable change so I'm fairly sure the hum is not a supply or grounding issue.

The only part of the circuit left to populate is the I2C bus connection and on board EEPROM positions so we'll add those now, finishing the build process. The ATmega644PA and 1284P have some internal EEPROM space where data such as high score tables can be saved but using their I2C bus external serial devices and EEPROMs can be accessed. I've used the circuit examples provided on the jcwolfram.de site to include positions for two serial EEPROMs on board.

The serial EEPROMs can be type 24C64 to 24C512 and I've initially fitted one 24C512, 64k Byte EEPROM to the position with address 0, the empty socket is address 1. The EEPROMs can contain data rather than program information and are accessed using the XPOKE and XPEEK statements. They could also be preprogrammed with data and, with relatively large amounts of storage I can imagine these containing large arrays and even pre-rendered bitmap data which can be transferred to screen within a simple program routine.

At this stage I'm not familiar enough with the specific version of BASIC used by the system to properly utilise the resources but some initial ideas include a program to generate simple test patterns on screen, using a menu selection controlled by joystick and buttons. Such a program could be set to autoload on startup, alleviating the need for a connected keyboard. Most of these useful patterns are simple combinations of geometric lines, shapes and colours which could be easily produced by a basic program or even loaded directly from EEPROM.

So with the assembly complete the PCB appears to be working correctly, the next stage is to learn the finer points of the AVR-Chipbasic2 programming language and write that test program, maybe some simple arcade style games.

30/8/24

I've assembled and tested my first PCB design which incorporates a JAMMA standard edge connector with the open source AVR Chipbasic2 computer (a link to the original project page for that system is included below). The system is up and running, basic checks of the input and output interfaces including the JAMMA standard video output and control inputs show all working as expected.

It's time to learn the specifics of the BASIC programming language included with the Chipbasic2 system, there is a complete BASIC reference as well several example programs contained within the linked pages below. To begin with I'll try a simple exercise to load some of the mini game example programs and edit the BASIC commands to replace keyboard control inputs with joystick and button controls via the JAMMA / Parallel input port.

That turns out to be pretty straightforward, replacing KEY( ) statements with IN( ) commands where appropriate so the next step is to attempt to create a new program from scratch. My initial thought was to write a test program to use in a JAMMA wired system which could generate RGB test patterns as well as check control inputs, speakers etc.

Test patterns are fairly straightforward being composed of geometric lines, shapes and colours and a simple menu system would allow the program to be controlled by joystick and buttons without the need for a connected keyboard. The system can be set to autorun one program on startup.

With each program space limited to 95 lines of BASIC code I thought the menu as well as the routines to draw the patterns wouldn't fit into a single program slot so I began writing two separate programs, one to draw the patterns and then effectively do a screen dump to the on board serial EEPROM and a second program to create a menu and then transfer the selected pattern from EEPROM to screen.

Although each BASIC program space is only about 3k Bytes one 8 pin serial EEPROM can contain up to 64k of data, ideal for complete graphic images. As it turned out with a bit of trimming the entire program could be squeezed into one slot anyway so the patterns can be selected from the menu and generated on the fly. There was just enough room at the end to add a simple button test which plays a unique tone for each of 8 control inputs.

I've included a video below of the first version running on my test bench RGB monitor. I selected 60Hz as most standard definition arcade monitors run at that rate though my PAL TV/ monitor isn't exactly set up for that standard. The same program will also run at PAL / 50Hz frequency, with an increased border area.

Being written in Basic it's quite simple to add or change the program to suit a specific requirement. I'll attach a text copy of my Test Pattern Generator program here to show the very concise (and fairly easy to learn) version of BASIC employed by the system. There is also a version of the program which is operated by keyboard rather than JAMMA control inputs and should be useable with the original AVR Chipbasic2 and CB2 Micro systems.

tpg_jamma.txt JAMMA Test Pattern Generator v1 BASIC program listing

tpg_rgb.txt RGB Test Pattern Generator v1 BASIC program listing

5/12/24

Here's a little update on the JAMMA_AVR2 Retro computer / test PCB project. I mention the term 'test PCB' as major inspirations for combining the micro computer circuit with a JAMMA edge connector were the JAMMA 'test PCBs' of the 1990's which were included with Japanese 'candy cabs' so they could be sold as complete working machines.

I became fascinated by these tiny games when I picked up a Sega Dottori Kun PCB a while back and did some research to understand why such minimal, 70's style games were produced well into the 1990s. Since then I have also picked up a working example of Taito's 'Mini Vader' test PCB. On the left, Sega Dottori Kun. Taito Mini Vaders on the right and my JAMMA_AVR2 PCB, centre of photo.

Although they were dubbed test PCBs the little boards included very few test functions at all and the included game was so minimal it barely met the letter of the law which required the machines to be sold as complete and working. Realising their unused potential I wrote a ROM 'hack' for Dottori Kun to produce some monitor test patterns as well as a button test but the included hardware is also very limited with low resolution, black and white graphics and no sound whatsoever.

Dottori Kun does have some ability to change colours via a RGB colour palette, at best this could produce a 'space invaders' style colour overlay to the monochrome graphics but this would have to be carefully timed within the program to produce stable colours at various points on screen while Mini Vaders has no colour ability at all, the three colour outputs being identical. Both are Z80 based so can only be programmed in machine code or z80 assembly language.

The PCB which I've produced is based around the AVR Chipbasic2 operating system by Joerg Wolfram so is programmable in BASIC with several graphics modes and sound / sequencing ability. Although there is considerable overhead running BASIC the MCU clocks along at 20MHz compared to 3 or 4 MHz for the two Z80 based PCBs.

My first revision PCB works well, so far I have written a BASIC program to produce some 'proper' monitor test patterns as well as a simple button / sound test. Since producing the initial PCB I've imagined some enhancements and have come up with a second revision to include some additional features, squeezing a few extra components onto the already busy PCB layout.

The main changes from the Rev. 1 PCB are; *Some silk screened component designations corrected.

*A reset button added. I found an easier way to restart the MCU than power cycling the PCB was to ground the reset line at the ISP header. To simplify the process I've added a footprint for a tactile switch on the PCB.

*A third LED added to indicate if the -5V supply is present on the JAMMA connector and if so, that Voltage is used to supply the -V for the RS232 interface via a diode and a couple of smoothing capacitors. If the -5V is not present the existing 'charge pump' circuit of the original design can still be used.

*An additional jumper position which allows parallel input bit 7 to be linked to the JAMMA Coin1, 2P Start or P1 Button 3 input.

*I've changed the pinout of the 6way RGB header connector to include a separate Vsync signal if H / V sync is selected at the DIP switch rather than combined sync. this may be useful for any VGA type displays which can run at 15kHz 'standard' or CGA resolution. Apparently some VGA monitors can do this although I have yet to find any, so far all the ones I've tried report the signal as 'out of range'.

*I've added an IC to provide USB connectivity, admittedly I don't have this feature working as yet. The PCB already has a micro USB connector for 5V power to operate as a standalone computer without JAMMA connections, the interface IC should allow programs to be loaded or saved to a PC / laptop via USB rather than requiring an RS232 interface which most modern computers don't have.

The interface circuit should be straightforward and my PCB connections appear correct but both ICs I have tried so far appear not to work. Reading the data sheets it seems the IC's internal 3.3V supply should have a bypass capacitor added also some user notes suggest a pullup resistor should be added to the IC reset line even though an internal pullup is present.

Perhaps without these two additions the ICs may have been affected by noise or crosstalk from other signals around the MCU and may even have failed as a result. I've tried adding the recommended components on the solder side of the PCB with no improvement so the next step is to order another couple of ICs in case the original ones have already failed. More on that later.

Anyway having built up a couple of PCBs which are working (apart from the USB connectivity) I have drawn up and 3D printed a little case so the PCB can be used as a standalone computer. A simple instrument case comprising top and bottom halves with a separate front panel having cutouts for keyboard and power / interface cables.

The majority of external connections (as well as the LEDs) are placed around the perimeter of the PCB so I've allowed access to these, leaving them flush or slightly recessed where possible to prevent unused connectors from jutting out. At the rear the JAMMA edge connector can be used or not, I've also left a slot for the RGB video cable and fitted a right angle, 6 way header to the PCB to allow horizontal connection.

The lower half of the case has an external mounting flange for fixing within a cabinet as well as 75mm VESA mounting holes to allow it to be affixed to the back of an LCD SCART TV / Monitor as shown here.

The lower case can be used on its own just as a mounting plate or fully enclosed with lid and front panels fitted. The lid includes a slotted grille for ventilation and could also incorporate a small speaker but for standalone use I prefer to connect the low level, RCA audio output to the monitor audio input and use the monitors internal speakers.

Although not intentionally copied from other products, due to its overall shape and size the finished case does resemble a typical multi game JAMMA PCB so I've nicknamed this one 'Aunt Dora's Box'...

Ok, now that I have a couple of JAMMA-AVR2 PCBs made up and working it's time to see if I still remember how to write some little retro games in BASIC. Browsing the AVR Chipbasic2 and CB2 micro project pages there are already a number of example programs which will run on my version of the hardware and, with a little adaptation can be controlled by joystick and buttons connected to the JAMMA interface.

A couple of favourites are a little program called Racer, this vertical scrolling car driving game reminds me of one I programmed for the Ohio Superboard in about 1980. My program had no colour or sound (of course) but apart from the randomly generated winding road sections mine had occasional straight sections where oncoming cars hurtled towards you and had to be avoided.

The other little gem is a Tic Tac Toe game which reminds me of probably my earliest memory of an interactive electronic game. I saw and played 'noughts and crosses' with a machine at the Powerhouse Museum (then known as the Technological Museum, in Ultimo) as a kid in the early '70s. This early computing technology made a huge impression on me at the time and would steer my future career choices.

So for the sake of nostalgia I'll attempt to write a BASIC game or two and, reading the programming manuals for the AVR Chipbasic2 OS I'm inspired to have a go at everyone's favourite block stacking game. The 16 colour graphics and sound along with the ability to display text and blocky graphics characters seems to lend itself to this purpose. I'll call the game Blocky, which seems appropriate.

As well known versions of the game are always accompanied by a music score I'll begin with the music and attempt to program a recognisable tune for the inbuilt sequencer which runs in the background as the program is executed. But first I need to know which note values correspond with which musical notes so I'll write a little program to test them out.

Here I'm using a little instrument tuner with a program to select and play any note value on the system. The little square is indicating the note is a C while the needle display and red arrow are showing the pitch is a little on the high side - but close enough for retro! This would be the nearest value to high C on a piano.

After testing every note value in that range 64 - 128 and marking the corresponding musical notes I'll use those values in an array to define a brief tune. I'm not great at reading sheet music but have located a chart of piano notes for the desired tune, see link below. I don't think the system will play chords and the additional notes would require too much data space anyway so I will try to capture the melody, sticking to the higher scales.

Having stored the note values and durations between notes in the array (a total of 107 notes occupying 27 BASIC lines of array values) and using the BASIC command PLAY to set the sequencer in motion I'm amazed to hear a faithful rendition of the intended tune. It sounds great but I can imagine it will become incredidbly irritating when repeated over and over during gameplay. Oh well, it can always be turned down...

On to the graphics and there are 7 possible shapes each comprising 4 individual blocks, with 4 angles of rotation so I'll store the relative position of each block for every combination in another array. The relative X and Y positions are numbered 0 to 3, avoiding negative numbers as the '-' symbols would take up extra space in the BASIC lines defining the array data.

For every shape / rotation value one of the four blocks is in position 1,1 relative to X and Y values so I only have to store the positions for the other three blocks in each case. That takes 14 lines of BASIC, another 2 lines to define the characters to draw smaller versions of the shapes in the 'next shape' preview area.

There is also one line to define a sprite which will be used for potential collision detection and one to contain the Ascii characters to draw the title BLOCKY with individual background colours so the array values take up the first 45 lines of BASIC code. That leaves exactly 50 lines of the 95 in a single pogram slot to write the actual program, which I'll include below:

Apart from moving the shapes, avoiding potential collisions and detecting when the shape has 'landed' on the pile the program determines scores and stores the high score value to the MCUs internal EEPROM at game end. One point is awarded for every shape placed and any layers which have been filled are then removed. Ten points for a single layer cleared or more if multiple layers are filled in a single pass.

To keep the mathematics simple and save additional lookup tables the points awarded for clearing layers are 10 x (the number of layers cleared)squared so 10, 40, 90 or 160 points for 1 to 4 layers in a single pass. Along with the music track a tone is heard when each shape is placed and another tone of increasing pitch as each full layer is cleared. At 20 layers the speed of the shapes falling and tempo of the background music is doubled.

The total program size is one program slot of 95 BASIC lines including music and graphics data or about 3k Bytes of program memory. Not bad I think for a game which involves a lot of calculations.This version uses keyboard input left, right and down to move the shape and L_Shift / L_Ctrl to rotate so this program should also run correctly on original AVR Chipbasic2 and CB2 Micro computers.

blocky.txt Block stacking game v1 BASIC program listing

The next version will accept input from JAMMA connected joystick and buttons which will most likely require some subroutines in an additional program slot so I may take the opportunity to also write an arcade style attract mode and 'press start' routine rather than having the program terminate at game over. If / when I get around to doing that I'll add a link to that version as well. Meanwhile here is a little video of the gameplay.

To be continued...

JAMMA_AVR2 PCB specifications

Web Resources (External Links) -

AVR-ChipBasic2 - www.jcwolfram.de

CB2 micro - SV3ORA website cb2.qrp.gr

CB2 Microcomputer channel - YouTube

Dance of the Sugar Plum Fairy by Tchaikovsky - Piano Letter Notes

Home