Machinations

Inspiration

2011-10-24T12:01:00.001-07:00

This is perfect. Seriously perfect.

TRSAC

2011-10-23T14:48:00.000-07:00

...was EPIC. Seriously a great party :) . I made two things for it:

A quick demo with music from Lug00ber; the entire thing was produced from scratch in 24 hours which was really fun!

Also: http://soundcloud.com/yupferris/atmos Some wubwub that got me 2nd place in the music compo :) .

I'll have pics and videos up soon, be patient :D

New Gameboy Track

2011-08-16T15:22:00.001-07:00

..is HERE :) .

Until next time.

Chiptunez

2011-08-08T04:37:00.001-07:00

Small update; got a new flash cart in my DMG and a small recording deck, so I took the opportunity to touch up some old stuff, which you can now find on my Soundcloud here:

http://soundcloud.com/yupferris/sets/old-dmg-remastered/

Enjoy :)

Pixels

2011-07-02T15:42:00.000-07:00

Always wanted to be able to do pixel art. Been studying it for a long time, actually, but never got up the guts to finish one of my test pieces.. until today :) . Nothing fantastically impressive, but a good first finished pic. Used 7 colors (which you can see at the top left of the pic):

Hopefully this is a skill I can improve on over time.

The Proper Way to Fill Useless Bytes in your Binary

2011-05-21T13:01:00.000-07:00

No, I'm not bored, just hate using nop's to pad bytes. The result? This:

You know you love it.

Milk and Compressors

2011-05-01T11:27:00.000-07:00

Late last December, Decipher and I had plans to complete a highly massive 64k intro for The Gathering. Around January, we started on tool/framework development, and had a pretty good start. We made one mistake, however: We assumed that once we had the technology, the creative aspect of the intro would be trivial. Because of this, we developed highly capable tools and such, but in the end had nothing to show. In other words, we failed :) . On a side note, I was also busy preparing to move to Norway to work for a fantastic startup company founded by former demoscene group Outracks and finish up my current semester at WIT, and Decipher was tied up in work projects at Nokia. Excuses, excuses ;) .

Needing a backup project to avoid arriving at TG empty-handed and deal with the stress I had encountered, I decided in the last three weeks to produce a 1k intro. Problem was, the version of Crinkler 1k that we had on-hand was an older test version that wasn't very compatible yet (and do to mistakes we had made the previous year, we didn't want to request a new version unless we absolutely had to). So, I wanted to produce a prototype of Juicer; a 1k compressor that Decipher and I had planned to produce many times before but never got around to finishing.

So, [re-]development of Juicer began. It started with producing some sort of dumbed-down version, as a proof of concept (and to refresh my very dated data compression experience). For this, I chose to develop a packer for Commodore 64, simply because the executable format is much simpler (no header besides a 16-bit load address, as opposed to the Windows PE header, which is a real pain), and I just love coding for that system. In about five hours or so composed of researching compression techniques, coding, and testing, I had a working lz77-based C64 intro packer. The compression wasn't very good, but the decompressor (including autostart stub) occupied only 87 bytes, without optimization. Unfortunately, I don't have the original packer, as my beloved flash drive was lost in the move, so I can only show an unworking version that I have left over here:

Go ahead and laugh :) . But yes, this was a success (at one point). Also allowed me to write a nice little class I call bitbuf (bitwise data buffer). Self-explanatory ;) .

Next was to do it in Windows. If you read my previous posts, you'll know I've had plenty of trial-and-error experience with PE hacking, so this part was nothing new :) . Once I had the systems (and virtual machines) to test on, I had a working, handmade PE header in assembly in a few hours. The compressor was much harder, though.

The first thing I tried was based on the C64 lz77 scheme, but with some lzma-based modifications. I had decent results on ASCII text (namely, size-optimized GLSL code), but it didn't work very well on binary data. So, I read up on what Crinkler was doing. As described in the Crinkler manual, this blog post, and a few other sources, Crinkler is doing a (very strange, mind you) 33-bit arithmetic encoder with order-8 context modelling. These buzzwords are too complex to explain here (and that's what Google's for, you know), so I won't :) . But basically, I delved into these methods myself....and I can't yet share my results until the project's finished, so let's move on a bit ;) .

Long story short, three weeks simply isn't enough (at least for me, hehe) to beat such an efficient compressor as Crinkler 1k with a decent decompressor size. Not to mention I lost two days from TG stuck at the airport in Boston, but that's another story.

So, we had nothing to show at The Gathering, except perhaps a nice effect I planned to squeeze in the 1k. Which I was going to save until we did a proper packer, until Duckers/Outracks called us 30 minutes before the intro compo saying, "If you don't release something, we have to drop the compo because of the number of entries." So, with 30 minutes to do an intro, you do what you can with what you have :) .

