Instant wifi - just add "Edimax EW-7811UN"

Archimedes could use one of these with a pivot

Ah, the 3Com OfficeConnect 3CRUSB10075. I remember it well...

About five years ago this would have been sold as a USB wifi adaptor, though its actual purpose was more to test the structural integrity of laptop USB ports. Extending no less than three inches, it was also cleverly more than an inch wide - providing the added bonus of preventing laptops with vertical USB ports from sitting flat.

Slightly larger than the average car's indicator controls, and also slightly easier to hit, it was close to guaranteed that at some point *something* would strike the OfficeConnect a lateral blow, resulting in  two goodly sized pieces of grey plastic, one still securely connected to the USB port.

Of course the unlucky would find themselves with one very large piece of plastic, still securely connected to your USB port, and a usb sized hole in the side of the laptop.

For mild amusement, I plugged it into my Thinkpad (after turning the laptop on its opposing side, then using both hands and alignment rails to guide it into place) and NetBSD's dmesg blurted out:

zyd0 at uhub3 port 1
zyd0: 3COM 3CRUSB10075, rev 2.00/43.30, addr 2
zyd0: HMAC ZD1211, FW 46.05, RF RFMD, PA 0, address 00:0f:cb:c0:8c:d6
zyd0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
zyd0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

If I recall it even came with a cap - which itself was around three times the size of the other USB wifi adaptor in the picture - an Edimax EW-7811UN.
For the princely sum of GBP8.95 delivered this diminutive device provides wifi connectivity without significantly adjusting your machine's centre of gravity:

urtwn0: Realtek 802.11n WLAN Adapter, rev 2.00/2.00, addr 2
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 80:1f:02:61:13:b0
urtwn0: 1 rx pipe, 2 tx pipes
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

I had hoped to provide some benchmarks between the two USB devices and my Thinkpad's built in Intel PRO/Wireless 5100 AGN:

iwn0 at pci3 dev 0 function 0: vendor 0x8086 product 0x4237 (rev. 0x00)
iwn0: interrupting at ioapic0 pin 17
iwn0: MIMO 1T2R, MoW, address 00:16:ea:c5:bb:10
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

... but unfortunately the OfficeConnect appears to no longer be able to associate with my WPA2 network. Possibly some of its valves have worn out, or maybe a small family of mice have set up residence inside - I would shake it to see if it rattles but I fear I might put my back out...

For reference the PRO/Wireless 5100 reported ttcp rates of 17.2 Mbit/sec send and 16.9 Mbit/sec receive, while the Edimax managed 12.7 Mbit/sec and 12.2 Mbit/sec.

Not earth shattering, but not too bad either.

So what prompted this trip down "USB wifi adaptors the size of vinyl records" memory lane? Someone on a mailing list was running NetBSD on a macbook and it wasn't recognising the wifi. I suggested trying a nano USB wifi dongle, but I wanted to recommend one that worked - so I bought one to see it work.

In the process I found out that while NetBSD-current included the urtwn driver and the firmware, NetBSD-6 BETA2 only had the driver and required a manual download of the firmware, so I submitted a pullup request to get the firmware into the NetBSD-6 release - its always nice to have stuff work Out Of the Box :)

About the only thing bad I could have to say about the Edimax is its use of one of those violently blue LEDs - you know the one's suitable for landing aircraft in heavy fog or signalling direct to the Curiosity rover on Mars. It doesn't have any gaps or transparency in the case - the LED just shines directly through the black plastic (and I suspect the metal USB plug if it was far enough out of the machine).

(some time elapses, as it does)

Now *that* is interesting... in a "random profanity and threatening of inanimate objects" sort of way...

Presumably the OfficeConnect did not appreciate my less than glowing comments about it - that, or possibly because I forgot to use the correct guide rails and block-and-tackle to remove it from the machine - when I unplugged it my laptop hung for a moment and then rebooted.

More deserving of the profanity however, on reboot the laptop hung when probing the CPU. Repeated. Powered off, leaving for a minute and back on and it *still* hung on probing the CPU. Eventually I removed the battery and power cable, held the power button down for 30 seconds, then reassembled and successfully booted.

So it appears the OfficeConnect is capable of deranging the USB hardware on a Thinkpad sufficiently well to require a complete disconnection and draining of all power. Handy... if you like the sensation (albeit briefly) of all blood draining from your face as you consider the prospect of your laptop having just been completely fried.

Things you would prefer not to fall out of your battery

