⬡

What is Net Neutrality?

2010-12-23T22:48:00.001-07:00

Wow, it's been a while since I wrote anything here. I hadn't forgotten, just really not had much to say... better a few quality posts than a lot of boring ones. That said, I'll try to post more than once every three months at least...

There's been a lot of buzz about how we should be fighting to save Net Neutrality and the free, open Internet, but little explanation of what that actually means. Here's my attempt at a hopefully simple explanation:

As it is now, you pay an ISP for a connection to the Internet. What you do with that connection is entirely up to you. Whether you watch streaming video all day or just read your emails once or twice a week; whether you look at porn or use it strictly for business matters; whether you play games or just read the news, an Internet connection is an Internet connection, and you're free to do all of those things with it.

To summarize, Net Neutrality is a set of laws that ensure:

Any Internet connection lets you access anything on the Internet.

All traffic is treated equally, regardless of source and destination.

Anyone with a computer and an Internet connection can host their own website or web service and publish whatever they like.

Your connection is not censored - you're free to look at whatever you like and say whatever you like. You can look at porn and talk about how you hate the government to your heart's content.

ISPs want to get rid of these pesky laws to make some easy cash. Without these laws, they can - and will - charge you for access to specific services, and also charge those services for traffic priority.

What this means for consumers is basically just the Internet becoming cable TV. Pay more than you are now for less than you have now, buying "packages" each with one site you use and 50 you don't.

What it means for publishers and businesses is significantly more devastating. Right now, anyone can start up a website and anyone can see it - a level playing field. Under this new system, you'd have to pay each ISP for them to add your site to some of their packages so people can access it. Basically small businesses would have to pay a ton of money to have any chance to compete - and you with your little personal website? Forget it! If you wanted to host a blog, you'd have no choice but to use an existing blogging service - where you can't ensure that your publications, unaltered, are reaching anyone at all. So much for that freedom of the press thing.

(Yes, I am aware of the irony in that this is posted on Blogspot. At least right now if I suspected they were censoring me, I could switch to hosting it myself. That would no longer be possible under the new system.)

Then on top of paying for people to be able to access it, they'd be able to implement traffic priority. Pay $xx/month and traffic to and from your site is given higher priority, making it load faster and drop less frequently. Of course, bandwidth is a limited resource, so this basically means everything else loads slower and drops more frequently. That's another fee your business would have to pay to remain competitive. What's great about this is when multiple competing businesses each pay for priority, they essentially neutralize the effects, bringing them back to a level playing field (among eachother, at least) - paying extra for what we already have now.

On top of all that, they'd be allowed to censor the web. If Big ISP Co. doesn't like what you're saying on your blog, or the fact that your service competes with one of theirs, they can just block all access to it. This would effectively fragment the network - certain websites would only be available from certain ISPs.
(Some countries are already doing this; generally dictatorships censoring those who speak against the government and things they don't want people to know, but also increasingly trying to block all access to pornography.)

Oh, and how exactly can they charge or block on a per-service basis? Well, they'd have to look at your traffic to see what you're accessing. That means they have to be able to read it - which means it can't be encrypted. So look forward to paying extra for any kind of secure communications. Privacy? What's that?

So, now that we know why we should fight for Net Neutrality, the next question is how? There are a few things you can do:

1) Complain loudly to anyone opposing it. Write to congress, switch ISPs, spread the word.

2) Move to decentralized systems such as Freenet which can't easily be censored, taken down or blocked. In these systems, content is hosted in thousands of caches around the world and it's impossible to tell whether you're accessing a file yourself or it's just passing by - nor what's in it if you aren't the one accessing it - so censorship becomes quite difficult.
Tor is another popular system; it provides anonymous access to the web, whereas Freenet is essentially a separate web entirely. Both use heavily encrypted traffic.

3) In the meantime, encrypt as much of your traffic as you can, while you still have that option. There's no telling if some ISPs aren't already (illegally) throttling access to competitors' services and censoring pages - encrypting your traffic prevents that, for the time being.

Rena SVG Trace

2010-09-01T15:35:00.002-06:00

Right so life has been pretty boring lately and thus I've had nothing to write about BUT here's something I'm sure people will enjoy on the off chance anyone actually reads this nonsense. More nice SVG traces, this time of Rena Kunisaki, the same girl you see in the corner of all these pages. This one's based on a monochrome scan, so I got to take some liberty in colouring it as well, and I'm pretty pleased with how it came out.

Be warned that this post contains roughly a megabyte of inline images. They're not safe for work either but that's what that content warning clickthrough thing is for.

These images are pretty huge, so I've used half-size versions inline.

Original scan: (large version)

The Japanese edition probably would have had colour, but English speakers tend to get screwed in that department. Oh well, I'll just have to add some.

Obviously the background isn't going to be a perfect recreation but really who cares about that anyway. I sampled in colours from other images for accuracy, added some gradients and smooth shading, and tried to make the hair fairly realistic.