And, what we did was this; Milk by The Compo Xaviours (a group name coined by the group PlayPsyCo from last year's TG, when they saved the same compo with another entry):

It's the 1k content I had planned, with Decipher's C framework and a quick tune with my 4k synth. The visuals are kindof cool, so I'd like to break them down for you. Here is the code:

Vertex shader:

varying float t2;

void main(){

t2=gl_Color.x*2222222;

gl_Position=ftransform();

}

Fragment shader:

varying float t2;
float t=t2-fract(t2*.4),d,c=cos(t*.6)*4;
vec3 r(vec3 x,float t){
 for(float v=0.;v<3.;v++)t*=.8,x=vec3(cos(t)*x.x+sin(t)*x.z,cos(t)*x.z-sin(t)*x.x,x.y);
 return x;
}
void main(){
 vec3 x,a,z=vec3(0),y=r(normalize(vec3((gl_FragCoord.xy-vec2(320,180))/300,1)),c);
 for(float v=0.;v<3.;v+=.06){
  x=abs(a=r(abs(z-r(
    vec3(sin(t*.4),0,3.5+sin(t)+t*.05)// Camera
   ,c))
    -vec3(clamp(t-20,0.,1.5))// Mirror displacement
   ,
    max(t-10,0.)*1.2// Mirror rotation
   ));
  d=min(max(max(x.x,x.y),x.z)-1,8.-length(x));
  for(float v=0.;v<3.;v++){
   x=abs(fract(a*pow(3.,v))-.5);// Subdivision
   d=max(d,mix(
    .17-min(min(max(x.x,x.y),max(x.x,x.z)),max(x.y,x.z)),// Cubes
    length(x)-.6,// Spheres
    .5-cos(t*.07)*.5
   ));
  }
  gl_FragColor=mix(vec4(1.1,1,1.2,1),vec4(1,1.1,1.2,1),y.y+.5)*v*.3;
  if(d<=0)break;
  z+=y*max(d,.0001);
 }
}

..unobfuscated, that is. Basically, it's the popular sphere tracing technique, but with some neat little tricks. Let's break some of it down. We start with this:

This image really only has two objects; a cube and a background sphere. These just look like this:

Then, I intersect the two volumes with a repetitive cutout cube. This looks like this:

Simple enough. Now, do this with multiple iterations, where you decrease the size of each cutout and increase the frequency, and you have the original image. The next trick is the cube deformation, seen here:

This is MUCH simpler than it looks, actually. Let's remove the "sponginess," for clarity:

In this shot, it's actually quite obvious what it is that I'm doing. I'm tracing just the cube and sphere normally, except for one thing: mirroring. Imagine 3 mirrors, set on each axis, and all facing the upper-right corner. This is the entire trick. Everything you see is just a mirror of the upper-right corner (1st domain). So, this deformation is just a matter of rotating the cube. That's all :) . Camera operations still work normally, so it looks quite nice.

The next trick, if you look at the original screenshot of the prod (with the four spherical things), is that the cube separates into four more cube-like structures. This is actually the same trick as before; the mirrors. All I do is move the cube outwards diagonally, and the mirrors follow. The demoscene really is all smoke and mirrors, anyways ;) .

My next trick explains why the objects in the main screenshot are spherical. This is simple, too. As the intro progresses, the cube cutouts actually transform into spherical cutouts. And, well, that's actually enough explanation :) . Instead of cutting out cubes, we cut out spheres. Blend from cube to sphere, and you have the main timeline for the intro.

Finally, we have the "multiple camera angles." Actually, we don't :) . This is the simplest part of the intro, and one of the most rewarding. Instead of cutting multiple cameras, we just create one that's very dynamic. After that, just cut time instead. The result looks like multiple angles, when in reality it's multiple instances of time.

So, that's it for the intro. The 1k version uses some more nasty hacks to get it smaller, but the posted code (obfuscated, of course) is exactly what made it into the actual prod. Had it been 1k, I think I'd've gladly used the Youth Uprising label, but it was just too insignificant as a 2.5k I think :) .

Speaking of YUP, I'd like to mention, we have a new member, Gunda. He released his first production at The Gathering in the demo compo, Nitesco. A cool firstie; he did all code and design, while I did the music and framework, and helped out here and there. Look forward to his next releases - he's bound to progress quite fast (as he did during the making of this prod).

And finally, I released a 4k intro starter kit and seminar at TG. The kit can be found here and the seminar video is here. Won't say anything more about that; you can just check the links :) .

Until next time :) .

New Chiptune!!!

2011-02-13T22:01:00.000-08:00

Hey guys, been busy the past few days with many things. One of which I think you'll quite like :) . It's my first Gameboy track featuring vocals (by Farisha) and a proper sampled kick drum. The song is here:

Ferris - Breathe

This is a recording straight from the Gameboy itself, plus a little mastering. Enjoy :)

Breathing Inspiration

2011-01-08T00:26:00.001-08:00

Ah, what to say here. Not much more to add after that title :) . I suppose I can say that YUP is hard at work on our Easter prod(s) already. Been feeling rather inspired and motivated. Hopefully it turns out alright!

Back to slaving over code.

DMG, How I Loveth Thee

2010-12-28T03:59:00.000-08:00