As an added bonus, when I removed the battery I found myself in possession of a small spring and broken black plastic tag, which appear to have fallen out of the battery.

It could be a subtle suggestion that its time to replace the battery, or a somewhat less subtle hint that I really should drop the Thinkpad less..

Anyway, that concludes today's "Fun With WiFi And NetBSD" - and today's top hints are:

• Edimax make a cheap and usable tiny wifi adaptor
• If you have an old wifi adaptor large enough use as furniture, just carefully dispose of it
• While repeatedly dropping a Thinkpad may make it gradually lighter over time, its not a good idea

Final Dreamcastery nonsense at the end of Retrochallenge 2012

Retrochallenge 2012 has come to an end, so this is a catchup post of the mainly Dreamcast related foolery over the past week.

What every Dreamcast needs

Quite some time ago Kiyoshi IKEHARA designed a DCEXT board enabling connection of an IDE disk and an ISA (typically network) card to NetBSD/dreamcast, (I believe Izumi Tsutsui wrote the code). The patches never made it back into the main NetBSD tree and have just been maintained by Izumi.
 
Now someone is trying to add support for it to DreamShell, an alternative gaming OS for the Dreamcast, so I found a copy of the patches for netbsd-5, tweaked them for current, built a test kernel posted it to their forum.

Annoyingly the email notification of subsequent comments didn't seem to work for me, so I missed the very quick response asking for a kernel with additional debug. Just seen it now, so just built & uploaded it now :)

Elsewhere in my world of retro-challenge I still don't have public IPs for wopr (VAX) and orac (Dreamcast) after the office move, so wopr is very lonely on an internal network and orac is at home (where at least I can poke at it).

Unfortunately my "at home" Dreamcast CD-R burning opportunities are somewhat limited:

• My thinkpad DVD drive is more than a little unwell. It writes CDs that not even it can read, and had a tendency to just randomly eject at any point during the day. Hence its been replaced by an sata drive bay
• Michelle has a macbook air, which is beautiful, but optical-drive-less
• My gaming PC has a blueray drive, and none of the CD-Rs it generates work with the DC. I have a whole stack of coasters that prove adjusting speed, burn options, or switching NetBSD/Windows has no effect
• I have a Mac-mini which has a drive, but only OSX installed. (thinks). I *could* port dc-burn-netbsd to OSX, or at least the "burn existing ISO" option...

Anyway...

I had a play with telling NetBSD to add unused video ram to the normal kernel memory. Works perfectly on gxemul, but real hardware was a little pickier, so that it going to take some more work (if its possible).

Nick Hudson posted me a Dreamcast serial cable he was now longer using, which enabled me to find out that getty and remote are *really* fussy about using a read-only /dev, so I'm probably going to have to switch my live CD to use the standard tmpfs /dev trick. That is annoying to the tune of around 300K of wasted memory, but not the end of the world.

My current "goal of randomness" is to get the live CD to show a prompt in an xterm. Thats readonly-root-on-iso9660, with misc tmpfs & union mounts, running multi-user in 16M without swap, with the X server and one xterm running.

I've tested it on root-on-nfs without swap, so I think it should be doable... just. I wonder if I should add an option to dc-burn-netbsd to create a root filesystem suitable for testing over NFS - to avoid a fresh coaster per test (and the feeling that I can hear the Dreamcast CD seek mechanism expiring before my ears).

As if the VAX & Dreamcast retro-madness isn't enough I've just collected a PowerBook Duo 270c from someone who ran out of space. 12M RAM, 240M disk, 68030 & a 9" 640x480 screen. Its so *tiny* and cute that I actively want to do something useful with it, unfortunately its only I/O consists of two serial ports and a dock connector.

Did I mention I also picked up a Duo Dock II with it, which has a vast selection of ports, floppy drive, space for an addition disk, an FPU chip, additional VRAM, and two nubus slots. It addresses the "tiny, cute but no ports" aspect of the Duo 270c in a big way. However...

Do not make Dock angry. Dock crush!

1. It is the size and weight of a small bus. I keep having to check underneath for wheels
2. The network port does not appear to be fitted - so the *one* thing I need most, it doesn't do
3. It requires the laptop to be closed and inserted - so I now need to find a an external ADB mouse, keyboard, and a mac compatible monitor (or adaptor)

Don't worry, its Apple approved

There is a beautiful scene from the film Brazil, where Robert De Nero - playing a renegade special forces equipped air conditioning engineer - pulls out a tiny component and says "thats your problem". When asked if he can fix it he says "no, but I can bypass it with *this*" and proceeds to take from his bag what can only be described as a cross between a cybernetic cthulhu and the spinal column of a robot made from valves.

