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, CPU and sound 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 + more complete internationalization support.
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 [specificatoins].
- Sharp ARM7TDMI processor
- 256 + 32 + 96 kbyte RAM internally + any amount on cartridge
- 0 FLASH internally + upto 128Mbyte (1Gbit) on cartridge. 4Mbyte flash is available on the low-cost cartridge
- 2.9inch size 240*160 color LCD/TFT display This is between 30x20 and 40x20 characters in alphanumeric LCD terms. Subpixel rendering works nicely
- 10 buttons (+power+backlight), 4 of them arranged as arrows
- stereo audio (available as analog output) with one speaker
- serial-port (near RS-232C with an appropriate transceiver)
- SP variant has rechargable Li-ion battery with 10/18 hours (backlight on/off) of "playing"-time (the non-SP version used AA batteries)
- SP variant has backlight for the LCD (illuminated screen)
- SP variant is fold-design ([check pictures])
- weight is only about 125g, slips into your pocket
- 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, probably same as Andrew May's drawings found from linker section of [Ziegler GBA page]
- need writeable (FLASH) cartridge
- we found a rewriteable 32Mbit flash cartridge < 15 USD (in biig quantities)
- USB cables for reflashing like "Flash 2 Advance" or "EZF Flash Advance" are available <15 USD
- note that cartridge seems simple to design and cheap to manufacture, downto appr. 15 Euro. Check [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
Software layer - should it be another page? maybe OtherTuningSoftware/CommonInfrastructure with some cleanup ?
I reviewed [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:
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
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 [debian package]. In practice it means that the following simple command is needed to run the GBA software on a debian machine:\nÿ1ÿ
Notes:
- only the apt-get command is run as root.
- Also simple to run on inferior platforms: I [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://www.devrs.com/gba/docs.php another site with tons of info
- http://boycottadvance.emuunlim.com/ -- BoycottAdvance Emulator
- http://vba.ngemu.com/ -- VisualBoyAdvance Emulator
- [JAVA based GBA emulator] - awesome
- [nintendo's official index page - eg. user docs]
- [0 Euro cable that supports multiboot to upload images to GBA] - requires an x86 PC with parallel port running DOS though. ARM-side sourcecode included (!), DOS-side commented (x86 ? C ? Pascal?) source code apparently not.