While working on our upcoming C64 demo (upcoming as in, the one we've had in the works for about a year, and it may be another year before the dang thing's finished, hehe), I realized all the SID tunes I had done myself were rather mediocre. I started looking for other sources of inspiration (aside from the usual C64 prods I've seen far too many times). What did I find? Gameboy demos. They had the flavor of C64 demos but a nicer pace, and the sound had something special to me. This is not to say I'd give up on the C64 prod - far from it. But of course, I started looking into this alien system.

Codename DMG - Dot Matrix Game, this little beast boasts a 25x25 character screen (similar to that of the C64), something like 40 sprites, 4-colors with a square pixel ratio, and my personal favorite: 4-channel audio. More specifically, the audio consists of two pulse wave generators, a sampler-like wavetable channel, and a white noise generator. This sure doesn't sound like much, especially compared to the extensive capabilities of the C64's SID channels, but as I said before, it had something special.

I started looking into more of this DMG chip music stuff and found a few artists I really liked, including cTrix (whom I had met at @Party, though hadn't realized his influence on the modern chip scene until now), Nordloef, Sabrepulse, Anamanaguchi, and others. Each of these artists brought something unique to the table, but everything marked "LSDj" still caught my eye. So, I looked into that aswell.

LSDj - Little Sound Dj is a DMG program that allows you to produce music in a tracker-style interface on the system itself, which I thought was really cool. Not to mention that I had started my demoscene music career with good old Modplug Tracker (now called OpenMPT), and I really do love trackers in general :) . I grabbed a DMG emulator and the LSDj demo and, within hours, had fell in love. At the risk of sounding like a cheesy 3AM infomercial, this program was a total dream to work with; I found the interface navigation to be very intuitive and the features of the program were impressively extensive. Pictures:

Pictures from http://www.littlesounddj.com/lsd/ .

The closest experience I can relate it to is actually my 4K synth, Sonant 2, which is nice, since the workflow in my synth was designed for my needs specifically. Being that they were so similar, I had picked up the software quite rapidly. Within days I had my own full copy of LSDj and a DMG USB cart in the mail :) .

The results? Well, among others, Sidchain is a song that I'm quite proud of. For using LSDj for less than two weeks, I'm very much happy with what I've accomplished. In addition, it looks like I'll be playing my tracks at a little house party on the 30th, which is very exciting for me :) . It will be my first electronic performance ever, and I must say I'm honored to go into battle wielding the infamous grey brick. Obviously, pictures/videos (whichever I end up with, hehe) will be posted :) .

Until next time.

Finally Broke Five

2010-11-18T12:06:00.000-08:00

4:56.21s. That's my new record for rubik's cube blindfolded :) . This is a pretty nice achievement for me, though it's not exactly competitive. For those readers who don't know what this time means, it means that in under five minutes I memorized a rubik's cube, donned a blindfold, and solved it. I'm quite proud!

The cube is broken down into corner and edge pieces (as the centers never move relative to each other). There are then 12 edge pieces and 8 corner pieces. Normally, when solving the cube, you use a layer-based approach. This means you don't go side-by-side, but instead, solve the first side and its edges, then fill in the middle slice, then solve the last layer. In my speed case, I use a CFOP (Cross, F2L, Orient last layer, Permute last layer) approach. For more information you should check out this link.

For blindfolded solving, though, the method for actually solving the cube is much simpler. It relies on basic principles of the cube and is intended to minimize the amount of thinking required to actually solve it, in order to improve memorization and retention. My blindfold method goes through simple steps: First, I orient the corners. This means I make sure they're either facing up or down. After that, I permute the corners, which places them in their respective positions. After that, I orient and permute the edges in one step. After all is said and done, the only thing I'm left with is possibly to re-orient an edge or two, and fix parity, or a special case where two edges and two corners must be moved at the same time, when necessary.

For you cube buffs out there, this method goes like this: Commutators fix corner orientation, then I use the Pochmann method for corners (but shooting to UFR instead of RFD using the normal Y-Perm). If there's an odd parity, at this point, I also execute a Y-Perm, swapping UBL and UFR and fixing the UL and UB edges. I resolve this later. Then, I use Pochmann's M2 method to fix edges. If we had parity earlier, I do this algorithm: M2DS2-(Y-Perm)-S2D'. After that, I finish off possible edge orientation left over from shooting to the M slice during M2 or edges that may have been correctly placed but oriented wrong in the beginning.

Interestingly, I memorize all of this information backwards. That is, I memorize my edges first, then corner permutation, then corner orientation. This is because of the way I memorize them. I memorize edges in pairs of letters, and as I go along, these pairs are converted into words. At the end of my edge memorization, I have a sentence (usually nonsense) that I'm unlikely to forget. Then, corner permutation is a sequence of numbers. I can't really leave this in my head, but I can repeat it to myself while I memorize and solve the next part. Corner orientation is memorized visually, either in pairs of corners, where one needs to be turned clockwise and the other counterclockwise, or as triplets where all three corners need to be turned clockwise or counterclockwise. If I must, I tap their faces to help me. This way, the information I am most likely to forget is taken care of first.

This system, though a bit complicated, works out well for me. I hope to improve it and improve my memory over time.

On another note, YUP has released two prods this month! Pics:

The top one was a co-op with Outracks and Kvasigen, and an invite to The Gathering 2011 in Hamar, Norway. You can download that here on Pouet. The other one was a small noise demo. For some reason tons of people are producing TV noise effects, for fun I suppose :) . We did one, and yes, it was fun!! That's here.

All for now, see you guys :) .

Painting Revisited

2010-10-13T22:03:00.000-07:00

Over a year has passed since I've painted (mostly for emotional reasons), but today, I had a little taste of what I've missed. I must admit that I'm a bit of an oil fanboy; however, living the poor college life has forced me to resort to a mix of ink and watercolors, but it's definitely enough to get me by until I can reunite with my oils back in Idaho.

So far all I've done is some test subjects (creepy animals, Victorian-era furniture, twisted trees), but it's gone quite well. They have more of an illustrator quality than I would like, but I'm still certainly pleased with my gimped medium. Not to say watercolors are lesser than other media, per say, but I just don't feel quite at home with them :) . Nevertheless, the feeling has definitely been missed, and I'm quite pleased.

