Propeller-based luggable PC

Dennis Ferron

Well I finally found the right case for my Propeller computer project. I found a nice black aluminum suitcase that will look like something out a James Bond movie. It is just wide enough to hold a keyboard inside and I can mount an LCD TV to the inside cover, and breadboards underneath everything. The suitcase is deep enough to hold everything comfortably, but shallow enough to be believable as a "giant laptop" (actually, a luggable computer). I'm also going to provide A/V-out and connections for 2 or 4 playstation controllers, so that it can double as a game console.

My idea is to use the Propeller for the video and all I/O, but pair it with a Motorola 68000 and lots of RAM so that I can compile C programs to run on it. This is so that I can recompile a stripped-down version of Minix (a version of Unix) to run on my luggable computer. This way I can include an IDE hard drive and file system. All I have to do is modify the low level operating system code to talk to the IDE drive through the Propeller, and the levels of file system code above that should work the same. (Older versions of Minix could be compiled for the 68K anyhow, and they would like to do it again but haven't gotten to it yet, so making the latest version to run a 68K machine is not far fetched.)

Not only does using the Propeller eliminate the need for other I/O chips and glue logic, it will also allow me to eliminate the need for a ROM for the 68000. I can give the Propeller DMA (direct memory access) into the 68K's address space, and wire it up to be able to do bus mastering. When the computer boots up, the Propeller will boot from its own ROM. The Propeller can then reset the 68000 and steal the 68000's bus from it, and start writing to the Motorola processor's RAM directly. This will allow the Propeller to load the boot program directly into 68K RAM space without the need for a BIOS ROM! (The Propeller could, for instance, get this program from the boot sector of the IDE hard drive.) Since the Propeller has the ability to interrupt the 68K at any time and read or write the contents of RAM, this same mechanism can be used as a means of communication between the Propeller and the operating system running on the 68K. It will also be a powerful debugging tool because the Propeller can have a boot/debug monitor that a key combination would break into and allow you to do anything you like with the contents of RAM, or make the 68K jump to a certain program address.

I think the main reason I started this project is seeing Mike Green's post about his Propeller operating system. That could become the basis of the boot monitor for my luggable computer and would provide keyboard and video control. In fact, the computer could certainly be operated just fine without ever starting a program on the 68000. The main benefit of having the 68000 in it is to be able to run the Minix file system from a hard drive, interface to more RAM, and as yet another processor for game applications.

When writing video games on this computer, the 68000 could be used for main game code, while the Propeller could act like a virtual hardware accelerator for graphics and physics. For instance, the main game program on the 68000 could simply tell the Propeller that a bullet should be spawned at point P and it has velocity V and uses animation A. From then on, cogs on the Propeller would take care of simulating the physics and moving and animating the bullet. When the bullet intersects with something, the Propeller could interrupt the 68000 so that it could compute what should happen then. (Meanwhile the 68000 could be processing the AI scripts or unpacking level data.) I don't know if any of you have heard of physics accelerator boards - basically, it's the same thing as video acceleration except for physics. Since the Propeller in this luggable computer would be a piece of reprogrammable virtual hardware, I could actually program a physics accelerator, or anything else.

I'm also thinking that having the 68000 paired with the Propeller would allow me to do some modest 3-d graphics. The most memory-intensive parts of the 3-d engine would run on the 68000, while the most pixel-intensive parts of the engine would run on the Propeller. Another way of putting it is that the 68000 would keep track of *what* can be seen, and it would pass that information along so that the Propeller could determine *how* it looks.

Edit: Oh, I almost forgot to say what I do have right now for this project. I have 256K worth of static RAM chips, the 68K processor, the breadboards, and a whole bag of 8255 I/O port chips because I'm going to need lots of I/O lines! I'm using a PropStick for the Propeller, EEPROM, and serial communication with the PC. I had a problem with the first Propeller chip I got but the new one is working fine, so hopefully I'll have something up soon. It's slow going because between work, college, church, and other things I don't ever have more than 1/2 hour at a time to work on anything I want to do. It's difficult to sit down and get some serious hacking done when you are constantly interrupted, so what I do is I gather everything I need, and think about what I will do, and gather some more, and then hopefully a rare day will come along when I have three hours to myself and I can get everything assembled in a mad sprint.

Post Edited (Dennis Ferron) : 9/7/2006 11:28:21 PM GMT

Mike Green

Just a thought, but with the costs and capacity of Compact Flash cards being what they are, you might consider a 1GB compact flash card rather than a real hard disk. Power requirements are less, there are no moving parts, etc. They essentially have an IDE interface anyway.

This sounds like a fun project. Best of luck!

Dennis Ferron

You're absolutely right. Compact flash is more practical for this application. I still want to use a hard drive, though, because for me drives (hard or floppy, but who wants to mess with floppies?) have always been sort of this black hole in my knowledge. Theoretically I know I could use them in a project, the information to interface with them is difficult but not impossible to come by, but in another sense it just seems a million miles away. So to actually get it working with "a real hard drive" would be intellectually liberating and a source of confidence. If the novelty of doing that ever wears off, then, since they do share essentially the same interface, I could replace it with a compact flash.

The other reason for using the IDE hard drive is that I could set up a second standard PC also as a Minix system, and I could check that my suitcase PC is writing to the hard disk correctly by moving the drive back and forth between the standard PC and the suitcase PC. (Arguably this could be done with the Compact Flash more easily. Not sure I'm making my point or undermining it...) Of course, I'd have to boot the Minix PC from a different drive since the boot loader machine code will be different, but that doesn't stop me from mounting the other disk too. I could even use that method to load programs on the suitcase PC as an alternative to the serial interface. And it would be good for disaster recovery, etc., etc. A potential problem with doing this is that the 68000 is big-endian while the Intel PC is little-endian, so I would either have to program the suitcase computer to swap byte order when it works with the disk, or program the PC to understand the Martian byte order when it inspects the suitcase computer's drive. Not sure which way I want to go with this one. I think it would be worth solving though; I recommend one always go into a project with a Debugging Plan (capitals emphasized) and moving the drive from the machine under development to a known good environment would allow me to isolate many potential problems.

Thanks for taking the time to read about my project, Mike, and I hope I have some more to show you soon. I read some of the code for your Propeller OS and I've been amazed at how much you have done with that and so quickly. I hope we see a trend start with people building portable computers out of the Propeller. I mean, think about it, take the Propeller development board, build your keyboard, dev board, batteries, LCD TV and maybe a trackball into a small suitcase and suddenly you have your own custom laptop that nobody else in the world has one quite like. One doesn't necessarily have to use a 68000 or do as much from scratch as I'm doing for this. I have a strong electronics background but someone who didn't could stick with the dev board and the accessories kit; then it just becomes a question of assembling the components. A guy in college could take it to his computer science classes to take notes on, impress his friends and intimidate his professor with it.

Now all we need to do is find a way to get the Propeller and Mike's OS to work with wireless internet, and then we can write a Propeller web browser and rule the world!

(Maybe hack a PCMCIA card interface, or use one of the Atmel USB controller chips and a USB wireless adapter? Does any company make some kind of crazy modem that bridges WiFi to RS-232 serial? A browser with real internet access is the killer app for something like this. We could do this!)

Edit: Holy Smile they really do make a serial to WiFi bridge! I found one!
news.thomasnet.com/fullstory/453466

Post Edited (Dennis Ferron) : 9/8/2006 5:09:31 AM GMT

Mike Green

The biggest problem with a practical browser is the low resolution graphics screen. I've played with text only browsers and they're just not useful except for special purpose applications. E-mail you can do even though more and more e-mail contains PDF or RTF attachments with the "real stuff" in them.

There's an ARM based Linux microcomputer called the GumStix because it's about the size of a large pack of gum and pretty cheap. You can add Bluetooth and Ethernet to it, but it's strictly text-based. There are addon options for MMC/SD cards. It could make a good network/storage coprocessor for the Propeller. A complete system for $199 comes with Bluetooth, MMC/SD, and USB along with 2 serial channels.

Dennis Ferron

Oh I forgot about GumStix. That might be easier than controlling the wireless directly, and, like you said, it comes with all that other stuff.

I'm with you - I don't find text mode browsers very useful either. I used Lynx on a FreeBSD system and it was quite a novelty, but navigation can be a pain in the butt and many websites don't work well without their graphics and don't lend themselves well to a text only display. In an ideal world, all website designers would follow the original intent of HTML, which was that you control content but don't control presentation. Unfortunately most people just don't "get" it or have pragmatic reasons not to follow that intent, so you get a lot of websites that break if not displayed just so.

I want to write a graphical browser. The low resolution might be a problem - um, just *how* low is the resolution? (I haven't had a chance to play with the TV out yet - I've been using serial and a terminal with my Propeller.)

I can see two problems the low resolution could cause. One is that text will take up too much room and overflow all over the place. The other is that images wouldn't display well. For the images, I'm thinking that when you download the image, you discard 3/4th or more of the pixels on the fly, and display the image on the TV with a relative size to what you would see on a computer monitor but with a lower resolution. It would look muddy but using a TV connection I can watch my professor in one of my distance learning classes browse the net and I can still understand what the page looks like, even if it doesn't come out very clear. We wouldn't want to store lots of images anyhow - not enough RAM. In fact, I would go so far as to say we should discard an image when it scrolls off the screen, and reload it in a background cog when and if the user scrolls back. If the user has a spare EEPROM or a hard drive, then we could cache the images, but if not we could degrade gracefully to dropping images when they aren't visible.

For text, I think I have a solution that would work. Again we make every text field take up roughly the same screen real estate on the TV as it would take up in Firefox on the PC. That way, websites will still have a layout similar to what you've come to expect from a graphical browser. This time, instead of discarding pixels we have letters displaying much larger than they do on the computer monitor. Instead of letting the text overrun the space for it and fill up the screen, we would only display the amount of text that can fit in the imaginary box, and truncate the rest with a "..." on the end. Then we make the cursor act like a magnifying glass, so that if you move the mouse over a box of text the box expands to a size large enough to display all the text in that area. (I don't know what happens if the text is too big for the entire screen - a fairy dies?) The magnified text box will cover other content but that's ok, because moving the mouse out of the imaginary box returns the box to its smaller size. Links inside the expanded text will be tricky because you need to be able to move the mouse to the link without making the text "bubble" pop when you leave it's smaller box. Maybe have add a delay that keeps the bubble open for a short time? Or we could move to a system where you have to actually click on a text box and click off of it to make it expand and go away, instead of it just popping up like a giant tooltip. One thing we must NOT do is force the user to find and click a tiny X button everytime. Also, if it pops up automatically, it should go away automatically. If it has to be clicked to go away, it should have to be clicked to come up, too. I.e., if we initiate it ourselves, we should resolve it ourselves too. If the user initiates it, we should wait for the user to initiate its going away too. Law of least astonishment.

I think this text truncation thing could become intuitive because if you think about it, you never read everything that is on the screen on a busy site. You are usually interested in the place you want to go or the one thing you want to read, and the rest is just a big distraction. It's even more so if you already know what the site looks like. And websites that don't load the screen with useless junk (for instance, the Google search page) the resolution is not a problem because all of the content on the Google search page is going to fit anyhow.

Speaking of Google, I noticed that most of gmail seems to be run server-side. I could be dead wrong but much of what the page source is seems to be vanilla HTML. If that's the case, we should be able to access gmail with a very simple browser.

I have an ulterior motive for wanting a web browser. I want to use a browser to replace/eliminate the Unix terminal and command line entirely. The command line is just a program that gives you control over the operating system. We inherited the command line/terminal format from early systems which used dumb terminals or even teletypes. It's not the only way of doing things. Instead of organizing your shell as a command line with utility commands, you could organize your shell as a set of webpages with fields and buttons you use to do the same things. (Like when you use your web browser to configure the cheesy router you buy at Walmart.) The browser could be your shell instead of the command line. Instead of Telneting into a remote system, you would browse it over HTTP.

The reason I want to do this is that if you sit someone down at a command line and they don't know the commands, they're lost unless they have some good documentation or someone to teach them. The command line just doesn't provide you with any context clues on what to do next. But if you sit someone down in front of a web site that is reasonably well organized, there is a good chance that they will be able to figure out what to do just by following links around. It always amazes me to see people who can't use a computer's desktop or commandline well or not at all, but get them on the internet and they do just fine. I think there's something important there. As geeks we may do just fine with commandlines, but we also like to tinker. Maybe I'm just getting old but I've grown to like the thought of being able to sit down at a computer and have it just work. And with a web interface, it seems to me someone is much more likely to have that experience than if they're trying to guess the right format of a command they're trying to type at a command line.

Mike Green

A web-based command interface is certainly easier to use and can be more intuitive than a command line interface although there was a command line system for the DEC PDP-10 Tenex system maybe 30 years ago. It had built-in context sensitive help, did command prediction based on context. As long as you knew to type a question mark, it would provide increasingly more detailed help information - totally text based. I've never seen anything even remotely as sophisticated since then. I had hopes for the Apple Newton since it too was based on a LISP-like AI framework and did a lot of prediction, could handle context. Unfortunately, it came too early for the processing power needed to do it right and fell victim to corporate politics as well.

Have a great project! After seeing what Andre has done with the Hydra, I'm impressed with what can be done with the Propeller.

Lawson

The Matlab computing environment also has a wonderfull command-line help system. I think you need to know the bare basic commands, but after that it's quite easy to just type in "help <some command>" and get detailed information and examples AND a short list of similar commands. Nothing too sophisticated really, just well organised help files easily accesable via command line.