Open Pandora lives and breathes... Hell yeah!
Video of a production model here...
Vid on Pocket Gamer
Now... Where's my one! Any minute, any minute, any minute ;-)
I'm not that rushed... I preordered in November last year. I'm patient!
Can't wait for this and, although I'm not the most vocal of supporters, it has been fascinating, and a learning experience of it's on) to watch the guys build this thing and all the trials and tribulations. The fact they've pulled it off in a year is astonishing.
Ohh... and it's just started snowing again.... could this chrimbo get any better (yup... I get to spend ages with my lovely missus in "the lodge" eating and boozing our way through my parents larder... then her parents larder!)
Thursday, 17 December 2009
Friday, 16 October 2009
Rant in 0x0e minor...
This has bugged me for a LONG time. First of all this... my first machine didn't have "characters" at all. It was a KIM1 and characters were just a pattern on the 8 style LED read out - you couldn't even draw some letters like Z or X - yeah, very strange. After this I had a ZX81 - this didn't use ASCII either, in fact not at all, but plugged into the telly and displayed 8 by 8 pixel chars (a whole 64 of them).
The CPU of this machine and others had some very odd assembler ops to cope with converting "raw" numbers to displayable ones. Many CPUs did, it required extra flags and extra instructions... they were only there cos' it was quicker than software. The x86 still has them.
Eventually I had a real machine that had ASCII(ish).
So, I posit the question. Why isn't number 0 (0x00) the character '0', 0x01 is '1' up to 0x09 for '9' THEN A-Z...
Think about this. When we convert from integers to text strings we no longer have to add 0x30 to the output characters. It's worse still if you're printing hex as there's a gap between '9' and 'A' so you have to detect this and add a little more.
How many machine cycles have been wasted doing this? It might not seem important on a quad core, nitrogen cooled behemoth under your desk but when you study the problem the problem is still there.
This has carried on, we've inherited this baggage in the UNICODE spec... Strange...
Maybe that '0x00' was useful as a string terminator... fact is, you SHOULD remember the length of the string. Blimey 0xff is just as easy to detect in HW as 0x00 is if you want a terminator.
Yours,
Ranty 'burnttoy' MacRant.
The CPU of this machine and others had some very odd assembler ops to cope with converting "raw" numbers to displayable ones. Many CPUs did, it required extra flags and extra instructions... they were only there cos' it was quicker than software. The x86 still has them.
Eventually I had a real machine that had ASCII(ish).
So, I posit the question. Why isn't number 0 (0x00) the character '0', 0x01 is '1' up to 0x09 for '9' THEN A-Z...
Think about this. When we convert from integers to text strings we no longer have to add 0x30 to the output characters. It's worse still if you're printing hex as there's a gap between '9' and 'A' so you have to detect this and add a little more.
How many machine cycles have been wasted doing this? It might not seem important on a quad core, nitrogen cooled behemoth under your desk but when you study the problem the problem is still there.
This has carried on, we've inherited this baggage in the UNICODE spec... Strange...
Maybe that '0x00' was useful as a string terminator... fact is, you SHOULD remember the length of the string. Blimey 0xff is just as easy to detect in HW as 0x00 is if you want a terminator.
Yours,
Ranty 'burnttoy' MacRant.
Wednesday, 29 July 2009
Awful sorry!
I've had my Vaio die on me so I've got a cheapo Mac Book (the white one). I _will_ fix the old Vaio shortly after getting paid! Having just moved jobs I'm doing that "blimey... how long between pay cheques?" thing... *argh!*. Anyway, it has to get fixed so I can recover http://www.archway-london.co.uk and the canvas projects amongst other things (like all my SSE DSP code!)
Anyways - I've spent a huge amount of time working with Qt - which, as always, doth truely rock thy world (native C++ components in Webkit? Very bumpers!).
It even supports the HTML "Canvas" element.. cripes (very useful test bench). There are bugs... but then, ain't there always?
Been working on some QObject <-> Table Model stuff and autogenerated XML output of any QObject. Priddy sweet. More later.
Anyways - I've spent a huge amount of time working with Qt - which, as always, doth truely rock thy world (native C++ components in Webkit? Very bumpers!).
It even supports the HTML "Canvas" element.. cripes (very useful test bench). There are bugs... but then, ain't there always?
Been working on some QObject <-> Table Model stuff and autogenerated XML output of any QObject. Priddy sweet. More later.
Subscribe to:
Posts (Atom)