Pictures up soon when I get some decent works finished!! Now to sleep and await the arrival of my midi keyboard (M-Audio Axiom 25, an older [special-edition] version), here:

Image from http://www.kvraudio.com/forum/viewtopic.php?t=238861.

I'm also waiting for some clothes and other random things :) . Until next time!!

Thoughts

2010-09-18T09:33:00.000-07:00

Well, in the last post, I promised some Studio4 screenshots, so let's get that up and out of the way :) .

OK, so maybe just one screenshot ;) . This is the tool in action, and you can see that's our 4K "Ethos" (which can be downloaded here). It's a nice little tool, though it doesn't support our latest developments, so a lot of it will actually be re-done. And, as far as SNESAsm goes, it's pretty much dead.

Since my last post I've moved to Boston, Massachusetts, to study computer science at Wentworth Institute of Technology. It's a pretty sweet place, and I'm loving the college life. And, as always, I have tons of small projects to keep me sane through it all :) . One of which is a raycast engine (among other 3D works) on a certain hacked Casio calculator; the model of which I must keep quiet because I plan to be the first to release a demo for it. Speaking of which, we already have three other projects that are on track to be released this Easter - the forementioned C64 demo, a project led by Decipher, and another one I can't really speak much of ;) . Gotta love demoscene secrets!!

Another of my projects lately has been music production. Throughout my demoscene career I've done tons of songs, but ever since the release of Rarefaction, all the music I've released has been in 4K's. Coincidence? No, this was on purpose. At NVScene Gloom and Gargaj told me I needed to learn mastering, and I've spent two years now doing so in the background of my other projects. I'm getting there, I think, but as always it still needs a lot of work. It's a fun process though, and I'm always game for learning new things. Someday I hope to release an EP actually, though that's in the somewhat distant future. For a sample, you can listen to this track and let me know what you think :) .

That's all for now, see you guys.

2010 Thus Far

2010-05-12T17:14:00.000-07:00

A list of YUP updates:
Magnus - 4k intro - 1st at TG10 combined intro compo (this means two first-place 4k intros in a row; watch out ;) )
JenterErForetrukket - 1k intro - 2nd at TG10 combined intro compo
Simulacra - 4k intro - no party

And, a list of current projects:
Studio4 - 4k intro development tool, all-in-one. Screenshots and development progress will be posted when I'm less busy.
SNESAsm - A cute little IDE I started about a year ago for SNES development. I abandoned the project after moving to C64 (SNES was too complicated for me at the time, sadly) and realizing that things like RichEdit controls are a total pain to work with just with C++ and WinAPI directly. I've restarted the project using VC++ (which I've since switched to), and it's funny; I've made exactly as much progress on the tool in a night using .NET and forms as it took me over a week to do last year with WinAPI and GCC. Haha. To see progress I made before abandoning, you can check out this link, and I'll probably keep updating stuff there...but you'll just have to wait and see how it goes :) .
...And, there are a few other projects, too, but they're minor for now and school sucks so not alot of development time.

Anyways, sorry to be so brief for now, but I've got things to do :) .

Update

2010-02-21T20:04:00.000-08:00

So, it's been almost a month since I last posted. Due to incredible business (mainly from involvement in my high school's FIRST Robotics team) I haven't had any time to work on my microcontroller business (besides making some blinking lights. Pfft). On a lighter note, however, I resurrected an old 1K intro, which I plan to release when I go to Norway for The Gathering this year :) .

The progress has been VERY good. Originally, it had a softsynth (the first on Earth for a 1K), but it only played the same instrument (saw wave) at two octaves; a rather cheap trick to get multiple patches. So, I tried midi. About 100 bytes smaller and now 4 instruments (including a percussion track!), midi is DEFINITELY the way to go in 1K. I suppose if you had no visuals and just played a song you could get away with doing a pretty cool little synthesizer, but really - what good are 1K's with no animation :) ?

I've also been doing some hardcore pe file hacking. PE - Portable Executable - is the Windows .exe format. It's bloated, crappy, and can be described with many other colorful words...the worst part is, much of the data (30-40%!!!) is even skipped by the Windows loader, rendering it useless.

Useless? Or, is it?

Not really :) . Anyone who's done anything in Assembler should know that we can squeeze a few opcodes here and there throughout the header :) . By hacking like this with the help of a nice debugger (thanks, Mentor!), I'm now down to 269 bytes, which is fully XP/Vista compatible (haven't yet tested 7, but it's likely to work), and about 40% nop's. Doesn't seem too exciting (269 bytes is still pretty big it seems....guys have gotten a PE file into 97 bytes, but this relies on the fact that when it's loaded to memory all data after it for about 4 kilobytes are just zeros, which "replaces" data that SHOULD be in the PE file. Also, they clear a major chunk from the file [about 144 bytes], which doesn't work with Vista, so no go), but I have some really good ideas to fill it.

What's this for?

Juicer. A 1K-intro compressor for Windows. Decipher/YUP and I started the project over the summer and I got hung up doing this PE hacking...worked just fine on the retry, so I suppose it's back in business :) . It'll have to be halted to keep up with all the demo work we're doing for Breakpoint and TG in April, but I'd bet the guys developing Crinkler (and the secret Crinkler 1K ;) ) would appreciate some nice competition.