Of course then I had to go and expand upon it a little.

I had to adjust the posture slightly; it's really only noticeable if you compare them side by side. The legs are traced from some random porno; they could probably use some work still, but oh well. (Just getting them decent was difficult as it is... >.>)

Here is the full, 1.2MB SVG version in all its smooth, crisp glory. Both versions are contained in the file - open it in Inkscape and play with the layers; the second image is "alt1". In addition there are some other goodies inside; some of them kinda suck and I'm not sure I'm happy with the body shape but whatever, there you go, play around with it, feel free to improve on it if you have any actual art skill unlike myself.

Lunamon SVG Trace

2010-08-21T23:25:00.005-06:00

Here's another SVG trace of another Digimon character: Lunamon.
[SVG Image]

This isn't perfect (though most of the more noticeable flaws are traced from the original) and I had to cover this pixel-thin seam that just wouldn't go away (Inkscape bug?) with a line, but I'm still quite satisfied with it.

Original:

Also, I tweaked the page design slightly to work better with smaller screens. I honestly think it looked nicer before, but functionality comes first.

Lua Blob v86336 Release

2010-08-20T13:08:00.002-06:00

Nothing major here, just a quick update to the Blob library to allow proper storage and retrieval of signed integers.

Car Hax

2010-08-13T18:21:00.003-06:00

Yo dawg, I heard you like hacking, so we put a bug in your Bug so you can crash while you crash. Yeah, apparently new cars are being equipped with sensors on their tires. Wireless sensors. One guess how secure these sensors are.

[Attackers] could alter and forge the readings to cause warning lights on the dashboard to turn on, or even crash the ECU completely.

Wirelessly crashing the engine control computers of passing cars? It's like a sci-fi nightmare come true. Can we please start requiring some sort of "I know what the hell I'm doing" license to be allowed to program things that can kill people? I don't even want to think about the possibility of a buffer overflow exploit.

Google vs The Internet

2010-08-12T19:41:00.006-06:00

So, this is not exactly the most punctual article I've ever written, but better late than never. It seems Google has done a quick 180 and gone from protecting net neutrality to directly attacking it. Specifically, teaming up with Verizon to come up with a Trojan horse legislation that will pave the way for the end of the free unregulated Internet as we know it.

The best way to explain what net neutrality is is to explain what we'd have without it. Right now, the Internet is the ultimate level playing field for competition. Anyone can start up a website and do business, and the competition is (mostly) fair no matter who else is involved. Those who attack net neutrality want to change that.

Their immediate goal is being able to buy priority. As it is, information travels the web in a first-come, first-serve system. Routers deliver every packet as fast as they can. What these companies want to do is be able to pay to have their packets given more bandwidth, jump to the front of the queue, and so forth so their sites will load faster than their competition's.

You can probably see a number of problems with this already. Say you start up a business that stands a chance of competing with Youtube. Right now, all you have to do is convince people to use your site instead of the other video sharing sites, and you're winning. In a priority-based system, Google can afford to boost the priority of their packets, which means Youtube gets faster and faster while your site feels like dialup - bandwidth is a limited resource, after all, so one site having priority means others being slowed down.

The "Trojan horse" aspect comes from an interesting twist: they want to apply this to wireless Internet, while keeping wired neutral, likely in an effort to get people to think it's not so bad, won't affect them, etc. Of course, wireless is the future, and mobile Internet already sucks enough without this sort of nonsense. There's no reason they should be treated differently.

Eliminating net neutrality will serve to keep the rich rich while allowing them to crush any smaller competitors by effectively throttling them down to lower and lower speeds.

It gets worse, of course. Allowing packets to be treated differently depending on their origin does more than allow big companies to stifle their competition. Think of what ISPs will do with this. Basically, it'll turn the Internet into cable TV.

Right now, you pay your ISP to route packets to and from your computer, regardless of what those packets contain. Ending net neutrality means they'll be allowed to treat packets differently depending on the information inside.

Now, think about this. The information inside any packet includes whom it came from and where it's going. In the case of web page requests, it includes what page is being requested. "Treating the packet differently" can mean anything - including throttling it or discarding it entirely. That means ISPs will be free to, say, block any requests to a certain site.

Censorship is already a bad thing, but it's still not cable TV. Think greedier. Think about the sales pitches. Instead of blacklisting, we'd have whitelisting. Want to use Google's various services? That's 10 bucks a month. Access to video sites such as Youtube, Hulu and Vimeo is another 20. For 5 you can write your own blog. Just want to read the news every morning? Well, you might get the media package - that's 37 news sites you've never heard of, a couple game sites, some movie review sites, and a tech help site, all for only $35/month. The deluxe package at $45 also adds a couple Internet radio stations.