I look at the tiny Duo 270c and the across at the docking station from hell, and think... "Thank you Robert, that will do just fine".

Nice NetBSD/dreamcast shell script, but can you do it under Windows?

I posted about the dc-burn-netbsd script on one of the Dreamcast forums, and someone asked if they could run the script under Windows.

I suspect pointing him at Microsoft's current *nix-on-Windows solution (Interix? Windows Services for Unix?  Subsystem for UNIX-based Applications? Grudgingly Provided but Subtly Maladapted Compatibility Subsystem for Customers Who Otherwise Would Use Some OS Begining with L?)... might have (quite rightly) have been met with a vigorous but somewhat impolite reply, so I decided to generate an image for him to burn directly.

I also took the opportunity to cleanup dc-burn-netbsd a little more:

• split out 'extract sets' from 'setup extracted data for live usage' (now -l) - after all, why should I assume my live setup is the One True Way?
• tweaked live setup further (do we *really* want to try to rebuilding the X11 fontcache? I think not), and /etc/motd was not reporting the kernel version (tsk, fer-shame)
• making -l default to the right kernel and minimal sets. I have a deep seated antipathy towards typing many options on a command line. (If I'm building a live CD then it should be able to work out that it needs some sets and a non ramdisk kernel - but only as a default of course, if the user wants to explicitly select something apparently stupid... "here is rope")
• Adjusting default behaviour to generate but not burn the image (added -b to burn). Ah, now I have a naming crisis as it no longer "does what it says on the tin" by default. Foo. I'll come back to that later

He also asked another question - to paraphrase it - "why?"

Currently the motivation for all this has been "because its there" - while NetBSD/dreamcast can run a whole bunch of standard unix software (see http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/dreamcast/5.1_2012Q1/All/ for example), not all of it necessarily makes sense on such a platform.

But again... "here is rope" :)



I also put together a README (I'll quote it below - mainly on the grounds I've already spent time writing it, got distracted watching the Olympics opening ceremony, and its a cheap way to pad out the rest of this entry)


netbsd-dreamcast-6_BETA2.iso.README

Sample NetBSD/dreamcast live image (Generated by "dc-burn-netbsd -l -n"):

Requirements
- Dreamcast or gxemul emulator (*)
- If using a real Dreamcast, blank CD-R & Dreamcast keyboard
- Optional: Dreamcast BBA (broadband adaptor) for network access

Usage:
- Download netbsd-dreamcast-6_BETA2.iso.7z and uncompress to get .iso image
- To burn to CD for booting on Dreamcast:
  - On Windows use http://code.google.com/p/bootdreams/downloads
  - On NetBSD no need to download this, use http://pkgsrc.se/sysutils/dc-tools
    and run 'dc-burn-netbsd -l' directly
- To boot in gxemul (*) run
  "gxemul -XEdreamcast -d co23965696:netbsd-dreamcast-6_BETA2.iso"
- Once booted enter "gdrom0" and return three times when prompted
- Login as "root"

This is still a work in progess, in particular future goals for future versions
include:
- Including installed binary packages such as some from
  http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/dreamcast/5.1_2012Q1/All/
- Switching to a shell with command line editing
- Support for Serial-SD and potentially Serial-Ethernet adaptors
- Better X support (currently insufficient memory to effectively run)

(*) Running under gxemul requires gxemul-0.6.0nb3 or later from pkgsrc, or the patch-src_devices_dev__dreamcast__gdrom.cc patch applied to gxemul-0.6.0

Interestingly X doesn't  start under gxemul - I'll need to test on real hardware before I dig further into that, but as my DC is in my office, and I'm currently in a Days Inn in Winchester (not Inglewood - that was a rather different experience), that will have to wait...

Virtual Dreamcast - Virtual (a)Live?

There has been something of a hiatus in my Retrochallenge 2012 postings.

Last Tuesday evening I visited London Hackspace and... made it home in the decidedly early hours of Wednesday morning, rather neatly occupying the time during which I would have tried to do something Retrochallenge related and then have written about it.

Then as ever, "stuff happened", but finally I have made time to get back to it!

"...Last episode on Retrochallenge2012, I was doing something with a Dreamcast, or a VAX - I really can't remember now, possibly even combining the two in a gratuitous and potentially amusing fashion, but I did remember that trying to create a Dreamcast live CD was quite an annoying process, requiring as it did burning a CD-R each time to test.