'Till next time.

Adventures in LPT Part II.V

2010-01-23T22:28:00.000-08:00

I know, I keep bumping back part III, mainly because of school and other projects.

Basically, here's where I am now: The parallel port sucks in Windows. It's impossible to poll the C64's serial communication fast enough in any multitasking OS, which is a huge setback.

However.

I've been looking into using a microcontroller board so that a MCU can handle the serial communications, and a Windows program will run a 6510 emulator, thus the entire apparatus will emulate a 1541 disk drive. This will still use the parallel port, but everything should work correctly...if not, I still get a microcontroller to play with :) . After I get that working (if it's even possible) the project will move to USB. Basically, it'll be like this guy's project, except backwards and I plan to try to get it working all on one ATMega168 MCU. This should actually be pretty simple, or totally not depending on how fast everything is (as I know the USB interface will run in low-speed mode; which is still pretty fast for what we're doing though).

Hopefully all this will work, and hopefully I'll get some money with which to buy the hardware :) .

What? A Short Post??

2010-01-23T07:02:00.000-08:00

Surprising, I know :P .

Anyways, I'm kinda nervous. In fifteen minutes I take my SAT (for you europeans out there, this is the Scholastic Aptitude Test; a big general college admissions test). I'm a bit late taking mine, but I'm taking it nonetheless. I feel confident that I'll do well, but how well is important; as I applied to MIT :) . Nevertheless, wish me luck!! If all goes well I'll definitely post more here.

C64 Advantage

2010-01-19T21:00:00.000-08:00

Any retro gamer understands the importance of one thing - The Joystick. U/D/L/R & Fire, what more could one ask for?? Well, I needed one for my C64. My first plan was to rip apart an old SNES controller (My SNES, mind you, is probably my most beloved old system, so this would be painful for me..), and use the d-pad and one of the buttons. So, I looked through my game controller cabinet, and found something even better...

Anyone ever heard of something called the NES Advantage? It's basically a beefed-up NES controller, with a joystick(!!) to replace the d-pad and some features like turbo and slow button mashing. Well, it just so happens I had one laying around :) .

Image from http://sinfoniafantastica.wordpress.com/2009/03/10/la-evolucion-de-los-controles/ . I also have an SNES equivalent...but that's beside the point :) .

Now, like all of my systems, I love my NES dearly, so I didn't want to open this thing and just ruin it...besides, wouldn't it be cooler if I added a DB9 port, making it compatible with both systems? Yeah, I thought so too :) .

It just so happens that the pinout and functionality of the C64 joystick port is SUPER simple. Simply ground any of the 5 input pins (up, down, left, right, and fire), and the button's pressed. This is perfect for any controller to be modded :) . The pinout on the left (DB9) shows the pinout for this port:

http://zimmers.net/anonftp/pub/cbm/documents/projects/interfaces/plus4joy/plus4joy.html ; Thanks Zimmers :) .

And so it began. First, I had to open the controller, which actually took more work than I had expected...turns out they used to put screws under the feet for these things :P . Blast.

The layout of the two boards in here were pretty simple (at least for my purposes). I really didn't care much about the extra features of the controller; I just wanted the joystick to work and use the A-button for Fire. This way, I really just had to solder the right wires - one for ground, and five for the inputs. For the connection wires, I just spliced an old Ethernet cable, then just crimped the DB9 connector pins to one end and popped them into the connector:

With that end of the cable taken care of, I remembered I'd need to cut out part of the case to mount the connector. I had my friend Stephen help me with that (as I'd never used a dremel before)...Honestly, he just did it for me :P . Turned out a bit sketchy, but hey - it was his first day with the tool, so I'd say that's pretty good :) .

Then came the soldering. Turns out, the U/D/L/R controls were all labelled on the PCB, which made that part rediculously simple; the Fire connections were found by sight and confirmed with a multimeter. Once soldered, the rest was just reassembling everything:

So, very easy :) . Here's what it looked like just before I tested it (the new port is on the left; the black cables on the right are the original NES inputs):

...and here's what it looked like as it worked first try :D !!

Don't you just love the sweet smell of soldering success :) ? By the way, you can't really tell because of my crappy phone camera...but the game I'm playing there is called Delta :) . You can find details here: http://en.wikipedia.org/wiki/Delta_(video_game) . If you like retro games, especially side-shooters and space games, check this one out; it's definitely one of my favorite arcade-style games ever. Well, I suppose that's all for now...see you next time :) !

Hardware Hacking 101

2010-01-18T19:24:00.000-08:00

DISCLAIMER: Yes, this IS another post about my C64 :P Get over it :) .

My C64, recently, has been overheating, which is pretty unfortunate...so I wanted to fix it :) .

And by the way, my girlfriend Courtney took a couple of pictures while I was working on it and I like them :) . So, here those are:

Anyways, back to the Commodore. I opened 'er up and started feeling which chips might be the ones getting hot and causing the screen to fill with random characters. I knew it was obviously one that shares the same data bus as the VIC (yeah, THAT narrows it down, considering they all share the same bus :P). At first, I suspected the PLA, since that chip seems like a pretty common one to fail...however, that chip was the coolest one there!!

On later inspection, I noticed the PLA was actually made 5 years after the rest of the system, which means it was replaced at some point.

To my surprise, it was the SID. Also, the CPU and CIA chips were a bit warm, but not enough to really worry about it. So, how to fix it?

