Pong

I fixed a heck of a lot of bugs, implemented timing, interrupts/exceptions, randomness and added some non alphanumeric characters. In the process, I made a fun little pong demo (controls are up/down on nav toggle for player1, rew/ffw on remote for player2 and play to toggle backlight). Here are a few screenshots from that:
The Title Screen:

How many points should we play to?

The Game Itself:

Interactivity!

After I got text output working, I wrote a ultoa and itoa routine and some code to output conversions of all ADC channels. From this, I can read values that will help me interprit the various button presses. I noticed that the play and hold buttons on both the remote and main player didn't result in an ADC change, but found GPIOs that corresponded to them. So I think I will try to write a pong game soon as a demo, but I will probably need to get timing working first. Well anyways, here's an image of my tool, with descriptions of the different readouts (click image to see bigger):

I found a site that hosts files like these, so if anyones interested you can download it here (compatible with the rockbox bootloader). I hope to setup a sourceforge page shortly.

Hacks

The code I have added over the past couple of weeks has basically been a big collection of hacks that I plan to get rid of eventually but should speed up development. First, I coded a basic malloc routine, based on the first fit algorithm. I plan to switch this to a buddy allocator in the future. I figured that I wouldn't need to free memory yet, as there is 32 MB available, so I did not implement the free function yet... I may just wait until i write the new allocator to do that. I decided I wanted to handle button presses, so I learned about the Analog Digital Converter (ADC) which the buttons are wired to and wrote some code that should read from it. The issue that turned up is that I can't really detect button presses if I don't know what resistances to check for. So i decided that I needed some output of the resitances, which means that I need fonts. So I wrote a plugin for GIMP that outputs an image as one of my image_data structures in some generated c code. So to put the image into my code, I only need to compile the generated c file and use the symbol name. So what I did to get a font going is type a long string of letters and numbers in a monospaced font into an image, save it using my GIMP plugin, and then write a routine to blit the correct section of that image for each character. I plan to get real fonts going in the future, but I wanted some sort of quick output for the time being.

Then I proceded to test out my letter blitting routine by drawing letters vertically:


And then also my string drawing function:

IDE & Memory Management

So I wrote a temporary memory management implementation, using the first-fit algorithm. I am planning on implementing the buddy system or possibly something newer later on. I only needed a temporary fix so I could continue.

I was able to initialize the IDE interface, but I'm having difficulties finding examples of uses of it in the disassembly. Also, the m5249 docs don't seem to have much info. Hopefully I will be able to figure this out soon so I can interface with it and then write disk io functions.

Working LCD Driver

So I got my LCD driver to fully work this morning. Some bits of it are sketchily set up though due to no memory management. Heres a pic of what it looks like now (drawing from a buffer):

So I guess the only thing left to do with the driver (which I will put off for now) is to create a partial update function that only updates a region of the display (when the whole display is updated, there is a visible tear which can hopefully be fixed through partial updates).

I'm not exactly sure what I should do next. I guess the possibilities are: memory management, hard disk access, graphics api, kernel & threading. I think that text output would be a good thing to have. For this (unless I come up with a better way) I would need to have bitmap font loading from the harddisk and likely memory management stuff as well. So i think that I should get the memory thing done with and then hard drive accessing and then bitmap blitting / fonts. Since I'm not very familar with the implementation of thread schedualing, having text output would probably speed up development in that area significantly.

Display Oddities

I've been messing with LCD output a bit. At first when I tried to clear the screen, I just ended up with a set of vertical lines, as if it skipped every other pixel in drawing:



So I decided to reinitialize the display. I wrote some bad init code from the start, so i had to mess with it a while, but then I redid it and ended up with blue! even though Its not a color display! I will try to find out if it is a bad thing for the display to have color on it - and whether more colors are possible.

LCD Accessed

I figured out how to access the LCD today. I read the disassembly for some code that accessed CS1 (where the LCD is hooked up) and found patterns that matched up with those in the LCD user manual. Basically heres how it works:

