Friday, October 21, 2005

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:

Wednesday, October 05, 2005

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.

Sunday, October 02, 2005

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.