Enter gxemul, a very nice set of emulators which included one that could boot NetBSD/dreamcast, including a rather elderly NetBSD-3.0 live CD image. Unfortunately... I was unable to get a recent NetBSD CD image to mount - the kernel would load, I could view the start of the CD image partition which looked fine, but it would just refuse to mount the ISO9660 filesystem.

Sprinkling some debugging prints in both the kernel and gxemul (it is *so* much nicer to be able to debug from both sides), revealed the NetBSD kernel trying to access sectors somewhere in the multigigabyte range (a neat trick on a medium with a maxiumum of 900MB capacity).

The issue, it transpires, was gxemul only fakes up enough of a CD ToC (Table of Contents) to allow NetBSD to boot... specifically NetBSD 3.0. NetBSD 4.0 and later have stricter requirements. Actually the code is very similar and I have a horrible feeling that the fake ToC caused the NetBSD 3.0 gdrom code to fall off the start of an array and read some nulls. Nasty.

So I went searching for the CD ToC specifications, and eventually determined that I needed the Yellow and Red Book standards, written by Sony & Philips and apparently still to this day considered commercially privileged and not freely available. However... their contents match the freely available (and catchy named) Standard ECMA-130: Data Interchange on Read-only 120 mm Optical Data Disks (CD-ROM) which has insane level of detail on the ToC (among other things).

So I read the relevant section, rubbed my eyes a few times and read it again, then took out a pad & paper and thought about drawing diagrams... and then read it again. I considered the strange need for some engineers to produce overly complicated and involved solutions, and about technical writers who actively despised their potential readers.

I just have to share Figure 15 at this point. Looks nice and simple? Just split up 96 bits into sections? Only... bits 0..97 makes *98* bits, and the Control bits have two extra bits (for free). Don't even get me started on how each track has 4 bytes in the ToC data returned, but something like 10 bytes in the spec.


Then I experimented with building gxemul with some values that should have made sense... but apparently didn't. In the end I burned a NetBSD/dreamcast disk with a modified kernel which dumped the ToC values, then updated gxemul to fake a more convincing ToC...

Final result is an updated gxemul which will boot NetBSD/dreamcast 3, 4, 5 & 6 kernels, a NetBSD/dreamcast kernel option to dump the gdrom ToC, and a tweak to the gdrom parsing code to reject too-fake ToC values.

Once the above was reached it only took a few quick iterations to get dc-burn-netbsd building fully functional Dreamcast live CDs, including the ability to login to both the graphical and the serial consoles - literally multiple users on a virtual Dreamcast without any network interfaces or persistent storage, virtual or otherwise. And they say retrocomputing emulation has no practical use? Pffff...

wargames meets Linux (and Dreamcast VGA)

When I wrote a small script to simulate the W.O.P.R. computer from wargames, little did I expect it to help me learn some new things about Linux (specifically Fedora in this case).

One criticism often cast towards people writing software on Linux is that they only write it for Linux, not caring about basic portability to other systems. Sometimes there has obviously been a pass to make it run on OS/X also, though earlier versions of XBMC were my go-to case for "portability" code which only cthulhu could love (So, if #ifdef _LINUX and #ifdef APPLE then... no, wait, what?)

Anyway, My Little Pony-I-mean-Wargames script was written on NetBSD, for my own use, but not intentionally using any NetBSD specific features.

Since I had the temerity to host it on github, of course someone is going to come along and try to build it on their $OS_of_choice, in this case Fedora.

So, lets count my portability fails

1. I used "tput up" to move the cursor up, rather than "tput cuu1" (both work on NetBSD). To be fair "cuu1" does sound more like something a standards committee would define, probably short hand for "CursorUnproportionablyUpOneLineOnly"
2. I used "{.TARGET}" and "${.ALLSRC}" in the Makefile. Gmake does not support these, which is interestingly as I thought the gmake project mission statement was to make bash look like a lean, minimally functional application. Still, easy enough to hardcode the values & we're portable
3. I include a getopt(3) using program for outputting text called wopr, which at one point was called as 'wopr "IDENTIFICATION NOT RECOGNIZED BY SYSTEM" "--CONNECTION TERMINATED--" ""'. Traditional getopt() usage has option parsing stop when the first non '-' prefixed argument is reached. Linux is more... helpful... in this respect and happily picks up options from anywhere in the arguments... and quite possibly from the environment and your dotfiles. Wait... (check online), No, apparently I only *thought* I was kidding:

ENVIRONMENT VARIABLES

_<PID>_GNU_nonoption_argv_flags_

This variable was used by bash 2.0 to communicate to GNU libc which arguments are the results of wildcard expansion and so should not be considered as options. This behaviour was removed in bash version 2.01, but the support remains in GNU libc.

 So, now wargames now runs on Linux. Anyone with a Solaris/Illuminos machine want to take a pass? :)

