#####  
 ##  ##  
 ##  ##  
  #####  
     ##  
 #####   

 #       
 #       
 #   #   
 #  #    
 # #     
 ## #    
 #   #   
         

         
 ##      
 ##      
 #####   
 ##  ##  
 ##  ##  
 ##  ##  
         

 __  __
 \ \/ /
  \  / 
  /  \ 
 /_/\_\
       

         
         
  ####   
 ##  ##  
 ##  ##  
 ##  ##  
  ####   
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Nintendo Gameboy is the best low-cost hardware user interface option''' for OtherTuningSoftware or controlling simple processes. '''Why nintendo?''' We really looked (for LCDs, PDAs, remote controls, cellphones: see GraphicalDisplay) and found that it's hard to get just the LCD for the price of the gameboy advanced. While adding LCD control, serial communications and CPU might be easy,the buttons and case are hard to get right cost-efficiently in < 1000 quantity. Some cellular phones come close. See OtherTuningSoftware/JTune/HardWare '''How would it relate to tuningsoftware on other platforms?''' If we can make a tuningsoftware work for GBA (given screensize, input devices, memory footprint, CPU power) it will be simple to make it perform very well on other platforms (win + unix) with little effort. Some (compile or runtime) configuration is needed for PC to make optimal use of bigger screensize and multikey keyboard. Therefore MembersPage/RichardBarrington/QTune and GBA software must be unified, built on same base as much as possible. ---- '''Hardware''' '''Nintendo Gameboy Advance SP (GBA)''' is of particular interest (see [http://www1.shopping.com/xPF-Nintendo_Gameboy_Advance_SP specificatoins]. * '''Sharp ARM7TDMI processor''' * 256 kbyte RAM internally + any amount on cartridge * 0 FLASH internally + upto 128Mbyte (1Gbit) on cartridge * '''2.9inch size 240*160 color LCD/TFT display''' This is between 30x20 and 40x20 characters in alphanumeric LCD terms. * '''8 buttons''' (+power), 4 of them arranged as arrows * stereo audio * serial-port (near RS-232C with an appropriate transceiver) * SP variant has rechargable Li-ion battery with 10..18 hours of "playing"-time (the old version used AA batteries) * SP variant has backlight for the LCD (illuminated screen) * SP variant is fold-design ([http://reviews.cnet.com/Nintendo_Game_Boy_Advance_handheld_game_system/4505-6464_7-30471475.html?tag=series check pictures]) * weight is only about 125g * I got my GBA SP: it's cuter than I thought (smaller than it looks on images) * bought some accessories in a 30 Euro "SP starter pack 11 in 1" ** 12V cigar lighter powered supply (charger) 5.2V DC needed on the low voltage side, but uncommon connector ** '''connect 4 GBA cable''': cannot figure out what chip/intelligence can be in the 4-GBA connector cable (the cable that connects max 2 GBA has no chip inside) * need '''writeable (FLASH) cartridge''' ** bad news is that we found no writeable cartridge under 60 USD so far (this sucks, comparable to the price of GBA). Worths some more looking (and calling manufacturer of "Flash 2 Advance" and "EZF Flash Advance") to get it for 30USD (in quantities) - likely possible. ** good news is that cartridge seems simple to design and cheap to manufacture, downto appr. 15 Euro. Check [http://www.ziegler.desaign.de/readplus.htm homemade cartridges] for ideas. Anything is possible, eg. *** DAC (although it has hifi stereo sound already) *** ADC (which is often useful in a car, as we know) *** RTC (realtime clock) *** RAM besides FLASH (shouldn't be needed) *** LEDbar driver *** CAN, etc... * need 3V serial/RS232 or USB connector for PC-link connection. This is often called multiboot cable, since GBA can boot from the image coming from the PC. The '''drawback is that internal RAM is on the low-side''', so GTK is out of the question. Porting MegaTunix tuning software seems a waste of time to try. A software that is usable on GBA is very usable (configured a little differently) on other platforms (with more keys, higher resolution display): IPAQ, Sharp Zaurus, notebook. Price is about 80..150 USD for a brand-new unit and 30..70 USD used (see your favorite auction-site). ---- '''Who would contribute?''' Maybe we can get people, eg. from * Alexander Guy seems to be active these days and efficient and successful - many thanx * Csaba Pataki seems to like the idea * http://www.pgmfi.org/ * ... ? to help. Once the '''framework''' is there, it '''can be used for many different applications'''. Actually, tuning the honda-ecu and genboard is very similar. Basically the honda-ecu is just a subset of GenBoard functions. Controlling swimming-pool automation is somewhat different, but still a huge part of the code (framework) could be reused. ---- What would be really good is an application core written in UML that all OO applications can use. It's a big ask though. Also, this Java for GBA system might be of interest. It adds cost, and only developer version is available right now, but may be initially easier than a native app... http://www.jemblazer.com/developers/index.htm ---- '''Development Environment''' * CrossCompilation * CrossCompilation/GameBoyAdvance ---- '''Software layer''' - should it be another page? maybe OtherTuningSoftware/CommonInfrastructure with some cleanup ? I reviewed [http://www.work.de/nocash/gbatek.htm#lcdvramoverview GBA specs]. It kinda takes us back to the C64 (/Atari/Amiga/DOS/you name it) days when we programmed everything. Except we have gcc now and the wonderful ARM processor. Since the GBA software is relatively laborsome, it would be too sad to save 4% work and restrict it to GBA forever. With a little care, a tuningsoftware for the GBA would be much more than that: a tuningsoftware that is damn-easy to port anywhere * 90% of the software (as much as reasonably possible) must be written hardware-independently * the 10% hardware dependent layer would be just GBA for now, but could be rewritten for other platforms (including PC), given that * the interface (HAL == hardware abstraction layer, or for the GUI we can call it "widget-set") should support other platforms ** for graphics this suggests: some lightweight rectangular window abstraction for layout-packing and selecting "input-focus" - essentially a subset of GDK ** sound: while it is DMA and beep-beep, it should be easy ** key-input: probably we can live with all input-events (not dispatched to subwindows beforehand, but decided where it goes according our internally maintained focus-info). ** scheduling: not sure how this should be done. I guess some kind of cooperative multitasking (each task is called, but is responsible to return control soon) would support relatively painless porting to gtk later (gtk or any other recent API is action-based, but periodic callback is available too). * keyboard limitations: even if usable on GBA, it must be possible to make it even more user-friendly when eg. numeric keypad is available (==keys not hardwired. Simple #define based lookup at very minimum) * display limitations: it must be possible to pack more widgets on screen (without too much headache) where larger screen is available (comes almost free from the above mentioned "window abstaction" that has other advantages too) '''GBA 'Comms' Interface''' The GBA has a special serial port: it is capable of doing both 16 and 8 bit words, and has a non-standard connector. Its voltage level is standard FBUS (non-inverted 0/3V). The GBA supports the 'netbooting' of firmware (execution in RAM), over the comms interface, using the MultiBoot protocol. This protocol relies on the use of an uncommon serial format 1/16/1 (i.e. 1 start bit, 1 stop bit, 16 bit word), which makes it difficult to do without a specially designed hardware/software combination. The two common approaches are: * Host-based bit-banging through a parallel port (CPU intensive, prone to clocking errors). * Dedicated bit-banging, using an external microcontroller. People have had good luck building their own external cables using PICs, and other microcontrollers. One of the most interesting hacks is using an off-the-shelf USB->Serial adapter based on Cyprus' EZ-USB chips: * [http://home.knuut.de/arnim.laeuger/usb_gba/usb_gba.html USB to GBA] MultiBoot is primarily used in development, but it can be also used (with appropriate software already running on the GBA) to reflash writable cartridges inside the unit. This would be useful for upgrading on-cartridge firmware from a laptop. The GBA's UART also supports more normal modes of serial communication (e.g. 8-bit words), but they can't be used for network booting. These communication modes would be useful for the actual communication with the ECU; the stocked pl2303-based UsbtoFBus cables should work for this, as well as the RS232-FBUS cables. ---- == GBATune Development == http://www.andern.org/alexander/images/gbatune.png === Current Functionality === * VE editor. Gameboy arrow keys move to different, A increases the amount, B decreases it. L and R change between screens (currently disabled). Select changes between widgets on the screen. === Source Availability === Source is in the megasquirtavr SourceForge CVS repository under the gbatune module. ---- === Executing ROM Images Using VisualBoyAdvance === VisualBoyadvance is also available as [http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=visualboyadvance debian package]. In practice it means that the following simple command is needed to run the GBA software on a debian machine: <code> # apt-get install visualboyadvance $ VisualBoyAdvance /tmp/gbatune.gba </code> Notes: * only the apt-get command is run as root. * Also simple to run on inferior platforms: I [http://vba.ngemu.com/ downloaded] version 1.8, unzipped and run, selected .gba file from menu. * We don't have control over exact execution speed in any case: depends only on processor and load. A and B gameboy keys map to Z and X, and L and R get mapped to A and S, in the standard VisualBoyAdvance configuration. Maybe we should standardize on config with same keys as used in GenBoard/MenuSystem ---- '''See also''' * http://www.work.de/nocash/gbatek.htm -- No$'s GBA Bible * http://www.cs.rit.edu/%7Etjh8300/CowBite/CowBiteSpec.htm -- CowBite's GBA Emulator Specifications * http://www.thepernproject.com/ -- GBA Development Tutorials * http://boycottadvance.emuunlim.com/ -- BoycottAdvance Emulator * http://vba.ngemu.com/ -- VisualBoyAdvance Emulator * [http://www.bonusz.hu/play.php?idA=pijgnjdohuxw JAVA based GBA emulator] - awesome * [http://www.nintendo.com/consumer/systems/gameboyadvance_sp/index.jsp nintendo's official index page - eg. user docs] * [http://www.sg.hu/cikk.php?cid=23530 bluetooth module for GBA SP] - it's Hungarian, but you can use google and the company names like "X-Tra Fun" to find English articles
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.