So, I took a break from working on stuff around the house this afternoon, to go see what Sherry's computer panic was - her aforementioned SBC/Yahoo DSL service (on Mac) had stopped functioning.
First observation: she's still using IE (gotta install Firefox, sometime when she has a working net connection). On the Mac, as on Windows, IE gives a completely bogus error page, which hides the actual error condition, and tells you exactly the same thing ("It didn't work!") regardless of whether the problem was (1) DNS lookup failed, (2) the connection timed out, (3) there was some other network error, or (4) the server returned any of several possible HTTP error codes.
Second observation: there's a big cutesy "SBC/Yahoo DSL" icon on the desktop. Presumably, this is meant to do something useful. In fact, double-clicking it gets a "busy" cursor for maybe a second, and then it's back to status quo ante clickum.
Grrr... awright, there's supposed to be BSD hiding behind the pretty, dumbed-down facade. Is there a shell somewhere? Start rummaging... aha! There's a terminal thingie. This gets me a shell, and ifconfig, netstat, ping, traceroute, and all that good stuff.
The Ethernet port is up, and set to 192.168.1.64 or something... eh? A private address? Well, that makes good sense for a typical end-user, really, but I don't know if that's how it's supposed to be set up. The default router is 192.168.0.1, which is pingable. A traceroute to anywhere gets as far as 192.168.0.1, then goes nowhere. Dead router/NAT at the ISP?
Curiously, a Mac-specific "network something-or-other" program offers a choice of interfaces: en0 or fw. It doesn't seem to be offering any more information than the basic command-line utlities, nor anything usefully Mac-specific, as far as I can tell.
So, any information needed for diagnosing the problem is either (a) at the ISP, if it's a router problem, or (b) locked up behind the happy shiny useless facade. Naturally, there's no documentation on how it's supposed to be configured; you're just supposed to run the installation program and not worry your pretty little head about what's going on - which is all well and good until anything non-routine happens, and there's no bloody information on what the problem is, nor even a meaningful announcement that there is a problem.
Anyway, I left Sherry to call SBC and try to sort out the problem, and returned home to my problem: the standard AVR assembler doesn't allow data directives (like .dw) inside a macro. Huh??? That's not documented anywhere, and I just wrote 61 lines of macro invocations to fill in a ROM lookup table with semicalculated values. Why would data directives be disallowed in macros, anyway?
Well, as it turns out, AVR assembler version 2 (the new, experimental, reputedly buggy one) does allow this construct, so a (free) software upgrade solved my problem.
Still, the AVR assembler continues the recent (last decade?) tradition of assemblers written by young whippersnappers who've never done any real assembly work, and have never been exposed to a good macroassembler. Version 2 fixes a few problems, but instead of upgrading the normal macro system, it grafts on a C-style preprocessor - which is fine for C, but not terribly useful for assembly.
Enough ranting for the day. Maybe I should get around to cleaning up the assembler/linker toolset I wrote back in '87, and release it as open source... that was a nice assembler, for assembly programmers, not just a backend for a compiler.
Comments