Sound ridiculous? It's all possible right now - the only thing stopping it is that net neutrality makes it illegal. For that matter, some countries - China and Australia are notable examples - already have similar systems in place, for the purpose of censorship. China's is a full-on Orwell-style system that censors information about the government, rebellion, etc. Australia's blocks "porn" (using a very loose definition) and "illegal files". The only difference between censoring the Internet and charging for access on a per-site basis is in how the software decides what to block.

So, what can you do about this?

The first step, obviously, is to raise hell. Write to congress and the companies involved and tell them where they can stick this idea. Post and spread the word. People need to know - if nobody knows about it, nobody will challenge it, and if nobody challenges it, nothing's going to stop it.

Then, join Freenet - a completely decentralized, encrypted, anonymous network. Essentially, it's a giant distributed file storage - every user contributes some storage space, and relays requests and data around to their destinations.

Freenet differs from traditional peer-to-peer services and the world-wide web in several ways:

Everything is encrypted. A file's identifier includes its encryption key. It's encrypted when it goes in and decrypted when it comes out. Those storing the file and those passing it along can't see what's inside. Freenet has a strong focus on anonymity and encryption.

When a file is inserted, it's spread to a number of users, who then host parts of it. It's therefore not necessary for the original inserter to remain online after inserting it.

There are no direct connections. You ask someone if they have the information you want. If they don't, they ask someone else for it. They might also keep a copy as they pass it on. So there's no way to tell if someone is downloading a file or just passing it along.

Its distributed nature makes censorship essentially impossible. The only way to remove a file is for everyone to stop downloading it until it gets dropped from users' storage to make room for more popular files. The more people download something, the more available it is.

It's browser-based and can support static websites ("freesites") and email. Support for IRC is under development as well.

What makes Freenet especially relevant to this post is that the encryption, decentralization, and chaining make it impossible for an observer - such as an ISP - to tell just what you're accessing, which means they can't treat the packets differently depending on their content. Neutrality is the only option.

Aside from that, as I always say, encrypt everything. Use HTTPS and SSL whenever possible, encrypt your hard drives, and use strong passwords. These things take minimal effort and will not only help to preserve neutrality (they can't filter packets they can't read), but also to keep you safe.