I could replace the chip, but it sounded just fine when it ran. Not garbled, all 3 voices played correctly...this seemed fine. Then I checked my power supply, since I thought it might be pumping out too much voltage for the system. Foiled again!! Both the DC5V and the AC9V outputs were consistently putting out their ratings (with an error margin of about 1/100th of a volt). I was actually pretty happy about this, since I'd hate to have to replace anything :) .

Yet the problem was still there...So I decided to go a modern route: add a fan :) . I had a small DC12V fan lying around from ripping apart dead computers at some point. Then, I just had to figure out where to mount it and where to wire it...And on top of that, adding a fan gave me a green light to do some other aesthetic mod's to the machine :) . More on those later...here's the fan I wanted to use:

As it turns out, I figured I could steal some power from the SID for the fan. This should drop the voltage to the chip, which would be good since overheating is usually a sign of too much power input. Also, the fan would pump some air through the system, which would be good for the other warm chips aswell.

I checked the pinouts for the SID. I got them from my copy of the Commodore 64 Programmer's Reference Guide, but to show you, I also found this one on Wikipedia:

The chip has one ground lead (GND; pin 14) and two voltage input leads: VCC (pin 25) and VDD (pin 28). I checked the voltages on these, and VCC is for the logic circuits, running at 5V. VDD is for the rest of the chip, and it runs at 12V.

I turned the C64 on and touched the fan first to GND and VDD, since my fan was rated at 12V. BAD IDEA. The screen went brighter and there were weird characters all over the screen...apparently this line is shared with the VIC's voltage input, so by somewhat shorting this line, the VIC seemed to get overloaded. I could be completely wrong with what really happened, but this explanation makes sense to me :) .

So, I reset the system - nothing broken, whew. So I tried it again :) . Don't worry; I used the 5V VCC this time...success :) . C64 still ran fine, and the fan went at a nice (and quiet) speed. So, I left the C64 going with clips holding the wires in place, and the fan just sitting on top of the SID for about an hour. Usually, the machine craps out in about 20 minutes, but not this time!! It lasted the full hour, with the SID still at a decent temperature :) Ladies and gentlemen, we've solved our problem :D .

Now for those aesthetic mod's I mentioned earlier :) . My main desktop is black with blue lights...see where I'm goin' with this ;) ? Why not make them match? I went out and bought some semi-gloss black spraypaint (I chose semi-gloss after a long internal debate between high gloss and flat black :P), and some blue painter's tape. I figured I'd start the painting first since I could do everything else as it dries.

I have to admit that taping off the two C64 logos and the model sticker on the bottom of the case was pretty annoying and/or difficult to do...but it was worth it :)

The LED replacement was pretty trivial, so no need for the details...just a picture :) :

Blue LED's kick so much tuchus :D .

Now, when I installed the fan, I ended up just soldering the fan wires directly to the pins of the SID. I figured it'd be the right thing to do since my test had the wires held there anyways :) . Here's how it looked running without the case (I couldn't resist; I had to play some games while the case dried!!):

Next I just had to permanently mount the fan. I figured I'd just hot glue it on top of the chips that it was already resting on :) . This would be quick and easy...so I taped it down and took care of that. Oh, and one more thing - at some point when I was prodding around with a multimeter I had it on a DC setting instead of AC, and it blew the C64's fuse :P . Anxious to get it back together and working again, I ended up just bridging the connection by soldering a normal wire to it...NEVER FOLLOW THIS EXAMPLE. Hehe :) .

The rest of the project was pretty much just reassembling and some minor details...then testing, and still to this day the C64's been functioning happily :) .

As you can see, the mod was pretty straightforward and went really nicely. I mean, as far as mod's go, it's pretty amateur; but I solved the problem and really enjoyed doing it. Something about playing with code or wires or anything like that just gets me...expect some more mod's in the future to my C64 and my other systems I have laying around :) . Until next time!!

Some GLSL Wizardry

2010-01-07T07:03:00.000-08:00

I was browsing through my pictures at some point and I came accross an interesting one:

Doesn't seem like too much, does it? Well, this is actually pretty cool.

Last August, after winning Assembly Summer '09's 4k intro compo with Muon Baryon, Decipher and I renounced raymarching for good. Yup, we're done with it.

What next?

Well this was just one answer to that question (among the many that I had). This image itself isn't much at the surface. But, then, why did I show it? Simple: The code is awesome :) . Look at the reflections on the objects: there's a room there. Now notice the background - no room. How can this be?

Well, back then I had this really neat idea to synthesize a room out of simple vector math, which even used the vectors already present in the Phong lighting model to compute. Needless to say, it worked beautifully :) . And you'd be surprised at how small this room actually is in code. Well, I'll show you :) . The code to generate this reflected room in GLSL is:

c+=pow(max(max(abs(r.x),.4-r.y),abs(r.z))-.4,2.);

Boom. One line of GLSL is one whole reflected room. Now, normally in a blog post, I'd tell you all the little details of every little bit...But this time, I won't :P . Sorry; a bit too valuable ;) .

Now, I'm going to school. Bye!! :)

Adventures in LPT - Part II

2010-01-06T22:00:00.000-08:00

In the last post, I mentioned the XE1541 cable and the fact that it can be used to connect the C64 to a PC, where an emulator runs on the PC and through the LPT acts like a C64 disk drive. This is a pretty cool idea...but to do so, I'd either need to download someone else's emulator, or write my own.

