Hey. I do a lot of stuff. I do this:
- Upload my thesis versions and write essays on my blog: bootlickers.party
- Vlog on YouTube: www.YouTube.com/JollyCommunist
- Run the Hip Hegelian Memes Facebook meme page: www.facebook.com/goodoldhiphegel
- Develop Homebrew Communist Atari 2600 Games: http://atariage.com/forums/topic/269750-sierra-maestra-an-early-wip/
- Run an Educational Blog on Atari 2600 Programming: http://atariage.com/forums/blog/703-vidaks-blog/
- Run a Bl
Just checking in here after a really exhausting 48 hours after arriving back in my home town of Perth, 4000km away from Sydney, where I live now.
I think I can finally relax after driving 200km yesterday and then another 200km today. We were meant to be staying in Collie, 200km south of Perth, in the country. That's where my sister in law lives.
It turns out their dogs hated my dog, and we couldn't stay there, so we had to drive another 3-4 hours back up to Perth. It was very stressful.
The new Star Wars movie is amazing. It has inspired me so much. I felt like I was getting tired of programming, but seeing Luke Skywalker really picked me up and made me feel so energised.
It is such a good movie. I enjoyed it IMMENSELY.
I am in the process of making an Atari 2600 game. I have been given a lot of support and shown a lot of kindness, even at this very early stage. So I wanted to give back in a small way. In this blog post, I will make five arguments for why you, someone who has never done programming before, should get started in making homebrew games for the Atari 2600. This also applies to the 5200, and the 7800 -- and perhaps even to the Atari 8-bit home computers.
Development is Easier Than It Has E
Okay! So I think I have mastered how to draw the kernel that SpiceWare outlined in StayFrosty. If make sure you read all of the blog posts under the #5 heading so you understand what I am talking about. Remember this his how the main player character is drawn in the kernel:
ldy Heights+.SEC ... lda (FrostyImagePtr+.SEC*2),y and (FrostyMaskPtr+.SEC*2),y sta GRP0 lda (FrostyColorPtr+.SEC*2),y sta COLUP0
Despite the fact that I have always been obsessed with computers and programming, I have always been a novice at it. I only ever learned to program the simple programs you could copy out of magazines. The programming language I know best is 6502 assembly, but I started learning it 6 months ago. The next language I am most proficient in is Python. My level of skill is finishing the Code Academy guided learning tutorials. The subject area I am most proficient in is philosophy.
One thing doesn't add up in my analysis of how the Y Register in the Stay Frosty kernel is formed. This code forms the Heights variable:
ldy #SECTIONS*DATA_BYTES_PER_SECTION-4-1+2+2 ; -4 for the 4 unused platform bytes ; +2 for fireball size info ; +2 for level control init.plLoop lda (LevelDataPtr),y sta Heights,y dey bpl .plLoop
The SECTIONS constant equals 5. The DATA_BYTES_PER_SECTION constant equals 11.
Okay. I was off to the wrong start with my first kernel. On the WIP thread for this game in the forums we established what was really going on as Commando 2600 drew the screen. I will repeat the "discovery" here. Commando draws the screen in bands, what SpiceWare calls in Stay Frosty, "sections". So what we are able to do as we move down the screen is forget that we have drawn the playfield and Player1. This is one of the advantages of the 2600's "racing the beam". You are able to draw as many c
I looked up the specifications of the 7800, the NES, and the SMS.
The 7800 is amazing! It can draw many more sprites on screen than the SMS and NES can. It also has a much larger palette of colours than the SMS and NES.
What amazing hardware! I suppose the only drawback is the sound chip, which is virtually the same as the 2600 - but honestly I couldn't care, I love the 2600 sound the way it is.
I figure posting on here is better than clogging up the forums. I'm learning a lot by constructing my own kernel. I suppose the first thing to mention is that if you are drawing an asymmetric playfield, you MUST consciously draw the playfield every line. You are forced to update it every line, otherwise the right half will be displayed on the left by the time the beam comes around on the next line. You can have a 2-line resolution, as in a playfield that has its graphics changed every two li
So I'm running out of time in my current draft of my kernel. This is what I'm trying to achieve by using SpiceWare's Collect tutorial as a framework: Preload:
Blank Playfield and load scanline index Y (13 cycles)
Load playfield scanline colour (8 cycles)
Load Player0 graphics (18 cycles)
SLEEP 15 for timing of left side of playfield (15 cycles)
Draw left side of asymmetric playfield (PF0, PF1) (16 cycles) (70 cycles total)
I decided to go into the city today and work from a Starbucks. It's a very different experience than the library. Homeless people frequently come in asking for money. I feel better about coming here than the posh Sydney University library because that way I can give my change to people who need it. I remember reading an article on why you should give money unconditionally to homeless people, so I'm happy I've made the change. Anyway today I'm gonna try and get a nice big bulk of the work nee
I have just been told about the website 8bitworkshop.com! It's amazing!
I feel like writing a kernel for an Atari 2600 game is a lot easier than I originally thought.
Everything seems so cryptic when you first get into 2600 programming. As soon as you grasp that everything is about drawing the screen line by line, it becomes a little clearer.
Looking at other people's code is a must. I don't think I would have learned as much as I have without reading the code of past masters.
This is the game I am developing where the main game mechanic is like "snakes with guns".
So I have learned how to write to the Playfield register, and how to count scanlines.
So now I know how to do that as well as load player graphics from tables. I also learned how to load graphics using a pointer. By using LDA (ZP),Y I can point to whatever table of graphics I want to.
I have also learned how to position graphics on the Y and X axis.
One thing I still need how to learn how to
After a day working on Commando, it's proving very confusing.
The disassembler has obviously scrambled all the variable names, labels and routine titles.
Maybe tomorrow I will start posting snippets of code on the forums and ask for help.
I know what some of the most important variables are, I just can't seem to work out what any of them are doing.