Adventures in Internet Publishing
Thursday, February 17, 2011
New blog template and a bonus!
Grey-on-black is an entirely 1990s anachronism on the internet these days, and painful on the eyes to boot. Here's a better theme for now.
¶ 5:13 PM 0 Comments
I have been working on a set of programming tutorials for the Nintendo DS/ARM that I plan to serialize here. For now they are on the Something Awful Forums in the Cavern of COBOL, which is open to public viewing. Check it out here:
Tuesday, January 11, 2011
ARM Assembly Gotchas
31 is not the same as 0x31.
¶ 5:13 PM 0 Comments
Immediate values can only be one (shifted) byte.
Why am I doing this?
I'm getting sucked back into DS programming, because my expedition into Atari programming taught me some basic concepts that I just wasn't finding in the source material for DS stuff. I swear, I need to write a huge book on computer concepts from the ground up.
So the main problem I was having with understanding ARM assembly on the DS was the black magic / voodoo performed behind the scenes by GNU as. Specifically, that it takes labels and creates relocatable code, and that everything resides in memory, usually.
Well ok, so relocatable code means that only offset-based addressing is used, not hard-coded memory locations, so the code can be anywhere in memory. This is why the intermediate format used in compiling/assembling is ELF, I guess. The NDS header specifies where the code is to be placed, namely the start of shared ram, or 0x2000000. So how do we get graphics data in there?
Well, without using some kind of filesystem, all data has to be stored in main memory, either interleaved with the code (yuck) or in a blorb at the end (not as bad). Properly aligned, etc. So my next trick is to figure out what directives I need to use with as to accomplish that.
Update: Well, I figured it out, you can plop in data with either .word or .hword for 32-bit or 16-bit values, respectively. And it survives the objcopy process. I should be able to use output from grit, at this rate.
Update 2: Hooooooly shit it works
Update 3: There is something very strange going on with the code I'm using, time to do it all from scratch.
¶ 1:19 PM 0 Comments
Sunday, November 28, 2010
The Original RISC Chip
I can see why the 6502 was once called "the original RISC processor." It's not, strictly, a RISC design, more of a parallel invention, but the BBC Micro used a 6502, and Acorn Research went on to produce the ARM architecture on similar principals. Looking at the instruction set, and how the registers work, it looks like you could even get it pretty close to the one-clock-per-instruction ideal, if you ignore the extra data fetches. It explains why it outperformed the z80.
I've only got experience with the 6502 and ARM instruction sets, and they're quite similar, the ARM being a heavily upgraded (and incompatible) version of the former. You've got arithmetic operations, memory operations, and program control, and that's it. ARM added multiplication which never gets used. Oh, and a bazillion registers.
Looking at the 8086 instruction set, it's got stuff that I don't even know what to do with. String operations, right there in machine language. An operation to compare two values in memory (the extra microcode to take care of that is probably slower than loading the values to registers, then comparing). Arithmetic shifts? Probably all useful stuff if C didn't exist and you don't have a macro assembler, though. Which was pretty much true with the original IBM PC.
VAX has a million different instructions, in fact it almost looks like it was created to run UNIX. Probably not too far from the truth. It has instructions to deal with polynomials.
Rambling now. I should probably go do something else.
¶ 1:22 PM 0 Comments
Saturday, November 27, 2010
Why Atari, again?
Well, now I've finished reading Machine Language for Beginners, not so much because it's a quick read but because I read it all day. It didn't really teach me all that much that I didn't know, but it filled in a lot of gaps, I guess. I can at least say that I know what all the hashes and parentheses mean after a mnemonic, and I have a vague idea of how the stack works.
I come back again to asking why the Atari is so much easier to program than anything else, and I am reminded of why I was frustrated with programming the TI-84+: there's no easy way to program it on the device. Aside from Atari's assembler, Machine Language for Beginners came with a short-but-useful assembler written in BASIC, that lets you write small programs and get a feel for the processor. You can literally write a small, 6-instruction program, assemble it to a safe memory location, and execute it right there, then give control straight back to BASIC. So, let's say you want to play with the arithmetic functions, you can write a little program, save its output to memory, and then PEEK it back in BASIC.
On the TI calculators, well, you'd have to write the program on you computer, transfer it to the device, execute it, and heck I don't even know if there's an equivalent to PEEK and POKE on the thing. So you'd also have to write code that outputs your little test data to the screen in some fashion. The barrier to entry is a lot higher.
Same with coding on the DS, since it doesn't have a flexible runtime environment. You have to write quite a bit of complex code just to play with the thing. It's easier when you're piggybacking off of DevKitPro, but that obfuscates the hardware away and it's harder to see what you're actually doing.
I suspect this is also why Python is such a beginner-friendly language, since it has an interactive interpreter. You can play with functions before working them into formalized programs.
So yeah, BASIC is a pretty limited system by today's standards, but it gets the job done if you know what you're doing.
¶ 11:11 AM 0 Comments
Friday, November 26, 2010
Misconceptions
I just started reading Machine Language for Beginners, which looks pretty good, but it had this gem in the introduction:
"ML can use up about as much memory as BASIC does when accomplishing the same task. Short programs can be somewhat more compact in ML, but longer programs generally use up bytes fast in both languages. However, worrying about using up computer memory is quickly becoming less and less important. In a few years, programmers will probably have more memory space available than they will ever need."
Oh, who was it that said that programmers will always adapt to use up all the available memory?
¶ 4:59 PM 0 Comments
Atari 8-bit Programming and You
Wow, I have something to write about!
I've been doing some preliminary studies on Atari 8-bit programming. Which means I've pretty much come full circle, because the Atari 400 was really the first computer I ever "programmed." So far my studies have included:
- Reading Racing the Beam, the book on 2600 games. An interesting read for a top-down perspective on early Atari programming. Yeah, it covers the Atari 2600, but the 8-bit computers were essentially based on a heavily upgraded 2600 design. It's still all player/missile graphics and playfields, and there's a similar general programming approach to them. While an interesting read, Racing the Beam isn't a technical manual, so it lacks a lot of the information that would be needed to actually write programs. It does give one an excellent starting point for getting into the Atari mindset, though.
- Reading De Re Atari, ANTIC Magazine, and other old references. Turns out my dad actually wrote a comprehensive-but-terse Atari reference that's been floating around on the internet for a while, and it's one of the foremost documents on the platform now. Who knew?
- Setting up a dev environment. MAC/65 and the Atari Macro Assembler are available on different sites, and it's interesting to try and work with them, line editing and all. I'm a bit of a purist in this regard, and I remember typing in programs from ANTIC when I was a kid* so... I'm not really tempted to write code in Vim and cross-assemble. I am, however, somewhat tempted to try and write a screen editor in the same vein, maybe even do some rudimentary syntax highlighting...
So, with my background in Nintendo DS hacking, it's interesting to look at the features and limitations of the old 8-bit computers.
For instance, in the more common graphics modes, you have access to "playfield" graphics, 4 players, and 4 missiles. The playfield is a bitmap that fills the entire screen, if you like. That's it. Then you have the players, which are 8-pixel-wide strips spanning the entire height of the screen. Your player graphic occupies a small part of this strip, you can move the strip horizontally through a register, and to move the image vertically you rewrite it to a different portion of the strip. Player graphics are accelerated in hardware and draw quite smooth. Missiles are similar to players, except they're 2 pixels wide, and take their color from the player they're associated with (or you can switch them into a special mode where they emulate a fifth player). What's nice is that collision detection is supported in hardware for all the players, missiles, and the playfield, so you don't have to write costly collision detection code.
Now, the thing about the playfield is that it takes a lot of computational time to change it around, so you can't really animate it that much. No scrolling backgrounds, then. You're also pretty tightly limited in the amount of stuff on the screen, though you can still employ tricks like flickering one player back and forth horizontally to make it appear to be two.
It's fun to look at the existing games and try to figure out what combination of playfield, player and missile graphics were used to put it together. The older-looking games obviously use the hardware without any special tricks, and newer games definitely have more interesting stuff going on software-wise.
*Ahhh, ANTIC. I think I managed to get a grand total of one game typed in and actually running. All I remember of it is vague graphics, though.
¶ 2:47 PM 0 Comments
Sunday, October 31, 2010
Whoa, I have a blog.
Yeeeeeaaaah, it's been a while, hannit?
I've mostly switched over to Facebook for "personal" blogging, which is nice because I can pick who gets to see it for the most part. Which means I've mostly forgotten about Blogger. I guess I can still use this for my programming escapades, though, to keep on track somewhat.
Lesse. I got an HP 32S I haven't bothered to try and program yet (the battery is low anyway), and I've all but given up on my Tandy PC-3 because I got an awesome TI-83+ SE. A screen that can show real graphics! Multiple lines of text! Games! I've messed around putting software on it but I don't know how to program it really, hurrr. There seems to be some good documentation on Z80 asm, though, so I can start reading that. Still won't impress my dad though 'coz it's not 6502 asm.
I have done nothing with my big pile of 74xx chips, mostly because I haven't bought any LEDs and I'm afraid of blowing them out. Need to take a crash course on electrical engineering. I'll be doing that as part of my major pretty soon, though.
I guess what I need to do is keep working on the DS programming? The ARM architecture is a lot more flexible. I've got plenty of other stuff to keep me busy though, like Left 4 Dead. ¶ 12:32 PM 0 Comments
I've mostly switched over to Facebook for "personal" blogging, which is nice because I can pick who gets to see it for the most part. Which means I've mostly forgotten about Blogger. I guess I can still use this for my programming escapades, though, to keep on track somewhat.
Lesse. I got an HP 32S I haven't bothered to try and program yet (the battery is low anyway), and I've all but given up on my Tandy PC-3 because I got an awesome TI-83+ SE. A screen that can show real graphics! Multiple lines of text! Games! I've messed around putting software on it but I don't know how to program it really, hurrr. There seems to be some good documentation on Z80 asm, though, so I can start reading that. Still won't impress my dad though 'coz it's not 6502 asm.
I have done nothing with my big pile of 74xx chips, mostly because I haven't bought any LEDs and I'm afraid of blowing them out. Need to take a crash course on electrical engineering. I'll be doing that as part of my major pretty soon, though.
I guess what I need to do is keep working on the DS programming? The ARM architecture is a lot more flexible. I've got plenty of other stuff to keep me busy though, like Left 4 Dead. ¶ 12:32 PM 0 Comments
Monday, March 23, 2009
Sometimes a phone is just a phone.
Money tiem.
Palm Centro smartphone: ~$25 with "new every two" promotion.
Voice plan: $80/mo for 1400 minutes, extra line, and unlimited calling to 10 numbers. $960/yr
Data plan: $45/mo for unlimited data with secret 5GB cap, +$15/mo to tether to N800. $720/yr
Total: $1,705 for one year.
On the other hand, an equivalent iPhone 3G is $80/mo for voice, $30/mo for data, and a $200 entry fee (even subsidized), so it comes to $1,520/yr. Tethering is currently impossible but we can expect a similar $15 fee, bringing it to $1700/yr. So basically, Verizon is cost-competitive with at&t. I thought I was getting shafted.
T-Mobile's data plan costs $20 less per month, but you only get half the minutes at $80 per month. So basically, phones are expensive. The Palm Centro seems to be a solid choice, given that Verizon has the best coverage.
Well, I guess I might drop the data plan for my phone, which'd save me $60/mo. There's free Wi-Fi most places I need it, so the N800 does pretty well without needing to tether. The Centro is still pretty good at texting, and running Palm apps on it is pretty cool, even offline. I just need to get DosBox working so I can play Prince of Persia. Maybe if I can find a cool Nokia phone that works with Verizon I'll try it out, since they're opening Symbian's source. That'd be nice.
Anyway, end rant. I don't feel as bad about my mobile internet device choices now, at least. ¶ 6:11 AM 1 Comments
Palm Centro smartphone: ~$25 with "new every two" promotion.
Voice plan: $80/mo for 1400 minutes, extra line, and unlimited calling to 10 numbers. $960/yr
Data plan: $45/mo for unlimited data with secret 5GB cap, +$15/mo to tether to N800. $720/yr
Total: $1,705 for one year.
On the other hand, an equivalent iPhone 3G is $80/mo for voice, $30/mo for data, and a $200 entry fee (even subsidized), so it comes to $1,520/yr. Tethering is currently impossible but we can expect a similar $15 fee, bringing it to $1700/yr. So basically, Verizon is cost-competitive with at&t. I thought I was getting shafted.
T-Mobile's data plan costs $20 less per month, but you only get half the minutes at $80 per month. So basically, phones are expensive. The Palm Centro seems to be a solid choice, given that Verizon has the best coverage.
Well, I guess I might drop the data plan for my phone, which'd save me $60/mo. There's free Wi-Fi most places I need it, so the N800 does pretty well without needing to tether. The Centro is still pretty good at texting, and running Palm apps on it is pretty cool, even offline. I just need to get DosBox working so I can play Prince of Persia. Maybe if I can find a cool Nokia phone that works with Verizon I'll try it out, since they're opening Symbian's source. That'd be nice.
Anyway, end rant. I don't feel as bad about my mobile internet device choices now, at least. ¶ 6:11 AM 1 Comments