Most of the emulators around now have a couple major flaws that I just can't live with: the free ones are DOS (I'll get into why later), and most of them only have the most basic implementations of the 1541's DOS. Pretty much all they allow are use of the C64's kernal LOAD and SAVE commands, and sometimes they can load a .d64's table of contents to the C64's BASIC memory (thus allowing one to display them on the machine with a LIST command). That's just not enough. If I really want to utilize the C64's hardware, I'm gonna need something that at least supports a basic IRQ loader.

For those of you who don't know, an IRQ loader is a C64 routine that allows data to be loaded into RAM from a disk drive while other things are happening on screen. This is extremely valuable for demos, since one effect can be playing from one chunk of memory while another effect or picture is loaded into a different part of memory, almost simultaneously. EXTREMELY cool :) .

The fact is, I want a freely-available, Windows-compatible, cycle-exact 1541 emulator. So, I'm making my own :) . Which means I need to figure out how all this works...the connections, how each piece of hardware is supposed to act and when, pinouts, the LPT, and more. This should be fun :) .

Well....I have a confession to make. That last paragraph said I have to figure it all out, as if I hadn't done so...now, that's not entirely true ;) . I HAVE actually done quite a bit of research into the topic (but that was probably obvious in the last post, hehe).

To start, let's talk about the LPT.

This is a DB25 parallel port. It has 8 data lines (input/output), 4 control lines (output), and 5 status lines (input). Though I'll admit the pinout isn't completely logical, it's still a pretty simple port to use and understand. Here's a pretty simple picture of the port and its pins:

Picture: http://slotcars.carlsoncomputers.com/Articles/lpttest/lpttest.asp .

Note that the unlabeled green pins are all ground lines, and I'll get to what "D", "S", and "C" stand for in a moment. As you can see, though some of the pins seem out of order, this is an incredibly easy port to design hardware for. "High" voltage always runs at (with negligible error of course) +5v, so an average LED is safe with just a 100kΩ resistor, and most MCU's are safe at this voltage even without any resistors at all.

So, this port is simple to wire...but what about programming? The "D" from earlier stands for "Data". These lines make up an 8-bit input/output port. the "S" stands for "Status"; a 5-bit input port. Finally, the "C" stands for "Control"; a 4-bit output port. But why these names?

Remember, the port is called "LPT" - Line Print Terminal. This is a printer port. The PC sends the printer a command over the control lines, then the printer sends its status back in the status lines, and they transfer data to each other in the data lines. OK, that's pretty simple...but still doesn't explain how to code the dang thing.

Well, it's remarkably simple. Each LPT in a machine (on normal PC's, usually 1 is present, and sometimes 2) has a base address which can be read from the system's BIOS from address 0000:0408. This points directly to the data register. The byte after that? The status register. And the one after? Yup, you guessed it - control register.

Fun fact: the serial COM ports' addresses reside at 0000:0400.

Now, we could always be safe and read these whenever we want to use the port, but c'mon. Unsafe is always more fun :D !! See, in almost every currently-used computer LPT1 resides at 0000:0378, and LPT2 at 0000:0278. This means that in pretty much every case we'll encounter, our data register for our port (we'll assume we're gonna use LPT1) is at 0000:0378, status at 0000:0379, and control at 0000:037a. Awesome :) We'll use those.

Only one problem - since the release of Windows NT, direct access to these ports has been banhammerred for security reasons.

Ouch.

This is why most emulators are written for DOS (told you I'd mention it later). But I want WINDOWS. WINDOWS!!!

So, we need a kernal mode driver. Once again - I either find a free one online, or a write my own. Luckily though, in this case, the guys at http://logix4u.net have developed the perfect .dll to get around this issue: Inpout32.dll. This .dll has a pretty simple architecture: on load, it checks if we're running under Win9x. If so, no driver is necessary. Otherwise, it automagically installs a very lightweight driver itself and directs all port processes through that. The only change then to the code is to use this .dll instead of direct writing to the ports. This sent a red flag in my head: SLOW BLOATWARE ALERT. But nope!! These guys did quite well. The source code to both the driver and the .dll are included in the .dll package. A quick glance at the [very clean] C code reassurred me that this is a great .dll :) . Awesome work, guys.

So now I have a simple way to code for the port and I have the pinouts. What's next? I'll tell you: my first real soldering project!!

I decided I'd make a little board to test the port :) Nothing too fancy...just need to display the control register with 4 LED's and wire 4 switches for the status register tests. Awesome :) .

Now, you may have noticed that I didn't include the data register or the 3rd status bit...this is because the XE1541 doesn't use these...not only that, but it made the project more lightweight and easier to build. The concepts are the same so I figured no extra work was really necessary. Besides, until my actual cable arrives from Europe (I ordered it on Dec. 27th, my birthday hehe), this should be more than enough to hold me off.

I took a trip to Radio Shack and bought myself a wonderful little soldering iron, solder, a male DB25 connector, a basic printed circuit board, and some helping hands. The rest of the stuff I had around since I like to play with a breadboard :) . I then did a YouTube search to find out how to solder, and sure enough, found this wonderful video, which was all I needed:

Wonderful :) Anyways, I'm rambling quite a bit, so I'll just post some pictures of the project. Sorry for the crappy quality, too...took them with my cell phone:

