Roar.

Hmmmm, well I was wrong about why newlib was crashing. It's because the 'loader' is just executing the code in place, and the default linker script (that i've modified slightly) was re-aligning the data segment load address, but not the file offset. So again the data wasn't aligning with where the code expected it (rodata was still, which was confusing of course). For now I just removed the realignment of the data segment and yay, libc now seems to work.

It was still crashing in C++ though.

And of course, I downloaded the wrong version of the toolchain, so I didn't have the source to go looking through. But while it's downloading the right version I poked around on the cvsweb interface for newlib and found the right bit of startup code anyway. Ahh, missing a call to _libc_init_array.

Still crashing.

Hmm. At this point i'd developed the exception handler to dump the registers and some of the stack and was looking at finding out where in the C++ code it was crashing, so I recompiled with no optimisations and debug on. Damn, now it started working!

Mostly at least. Something is still wrong with bss in it or something - every time I compiled it it displayed using a different zoom/shear/rotations. Although if I set those explicitly, it all works fine.

Not terribly fast - every lion takes just under a second to render.

I've identified that the C code can't be compiled with optimisation -O2 or higher, so assuming there's no compiler bug, there's something in the dodgy setup code that's out of whack (C++ is compiled with O3 fine, but it isn't doing any of the hardware banging). But that doesn't surprise me in the least (missing volatile's and the like), and for now it can stay being unoptimised.

I've kinda forgotten why I wanted to render 2D polygons in the first place. I think it was to avoid storing big bitmaps, but using C++ seems to drag in stdio (for exception reporting) which blows code size out to about 200K anyway. Might be better off with a small PNG decoder instead.

Interrupts and exceptions

Yay, the weather finally turned. By the end it was just getting crazy - I'd accidentally left open a window in the house all day (or for a few days) and half of the house must've been 35 or more. Didn't think it was worth cooling it down - I just barricaded myself in a smaller part of the house with separate ac. A bit of rain too, not really enough but it'll do.

Should've got out digging in the yard this afternoon once the rain stopped but instead i've been poking around trying to get some stuff working on the beagleboard. I was trying to get AGG to render some stuff - but it's C++, and I don't really know enough about the execution environment of C++ to get it to work. But not even malloc() works in C, so for now i'm just trying to get that working (it uses newlib, and it crashes before it gets to calling sbrk()).

Since all I was getting was at best a silent death, I figured I'd work out a little about exceptions too - at least find the address of the crash. I misread the bit about interrupt vectors at first and spent a lot of time chasing that down ... I was writing a vector of addresses to the interrupt vectors, but it's actually a jump table. I found this out early on but forgot to fix the code and went off on a very long-winded goose chase trying to work out what was going on after some mis-direction from the mailing list archive. Well with the hot weather I hadn't been getting much sleep, so perhaps there's an excuse!

