nanogui: Thread: NanoGUI for uCSimm?

Forgive me if this is a FAQ, but is anyone working on/worked out what its
going to take to make NanoGUI run on the uCSimm platform?  I'm trying to
get all the components together for my uCSimm-based project, and would be
happy to assist with any effort to get NanoGUI working on it.



j.

--
Jay Vaughan                |            ####@####.####
TekLab                     |     http://www.teklab.com
{  Q:[8008] ICQ:[454804] IRC:[EFNet:#teklab/Torpor]  }
Music Technology Forums: http://www.teklab.com/forums/

** A3k Sample Library: http://www.samplelibrary.net/ **
^^^^^^^^^^^^^^^^^^^^^^^^^ NEW ^^^^^^^^^^^^^^^^^^^^^^^^^ 

On Tuesday, July 20, 1999 4:26 PM, Jay Vaughan ####@####.#### wrote:
: 
: Forgive me if this is a FAQ, but is anyone working on/worked out what its
: going to take to make NanoGUI run on the uCSimm platform?  I'm trying to
: get all the components together for my uCSimm-based project, and would be
: happy to assist with any effort to get NanoGUI working on it.
:
	Forgive me for my ignorance, but what is the uCSimm platform?
Nano-X and MicroWindows are quite portable, and can probably be ported
to any system with a working C compiler.  No runtime OS is required for operation,
as we've hardware drivers for keyboards, mice and screens.  These three
drivers will have to be written for any new platform.

	My estimate for the time required to port a new screen driver to be around
one day, given full understanding of the hardware.  The last driver written was a hercules
graphics driver for the PC and was ported from working C code in less than two hours.

	Are you a programmer with access to the uCSimm platform?

Greg

Greg,

>	Forgive me for my ignorance, but what is the uCSimm platform?
>Nano-X and MicroWindows are quite portable, and can probably be ported
>to any system with a working C compiler.  No runtime OS is required for 
>operation,
>as we've hardware drivers for keyboards, mice and screens.  These three
>drivers will have to be written for any new platform.

Sorry, should have included this URL in my message.  Details about the
uCSimm can be found here:

		http://www.uclinux.org/simm/

It's an SBC designed to run Linux, based on the Motorola Dragonball processor.

I may be mistaken, but its my understanding that the NanoGUI is designed to
run on this type of hardware, no?

>	My estimate for the time required to port a new screen driver to be around
>one day, given full understanding of the hardware.  The last driver written 
>was a hercules
>graphics driver for the PC and was ported from working C code in less than 
>two hours.

Got it.  Is there some sort of design doc that states the goals for
NanoGUI, how it is laid out, etc?  I'm assuming that access to some sort of
framebuffer is required.  Given that the uCSimm is designed to function
with relatively simple LCD displays I'm not sure how well this will work
out, but I willing to bridge any development gaps as needed.

Any other references I should be familiar with that are publicly available?
 I know that I can dl the code, and will do so...

>	Are you a programmer with access to the uCSimm platform?
>Greg

I'm a programmer, but I don't hvae access to the uCSimm platform yet -
they're still getting the developer boards mfr'ed, and I have 2 on their
way to me when they ship.  In the meantime, I'm trying to get myself
prepared for what its going to take to build my project.

FWIW, my project is tentatively called the "Geek Clock", the design for
which I posted to a recent Slashdot forum regarding the announcement of the
uCSimm prototypes being ready.  I'll have a more formalized site for it up
and running in the next few weeks, but basically what I'm doing is building
a general purpose uCSimm+Linux based portable data display device that can
be programmed to display information obtained from the network interface
(any info from any network source), with marginal user interface control in
the form of "Gameboy" style D-pad and 2 buttons.

The design for this project will be GPL-style - once completed, anyone can
take the various open parts (the uCSimm, Linux kernal, etc), stick it all
together and end up with their own "Geek Clock".

Its a starter project for what I hope will turn into a relatively
functional fully programmable PDA, with marginal input abilities.  Since
its fully re-programmable, I foresee all sorts of uses for this
network-capable tool.

So anyway I'll dl the NanoGUI code today and get more familiar with it.

Thanks,


j.

--
Jay Vaughan                |            ####@####.####
TekLab                     |     http://www.teklab.com
{  Q:[8008] ICQ:[454804] IRC:[EFNet:#teklab/Torpor]  }
Music Technology Forums: http://www.teklab.com/forums/

** A3k Sample Library: http://www.samplelibrary.net/ **
^^^^^^^^^^^^^^^^^^^^^^^^^ NEW ^^^^^^^^^^^^^^^^^^^^^^^^^ 

 
: Got it.  Is there some sort of design doc that states the goals for
: NanoGUI, how it is laid out, etc?

	Not yet.  Inspection of mwin/src/drivers/scr_bogl.c, the linux
framebuffer driver, is quite straightforward.  The scr_herc.c driver is a very
basic complete driver for the PC hercules card.



  I'm assuming that access to some sort of
: framebuffer is required.  

	No.  The nano-X and Microwindows graphics model doesn't
assume anything about the graphics hardware other than it has
read and write pixel capabilities.  The framebuffer architecture just hides
the hardware graphics setup and mmap()'s the video ram into user space.
We don't require it.   There are currently drivers written for Linux 2.2.x framebuffer,
Linux 2.x SVGALib, ELKS 0.78, and MSDOS, and bare PC hardware.


Given that the uCSimm is designed to function
: with relatively simple LCD displays I'm not sure how well this will work
: out, but I willing to bridge any development gaps as needed.

	Worry first about how to read and write a pixel, and you're 90% of the
way there.


Greg