So, yeah :) . Not too complicated, in fact ridiculously simple...but I had tons of fun making this :) . Now, I must admit, I'm pretty tired, so I should head to bed...next time I'll talk about programming and testing this little bugger :) .

Goodnight!

Adventures in LPT - Part I

2009-12-31T23:18:00.000-08:00

An integral part of cross-developing for any platform is obvious: how do we transfer our work to the real hardware?

In the world of the Commodore 64, a few decent solutions have been proposed:

1. Install a 5.25" floppy drive into your PC.

2. Create a C64 cartridge that emulates a C64 disk drive and takes an SD card (or similar) as input.

3. Create a cable to communicate between the C64 and a PC.

And yes, there are others that I didn't mention. But by far, my personal favorite is the third option. But what kind of cable do we use, and how does it work?

A few cables have been designed, my favorite being the XE1541 cable, invented by Nicolas Welte and Wolfgang Moser:

This image from http://amigakit.leamancomputing.com/catalog/images/1541-transfer-cable.jpg , if you didn't catch the watermark ;) .

This cable connects the 6-pin serial DIN port on the C64 to a standard 25-pin LPT (Line Print Terminal) on a PC. In this way, the two can be connected in such a way that the PC will act just like any peripheral device that could be connected to the C64. Specifically, we can write a program for the PC so that it will act exactly like a CBM 1541 floppy disk drive (or any C64-compatible floppy disk drive, really).

Astute and/or experienced readers will notice something. The C64's port is serial, but the LPT is parallel. How can this be, and why wouldn't we just connect the right lines to a serial COM port on the PC?

You have to remember here that the C64 is over twenty years old. The significance of this is that the transfer rate of its serial port is WAAAAAAAAAAAAY slower than that of modern COM ports. In addition, there are lines in the C64 serial port that can't be checked with a modern COM port without direct pinout control. This means that with hardware-controlled serial encoders and decoders on the COM ports, we can't slow the PC's connection down enough to effectively communicate with the C64. However, we can connect certain lines of the C64 to corresponding control and status register lines of the LPT. In this way, we can connect lines that weren't available to us by using a COM port. More importantly, though, we can simply continuously output or poll with correct timing the necessary values to/from the C64.

That's all for now I think :) . In the next parts of this series, I'll get into the specifics of the XE1541 cable, with schematics, some connector pinouts, etc :) . For now, wish me luck, as I finally submitted my MIT application! Also bring on 2010...YUP's got some big things planned; are you ready? ;)

YUP Commodore 64 Demo - Introduction

2009-12-31T03:14:00.000-08:00

Yes, it's true. The demoscene's youngest group is making a demo on the demoscene's oldest machine :) . Why, you might be wondering?

1. The C64's CPU is a MOS 6510. It's basically a 6502 but with an extra 6-bit I/O port. The instruction set for this ~1mhz tiny titan contains only 56 instructions (mostly 8-bit with some [limited] 16-bit support; as was the case with many microprocessors of its time) and very few addressing modes...not to mention a wonderful list of illegal opcodes supported by many assemblers out there :) . This is an extremely nice little processor to program.

More info on the MOS 65xx processors can be found here: http://www.masswerk.at/6502/6502_instruction_set.html

2. The color palette is completely different from most of the 8-bit computers at the time. Most of the C64's competitors used a typical "generic" 8-colors-at-two-brightness-settings sort of palette, just like in less-recent versions of MS-Paint...also like the Sinclair ZX Spectrum, whose palette can be seen here:

But strangely, when the C64's video chip (the VIC-II) was designed, they completely threw out convention and went their own unique direction for colors...well, except for black and white :) . This lovely palette can be seen here:

Thanks to the guys at http://www.retro-sanctuary.com/ for those images, by the way.

3. Well, um...I don't really have a third reason. I guess I could admit that I have a soft spot for vintage computers...but that's too cheesy, right? :)

So, yeah. We're doin' it. And no, we're not coding it for PAL machines, because I'm from the US where NTSC is the only way to go. Progress has been painfully slow, as [thus far] I've done all the development myself. This includes music, code, and graphics (if you'd even call crappy hardcoded bitmaps graphics)...though, I'm proud to say I've managed to do some nice technical things that most beginners in the C64 scene are too afraid to even attempt :) . All in all it's been a fun ride, except for music developmet. Mainly, this is because the only cross-development tracker for the C64 currently is a program called GoatTracker. Originally, it was written for DOS, and later it was ported to Windows, taking its confusing and dated user interface along with it. Maybe I'll end up doing my own someday to make this process more bearable. On the code side, I've been using Notepad++, C64Asm, and batch files for assembling. This works pretty well..though I'll most likely switch to an assembler like ACME, which supports scripting so I won't have to unroll speed-critical loops by hand. I suppose a couple screenshots for you wouldn't hurt, either:

...Nothing too impressive, really...mainly because I really didn't show you much at all ;) Not to mention that first screenshot is nowhere near finished...but I like the colors, so why not show it? :)

I suppose that's all for now. Wish us luck in finishing this beast someday :)

New Blog!

2009-12-31T00:58:00.000-08:00

Hey guys, Ferris here. After [far too much] nagging by [too many] friends of mine, I finally started a blog. Within a few days here you'll start seeing some progress for many of my current projects, including a new 4k synth system, a Commodore 64 demo, and more. For now, I'll spend several hours (or at least until my lappy dies on me) perfecting the layout; though we all know as a scener I'll never be truly happy with it ;) .