Well it told me it was crashing in malloc - but i knew that already. Can't easily figure out what's going on without source (it's something to do with static intialisation), so downloading the newlib source now (actually the whole toolchain), which is gonna take forever since I blew my quota.

Limited success.

Well I had some limited success on the DSI PLL clock front. I found some posts on the newsgroup and decided to look more closely at the kernel source too. Well I sort of got something working, eventually. Using the 72Mhz clock as the source for the PLL anyway. I dunno, it doesn't seem entirely right, and the monitor keeps dropping out every 20 seconds or so, so I might just leave it for now. At least I have a few of the bits needed.

I played a bit more with the matrix code. The snakey things move down the screen and react to things and bounce around like they should. The X-Y zappers move and 'zap' every now and then, planting a seed where they meet. Which ages and then drops off the screen. Even have a sequencer setup that describes the waves.

And I have screenshots! People like pictures don't they? Although it's only using putchar() as the 'rendering engine' at present!

This shows part way through wave 1, with the X-Y zappers just having fired.

And this shows a little later on - the attack ships and XY zappers have moved on a bit, the X-Y zap from the last shot planted a seed, and one of the earlier seeds have died and is currently falling down.

Bugger all code so far. Adding some user-controlled ship and bullet logic should be a doddle on top. Even played a bit with blender to draw some ships (actually I tried gimp first, but I really can't draw at all, not even slightly pleasant looking blobs), although implementing any graphics display is some distance off.

Now for another rant, sort of.

Since i've been back hacking for a while there's one thing i've really noticed. Boy is it much nicer developing using a GNU/Linux box than using Microsoft Windows (and that was XP, which is supposedly the best one). Ok this machine is a bit faster - quad core instead of dual, but the difference goes well beyond calculation speed. Everything is so much smoother and faster. I used to wait around for 30 seconds (I actually timed it) just for the friggan HELP to come up most of the time! Switching applications or desktops (using VirtuaWin) crawled. Even just using the browser ran like a pig after a few tabs were open. Pretty well everything I needed to do, every time i needed to do it, just seemed to illicit a groan of discomfort at the pain I was sharing with the CPU as it struggled to complete the task. I rarely even get the time on this box. And when it does take a while, it's usually obvious why.

Currently I have 5 x emacs, 1 x icecat (with 53tabs), 1 x javam (in icecat), 1 x blender, 1 x evince with 14 documents open (between 4 and 3500 pages long each), 1 x gimp, 1 x transmission, 1 x seamonkey (650MB alone!), 11 x xterms, 1 x xfontsel, 1 x gdb, synaptic, and even mythbackend recording tv as I type. The machine is using 3.5G RAM, and 1G of swap and has been up for 2 weeks.

Yet it just about runs like I just logged on.

Everything is snappy, and stable, I have all the tools I need at my fingertips - without having to use the mouse for every. click! little. click! fucking. click! thing. click! i. click! fucking. click! need. click! to. click! fucking. click! do. click! click!

Not going to enjoy going back to a windoze machine for work, if that's what I get lumped with.

Well that was a bit of a waste.

Blah. Spent hours and hours trying to figure out some of the clocking on the OMAP. My video output isn't quite correct at the moment - it works with my monitor, but it'd be nice to fix it. But I just couldn't get anything I tried to work. The documentation has strange examples which are a bit hard to decipher. I thought I managed to work out the programming of the clock it was using, but then the serial baud rate changed. Damnit. Tried using the other clock - and that took even more digging the documentation - but I can't get that to work either. The linux source is a bit convoluted but I might have to resort to working that that out to understand what's going on - the clocking system is pretty ... complex (there are dozens of clocks, with many cascaded from others).My new FSF membership card came in the post - or at least I got it out of the letterbox today. Bit thicker than i'd hoped - it's like a fibreglass PCB, so it might not make my wallet. The Trisquel installation is quite nice too - well setup, quite polished - everything just works. With a good selection of real applications too, like openoffice.org, gimp, inkscape, gthumb, and even evolution. Unlike some distributions with their weird application choices. Pity it's debian based mind you.

Hot again today - garden still alive somehow, at least the bits I remember to water. Getting a few (small) cherry tomatoes off every day - enough for a little salad. I suppose I need anything I can get to help my crappy diet lately. I even managed to get out for a bit - although it was just for groceries. Is it just me or are the roads a lot busier these days? Sigh.

gloat 0.1

I'm sure i'll live to regret this (i can already hear the glee of some kid discovering a buffer over-flow - well, in the unlikely event anybody ever downloads it), but i've uploaded my news snarfer 'gloat' to Google Code.gloat - it's a bit like brag ... err, geddit?

I'm going a bit loopy today. I was up till around 4am working on a 'matrix' clone (C64 - llamasoft), although now i've lost interest in it somewhat. And after a little mucking about in the garden have been solidly stuck behind my machine reading the net, manuals, and poking at bits of code all the way through till nearly 8pm - again. Well I had some lunch and coffee somewhere in all that.

Oh - it was too hot today to do much outside, but I suppose I should be using the weather to go to the beach or do some cycling or something I can't do all the rest of the year.

Wrong UART

Well I got serial output working - was using the wrong UART (should've read the docs before assuming UART1 - it's UART3). And Das U-Boot leaves it properly configured so the output function is only 3 lines of code.

Then I hit an issue as soon as I started to use static data - my code wasn't being loaded at the right address (which took me some time to realise, since the code still ran). I don't really know why it works but I fiddled with the Das U-Boot mkimage line and now it's loading everything to the right address - it should be loading at 0x80008000 but I need to tell it to load at 0x80000000 to make it work. *shrug*

I got sick of ripping the SD card out to setup a new 'kernel' image (and a little worried, the SD slot on the beagleboard isn't really designed for repeated use), so I rigged up a rather nasty `runscript' (from minicom) script which uses ymodem to upload the image whenever I reset the machine. While the image is small this makes the testing cycle pretty easy. Just need a serial port thingy for my workstation and then I wont need the laptop anymore either.

Also along the way I wrote up some basic graphics output - just to clear the screen and display text, including a simple printf type thing. I converted my favourite font 'fixed' to a c file and can now dump text to the framebuffer. Originally I just wanted it to get some debugging output since I couldn't work out what was up with serial, but it's still handy to have.

And lastly I had a bit of a play with the DMA engine. And after a LOT of mucking about, finally got it filling rectangular regions. I couldn't for the life of me work out why double-indexed DMA just did nothing - in my haste to avoid reading the docs too closely I missed the bit which says exactly how it calculates the next address after a 'frame'. I had the alignment mucked up so it did absolutely nothing. If nothing else, it can be used for a very basic 2D accelerator - 90 degree rotations and flips, rectangular moves/copies, solid colour fills, and even masked sprites (colour keyed). So now my 'random filled box demo' runs a lot faster than it did before - around 10x actually (not that it was particularly optimised or anything).

I did some research on USB. Man what a mess that is. A few books i 'found' on the topic were useless too, just written from the perspective of windows driver writers at best (when a book uses 'visual basic' for 'portability' you know there's something very very wrong). I found some USB host stacks but they're proprietary, GPL2.x only, or BSD + advertising clause. And in any event tightly coupled to a given OS (as they must necessarily be). The Haiku one is at least X11 licensed, and clean and simple, so apart from being C++ might be the place to start if I decide to hurt myself one day with that pain in the head.

Hmmm, perhaps interrupts next, will have to get my hands dirty with assembly at some point.

Unripe fruit and vegetables

It turns out I kept picking my cucumbers green. Of course, they were just like the ones in the shops - seedless, pretty bland (although not quite so bland) and 'normal' sized.

I missed one for a few days and picked this giant - about 2' long and 5cm in diameter. Wow. That's what cucumbers used to taste like. And of course do - if they're ripe.

Same with the button squash, I'd been picking fiddly little ones, often a little bitter with a very soft skin that spoils easily. Again I missed one for a few days - and it's a world of difference. If they grow to about 10cm across or more and get the harder outer skin they taste much better (a little sweet) and last much longer (i'm also letting one grow 'all the way' to see how big they get/how it goes - it's about 25cm across after a few weeks).

Green limes - fully ripe limes are light yellow. They taste utterly fantastic and have much more juice too. Although certain varieties, such as the Tahitian Lime can get a funny over-ripe taste, so there is some justification for picking them a bit earlier. But not when they're hard and dark green. But most of the time that's all you can find in the shops (let alone the exorbitant price).

People have been trained to buy this unripe fruit, so nothing else sells. How silly. They must be right down on vitamin C and other nutrients as a result.

Why is software so far behind hardware?

For various reasons I was trying to get some binaries from some very large newsgroups - so large that I couldn't find any client that would even list all of the messages without hanging or crashing. Interestingly, I found the mail/news application in seamonkey to be one of the better ones - it worked much better than thunderbird, using far less memory, although it still got stuck very often, and that was only with 200 000 headers rather than the 6 000 000+ in the group.

I saw a few scripts/programmes for grabbing stuff in the repository for this machine so I gave them a go. I can't remember all I tried but `brag' seemed to fit the bill and worked ok on a smaller test group. Well, needless to say it just didn't scale. Either the code is bung or tclsh has a big memory leak or simply isn't up to the task. It managed to download all of the subject lines (meanwhile memory use - ~2.9G!). Well my machine wasn't really swapping so big deal eh? But then when matching the headers memory use continued to climb - even faster. It ran out of 32-bit virtual memory ... well I guess I should've been using a 64-bit OS for such a complex task!

Err, no, that's just bullshit. So I hacked up a quick and dirty C version. Has somewhat fewer features but works more or less the same for what I needed. A bit over 400 lines of code in total, only using libc. No smart algorithms apart from a zero-copy 'read-line', no asynchronous reads or other decoupling of net i/o from disk i/o or processing, etc. Total memory used whilst reading and saving the subject headers of said 6 000 000+ group - about 100K (and most of that is from the C library, I think I malloc about 50 bytes, and have 11K of bss). Total CPU used, about 10 minutes real-time, and about 5 seconds cpu time (top consistently showed 0% cpu usage - well I mean as it should, it's entirely

CPU

I/O bound!). It takes about 3 seconds to scan the 780MB cache of titles with a regex when they're in the buffer cache, about 10 otherwise (using the same amount of memory).

Alas, this is the world we live in. This is why a `netbook' isn't big enough to run `real' applications - it will just be destined to run slow scripts which proxy the heavy lifting (when it is quite capable of doing an awful lot of the heavy lifting itself). It will be kept busy struggling to show adverts instead (even something my 4 core machine has trouble with, so I turn off animated gifs and flash and block lots of advert pics). This is why, after all the advances in hardware, we now have shitter apps that run more slowly - e.g. for all it's cracked up to be, compare google-writer to say, abiword, or calc to gnumeric - with no other benefits like stability, security, and so forth.

I was looking at javafx again just recently. Someone hacked (and I mean hacked) up a sort of 'space invaders' game. Except it has no sound (could be my use of oss4), no barriers, the aliens don't move properly or speed up, and unusable controls. And it jerks around in an unplayable fashion, with tearing and an utterly atrocious frame-rate. Flash et al are pretty much the same to me. Slow, jerky - crappy games. The machine in question is capable of emulating real hardware faster than that - you can play the real space invaders (or for me, the C64 version) with proper sound, control, and 'game' all in it's glorious full-frame-rate goodness with no problems (and so it should, it's emulating a 30 year old computer!), but it struggles with a half-arsed rip-off.

Poor algorithm choices. Bad language/framework/environment choices. Poorly implemented language/framework/environment. In short, poor engineering and system design.

Computer Science lecturers always say `we don't teach computer programming'. And it's pretty obvious - no, no they don't.

(TBH `brag' does more processing than just a regex match on the titles. It tries to find the filenames, and count the parts, and tries not to grab duplicates. And it uses multiple connections to improve downloading of the actual messages. Still, there's no reason it should use anywhere near that much memory, loading all subjects into memory at once is not ncessary.)