blog-duncan-08-2003
| index | WikiPages | AdditionalFiles |
Sometimes, I like to remember the good old days (obviously not first hand - I'm not that old)... Just how could something like »Ivan Sutherland's Sketchpad exist using such archaic hardware, with so little processing power and a minute amount of memory?
If you've got the bandwidth, download »"Doing with Images Makes Symbols Pt 1" (that's a pointer to a page on the Internet Archive, not the movie itself - it's a good 120MB in its smallest form). It's awe inspiring seeing this stuff and realising it was all done over 30 years ago!
I'm going to try to see what I can do in »a few kilobytes of memory, with a tiny microcontroller - we're spoilt by the powerful hardware we have now-a-days. My new motto is going to be "doing more, with less" - and I'm not only talking about technology.
I'm vascillating between eCos, Linux and NetBSD porting - argh! Must stop.. must choose.. but it is so difficult..
Update: Okay, my latest vascillation is eCos then NetBSD - eCos as a boot loader (in the form of Redboot), followed by NetBSD:evbarm as the operating system.
About-turn: Arm-boot & Linux.
I've ordered a few FTDI 245BM chips, so things progress (albeit slowly).
The bank holiday weekend's over, and its time to get back to developing Vidi. Following some intereting email correspondance, I'm convinced that a USB wearable display attached to the GamePark 32 is the way to go.
The »GamePart 32 is due to be launched in Europe soon (they can already be imported - I got mine from »Lik-Sang based in Hong Kong) and, in my opinion, it's the perfect basis for a wearable computer:
Such a system is more than capable of running Linux, and has been designed from the ground up to use as little power as possible. While there isn't a Linux port yet, there has been talk of one, although there's little surface action visible. If worst comes to worst, I'll have a USB wearable display that I can use with a laptop, I may even try to port Linux (but as an electronics engineer, I don't have any experience of porting an operating system - I'm expecting it to be very hard - but not beyond my reach).
Anyway, progress may appear to slow for a while - I have to get used to »Eagle PCB (I miss using »PowerLogic and PowerPCB, but at least its »free to use for non-profit purposes) - plus I want to investigate a Linux port for the GamePark 32. I shall keep you informed.
This page will be offline tomorrow (the 27th August 2003) to demonstrate my support against software patents in the European Union. I hope the politicians get it right - although that may be a first ;-)
The frame-buffer has been reinstated - it's just the right thing to do - so there's a newer, slightly more edible version of the »VHDL code to download now.
The frame-buffer means I need to use a larger CoolRunner now, so I'm going with the Xilinx CR3128XL-10VQ100 which has 84 user input/output pins and 128 macrocells. These cost between $8 and $10 in one-off quantities from the »Xilinx website - even with an additional SRAM it's not going to break the bank.
I'm going to have to start thinking about the analogue side of things now. It's not my favourate thing to do, but because it's a 1-bit monochrome colour depth, it shouldn't be too hard, even with the various supply voltages that will be needed.
As an aside, I do recognise that there's the possibility of tearing with the framebuffer as it stands. I'm going to add an extra address line and connect to a 32KB SRAM (16KB SRAMs are hard to find anyway) and double buffer the display - I just haven't gotten around to it yet.
Paranoia strikes! I just thought I'd leave the »VHDL code for Vidi somewhere off-site. It's not really fit for human consumption yet, but I thought I'd better put something out there just to give myself a little push.
This version of Vidi (the USB wearable display) will use pretty much all of the bandwidth (okay about 75%) of the USB connection, so it won't be feasible to connect it to a hub. Also, I'm not 100% happy that you can't resynchronise the display if something goes wrong - but I might be able to wrangle around this somehow (besides, it would only get out of step if there was a problem in software - that's not going to happen ;-)
Okay, so I'm fickle.. I've decided to resurrect Vidi (my USB wearable display) in parallel with MiMi (my Gameboy Advanced wearable computer / display).
Why?
Well, until I get an answer to some of the questions about GBA DMA I'm at a loose end :-)
I'm currently waiting for some information on the »Gameboy Advance's DMA system - I'm slightly dubious about whether the GBA will meet my needs (for the simplest approach anyway). However, I have managed to just fit my design into a 44-pin variant of a 64 macrocell CPLD - so that's some good news - although it is a very tight squeeze.
My main concern with the GBA is that information regarding the DMA is fairly ill-defined. Even if my interpretation is correct, there's still the question of whether the processor will be fast enough to handle my interrupt routine that will reset the DMA transfer once every frame.
Now that I've said all that, I must admit I'm glad I went the GBA route. Even if the the GBA display doesn't pan out, I can use the same low chip count approach with my USB device. I don't need any on-board memory, and can just reply on the isochronous USB transfer mode and the FTDI chipsets built-in FIFO.
If I do end up fleeing back to the USB approach I don't need to abandon my dreams of a low-cost wearable design completely. My »GamePark 32, which has more memory and a faster processor than the Gameboy Advance, has a USB connection that can act as either a slave or a host device. The GamePark also has SmartMedia socket for expansion, and there's the possibility of a Linux implementation in the works.
Still, I hope the GBA approach pulls through - keep your fingers crossed for me!
Who is Mi-Mi (sorry!) designed for? Well, I want to try and make this project as accessible as possible - the component parts need to be cheap, and you need to be able to build the system up with the minimum of additional equipment. As to skills - well I'm afraid you are going to need to some surface mount soldering skills (don't worry, it's not as hard as people make out).
Regarding the actual display, I'm going to try and get away without using any additional memory. The GBA will be tasked with providing data to the display at regular intervals using DMA. This uses approximately 25% of the processor's bandwidth - this is a lot but conversely 75% of processor's time is available to you for general programming - and it is a reasonably powerful processor. Adopting this scheme does simplify the design considerably, and should allow us to get away with a 64 macrocell device with fewer pins. (If the screen memory were cached in the internal Word RAM of the GBA, then only about 15% of the processor's bandwidth would be used for the display.)
The GBA has two methods for executing user-code. The first is to place the program code on a cartridge, the second is to use the multilink protocol through the GBA's multiplayer connection port. The first method would require flash memory to be added to the display cartridge, and increase the complexity and pin requirements of the CPLD code - so I'll go with the second method.
I propose a user-input device that connects via the GBA's multiplayer connection port. This device will be multi-purpose, with the following functions:
I've located a cheap source of PCBs, and JTAG programmers for programming the CPLD, and PIC programmers (for the user-input device microcontroller) are fairly easy to come by. If needs-must, I could provide a kit of pre-programmed parts - although hopefully this won't be necessary.
In the beginning, there was the idea.. and the idea was a USB-based wearable computer display.. and it would have been good. A potential glut of Motorola driver chips for Kopin 320M CyberDisplays put paid to that. Why would people need my chipset if they had easy access to one of those? How would people ever focus on the key issues if they were spoilt by greyscale graphics, and the associated expensive hardware needed to drive them?
And lo, it came to pass that I was mightily miffed - having just completed my VHDL code for the USB Display - and I did gnash my teeth most loudly. What was I going to do - how was I going to set the people free? How was I to ensure that everyone would have access to a wearable computer?
Behold! The mighty »Nintendo Gameboy Advance - cheap, low-power, affordable computing power - perfect as a wearable base! My wearable display will be reborn hooked into a Gameboy Advance! This new wearable will be programmed in Scheme, and connected to a rinky-dink glove-based input device.
I think I need a lie down now.
(Powered by PWP Version 1.4.2)