(I'd like to thank the person on github who took the time to try wargames, and then fix it up to run on Fedora, and who should not take anything of the above as ingratitude :)

... meanwhile, on planet Dreamcast

In an earlier posting I may have commented on the quality of the construction of a newly acquired Dreamcast SD+VGA adaptor in a fashion which might have been construed as potentially disparaging. I am now delighted to revise that previous comment and to be able to state positively that indeed, it is a bit sh*t. By repeatedly pressing the plug into the back of the Dreamcast, and - god help me yes - by tilting to engage the assistance of gravity, I now have a clear and fully usable display. As before, walking heavily, sneezing, or careless placing of coffee cups near the machine is strictly prohibited.

I appear to be getting carried away in mentioning previous postings, in this case why gxemul was not able to mount the CD as a root filesystem while booted. I am lightly disappointed to say it does not appear to be some boneheaded mistake in my script as the CD image runs fine on real hardware, so if I want to use gxemul to test root-on-cd9660 Dreamcast image I'm going to have to poke into the gxemul source. Definitely still retrochallenge 2012 material, though only just :)

Tidying up at the end of the week

Spot the server, printer, or cow

Spent some of today tidying up the house, and a little bit tidying up in the Dreamcast and VAX emulation world.

• Updated the Booting NetBSD/vax in SIMH howto to reflect the changes in NetBSD-6, point to the correct page for the simh pkgsrc package and misc cleanup
• Updated the NetBSD/dreamcast howto to point at the two very much easier methods of burning a Dreamcast CD
• Relaxed the timer granularity check on the SIMH pkgsrc package to allow setting the idle check on machines with HZ=100 - now emulated vax machines do not need to max out the host CPU all the time
• Fixed the configure mkstemp() check on the gxemul pkgsrc package, so it can boot full Dreamcast CD images again
• Adjusted the dc-burn-netbsd script to include a full set of devices in the release-in-root-on-cd case, and attempted to test this in gxemul (hence the previous item)

Interestingly I discovered that once the CD image was booted in gxemul attempting to mount the CD failed with the (verbose) gxemul console messages:

[ GDROM cmd: 30 20 39 fd 9c 00 00 00 00 00 01 00 (cnt=2048) ]
[ diskimage__internal_access(): disk_id 0, offset 2791911424, transfer not completed. len=2048, len_done=0 ]
GDROM: diskimage_access failed? TODO 

Given the entire ISO image was 97,910,784 bytes in size, I suspect tying to access data at offset 2,791,911,424 is unlikely to yield a happy result in any universe with congruent natural laws to our own, but just to make sure I'll try to test on a real Dreamcast tomorrow.

Looks like I'll either be hacking my dc-burn-netbsd script to determine what boneheaded bug I've added, or gxemul's dev_dreamcast_gdrom.cc. Good good!

Potential VAX gcc news (and damp dogs)

Today was not particularly productive in Retrochallenge terms - I visiting my parents and spent a large part of it digging fresh palisade roll into their garden, ably "assisted" by two dogs, one of whom tried to stand exactly wherever I needed to be, and the other just dug up random sections of flowerbed.


Fortunately it was raining continually, which should have driven the dogs indoors, rather less fortunately they were so caught up in helping me that they remained outside the entire time, finally following me back in trailing that distinctive fragrance of "damp dog"... and mud. Don't forget the mud.

I did manage to exchange email with someone who is both an expert on VAX assembler and gcc, who now has an simh NetBSD environment setup, and is investigating the possibility of fixing the latest gcc to be able to compile VAX executables which bear at least a passing resemblance to their source code.

This is definitely a Good Thing (in VAX terms), and would benefit anyone looking to compile VAX executables for any system using a recent gcc (Granted, this may be a rather exclusive club).

Oh, and I did fix a recently added reference in the NetBSD atf tree which unconditionally pointed to the gcc-4.5 stdc++, breaking the gcc-4.1 build (and I'm going to go out on a limb and guess the set of people who care about that make the group in the previous paragraph seem like a thundering herd).