GPIO1 Bit #3 (8 / -9 when or'd or and'd) corresponds to A0 on the LCD.
The memory address range set in the initialization (which is set simply through MBAR+$8c -> MBAR+%94 if i remember correctly -- look through the original firmware to find it) is used for the data byte.

So it seems for most commands you set A0 to off, set the data byte to the command name, set A0 to on and then set the data bytes to the data you want used by the command).

Since I am familiar with how it works, I should now be able to write an LCD driver and graphics API - though I only need text output so i can write the kernel. I will play around with it a bit first before I write the API though. I'm not really sure how I will design the API yet, as I may want to include bitmap scaling and other things and also may want to have separate application display contexts. I will try to find out quickly if there is a built in mechanism to the LCD for writing characters, as that would make debugging much easier.

Well, here are the lovely pixels I drew:

Backlight Flashing Images

Before I work on accessing the lcd display and writing a driver for it, I thought I'd post my work in its current state -- a flashing backlight that litterally looks like a strobe light. Its kinda hard to tell from the pics, but visuals are fun anyways.






























The general code for this is as follows:

First you need to initialize the MBAR (Module Base Address Register). Heres my code to do so (with MBAR and MBAR2 already defined):

#if MBAR & 1
#define MBAR_SET MBAR
#else
#define MBAR_SET MBAR+1
#endif

#if MBAR2 & 1
#define MBAR2_SET MBAR2
#else
#define MBAR2_SET MBAR2+1
#endif

move.l #MBAR_SET, %d0
movec.l %d0, %mbar

move.l #MBAR2_SET, %d0
movec.l %d0, %mbar2

Next, you can enable and turn on and off the light with some simple c code:
#define GPIO1_OUT *((int *)(MBAR2 + 0x000000B4))
#define GPIO1_ENABLE *((int *)(MBAR2 + 0x000000B8))

To enable the light:
GPIO1_ENABLE |= 0x00020000;

To turn it on:
GPIO1_OUT &= 0xFFFDFFFF;

To turn it off:
GPIO1_OUT |= 0x00020000;

I am really surprised, because if you set a bit > than the 16th bit in c with binary or, gcc optimizes it to bitset while if its less than 16, it is a binary or with a word. I didn't expect it do be this smart.

Bugs, bugs and more bugs

So, whenever I made any changes to my c code, seemingly unpredictable things would happen. I'll tell you what I learned and the final solution.

At first I thought it may have been a compiler issue. Using -Wa,-m5249 (specifies as should assemble for the m5249 coldfire processor) , I got an error that there was some bad assembly code -- generated code. So it seemed that the compiler was generating bad asm. I tried to do option -m5249 to no avail -- it didn't have that architecture available. I found a very useful list of options if you do m68k-elf-gcc --target-help . -m5200 was kinda-sorta in the list with -m5249 so i tried that and it seems to be working. Hopefully m5249 is a derivative of the m520x architecture.

In this process, I found fomit-frame-pointer to cut down on some assembly which doesn't look to do much. I don't know if I am schedualing my own demise by setting this though.

These didn't fix my troubles, so i ran back to my handy 92 MiB dissassembly and looked through the initialization code. I noticed that the stack pointer was being set to a location on SRAM0 (the 32k one). I tried to set this to that location, but unfortunately used relative addressing. Apparently the instructions look identical except for a # before the symbol name. I noticed the difference by reading the dissassembly of my own code and noticing that some move.l's ended in c while others ended in 9's. Apparently c is absolute and 9 is relative, meaning that bit 3 determines relative / absolute. So after I got the relative / absolute situation worked out, I got it to work.

So I guess the moral is to not setup a stack pointer that will write over your code when its used. I can't believe I could figure this out, because the symptoms were really very random.

I have my code flash the backlight like crazy right now. It is completely seizure-tastic. You really can't look away when it is doing that. I hope to figure out how to get the lcd working soon so I can actually get some decent feedback.