From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 27 Mar 2002 23:39:43 +0100 (MET)

On Wed, 27 Mar 2002, Gary Czvitkovicz wrote:

> >Right, we can now see the need for creating and keeping a proper source
> >repository. It seems stupid that the "real" lcd code we have now is in the
> >ui simulator, in Alan's code at home and in Gary's code at home. And they
> >are all mailed around in various archives...
>
> Thanks for setting up the CVS project. I promise to start using it :-)

You could start with mailing Björn your sourceforge user name so that he can
add you to the developer team to give you CVS write access. That would take
you a step closer! :-)

> >Have you kept to your initial buffer-approach that draws everything in the
> >buffer and then writes the complete thing to the lcd in lcd_update()?
> >
> >If you have, the ui simulator is gonna work pretty much unmodified with
> >your new code.
>
> Yep, it still works the same way. The main change was to generalize the
> character drawing code to draw arbitrary bitmaps, so I could draw icons,
> etc. A character is just a bitmap, so lcd_string() now calls lcd_bitmap()
> for each char.
>
> I did change the format of the memory buffer to make the code easier. (X
> and Y indices are swapped from the old code.) So if you have code that
> depends on this, a small change is needed.

Yes, my lcd_update() for X11 depends on this, but it is really easy to
adjust.

> >Good job! Can we get the windows simulator added to CVS too? We could
> >possible make the uisimulator in two directories, one for X and one for
> >Windows. I don't think there's any point to put them in the same dir, as
> >they won't really share any code. AFAICS.
>
> Sounds like a good idea to keep them separated. Maybe another directory
> for the firmware implementation? As the project grows, I'm sure we'll want
> to separate out other major pieces of the code.

Yes, we need to put the windows and the X11 simulators in one dir each, then
we need the actual target code put in the 'firmware' directory. The firmware
code need to be written to separate hardware-specific code from generic code,
so that we can maintain a lcd-recorder.c (or whatever we'll call it) that we
can use for the ui simulators etc. I noticed that you dealt with this by
adding a #ifndef SIM section around the hardware-banging parts.

We can also right now see the need for a defined way to handle for example
SH7034-specific defines etc, as both your archive and Alan's have their own
files for this.

I've told Björn that I await his action on the file tree hierarchy stuff. At
least as no one else has presented any other suggestions.

My updated suggestion:

 firmware/ - the container for target code
   hw/ - for misc HW setup etc
   serial/ - serial port code
   lcd/ - LCD display code
   led/ - handling the LEDs
   fs/ - file system (FAT32)
   ata/ - ATA control code
   keys/ - keyboard functions
   include/ - general include files
   app/ - application code
     include/ - application includes
     .../ - we will need to separate the app more in the future

> >I thought about toying up a filesystem api and simulate that (until we
> >have a real file system), then we could even start fiddling around with
> >file lists and directory hiearchies etc.
>
> Sounds good. We could use this to get started working on browsing UI.

Yes. Did anyone of you filesystem fiddlers (Linus, Alan, anyone?) think in
terms of upper level api yet? I mean, not the specific details but in
concepts?

> There's plenty of work to do.

Oh yes. We have a long way to go.

-- 
  Daniel Stenberg -- Hacking Archos => http://bjorn.haxx.se/rockbox/

Received on 2002-03-27