I still want to make my first-person shooter, and I still want it to be very, very good. But, I still need artists. Who's interested?

The communications link that I am using for my DS debugger, Xport 2.0's "cport", is a pain in the ass to work with. The cable provided receives hell from electromagnetic interference, meaning the data going across the cable ends up being incorrect about 30% of the time. Even worse, interference causes "ghost data" to show up on the line out of nowhere. How bloody useless is that?!

I have only two options to solve the problem:
1) Rewrite the comms software to help verify the data.
2) Create a new communications link using Xport's additional IO.

The best choice would be the latter, but that would require getting familiar with FPGA crap and learning how to create such a hardware link with it. A new comms link would still use LPT for the interface, but it could be done in byte mode (ECP) making the link about three times faster. Even better, it would get rid of all of the overhead on the cport which is used to control additional pieces of the Xport hardware. All I need is a stable 8-bit IO port. Using cport for that is a bit risky, because one wrong move could erase the flash memory and screw up the FPGA configuration. So a dedicated comms link would be perfect because it would be faster, but it would also be much more stable because I can use a proper IEEE standard cable with all the right interference shielding. ~1.5MB/s transfer rate with ~0.01% error rate.

The former choice would be FAR slower than it is now (now: ~37KB/s) because I would have to break down the data into smaller pieces. Right now I have invalid bytes showing up about once every 32 bytes or so, which means 32-byte blocks would be the best to start with. Run a crc16 on the 32-byte block to be sent, send the crc16 followed by the data. If the crc16 does not match the data received on the other end, it will ask to resend that block. The block will be resent forever, if needed, until everything matches up. this would probably make the link just a few percent slower, but typically about 4x slower than usual. (~8KB/s - 30KB/s) Alternatively, I could send the complement of every byte to ensure the data is sent properly. This would make it at least twice as slow, but typically more like 8x slower than usual. (4KB/s - 16KB/s)

I will probably start with the former method to get it at least working. 10 minutes is a long time to wait for a 4MB RAM dump, but it will be much easier to implement. The higher speed (and overall better) latter method is what I really want, but there's plenty to study before I can do that. Plus it will require a small adapter that I will have to build in order to connect a standard IEEE cable to the Xport's 34-pin IO header.

So does anyone have any Verilog resources for noobs?

I guess the idea for a decent FPS has failed. Either that or only two people read these entries.
So that puts me into a dull situation. I no longer feel like making a game. Maybe I will instead go back to my DS debugger when I can manage. I should have plenty to bitch about in relation to the debugger once I can get back to that projects, any way.

Watching The 1up Show: Episode 11, I was reminded by the Sin and Black videos just how great Half-Life 2 was back in the day. Back when the game was truly redefining the genre. And while Black looks like a decent shooter in it's own right, Sin looks like a complete Half-Life 2 rip-off. However, all of this reminded me of how much I have always wanted to create a first person shooter of my own. And it got me thinking about how badly NDS needs one. Thus, this idea was born: A first person shooter for NDS that doesn't suck. I know, it seems like a very unlikely task. A team of dedicated programmers, hackers, artists, and directors would need to put massive amounts of time and work into such a project.

So who's interested in giving it a shot? I'll keep it to myself unless people show some real interest in it. Only then can the details start to be ironed out.

I've decided to split my personal blog so that those heartless bastards out there who don't care about me as a person, but instead only care for what I give to the world won't be so annoyed by my personal rants. Here you will find only my technical blog entries, where I will list the status for any number of my programming and hacking projects. I don't have anything at all to say about any such projects at this particular moment, which is why my personal blog has been devoid of such content since early January.

I think it is safe to assume this blog will see much less activity than my personal rant/stupid stuff blog. But that's just the way things are.