(Yes, I'm aware of the irony of posting this on Blogger.)

On an unrelated note, it looks like a recent NoScript update broke my status widget after all the screwing around I did to get it working. Go figure.

CD64 Mods, Part 2

2010-08-11T00:16:00.007-06:00

Was hoping to post this earlier, but anyway... I traced the CD64's expansion connector. It's definitely one of the simplest I've ever seen for the number of pins. A diagram is available here but unfortunately many programs can't render SVG flowed text correctly. This version has the text converted to paths, so it will show up properly in most programs, but it's also much larger (1.1MB) and not easy to edit.

This connector is interesting, as it connects directly to the bus, meaning all ROM access shows up here. There is no "enable" pin (nor high address pins) that can be used to tell whether the access is actually intended for the connected device (CD64 is in an appropriate mode and address is in the correct range). Pulling the data lines low will cause that bit to read 0, no matter what the address, so it will corrupt reads/writes to other sources, and blindly listening to these pins would also cause your device to respond to accesses intended for other things.

The only safe way to use this connector would be for your device to listen for a series of writes as an "enable" signal, and hope no game happens to trigger it by accident. Alternatively, patching into the high address lines on the cartridge bus would allow you to tell if the address is actually in the range reserved for this connector, but it wouldn't tell you the CD64 mode (unless you listened for those writes too), and different modes actually assign different ranges.

A remote possibility is that there's a way from software to control the +5VDC pins on this port, so the device isn't powered on until the system is ready. However I see no evidence to support this theory.

Pin 38 is interesting; it may have been intended to allow the device to access the third flash ROM when there is no other bus activity. Currently this chip stores Gameshark ("X-Terminator") codes, but it may have been intended for boot code or resources for the MPEG decoder that would have connected here.

The address pins keep their state after each access, while the data pins are at +3V whenever no access is occurring. I can't tell for sure with just a multimeter, but it looks like high=0 on the data lines, whereas high=1 on the address lines.

Since the bus is 16-bit, there is no A0 pin. Byte access returns only the high 8 bits; word access probably gets split into two halfword reads/writes.

The expansion connector is mapped to 0xB1xxxxxx (and sometimes 0xB0xxxxxx; see mode chart below). Beware that games' exception handlers will usually trigger and consider the game to have crashed if you perform any unaligned access.

I also dug up some other interesting information:

The disc read code is fussy about ROM size. If the ROM is not a multiple of some unknown size, it won't appear in the list. 13,107,200 bytes (12.5MB) works, 13,107,201 does not. Keep this in mind if you want to add on to the end of a ROM.

The CD64 enable register (0xB780000C) has an unknown quirk. Normally you write 0x0A to this address (as a word; the high 3 bytes are ignored) to enable the CD64 registers. Early versions of my test program did this immediately before setting the mode (0xB7800000) and the result was inconsistent behaviour, as if sometimes the mode wasn't changed. Setting it only once at the beginning of the program solved this problem. This could mean you must wait some time after enabling before using the registers, or that writing a second time disables it - obviously there needs to be some way to disable the registers before starting a game.

The third flash ROM, which currently stores Gameshark codes, is mapped to 0xB7000000. To read it, read a word and discard the high byte of each halfword, e.g.:

LUI $A0, 0xB700
LW $A1, xxxx($A0)
SLL $T0, $A1, 8
ANDI $T0, $T0, 0xFF00 ;first byte
ANDI $T1, $A1, 0xFF ;second byte
OR $A0, $T0, $T1

or:

tmp = word[x]
byte1 = (tmp >> 16) & 0xFF
byte2 = tmp & 0xFF
data = (byte1 << 8) | byte2

The chip is an SST-29EE010 (128KB capacity). Writing would most likely follow the same method, placing a 16-bit payload in those two bytes. Accessing individual bytes (as halfwords) should also work the same.

The CD64 website documents some of the modes, but not all. The entire map appears to be:

Mode	B0	B1	B2	B4	B6	B7
0	CD64 BIOS	Expansion port	Cartridge	DRAM (R/W)	CD64 BIOS	X-Terminator & I/O
1	CD64 BIOS	Expansion port	Cartridge	DRAM (R/W)	CD64 BIOS	X-Terminator & I/O
2	Expansion port		Cartridge	DRAM (R/W)	BIOS/Expansion port
3	Expansion port		Cartridge	DRAM (R/W)	BIOS/Expansion port
4	DRAM (read-only)			Expansion port	Cartridge	BIOS/Expansion port
5	DRAM (read-only)
6	DRAM (read-only)
7	Cartridge

It's possible to switch out of any mode, but no modes allow writing beyond the first 32MB of DRAM, hence the ROM size limit. If I could find a 64MB module, it might be possible to defeat this limit by simply manually operating the write line and/or highest address line of the DRAM (which could then be connected to a pin on the expansion port and done automatically in software). Of course reprogramming the CPLD would be a better way, but having no method to do so (nor to even back it up) and no experience with CPLDs, I can't try this yet.

In mode 4 the 32MB DRAM is mirrored at B2 and B3, but this is probably because it's only 32MB; I suspect with a larger module all 64MB would be readable here.

In mode 5 (and 6) again the 32MB is mirrored across the entire range, but this would probably change if you installed a larger module. In theory up to 128MB is usable if you can write to it somehow.

Reading past the end of cartridge ROM or BIOS reads open bus; the result will be the low word of the address repeated for the entire word. Addresses above 0xB7xxxxxx are also open bus.

"BIOS/Expansion port" means the high 16 bits of each word will come from the expansion port and the low 16 will come from the BIOS. This isn't terribly useful since you can only read every other halfword of the BIOS (unaligned access throws an exception). 0xB7xxxxxx reads the X-Terminator chip instead of the BIOS (since BIOS is mapped to 0xB6xxxxxx and XT is mapped to 0xB7xxxxxx); in other words, in this range one halfword comes from the same place as it would in mode 0 and the other comes from the expansion port.

The parallel port adaptor (whose circuit diagram is on the CD64 website) contains some buffers and latches to make the port easier to use.

When you write a word to 0xB78xxx84 the low byte of that word is output to the data lines. They do not retain their state; when not being written, they read 0V (logical zero). For input, read a word from 0xB78xxx80; the state of the data lines is found in the low byte (+3VDC=1, 0V or disconnected=0). Thus, the adaptor adds latches to keep the last state written so the other end can read it without having to be in perfect lock-step (or having to run big slow loops).

There are still some things I want to try with this hardware. First I want to build this adaptor and dump the three flash ROMs. Then I'd like to play with the audio input port, look up documents and see if it has to be enabled in software or just given an input.

I'll also want to research how one goes about communicating with various IDE devices and see if I can interface with hard drives and CF cards, which will be the first step toward writing better software.

Finally I'd love to find a 64MB or even 128MB DRAM module I can install and see if I can get it to do anything interesting. I don't doubt I can work out some sort of hack for this.

CD64 Mods, Part 1

2010-08-05T23:20:00.002-06:00

A while ago I picked up an interesting gadget: a CD64 backup unit for the Nintendo 64. It's exactly what it sounds like: loads ROMs from CDs. It's also supposed to be good for development, but without the adaptor to connect to a PC, it's not really much good for that.

Anyway, it needed some repair, and when I opened it up I was intrigued by an unused expansion connector inside. Apparently they had planned to add an MPEG decoder here for VCD playback. Well obviously I'm going to have to make something cool out of that.

The first thing I had to do was try my custom Mario Kart track on a real N64. It... almost worked.

The track's a little invisible, but it runs!

Playing with it some more, I decoded the game's exception handler, which doesn't work on emulators.

As for the hardware, here's a blurry photo of the mainboard. The unused connector is visible at the right; nothing is actually soldered to it.

It has three flash chips - two hold the BIOS, the third I'm not sure about.

Having convinced the unit to function, I set about documenting the unused expansion connector. Some simple probing with a multimeter was enough to find a few of the pins - some just go straight to the also-unused video connector on the back - but address and data require a bit more in-depth searching.

The best way to do this of course is to write a program that will probe arbitrary cartridge addresses and use an oscilloscope to find those probes. However in my case I'm doing things slightly different. First of all, I don't have an oscilloscope, but a multimeter should do just as well if I have the probes loop for a second or two. (I can see it jump up and down on the read line as games load resources and play music from ROM.) Second, writing an entire program for this purpose means I'd need to learn how to work the hardware, which is something I've never done before - all my hacks have been injected into games, letting Nintendo handle the low-level stuff. So the obvious solution to that is...

...inject the whole damn program into a game. The game has a nice little feature that displays time trial records on the title screen. Taking over that routine and using a leftover debug print function, I hacked up a little "debug menu" of sorts for testing. The title screen works well for this because after the music finishes (which only takes a minute) the game isn't doing any other ROM access.

What's the point of this? Well, the CD64 has a lot of potential as a dev unit but it's unfortunately plagued by bad software. There's a lot of potential for enhancement even without any significant modding - say, DVD/hard drive support? A more advanced trainer? Loading Gameshark code lists from disc instead of the utterly retarded manual input method? Long filename support? Actually reading all the files on a disc?

An unused memory-mapped expansion port is just a bonus. All sorts of crazy things a guy could do with that, especially if a microcontroller were thrown into the mix. I haven't even decided what all to do with it. Networking maybe?

A strange glitch I found is that this CD64 completely fails to read discs using its own power supply. Only by connecting the disc drive to an external power source will it spin up for more than a couple seconds and actually read anything. I haven't found why this is; everything looks alright, capacitors tested fine. Fortunately this won't be a big deal anyway, because it fits with my plans nicely.

I'm going to have to find an old horizontal PC case with a plain flat front on it. (Vertical would waste a lot of space.) Get an N64 mainboard, mount it with the CD64 attached inside. Hook up a disc drive like normal and run the cartridge connector out to where the floppy drive used to be. Stick the controller ports in one of the other drive bays. Wire up some toggle switches, LEDs, maybe an LCD to the unused expansion connector for arbitrary use by my code. See if I can't get it to work with a hard drive. Possibly even try out an idea or two for defeating the 32MB limit, if I can ever find a 64MB module. It'll be pretty damn epic.

Another interesting note is that next to the video connector are four audio pins. A quick test showed these connect directly to the audio input lines on the cartridge connector. Most of Nintendo's cartridge-based consoles have had this, but it's rarely used. (The NES - but not the Famicom - is one exception. It has an input on its expansion port, but not its cartridge port.) I haven't found any documentation of how to use this input; generally it would have to be enabled in software, though perhaps this is not the case for the N64. In theory it should be dead simple to connect any audio input to these pins and add your own music to games. Probably the intention was to connect the CD drive's audio outputs here for sound during VCD movies.

Oh, and check out the mess.

You can see an early version of the test program. The display is a hollowed-out old DVD player - more on that later; there's another whole story to go with it.

Lua Blob v85840 Release

2010-08-01T07:16:00.002-06:00

Although I've never officially announced it, it's no big secret that Rena is written almost entirely in Lua*. This beautiful language is what allows for such flexibility and extensibility.

*Actually, I've made some significant changes to the Lua source, making it no longer binary-compatible with existing code. Thus it can't technically be called Lua anymore. I'm calling the modified version Aura. It's basically just Lua with some useful new stuff.

One great thing about Lua is that it's a very lightweight language. This of course means it may not have everything you need for a big project. It's really designed to be used as a scripting engine in games or "anything that needs one", as stated on its website. However, it's simple to write libraries to add functionality that integrates seamlessly into the language. LuaGnome is one such library, providing the GUI.

One thing Lua isn't great at is working with large arrays of bytes. Raw image data, emulated memory, anything where you have a huge block of memory you need to access directly. Your options are to use a table, or manipulate characters in a string. Tables are not ideal for this job since they function more as hash maps than arrays, and the native numeric type is double (64-bit floating point) - a lot of overhead for one byte. Strings aren't ideal because they're intended for (duh) strings of text - they don't provide direct access to bytes, only functions to extract and piece together substrings. Either method is slow, wasteful and potentially awkward for large memory blocks.

To solve this problem I wrote the Blob library. It simply gives you a memory block which you can access like a table. It can be accessed as 8, 16, 32 or 64-bit integers, floats, and doubles, converted to string, and dumped to or created from a file. Using this in place of an ordinary table for Rena's texture graphics gave a significant speed boost. It also provides a pointer that can be passed to libraries such as LuaGL.

This library is released under the New BSD License, so it's free to use as you please.

Renamon SVG Trace

2010-07-30T01:41:00.009-06:00

If there's one thing I can't do, it's art. Occasionally I can make some cool abstract design by accident, but if I set out actually trying to draw something, the perspective is just going to be all wrong and I'll ultimately end up with something that's logically correct, but just looks wrong for some reason.

However, I can trace art. Some would call this cheating, but I don't just trace over something and call it my own. What I like to do is take some existing art and trace it in Inkscape to make an SVG version. This is because SVG has a number of advantages over bitmap graphics.

SVG is Scalable Vector Graphics. Vector means there are no pixels. The images are made of objects and layers composed of (often curved) lines and points. Essentially, it's instructions and math that tell the computer how to draw the individual components of an image and put them together.

The result is that SVG images can be scaled to just about any size, and they'll remain crisp and smooth - rather than having to try to stretch and compress pixels, it simply re-renders the image, throwing some multiplication into the process.

Being object-based gives SVG some neat capabilities. Objects can be moved around or turned off to reveal things behind them, scaled, varied in opacity and colour, and transformed in various other ways easily. This makes it easy to modify images as you like (especially if they're designed with this in mind). You can take a character and add alternate outfits, facial expressions, poses, etc all in one file.

Further, SVGs can be styled with CSS and scripted with Javascript. So by changing one rule you can change a person's skin, hair or eye colours, the background, etc. Scripts allow for advanced animation and even games. A lot of Flash content can be reproduced in pure SVG. (Add in HTML5 and you basically replace Flash entirely!)

The only downside is lack of support. Inkscape doesn't support CSS, and browsers render much too slow (especially if any blurring is used, which is important for shading) to really make games feasible. These problems are slowly being resolved. Even so, SVG is pretty sweet.

Anyway. Enough chitchat. Here's my trace of Renamon - original vs SVG.
[SVG Image]
Sweet, no? And it scales. Zoom that shit in. I'd stick a zoomed-in version here but it seems like there's no way to do that without modifying the image. (Yo, HTML5 guys, what gives?) In Firefox (probably every browser) you can just view the image directly and zoom like you would any other page. It scales up beautifully until you can actually see the eyes. How awesome is that.

Also, here's a nice gradient-shaded version.
[SVG Image]

I've got more of these. Stay tuned.

Same Shit, Different DRM

2010-07-28T17:23:00.005-06:00

So today's latest DRM scheme is storing your media in "the cloud". That article is mainly bashing, so let's first look at some of the theoretical advantages of such a system.

No need to make backups.
Access it from anywhere.
Rental and samples become feasible.
Files aren't taking up your disk space.

Now to destroy those arguments:

Backups. Sure, major corporations make backups, right? It's not like any of them have lost customers' data before? Besides, this is pretty well offset by the fact that you need to be online the entire time you're using it. Which brings us to point two...

Access it from anywhere. Well, sure. Except when you're commuting. Or in a remote area. Or anywhere without a fast enough connection. Sure, in theory we should be able to get good enough bandwidth over a cellular network just about anywhere. In practice, it'll cost you an arm and a leg in the few places it's available with a strong enough signal to do the job.

Rental. Yes, with this type of system we can rent music, movies and games using a purely online distribution system. Just like with all the other DRM schemes. It isn't new and it doesn't solve the existing issues.

Disk space? Space is cheap. Like terabytes under $100 cheap if you look around. The only case this is any advantage is in mobile devices with flash memory (which even then is growing rapidly), and I already covered the problem with mobiles.

Ultimately, at some point we are going to want to use these files, and when we do, the data - encrypted or not - is going to have to be sent to us. Copying that transmission will be trivial (hello airodump). At that point, it's fundamentally no different from any ordinary DRM scheme. The only difference is now it's even less convenient, and it'll take slightly more effort to keep even an encrypted copy.

Sure, now they can revoke access to the copy on a whim. Previous systems could do exactly the same by revoking your keys. Thus why many existing systems require you to "check in" online when starting the program, and require you to keep the software up to date to be allowed to use it. Quite literally the only difference is where the files are stored. It doesn't give us any new advantages nor any new restrictions. Except of course that now we can only use it on a machine with a fast, reliable Internet connection, for as long as the servers remain online. Oh, and expect lower bitrates - streaming takes a lot of bandwidth, after all.

Job Applications Suck

2010-07-27T07:20:00.001-06:00

We've all been there: need work, go around asking if any place is hiring, and they give you this form to fill out. It's (unfortunately) become pretty standard practice among most businesses today. And my God does it suck.

The idea of a standardized form isn't too bad. Fill out some information on one sheet, make a ton of copies, hand it out. Quick and simple. Oh, wait, we already have that. It's called a resumé.

But no, for so many places now, a resumé isn't good enough. You've got to fill out this form with all the exact same information as is on your resumé, and then hand that in - with a resumé. Maybe this makes sense if you're applying at the Department of Redundancy Department.

Let's look at some of the ridiculous things they ask on these forms.

Right from the beginning, we have fairly standard information - name, address, phone number. I'm not sure why you need to know my address to consider hiring me, but OK, whatever. Then most of them ask things like "Are you legally entitled to work in $country". That sounds a little silly, but I guess they'd be in trouble if they didn't ask and hired an illegal immigrant. OK, nothing bad so far.

A lot of them also want my email address. Hold on. All the spam I get already, and you want me to just hand my email over to your corporation? For what? I've had exactly one job email me, ever - and they provided an account for the purpose. The video store, hardware store, grocery store, etc are never going to email me - except maybe some advertisements.

What's next. My social insurance number? Seriously? This is supposed to be highly confidential personal information, and you're asking me to just hand it over on a sheet of paper to whomever happens to be at the counter that day? Maybe I can assume this is an idiot test and not fill it in, but it's still a pretty ridiculous thing to ask, and seems like the kind of thing people get in trouble for. Oh hey, throw in some credit card numbers while you're at it, will ya?

Expected Salary. Oh, this is one of my favourites. How much do you expect us to pay you? Let's see, I can guess too high and be rejected or I can guess too low and screw myself. Brilliant fucking question there. Any time I see this question I have to seriously question the hiring process - can you say "lowest bidder"?

"Do you have reliable transportation?" My legs are pretty damn reliable. Does a bicycle count? Public transit? Kinda ambiguous question there.

"If you have applied to $business before, state when, where, and for what position." Yeah, I keep copies of every single application form I ever hand out. Totally.

"Positions applied for" and "what type of work are you interested in?" Let's see, "anything that pays?" Seriously, what am I supposed to put here? Do I just choose a job and hope they're hiring for that position? (Not every place - in my experience, few places - offers lists.) I doubt there are many jobs in your average store I can't do.

Education. They need to know all your school history. Sometimes as far back as sixth grade.
You might think this is a good thing to put on an application form. Haha no. This field right here is one of the big things that's wrong with society. The belief that there is a direct correlation between education history and intelligence or skill.

To put it simply, before I started school, when I was a young child, I was reading and writing at a college level. If I'd had a computer of any sort then, no doubt I'd have been doing insane things with them too. I've been hacking since first grade. I've been a better coder than most college graduates or even professionals I've seen since high school. Ask any of my former teachers, they'll tell you how brilliant I was. Ask my report cards, they'll tell another story. Simply put, Ontario's school system is a complete and utter failure. So is there really a relation between grades and skill or intelligence?

(Yes, smart guy, I've been starting sentences with prepositions and doing all these other grammar no-nos. I know better, I just don't care. This is a blag, not an essay.)

Just to make it more fun, a lot of them also have a field for "diploma received" and/or "year graduated". Since I'm still in college, I have nothing to put here. There's no way to differentiate "I'm on summer break from a multi-year program" from "I dropped out/failed/etc."

Then we get into the employment history. This part is annoying because it's probably 70% of the writing you need to do, filling out all the exact same information over and over again. What was that I said about a standard form? A resumé?

They'll ask some fairly standard questions, and then they get nosey again. Starting and ending salary? What business is this of yours? So many of them also ask "describe your duties" and then give you a liiiiiiitle tiny box to write it in. Get the microscope.

There's always the "may we contact this employer?" Except sometimes, it's "May we contact your past employers?" and a little checkbox. OK, so suppose the answer is "yes" for some and "no" for others? What then? Design fail.

"Reason for leaving". I guess "it sucked" isn't a valid response here. Ultimately, you only have enough space for one word anyway - enough to state what happened, not why. Unless the reason is something like "moved away" or "went out of business" (which are still multiple words), context can be pretty important here.

Finally, references. Ah, references. The better social life you have, the better chance you have of getting a job. Nevermind your ability, qualifications, or availability; it's all about connections.

Some just ask for a name and phone number. Others get right stupid. Relationship? Irrelevant. Address? Yeah, because I totally have the addresses of all my friends, coworkers, and former employers.

Then you have some businesses - coffee shops in particular - that throw in their own questions. In most cases, these questions are completely ambiguous, worthless, and unanswerable. There is only one correct answer, which you must guess.

My three favourite bands? Let's see. First I have to think of which of my favourite songs even have bands. Most of them are written and/or remixed by one person. I suppose "Hamasaki Ayumi (remixed by DJ Random Guy #37)" won't fit here. Oh who am I kidding, nobody in this town has ever even heard of Ayumi herself. I may as well make up random Japanese words.

My favourite type of coffee? To work in a coffee shop I not only have to drink coffee, but already be familiar with all the different kinds? Isn't that what training is for? Or even just a goddamn ingredient list?

"This job may involve a lot of cleaning; are you OK with that?" Clearly there is only one valid answer here. My choices may as well be "absolutely" and "toss this paper in a fire right now". You may as well have asked if I have a head. Am I really expected to believe anyone is ever going to say "no" and get hired?

So finally, once you've spent an hour filling out the same information 47 times and your hand is cramped from writing, you can go out and hand out these forms - with copies of the nice resumé you made up that present all that same information - so they can proceed to toss them out without reading them because you didn't guess the correct answer to that one completely meaningless question on page 3.

Some day I'll have to get a bunch of these forms, fill them out with a lot of "you don't need to know", "does not apply", "question is meaningless" etc and hand them in. For now, if you're the one responsible for hiring somewhere, here's what I recommend for an application form:

You'll notice it's blank. Grab a sheet of blank paper from your printer. Hand it to the applicant, ask for their resumé, and read it. If they're not a total moron, all the information you need to consider them will be right there. Otherwise, well, there's your idiot test. You can ask for addresses and SIN numbers and whether they're legally able to work in your country during the actual hiring process. Thanks.

Rena v85840

2010-07-26T09:36:00.007-06:00

Oh look, a blag. How did that get here. Well I'll try to update this regularly but I can't guarantee that I'll have a working Internet connection or anything worthwhile to say. WE SHALL SEE.

Latest screenshots from my WIP Mario Kart 64 level editor.

At present, it displays almost every level almost perfectly. The remaining visual glitches are mostly hardcoded things I have yet to track down, and one texture command Moo Moo Farm uses that I haven't decoded yet because who cares about Moo Moo Farm anyway.

Luigi Raceway is one notable exception.

Its textures seem to be in a very strange place indeed, devoid of any actual image data. Quite odd.

There is no actual ROM modification going on at present. You can click on polygons and they'll show up in the Polygon window. You can manually edit anything in these windows (but not add or remove) and it'll show up in the render. So basically all that's left is to be able to import models, drag things around, and save back to the ROM. You know, all the fun parts. Oh yeah, and I guess it should display Luigi Raceway correctly at some point too.

INFORMATION! *sprunge* Looks like something out of a Hollywood hacking scene... except these numbers actually mean things! :o You don't have to use dark widgets and stupid broken unreadable title bars, but you gotta admit it looks so much cooler that way.
The hex window is just for debugging; there won't be any hex editing involved here.

Menus, gotta have menus.

Can you spot the glitch in this render? Probably not unless you knew what to look at.

Polygon selection! Also Wario Stadium FTW.

Wireframe's always cool.

***BEGIN BORING TECHNOBABBLE***

Rena stands for Racetrack Editor, Navigator and Assembler and is totally not a backronym.

Rena takes a different approach to editing. It's designed to be very modular, flexible, and extensible.
Most first-party Nintendo games follow a similar design. There are no models. Everything is code. Each level is built from a few files - one containing all the texture graphics, one containing all the vertices, one containing all the display lists, and whatever else that game might need.
A display list is a series of commands for the graphic processor. This is a fairly simple system - all 8-byte sequential commands that map closely to OpenGL functions. Each frame, the game selects a single display list (which can then branch off and call others) to render the entire scene. Each list renders only a small portion so it's not wasting time rendering things you can't see on the other end of the level.

To convert between this command-based format and any traditional model-based format would be a slow and probably imprecise process - likely in the neighbourhood of O(N⁴). (In other words, coffee break.) Rena's approach is instead to edit in this native format, avoiding this lengthy process - though a model import function is high on the priority list. (Probably 10 times easier than implementing any actual editing functions, anyway. >.>)

Of course, N64 is a 3D game console from 1995, which means not a lot of processing power, which means a lot of design complexity to overcome that shortcoming. Those list commands can be pretty low-level, and nobody wants to deal with vertex caches and texture buffers and write 32 commands to draw a box. That's why Rena parses the game's low-level commands into a much simpler, higher-level, but still command-based format. In fact, all of the F3DEX microcode (i.e. the game's graphic commands) are summarized into six of Rena's commands, with a single parameter each.

Aside from the advantage of reducing complexity, this has a bonus side effect: we don't have to worry about microcode at all. Different games may be designed the same, but they tend to use different microcodes, which are incompatible. For example, Super Mario 64's vertex cache is half the size of Mario Kart 64's, which means if you wanted to port between the two, you'd have to hack around this limitation all the time. With Rena, you could simply import to the higher-level format, then export back out to any format you want. Not even necessarily an N64 format - maybe Gamecube, PS2, whatever. Writing a codec is dead simple.

Of course, first it needs to do the things it's designed to do, before I even think about branching off into other games. But damn that would be sweet.