I was expecting also for this class another “day one syllabus review” day and was pleasantly surprised to see we skipped this boring tradition today in both our LAIR classes. For HPC Fundamentals, also known as HPC 1 or even hpc0, we discussed how in UNIX/Linux we learned how to use Linux as user's and in this class we will be learning how to administer a Linux system. We will be setting up 'Linux from Scratch' which is building an entire Linux setup from all source code on our own desktops that we set up today. Today we all claimed desktops in the LAIR, tore apart the one whole “laptop pod area”, disconnected everything there, and then grabbed our own towers to setup. We had a little 5 minute (well Matt said it was going to be 5 minutes it turned into maybe a 30 minute) overview of PC hardware for those of us with less experience with hardware. We looked at all the major parts in the PC: CPU, fan, heatsink, power supply, RAM, video card, PCI slots, hard drive, motherboard, optical drives, etc. We took out RAM, put it back in, upgraded RAM, took out and put back in a video card, some of us put in a hard drive. After we were done with all this, we plugged everything in, claimed monitors, keyboards, mice, etc, and made sure our system worked. Most people didn't get to setting up an OS on it yet. Me and some of my guys did however. I installed Arch Linux on my desktop I claimed and have that functioning before I left the LAIR today.

In today's class, we looked at how to reset the BIOS admin password with the jumper on the motherboard and discussed jumpers in general from older PC hardware days. Once all of us had admin access to our machines BIOS, we poked around in the BIOS to see the information it gives us about the hardware. Also about how to enable and disable various boot devices, different SATA devices like the hard drives, optical drives like cd and dvd drives, old floppy disk drives, and even network boot options, PXE Boot. Then other students set up a partition scheme that roughly went 72 GB for a root partition, 8 GB fro a swap partition, and another 80 for free space for Linux from Scratch and any other future uses we may need. Other students installed their linux distros to their machines and I helped where applicable. I spent quite a bit of time helping a couple students get their dual monitor setups working, ultimately by setting up an xorg.conf file at /etc/X11/xorg.conf. Beyond that I taught a couple students how to update the system, search the repos for packages, and install packages, a very quick package manager overview. We spent the rest of the time just customizing our linux distros to our personal liking.

Today we actually started looking into Linux from Scratch. We went to their website:

http://www.linuxfromscratch.org/

There are now two versions, the old version and the systemd version. Matt spent some time describing the difference. When I attempted to do a Linux From Scratch myself a couple years ago, there was only the older version. I attempted it on a virtual machine and it failed to compile when I got to the toolchain, this time I have more linux experience under my belt, and we're doing it as a class, and I have someone who's done it successfully to refer to if issues arise, so I feel confident that I can pull this off. So we talked today about the old version of booting from a series of shell scripts and the System V and BSD way of booting up the system. Then we discussed how systemd has came in recently and its controversy in the Linux community. Since systemd worked well with bootup, some are looking to have it do more, which violates the UNIX philosophy we learned last semester of “Do one thing, and do it well.”

So the class chose which version of LFS they we going to use and then either grabbed the pdf or started looking through the html for the Linux From Scratch, which is essentially a book containing a list of instructions. We all started reading. I actually checked manually every host system package version requirements manually before seeing and remembering that there was a script that would do that for you.

#!/bin/bash
# Simple script to list version numbers of critical development tools
 
export LC_ALL=C
bash --version | head -n1 | cut -d" " -f2-4
echo "/bin/sh -> `readlink -f /bin/sh`"
echo -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-
bison --version | head -n1
if [ -e /usr/bin/yacc ];
  then echo "/usr/bin/yacc -> `readlink -f /usr/bin/yacc`";
  else echo "yacc not found"; fi
 
bzip2 --version 2>&1 < /dev/null | head -n1 | cut -d" " -f1,6-
echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2
diff --version | head -n1
find --version | head -n1
gawk --version | head -n1
if [ -e /usr/bin/awk ];
  then echo "/usr/bin/awk -> `readlink -f /usr/bin/awk`";
  else echo "awk not found"; fi
 
gcc --version | head -n1
g++ --version | head -n1
ldd --version | head -n1 | cut -d" " -f2-  # glibc version
grep --version | head -n1
gzip --version | head -n1
cat /proc/version
m4 --version | head -n1
make --version | head -n1
patch --version | head -n1
echo Perl `perl -V:version`
sed --version | head -n1
tar --version | head -n1
xz --version | head -n1
 
echo 'main(){}' > dummy.c && g++ -o dummy dummy.c
if [ -x dummy ]
  then echo "g++ compilation OK";
  else echo "g++ compilation failed"; fi
rm -f dummy.c dummy

and the code to check for library consistancy:

#!/bin/bash
for lib in lib{gmp,mpfr,mpc}.la; do
  echo $lib: $(if find /usr/lib* -name $lib|
               grep -q $lib;then :;else echo not;fi) found
done
unset lib

We then partitioned our free space on our hard drive, mine is at /dev/sda4 and created the filesystem on it with:

mkfs -v -t ext4 /dev/sda4

in my case I have ext4 on a 40 GB partition for LFS at /dev/sda4. We then mount the partition with:

mkdir -pv $LFS
mount -v -t ext4 /dev/sda4 $LFS

I already have a swap partition in use by the host operating system (Arch Linux) which is all we need. You only need one swap partition per system, as every linux distro on that machine can all use the same swap partition for swap space.

Then we set up a variable for the mounted partition, and we can put this command in ~/,bash_profile to ensure this is set up each time we startup:

export LFS=/mnt/lfs

And now we make a directory for our source files called sources:

mkdir -v $LFS/sources

We then change permissions on this directory and enable the sticky bit:

chmod -v a+wt $LFS/sources

Then we grab the wget list with:

wget http://www.linuxfromscratch.org/lfs/downloads/stable/wget-list

And then grab the md5sums for those downloads to verify their integrity:

wget http://www.linuxfromscratch.org/lfs/downloads/stable/md5sums

Then to download all of these we run:

wget -i wget-list -P $LFS/sources

Then run:

pushd $LFS/sources

and then to check the md5sum:

md5sum -c md5sums

Today I moved into actually compiling packages for the initial toolchain on Linux from Scratch. I completed binutils (1st pass) then compiled gcc (1st pass) then I compiled Linux-3.16.2 API Headers and glibc packages.

At this point you do a sanity check to make sure everythign is working right at this point, and mine was passed this check at this point.

I then build libstdc++ and moved on to the 2nd pass of binutils which fails in the cofiguration phase. We spent hours trying to troubleshoot this issue and I even went back and rebuilt binutils 1st pass with patches applied and then gcc 1st pass with patches applied and again it passed the sanity check. But also again when I reached the 2nd pass of binutils it fails on cofigure. I have yet to find any web posting of someone else who is having the exact same issue as I am and has a resolution. At the end of the day we decided that when I was checking my host system OS (Arch Linux) required packages and versions, that i had all of them and at least the minimum requirements, but a couple of my packages were beyond the recommended highest version (too new).

So one thing a started to attempt to do was build an older kernel from 2.6.32.65 when I was runnign on Arch 3.18.4-1, I downloaded the tar,gz, extracted it, then ran make mrproper, and make menoconfig, then make this compiled fine then went to run sudo make modules_install, this phase failed… At this point I feel like I'm hitting a bunch of walls and getting frustrated. This project, due to the machines being shut off at the ned of the day, i can't ssh in and do any work on this over the weekend, so this project is effectively on hold until Tuesday, before I cna even attempt to solve anything.

After another day of banging my head against the wall on my Linux from Scratch installation, I may have just made headway. I started today abandoning the quest from last week of tryign to recompile from scratch an older version of the linux kernel a la 2.32.65 and downgrading certain utilities because I was using a bleeding edge distro like Arch Linux. Over the weekend Matt had gave a link suggesting that the MAKEFLAGS option may be the culprit, and even now I'm nto positive thats what may or may nto have done it, but I set that from:

export MAKEFLAGS='-j 2'

to:

export MAKEFLAGS='-j 1'

and tried rebuilding binutils gcc and glibc, and things still failed at the same point. I did a memtest and left that runnign while I went to lunch today, which passed fine, so the memory is good. Then my frustration with it got to the point where I decided I'm gonna just reformat the whole partition and start from scratch. I purposely didnt set any MAKEFLAGS variable at all this time. Also I left the machine at the LAIR compiling, inside a tmux session, so I ssh'd into lab46 and into my Arch Machine doing the LFS build from, and attached to said tmux session and have been workign on it from here at home as well. Just now got past the point I kept failing at, which makes me excited to finally be past that hurdle adn be able to continue building my Linux From Scratch build.

Today after leaving my machine on and all my building of Linux from Scratch running in a tmux session from the host operating system, I had been building packages on the chroot system, the final builds laste into last night and in the morning and all day today. I had one hiccup in the process today. When i got to the util-linux package it failed some of the checks sayign it couldn't find mkfs.ext2, Matt and I went searching int he systema dn in fact could not find this in /bin, /sbin, /usr/bin, /usr/sbin, etc. and so I had to go back and redo the entire process for just the e2fsprog package, configuring, compilign and installing, then I came back to util-linux and started over on that package build and then everything went smoothly, I verified that the file it was looking for that we previously couldn't find was in fact there in /sbin after the fact, After that everything went off with out a hitch. I got to the part where we start configuring the system (Chapter 7) and settign up like /etc/resolv.conf, /etc/fstab, /etc/hostname, etc etc etc. Then here from home I finished up the linux kernel and modules compiling and copied the kernel and system map files over to the boot directory. I opted to NOT install grub from within Linux From Scratch system and just use os-prober with Arch Linux to have it pick up the Linux From Scratch system. However, my usual command:

grub-mkconfig -o /boot/grub/grub.cfg

On the Arch Linxu system stated that grub-mkconfig didn;t work with Linux From Scratch systems, so I just manually made a grub menu entry for the Linux from Scratch system in the Arch GRUB bootloader. Now I'm done with everything but I can't test it to reboot to see if it works and if my Linux form Scratch system is bootable or not until Tuesday, as thats the next time the LAIR is open for me to see if the system works. I'm lookign forward to find out, it would be my first functioning Linux From Scratch if it does, which is really cool. I havent decided if I want to try to pursue adding things like xorg and whatnot on this system afterwords if it is working, or if I want to now try to do another Linux From Scratch doign the systemd one. I guess I'll make that decision after I know the status fo this one fully. Until then…

I got into the LAIR first thing this morning at 8:00 AM, eager to reboot and test my long sittign and finished Linux From Scratch Build to see if it in fact works. Upon reboot, it said it couldn't find the kernel, somethign to the effect of /boot/vmlinuz-3.16.2-lfs-7.6 I booted back into Arch Linux, the host operating system and started looking at the grub configuration, noticed I had to root set to /dev/sda2, when my LFS is on /dev/sda4, changed that, saved and then rebooted again, same error, couldn't find the kernel at /boot/vmlinuz-3.16.2-lfs-7.6, rebooted again back into Arch, looked at Arch's own grub entries and noted the line:

set root="hd0,msdos1"

this is because arch is on the first hard drive hence the hd0, ant hen the boot partition i made is partion 1, which the next part doesnt follow the starting with zero convention, so msdos1 means partition one. So I added to my LFS boot entry, the line:

set root="hd0,msdos4"

as my LFS is on /dev/sda4, THEN it boot up. Which was exciting for me as I've never successfully done a Linux from Scratch build ever until now, it boots means that it works, now that I have a foundation…I aim to build on top of it. First of all it wasn;t recognizing my network setup, in the LFS book they have you configure a /etc/sysconfig/ifconfig.eth0 I knew Arch was calling the ethernet network card enp0s25 so I figured I'd start by trying that, so I made my file /etc/sysconfig/ifconfig.enp0s25 and set it to start on boot and saved it. This still failed. Later when Matt came in, I also showed him that running ifconfig wasn't showing the network card, we tried lsmod, dmesg, etc, nothing was showing the the network device, so Matt suggested I try reconfiguring the kernel, in kernel config we found the Intel Network devices and enabled another one. Ran the usual make, and make modules_install and copied over the kernel and system.map files over to the boot directory. This time it did notice the network card when I ran ifconfig, but still no internet. The enp0s25 configutration file in /etc/sysconfig was still set to gateway at 192.168.1.2. Dan Sahdeck helped me get this set up so that it went to 10.80.2.1 and setting the IP address, which for now we set to 10.80.2.243 after this my internet worked. And I was happy. :) Thanks, Dan!!!

From here I decided I wanted to get ssh and tmux running on this so that I coudl remote in and start building things like xorg and whatnot over weekends, break, etc. I looked up the Beyond Linux From Scratch Book (BLFS) and noted some of their packages, and decided first I wanted to get links and wget. I ran into some dependencies when encountering this, like wget recommends openssl and links suggests gpm if you want mouse support, which i don't necessarily need but I was like meh. So I grabbed the source for wget, ssl , links, gpm, and the openssl patch file. I downloaded those to my arch system then mounted the LFS and copied them into my /sources directory and then unmounted and reboot back into LFS. I had to start with openssl, and up until this point I had been copying and pasting commmands (liek eeryone else) from a GUI web browser to the command line of the chrooted system. Now I had to manually type in all the configuration options and patch the thing, make it, install, etc. After openssl I did gpm, then I got links set up and then wget. I tested wget by grabbing the openssh package and later the screen package (both actually in the BLFS list of packagfes with explicit directions on setup) sadly tmux is not on that list. So I started by getting openssh working, adn verifying that I can remote login to that LFS machine, and I could. Then I built screen, which also worked after finishing the process. Then I figured, I want tmux, don't care if its not in any of LFS or BLFS lists of packages. So I grabbed the tmux source, untarred it, then tried to configure, it failed cause it couldn;t find libevent. So I DID find libevent in BLFS's list of packages, wget that source, untarred, configured, make, and installed. Then I went back to tmux, reconfigured and it worked, make, and make install. Then I had a functioning tmux. Symlinked it back to /usr/bin and now I'm ready to rock, which is exactly where I was when I left today, but as I write, I'm remoted into said machine attached to the tmux session I left running there. What do I want to compile and install now?

Today in Linux from Scratch I decided to get git all set up which depends on curl and python 2.something. I got the source tarball, extracted it and the configuration worked fine, but the make resulted in nothing, which is odd. Usually at this point its actually compiling and tons of things are flying by but I get nothing, its not even like its not a command because if it wasn't then it would complain that make wasn't a command. We perused the config.log, the Makefiles, etc. Initially I thought it was just this package but I tried doing a few other packages like python 2.<whatevergitneeds> and dhcp and both of those ran into the same issue. So something is very wrong with my make on my Linux From Scratch. I spent the rest of today googling, asking various people at the LAIR like Matt, Shawn, etc. I even went to the public IRC support channel on #lfs-support on irc.freenode.net to ask for help, and ultimately still a dead end. The dream is over…at least for today. I'm half wondering if I want to leave the LFS up to try to FIX it as is (which is the ideal goal) or leave the host OS (Arch Linux) up so that I can reformat and just start all over again, this time cloning the partition once I get to a bootable Linux From Scratch, so that at worse, if something like this occurs then I can rollback to the earliest bootable Linux From Scratch build. But I feel like this is cheating and/or taking the easy way out. IF at all possible, I;d like to figure out how I can repair/rescue/resolve this problem on the current Linux From Scratch build.

Today most of us copied over Tyler's state of /tools and /sources to our systems to “catch up” I actually copied this stuff over as well. But since then I decided I'm just gonna redo the entire LFS, because I don't expect the others to finish from where Tyler has injected his state of his LFS to others. I think, being that I have sshon my host OS and tmux and such, I can run a whole new LFS set up (assuming I don't hit any snags) before everyone else has theirs fully funcional. Because I'm doing stuff now from home, at 9:20 PM, even while writing this up, while others are at home watching Netflix, actually I'm doing all of the above right now, watching Netflix, redoing LFS on the arch lair machine, and writing this opus entry. My point is I might be able to get it done by Thursday, but if not I can definitely finish it before next week, and I'm banking on the idea that everyone else is gonna finish all of their LFS builds before that. I just found out this week that we all need a working LFS system like ASAP, so that we can start doing stuff on top of it. Had I known we were moving to this state immediately after break, then I probably would have abandoned my trying to “fix” my old LFS make broken issue, and just redid the whole LFS over break, but oh well…doing it now…again…from the very beginning, I just reformatted the partition that had LFS on it.

I didn't come in today because:

Today in HPC0 a.k.a. HPC Fundamentals, we started lookign into our next steps beyond the Linux from Scratch build we have been working on for a while now.

On a side note my 2nd complete Linux from Scratch build booted successfully this morning, so I've done the vanilla LFS book from start to finish that resulted in a bottable LFS system twice now (thanks to the earlier make breakage issue I had before break.) The only issue I had, which I had to consult Matt on, was that upon bootup I got a nasty looking error that stated that it couldn;t initialize the Linux console, which I assumed meant I wouldn;t be able to login, but I was able to login in as root and tinker with files. Namely one source of complain was at /etc/rc.d/rcS,d/s70console After a lot of digging around and rebooting many times, we discovered it had come down to one file that I had set the keymap to “en_US.utf8” when it sould have been just simply “us”, which surprisingly I didn't make that mistake the first LFS build but I did make this error on my second LFS build. So now I'm at another stage with a fully functioning and finished LFS book state, I haven;t ventured into BLFS yet, debatign about clonign the current partition before I tamper with it so that I don't have to do another LFS build.

Since now, more and more of us are finishign up the LFS aspect, Matt started talkign abut what wer are doing next which include a couple things: doing a BIOS update on our machines, which incidentally are usually windows executables, which will requires us to have a runable DOS or something on a USB? I think I was a little unclear as to how exactly we were doing all that as we spent more time today talking about our other venture, setting up our own subnetorks. Matt called these two tasks “Sidequests” for the record.

I personally have little to no knowledge of networking stuff as I still haven't taken Networking Fundamentals, but apparently this might be a good thing. So Matt defined a few terms for us today. A gateway is the portal between 2 differnet machines sending packets, more specifically between two different mediums of transferring information, like from ethernet to cable line or something along those lines. On a network could be a bunch of routers, and the gateway would be one of the routers that all the data passed through going out or in. A subnetwork or a subnet is really what people mean when they refer to a network. We spent some time discussing IP address. There are 4 subnets at the LAIR. We have 10.80.1.0/24 which is the one juicebox router handles at lair.lan, 10.80.2.0/24 which caprisun router handles at offbyone.lan, and 10.80.3.10.0/ which the projects.lan is on that we all can have our own subnets from. When we see an IP written like 143.66.0.0/16 the “/16” refers to the masked IP addresses 16 out of 32 bits are masked, leaving 16 bits available, which results in 65,536 available IP address, this incidentally is how many CCC has allocated to them, cause I wrote it down cause I thought this was interesting. The mask blocks these IP's octets?(is that the right word?) Matt showed us a couple commands tracerout and netstate -nr to get some information:

traceroute

netstat -nr

In the event of say a 10.80.2.0/24 then 24 bits woudl be masked out of the 32 bits, and would leave 8 bits usable for a total of 256 available IP addresses. The IP bits would look like:

11111111.11111111.11111111.00000000

where 1's are masked and 0's are usable bits for the 256 possibile bit patterns. The above would have the netmask of 255.255.255.0

Another example would be 10.80.2.0/29 which would have 29 bits of the 32 bits available used, which would leave 3 bits available for 8 possible IP addreses which would probably be the lowest you would bother to go for a subnet. So in the event of say 8 availabe IP addresses the first IP is actually unusable as it is your network address. The last IP address in your range of the subnet is also unusable as its the network broadcast.

At this point we all got router logins for the projects.lan subnet's router which is located at 10.80.3.1

My personal subnet is the range 10.80.9.16 to 10.80.9.23

The 10.80.9.16 is my network address and thus unusable and the 10.80.9.23 is my network broadcast and also unusable. Currently lfs-lair machine is set to be at 10.80.9.18 as its IP address. My subnet mask is 255.255.255.248

Some of the files on the router we need to edit to change these settings are:
/var/names/master/projects.lan

in here we have the machine name like:

lfs-lair IN A 10.80.9.18

Another file we need to edit is /var/names/master/10.80.3
which is like a reverse lookup in the stucture:

10.80.9.18 IN PTR lfs-lair.projects.lan.

Note that DHCP requires that that line ends with a period.

Then we need to add the relevant stanza into the file:
/etc/dhcp.conf
which we add the MAC address of the machine to…I think.

We then can update this configuration with a command (that may take am inute to go into effect):

confupdate all

Very interesting day today, but I had to leave at noon, but I may need further questions to clarify a couple things.

For HPC Fundamentals for those of us finished with our LFS builds, we didn't actually do much as we need to get the subnets hooked up and working properly and to do that we needed cable that we couldn;t locate today when we had the time to try to resolve that. I helped Casper finish up his LFS build and get it booting, making him I beleive the 4th person to finish up their LFS build in our class and have it bootable. I look forward to moving on with this next week.

Today we officially switched over the network on the station most of us have our LFS machines on (which we included Casper into that subnet) and ran his thernet line into our switch. Upon rebooting I found Arch successfully had internet again, this time on my own subnet that we had set up last week. I rebooted into Linux froms cratch and after some tinkering, I fixed my LFS machine so that it operates too on the subnet. Which my problem was that I had teh gateway going to the projects router on 10.80.3.1 in my /etc/sysconfic/ifconfig.enp0s25 file, when it shoudl just be the first address in my subnet 10.80.9.16 through 10.80.9.23, whereas 10.80.9.23 is my broadcast address, 10.80.9.16 was my network address, and 10.80.9.17 was my router and gateway address which I set in the file, making that machines IP address 10.80.9.18. Once that was all good, I had a working internet connection on my LFS machine on my subnet at the LAIR.

After this I proceeded to look into a BIOS update for my LFS machine which is a Dell 755 and found the BIOS version to be A10 from 2008. I received a USB drive from ahoover with the correct update files for my machine on a dos flash drive, so I rebooted my machine to the USB drive and updated my BIOS to version A22 from 2012, reI set up and buiturned the flash drive and rebooted back to LFS system.

I then started building a few packages on my LFS machine again. I set up and build openssl and wget right off the get go. After verifying both of those were good, I grabbed links and ssh and set both of those up. LAst thing I build on my machien was tmux, which isn;t officially on the BLFS, but I grabbed the source from sourceforge and configured it to find it needed libevent, which IS on BLFS, downloaded and built libevent then finished tmux, so I'm pretty much back to about where I was when I lost my original LFS build. Everythign currently is still working. I was just planning on scrutinizing evreythign a little more closely at this point to make sure I didn;t repeat what I did last time.

I didn't actually work on anything related to HPC Fundamentals or my Linux from Scratch Build today. Instead I worked on some fallen behind math homework I had built up, and made a little progress on that. Also worked on writing up an instruction for HPC Sys & Net class for the NES simulator, 0x60 RTS Return from Subroutine. I also started looking into some Java books on pdf with Dan to try to learn some Java to help us with Joe's class in Comp Org and when Casper showed up we tried writing up a Nand class and RsNandLatch class. I still have my LFS machine on, with working ssh, wget, and tmux, so that if I choose I can work on more LFS stuff remotely as needed, like over the weekend, but ultimately I'm behind on other things so they will probably take precedence.

Today people not finished with LFS continued to work on LFS. We also have a side project of us all expressing our opinions and our eelings of how important the LAIR is to our education on posterboard for something to present to the college president and their minions. I kind of want to know what role my LFS machine will play in the future so that I could start grabbing dependencies and building towards that role. If we don;t attend the Ithaca Ed Tech Show thing on Thursday perhaps I'll choose a role for my LFS and just start building towards it.

Today I added a regular robgraves user and the group wheel to the LFS system, adding robgraves to the wheel group for future purposes. I'm planning on adding git an mercurial as well today, if I can get the dependencies and everything to work out as planned. I just finished successfully gettign git installed and mercurial in addition to the unzip package. Mercurial worked out of the box, whereas git complained about local SSL, will have to look back up the error message. Also just added zsh and fcron successfully. Installed nmap and its recommended dependences: libpcap, PCRE, and liblinear. Nmap appears to be working. And now added traceroute which is also working.

I'm actually at a point right now with both of these two LAIR classes on Tuesday/Thursdays, where I'm not entirely sure what to do. In this class, HPC Fundamentals, or HPC0, I have had my LFS system up and running from nothing to fully bootable twice after the make breakage. I've been slowly adding smaller thigns like openssl, openssh, tmux, links, wget, git, and mercurial. I feel like the end goal was that each of us was to pick a role for our machine and build it into a machine that does that job. I just don't know one, if that job or role is beign picked for us, or two if we should wait until everybody else catches up. But I've been slowly adding things but not growing towards this larger role. I'd like to start taking it towards the larger role.

Today in HPC0 we talked about how LFS is mostly over. We CAn opt to install virtualbox on LFS, and I still might in addition to installing xorg and maybe i3, but I currently made sure I have virtualbox installed on my arch installation at the lair. Dan and I started creating our virtualbox VM's with Debian Wheezy 32 bit, setting our VM's for the cluster we are going to start building, with 512 MB of RAM and 8GB dynamic hard drive. Bridged Network connection. We have the host name set up as ws#, ws0 was dan's vm, ws1 is mine, and ws2 is caspers. From here we are installing debian onto these machines for later use after the break.

Today we worked on getting Debian set up on Virtualbox on everyone's machines for the cluster.

I missed this day due to being in the hospital, etc.

I Think today we started talking about NFS and how that works and how one of us was going to set that up on our cluster VM.

I missed today as well.

Once again, Matthew Haas made a first day of classes more awesome than most by not doing the usual syllabus review day. We dove into (being a once a week class, we'd have to dive into something today) the main collaborative project we will be working on as a class, which is creating an NES emulator. Located and cloned from:

Locally from within the LAIR:
http://www/hg/project/nes-spring2015

And from anywhere else:
http://lab46.corning-cc.edu/hg/project/nes-spring2015

We started today discussing the components of a CPU, the Central Processing Unit. These consisted of:
1)Register Array
2)Control Unit
3)ALU

1)The Register Array is where variables that are stored in RAM go as the CPU only pays attention what's in the CPU's memory which are called registers of a fixed size. Registers are fast and the CPU only processes what's in its registers. We might have 1 Gigabyte of RAM but say only a Kilobyte of registers.

2)The Control Unit interfaces with other things. The CPU is self obsessed and processes data and this is where interrupts come in, so the CPU continues to do its own thing until say a key on the keyboard is pressed or a button on a controller is pressed. At this point the CPU halts what it was processing long enough to process the interrupt.

3)The ALU or Arithmetic Logical Unit is where the instruction set exists. Whether it can read and write to memory or do math and has instructions for every possible combination.

The NES's CPU was a 6502.
We think of NES as 8 bit because of the size of its registers.

After cloning this repository, we looked at some of the files we have in the sim directory, and then into the etc directory , like registers.conf:

#
# registers.conf - define registers to use in simulator environment
#
registers {
	a:8
	x:8
	y:8
	f:8
	s:8
	pc:16
	mar:16
	mbr:8
	iom:8
	iob:8
}

flags { f:S,C,P,R,D,I,Z,O }

We looked at parts of this file. The “a:8” line has an a which is the register name then a colon then a number which is the size in bits for that register. This register called a with a size of 8 bits is the accumulator. More on this in a moment… The “x:8” and “y:8” are data registers which we can use to store information. Say we were going to add 2 and 2. If we have 2 in the x register and a 2 in the y register, the result (4) would be stored in the accumulator register.

Moving on we see “f:8” which is our flag register, this has 8 special bits list below in the file on the line:

flags { f:S,C,P,R,D,I,Z,O }

Each of these bits has a special purpose.
S-signed bit (for noting the sign of the result) for example: a=x-a if a=4 and x=3 the result would be -1, the sign bit would then be changed to reflect the negative.

C-carry bit, the example we used today was if adding in binary:

1111
0001+
--------
0000

Would leave an extra 1 being carried on the last column working right to left, which would end up being stored in this carry bit.

P-parity bit. This checks to see if say and even or odd parity might be shown and if it remains after transferring data across a connection, like 01110010 woudl have even parity because it has an even number of 1's.

R-reserved bit. Which manufacturers reserved for possible future feature additions.

D-half byte array? perhaps, we as a class need to investigate further into documentation.

I-also unknown currently to us as a class.

Z-zero.

O-overflow.

Now we move on in this file to “s:8” the stack register. Last thing put onto the stack is the first thing to take off. bytes of data can be pushed onto the stack. Data from one end and instructions from the other end in hopes that they never meet up. We can push an accumulator, push an accumulator, push an accumulator and later pop one from memory if we need it. Function returns are a pop.

Next we see “pc:16” which is a program counter. The NES instructions are 8-bit but it can access memory at 16-bits.

“mar:16” memory address register and “mbr:8” memory byte register go hand in hand. Like if we were writing, what is in mbr would go into mar. Some pointer like stuff.

Then “iom:8” and iob:8“ for I/O memory and I/O byte.

we reviewed a few of the other files in this directory: memory.conf, io.conf, instructions.conf (which is the meat of the ALU) this file contains hex codes with mnemonic 3 letter names to denote what they do. Like 0x69 ADC is an Add with Carry. Or maybe Add to accumulator. so it would read in one byte 0x69 and see that that instruction needs 2bytes and read the next byte in for say 0xff and add it to the accumulator. Then we have lines like “0x21:AND ($%OFFSET%,x):2:6” which is like a pointer. 2 bytes are read and then 6 cpu cycles are taken.

After discussing how we are going to attack this to start, it was brought up that we needed an AddandCarry program or function for a binary number, which I personally have already wrote in a couple languages while progressing my logic gates for Joe's classes. So I'm going to work with that to see what modifications I may need to do to make that work with what we are doing here. Also we were going to read over some of the specifications for the NES CPU which we found on a couple sites:

6502.org

nesdev.com

New files in nes-spring2015 repo do a pull with:

hg pull

NES runs MOS Technology 6502 CPU

ALU is going to use helper programs, shellscripts, C programs, provides fundamental addition technology

add.sh adds the contents of two source registers.

If register a.reg we'll only say a, only adds 2 things at once.

ALU/add.sh

if 3 things are added, adds 1st and 2nd then adds the 3rd to the result.

read in register data, convert to decimal

NEED someone to write reg2dec.sh “00001000” ASCII binary = reg

reg2hex hex2reg reg2dec dec2reg oct2reg reg2oct dec2oct oct2dec dec2hex hex2dec mem2reg regtomem

10 in decimal

echo 10 | dec2mem

00001010

we have add, need subtract, multiply, divide, and, or, not

Scripts CheckZero - find out if value is 1 or 0 SetZero - make a 1 ClearZero - make a 0

sign carry overflow parity

ZEROFLAG=“Z” bitops=numbits-1 8 bits has 0 thru 7 cut counts from 1 which is why pos=1

“01011110” bit# 2^7 2^6 2^5 2^4 2^3 2^2 2^1 2^0 cut 1 2 3 4 5 6 7 8

datamanip/hex2reg converts hex values to ACIII binary format 0xdeadbeef 16H

“This is all simple, but its gonna take a while to wrap your head around it” - Matt Haas

datamanip/stdout.c looked at again

datamanip/load.sh load from memory to register grabs a byte at a memory address, convert to register format and place in register.

check for invalid memory address check for invalid register return from memory memget script

store is its opposite

memory/memgetbyte.c argv1 path+memory argv2 memory address in hex argv3 bytesize if NULL assume 8 bits currently only works in 8 bits

for loop gets us to the byte we are interested in then get the byte something unreadable

registers/regdisp.sh displays whats int he registers

memory.conf 65536:1

sim various conf files instructions.conf io.conf memory.conf registers.conf simulator.conf simvar.sh

can mapa device to a memory address

ops/0x69 reg,reg mem,mem immediate indirect (pointers)

this is an immediate add and carry this will flip the signs of the bits: zero sign overflow carry

If accumulator is zero,set zero, else clear zero.

Today may have been the first time I've actually felt like I might actually get through this course. Up until this point I sort of had a deer in headlights look about this whole project and was uncertain as to not only how we would collectively obtain the end goal, but how the parts that make up the whole were comprised and how everything works together. An not to say that now every piece makes sense to me, I at least feel like I know we need to do such and such, and that I am capable of makign a solution to such and such. From here I just need to start claiming cogs in the giant machine that I can make and start actually writing up the code for these…as Matt says “By any means necessary” so whatever language or hackish way we can use to implement the features we need with no regard to performance.

Today we also added a few web pages to our arsenal of reference to tackle this project. Today we perused these sites to get better insight into the instruction sets we will need to implement for our NES simulator:

http://homepage.ntlworld.com/cyborgsystems/CS_Main/6502/6502.htm

http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=6502_Opcodes

http://www.obelisk.demon.co.uk/6502/reference.html

Today Matt walked us through the writing of one of the instructions from the instruction.conf file:

#
# instructions.conf - define instructions to use in the simulator environment
#
#      hex  : instructions
instructions
{
	0x69:ADC #$%IMMED%:2:2
	0x65:ADC $%ZPAGE%:2:3
	0x75:ADC $%ZPAGE%,X:2:4
	0x6D:ADC $%ABSOL%:3:4
	0x7D:ADC $%ABSOL%,X:3:4+1
	0x79:ADC $%ABSOL%,Y:3:4+1
	0x61:ADC ($%INDIR%,X):2:6
	0x71:ADC ($%INDIR%),Y:2:5+1
	0x29:AND #$%IMMED%:2:2
	0x25:AND $%ZPAGE%:2:3
	0x35:AND $%ZPAGE,X%:2:4
	0x2D:AND $%ABSOL%:3:4
	0x3D:AND $%ABSOL%,X:3:4+1
	0x39:AND $%ABSOL%,Y:3:4+1
	0x21:AND ($%OFFSET%,X):2:6
	0x31:AND ($%OFFSET%),Y:2:5+1
	0x0A:ASL $%ACCUM%:1:2
	0x06:ASL $%ZPAGE%:2:5
	0x16:ASL $%ZPAGE%,X:2:6
	0x0E:ASL $%ABSOL%:3:6
	0x1E:ASL $%ABSOL%,X:3:7
	0x90:BCC $%RELATIVE%:2:2+1/2+2
	0xB0:BCS $%RELATIVE%2:2+1/2+2
	0xF0:BEQ $%RELATIVE%2:2+1/2+2
	0x24:BIT $%ZPAGE%:2:3
	0x2C:BIT $%ABSOL%:3:4
	0x30:BMI $%RELATIVE%:2:2+1/2+2
	0xD0:BNE $%RELATIVE%:2:2+1/2+2
	0x10:BPL $%RELATIVE%:2:2+1/2+2
	0x00:BRK $%IMPL%:1:7
	0x50:BVC $%RELATIVE%:2:2+1/2+2
	0x70:BCS $%RELATIVE%:2:2+1/2+2
	0x18:CLC $%IMPL%:1:2
	0xD8:CLD $%IMPL%:1:2
	0x58:CLI $%IMPL%:1:2
	0xB8:CLV $%IMPL%:1:2
	0xC9:CMP #$%IMMED%:2:2
	0xC5:CMP $%ZPAGE%:2:3
	0xD5:CMP $%ZPAGE%,X:2:4
	0xCD:CMP $%ABSOL%:3:4
	0xDD:CMP $%ABSOL%,X:3:4+1
	0xD9:CMP $%ABSOL%,Y:3:4+1
	0xC1:CMP ($%INDIR%,X):2:6
	0xD1:CMP ($%INDIR%),Y:2:5+1
	0xE0:CPX #$%IMMED%:2:2
	0xE4:CPX $%ZPAGE%:2:3
	0xEC:CPX $%ABSOL%:3:4
	0xC0:CPY #$%IMMED%:2:2
	0xC4:CPY $%ZPAGE%:2:3
	0xCC:CPY $%ABSOL%:3:4
	0xC6:DEC $%ZPAGE%:2:5
	0xD6:DEC $%ZPAGE%,X:2:6
	0xCE:DEC $%ABSOL%:3:6
	0xDE:DEC $%ABSOL%,X:3:7
	0xCA:DEX $%IMPL%:1:2
	0x88:DEY $%IMPL%:1:2
	0x49:EOR #$%IMMED%:2:2
	0x45:EOR $%ZPAGE%:2:3
	0x55:EOR $%ZPAGE%,X:2:4
	0x4D:EOR $%ABSOL%:3:4
	0x5D:EOR $%ABSOL%,X:3:4+1
	0x59:EOR $%ABSOL%,Y:3:4+1
	0x41:EOR ($%INDIR%,X):2:6
	0x51:EOR ($%INDIR%),Y:2:5+1
	0xE6:INC $%ZPAGE%:2:5
	0xF6:INC $%ZPAGE%,X:2:6
	0xEE:INC $%ABSOL%:3:6
	0xFE:INC $%ABSOL%,X:3:7
	0xE8:INX $%IMPL%:1:2
	0xC8:INY $%IMPL%:1:2
	0x4C:JMP $%ABSOL%:3:3
	0x6C:JMP ($%INDIR%):3:5
	0x20:JSR $%ABSOL%:3:6
	0xA9:LDA #$%IMMED%:2:2
	0xA5:LDA $%ZPAGE%:2:3
	0xB5:LDA $%ZPAGE%,X:2:4
	0xAD:LDA $%ABSOL%:3:4
	0xBD:LDA $%ABSOL%,X:3:4+1
	0xB9:LDA $%ABSOL%,Y:3:4+1
	0xA1:LDA ($%INDIR%,X):2:6
	0xB1:LDA ($%INDIR%),Y:2:5+1
	0xA2:LDX #$%IMMED%:2:2
	0xA6:LDX $%ZPAGE%:2:3
	0xB6:LDX $%ZPAGE%,Y:2:4
	0xAE:LDX $%ABSOL%:3:4
	0xBE:LDX $%ABSOL%,Y:3:4+1
	0xA0:LDY #$%IMMED%:2:2
	0xA4:LDY $%ZPAGE%:2:3
	0xB4:LDY $%ZPAGE%,X:2:4
	0xAC:LDY $%ABSOL%:3:4
	0xBC:LDY $%ABSOL%,X:3:4+1
	0x4A:LSR $%ACCUM%:1:2
	0x46:LSR $%ZPAGE%:2:5
	0x56:LSR $%ZPAGE%,X:2:6
	0x4E:LSR $%ABSOL%:3:6
	0x5E:LSR $%ABSOL%,X:3:7
	0xEA:NOP $%IMPL%:1:2
	0x09:ORA #$%IMMED%:2:2
	0x05:ORA $%ZPAGE%:2:3
	0x15:ORA $%ZPAGE%,X:2:4
	0x0D:ORA $%ABSOL%:3:4
	0x1D:ORA $%ABSOL%,X:3:4+1
	0x19:ORA $%ABSOL%,Y:3:4+1
	0x01:ORA ($%INDIR%,X):2:6
	0x11:ORA ($%INDIR%),Y:2:5+1
	0x48:PHA $%IMPL%:1:3
	0x08:PHP $%IMPL%:1:3
	0x68:PLA $%IMPL%:1:4
	0x28:PLP $%IMPL%:1:4
	0x2A:ROL $%ACCUM%:1:2
	0x26:ROL $%ZPAGE%:2:5
	0x36:ROL $%ZPAGE%,X:2:6
	0x2E:ROL $%ABSOL%:3:6
	0x3E:ROL $%ABSOL%:3:7	
	0x6A:ROR $%ACCUM%:1:2
	0x66:ROR $%ZPAGE%:2:5
	0x76:ROR $%ZPAGE%,X:2:6
	0x6E:ROR $%ABSOL%:3:6
	0x7E:ROR $%ABSOL%:3:7
	0x40:RTI $%IMPL%:1:6
	0x60:RTS $%IMPL%:1:6
	0xE9:SBC #$%IMMED%:2:2
	0xE5:SBC $%ZPAGE%:2:3
	0xF5:SBC $%ZPAGE%,X:2:4
	0xED:SBC $%ABSOL%:3:4
	0xFD:SBC $%ABSOL%,X:3:4+1
	0xF9:SBC $%ABSOL%,Y:3:4+1
	0xE1:SBC ($%INDIR%,X):2:6
	0xF1:SBC ($%INDIR%),Y:2:5+1
	0x38:SEC $%IMPL%:1:2
	0xF8:SED $%IMPL%:1:2	
	0x78:SEI $%IMPL%:1:2
	Ox85:STA $%ZPAGE%:2:3
	0x95:STA $%ZPAGE%,X:2:4
	0x8D:STA $%ABSOL%:3:4
	0x9D:STA $%ABSOL%,X:3:5
	0x99:STA $%ABSOL%,Y:3:5
	0x81:STA ($%INDIR%,X):2:6
	0x91:STA ($%INDIR%),Y:2:6
	0x86:STX $%ZPAGE%:2:3
	0x96:STX $%ZPAGE%,Y:2:4
	0x8E:STX $%ABSOL%:3:4
	0x84:STY $%ZPAGE%:2:3
	0x94:STY $%ZPAGE%,X:2:4
	0x8C:STY $%ABSOL%:3:4
	0xAA:TAX $%IMPL%:1:2
	0xA8:TAY $%IMPL%:1:2
	0xBA:TSX $%IMPL%:1:2
	0x8A:TXA $%IMPL%:1:2
	0x9A:TXS $%IMPL%:1:2
	0x98:TYA $%IMPL%:1:2	
}

We decide we would look at specifically:

0xAA:TAX $%IMPL%:1:2

TAX for this instruction stands for “Transfer Accumulator to X” the IMPL stands for implied, the 1 stands for 1 byte instruction, the 2 is for 2 cpu cycles used.

This instruction chnages the N and Z flags out of NZCIDV, N being the “negative” sign or the signed flag, and the Z being the zero flag.

The logic done on this is:

X = A
P.N = X.7
P.Z = (X==0) ? 1:0

here the X is assigned the value of a, the accumulator register
then “negative” flag or signed flag is set to whatever the 7th bit in the X register is, the signed bit.
then it checks to see if x is zero and if it is then it sets the sero flag, if not it clears the zero flag. the completed version of this we have now for this instruction for TAX “Transfer Accumulator to X” is:

# !/bin/bash
#
# INSTRUCTION:
# 	0xAA - Transfer A to X
#
# FUNCTION:
# 	Take the contents of the accumulator, and copy
# 	them into the X register.
#
# FLAGS FLIPPED:
# 	Zero
# 	Sign
#

# Initialize Simulator Environment
source ../etc/simvar.sh

REGSRC="a" 	# obtain from the accumulator
REGDST="x" 	# copy into the X register

# Copy the contents of source register into 
# destination register
cat ../reg/${REGSRC}.reg > ../reg/${REGDST}.reg

# Check to see if the current value in X is 0
VALUE=$(cat ../reg/${REGDST}.reg | reg2dec)
if [ "${VALUE}" -eq 0 ]; then

	# There is a zero there, set the zero flag
	setZero
else

	# There is not a zero, clear the zero flag
	clearZero
fi

exit 0

We also worked on the SBC instruction, “Subtract Memory from Acccumulator with Borrow” today in class.

All in all this class period, todays class, has made me more comfortable with this class and rady to start actually moving in it, which has my interest piqued more, as I feel like I can contribute to it now. It will be interesting to see how all this plays out over the next several weeks.

Stack pointers…

Stack - a data structure

say you're filling out your TPS reports,
“Didn't you get that memo about how we're putting cover sheets on all the TPS reports?”

first one goes on the bottom then the 2nd ont op of that and so on say to the 8th one.

Then you pop off the 8th thing.

Calling functions:
current position when callign a function is pushed onto the stack, then when returning from a function it gets the address of where you were from the stack.

A sample memory table if you called memory at address 32:

Instructions start usually at the top of the memory address, at the beginning and grow down. The stack usually starts at the end and grows up, hopefully the two never meet or bad things will happen.

The first row in memory we call a page or a “memory page”, so the firts row is refeered to as “zero page.”

Decree from Matt: “All memory functions for our NES simulator will be done in octal because octal gets neglected.”

In the classical model, the registers are inside the CPU and the memory is outside, so if we say that the LAIR classroom is the CPU and the pods in the LAIR are all registers inside that CPU, then memory would be somewhere like at the Arnot Mall. Transfers to and from memory can get expensive.

Stack pointer- will be a register on the CPU which might be 8 or 16 bits.

First thing people writing in assembly language usually do is set the stack pointer to a really high memory address.

LDSP - Load Stack pointer

stack
stack pointer
push - stack pointer moves
pop

Pointers- Indirection

in C we did:

int *a;
a=(int *)malloc(sizeof(int));

LDI A
Load instructions to A
which is different from
LD BEEF, A
INCrement Y
LDI A

In class we went over writing the instructiosn for both 0x2D “Bitwise AND against accumulator address in memory”
and
0x41 “Bitwise exclusive OR (XOR) between accumulator adn byte of memory accessed indirectly via X register.

Endianness comes from Gullivers Travels (I personally have never read it nor seen any movie versions of it) where peopel cracked an egg from either the little end or the bigger end.

BE EF
BE upper order byte
EF lower order byte

3 byte instruction:
2D EF BE (little endian 3 byte instruction)
2D is the instruction
EF is the lower order byte
BE is the upper order byte

the 6502 NES cpu, intel and most ARM CPU's all use little endian

Fetch Decode Execute Store - FDES
some CPU's have pipelines.

…………..cycles

on cycle 3 we have a full pipeline, A is being Stored, while B is being executed, and C is beign decoded, and A is being Fetched, simultaneously. On multicore systems you woudl have more of these sets.

Lair board picture from today:

And now, for no reason at all,
“Sweet Child O' Mine” - New Orleans Style Guns N' Roses Cover ft. Miche Braden:

Today, ultimately turned into a free day. We didn't work on anything related to our NES simulator today. We discussed things like whether or not the LAIR is moving and where. We discussed scrum and alternates. And then something towards the end about starting a business, at this point I wasn't paying as much attention to the general conversation as I was working on finishing up my 2nd complete run of LFS.

Today in class we went over the JSR 0x20 instruction for our nes simulator. This is a Jump to a Subroutine. A subroutine is like a function, this is a set of instructions that looks for instructions at a designated location. This is like a GOTO address. In the assembly realm, GOTO's are the only way to do things.

PC - Program Counter (holds the address of the next intruction to be executed) a 16 bit register.
Little endian, returns lower end first.\ SP - Stack Pointer BEED → subtract 1 from PC → BEEC → subtract 1 from PC → BEEB

0x20 Jump to Subroutine -
Store program counter into stack and set program counter to operands.
Flags flipped - None

# !/bin/bash
#
# INSTRUCTION:
# 	0x20 - Jump to SubRoutine
#
# FUNCTION:
# 	
#       Store program counter into stack, and set
#       program counter to operands.
#
# FLAGS FLIPPED:
# 	none
#

# Initialize Simulator Environment
source ../etc/simvar.sh

REGSRC="a" 	# subtract values from the accumulator
REGDST="a" 	# store the result in the accumulator
LBYTE=${1}	# lower order byte of the absolute address
HBYTE=${2}  # upper order byte of the absolute address

# Grab the lower order byte of PC into variable
LOWPCBYTE=$(cat ../reg/pc.reg | cut -c9-16)

# Grab the upper order byte of PC into variable
HIGPCBYTE=$(cat ../reg/pc.reg | cut -c1-8)

# Grab stack pointer into variable
SPBYTE=$(cat ../reg/sp.reg | cut -c9-16 | reg2hex.sh)

# Put lower order byte of PC onto top of stack
echo "${LOWPCBYTE}" | memput.sh ../mem/ram.mem ${SPBYTE} 01

# Decrement the stack pointer
TMP=$(echo ${SPBYTE} | hex2dec.sh)
SPBYTE=$((${TMP}-1))
echo ${SPBYTE) | dec2reg.sh > ../reg/sp.reg

# Grab stack pointer into variable
SPBYTE=$(cat ../reg/sp.reg | cut -c9-16 | reg2hex.sh)

# Put upper order byte of PC onto top of stack
echo "${HIGPCBYTE}" | memput.sh ../mem/ram.mem ${SPBYTE} 01

# Decrement the stack pointer
TMP=$(echo ${SPBYTE} | hex2dec.sh)
SPBYTE=$((${TMP}-1))
echo ${SPBYTE) | dec2reg.sh > ../reg/sp.reg

# Assign LBYTE and HBYTE to program counter
PCUP=$(echo ${HBYTE} | hex2reg.sh)
PCDN=$(echo ${LBYTE} | hex2reg.sh)
echo "${PCUP}${PCDN}" > ../reg/pc.reg

exit 0

We also took a quick glance at PHP instructions set (push p[parameter] to stack) BEQ Branch iff P.Z. is set

if (zeroflag != 1)
{
    thing
}
stuff

0xEA NOP - No Operation -takes two cycles but does nothing. This can be used in liek registration type call, nagware to edit something without recompiling in a hex editor to just put NOP operations in whereit was calling its registration things.

Today in class we talked about the flip flop and registers and some fo that works in conjuntion with a clock to make a clocked latch. We later also talked about the Interrupts in our NES CPU, the 6502. A picture of my notes from today:

Just finished today (Thursday, March 12, 2015) writing up what appears to be a working instruction for the Return from Subroutine 0x60 RTS instruction written in bash as seen here:

# !/bin/bash
#
# INSTRUCTION:
# 	0x60 - Return from SubRoutine
#
# FUNCTION:
# 	
#       Retrieve program counter from stack, and
#       set it back in the PC register
#
# FLAGS FLIPPED:
# 	none
#
 
# Initialize Simulator Environment:q
source ../etc/simvar.sh
 
#convert stack pointer to decimal
SPHEX=$(cat ../reg/sp.reg | reg2dec.sh)
 
#increment the decimal stack pointer
SP=$(($SPHEX+1))
 
#storing high byte to a variable
HIGH=$(echo "${SP}"| dec2reg.sh)
 
#converting back to register format
echo "${SP}" | dec2reg.sh > ../reg/sp.reg
 
#convert stack pointer to decimal
SPHEX=$(cat ../reg/sp.reg | reg2dec.sh)
 
#increment the decimal stack pointer
SP=$(($SPHEX+1))
 
#storing low byte to a variable
LOW=$(echo "${SP}" | dec2reg.sh)
 
#converting back to register format
echo "${SP}" | dec2reg.sh > ../reg/sp.reg
 
#asssigning high and low bytes to program counter
echo "${HIGH}${LOW}" > ../reg/pc.reg
 
exit 0

Today in HPC Systems and Networking class we looking into what the unix class is doing, differentiating between text and binary data. We redid one of their projects. We recieved a file called memdump.ram which we grabbed from the /var/public/sysnet directory. If we open this file in a hex editor like bvi (binary vi) or hexedit we can review the data in the memory dump:

bvi memdump.ram

In this file here we have 3 distinct sections. The first section on the right is the offset or memory address. The second section are 16 distinct 2 digit combinations in hex, the data in hex byte by byte. Then there could be a sequence of dots when there is no data or filler for zero padded data, or it has the actual binary data.

Looking throuigh this file, I found at the 001CED3 address the beginning of the table of contents for this file displayed as:

-toc-part2:0x1800,204240;part1:0x13ca0,110350;toc:0x1ced3,127;part3 0x1e188,104440;-toc

using bc we can convert these numbers for each part, the first is the address in hexidecimal, the second nmumber is the size of that chunk of data in octal. For dd we need to have all these addresses and sizes in decimal, so to convert it we first run bc and change its input to base 8 with:

ibase=8

then entering each number (the sizes) to get the numbers in decimal, then after exiting bc and reentering, we set it to take input for hexidecimal with:

ibase16

then we enter each address in (capitalizing the letters A,B,C,D,E,F) and get the addresses back in decinal to get the full list of addresses and sizes in decimal as:

        address     size
toc     118483      87
part1   81056       37096
part2   6144        67744
part3   123272      35104

Then we started exploring the capabilities of dd, like we can use dd like cat with:

dd if=/etc/motd

which displays the message of the day. We then run the memdump.ram file into dd with an output file specified and a count of 1 as:

dd if=memdump.ram of=poopstain count=1

which we see writes 512 bytes of data to the new file poopstain. If we ran something like:

dd if=/dev/sda of=pt count=1

Would write to the file pt, the partition table and the MBR, Master Boot Record.

We then can run the command:

dd if=memdump.ram of=tmp bs=1 count=1

and then specifying a size with:

dd if=memdump.ram of=part2 bs=1 count=67744

will give us the number of bytes copied that we want but not form the correct starting point.

we can grab the correct starting point with the *seek* option:

dd if=memdump.ram of=part2 bs=1 count=67744 seek=6114

and we grab the other two parts with the following commands:

dd if=memdump.ram of=part1 bs=1 count=37096 seek=81056

and:

dd if=memdump.ram of=part3 bs=1 count=35104 seek=123272

Now we have the three files we need, and using the file command we can see that part2 is uuencoded, we can change that with:

uudecode part2

Which when we run file on it again appears as a data file, same as part3. Part 1 after runnuing file comamnd on it shows up as an xz file. For unxz to work we need to rename part1 to part1.xz with:

mv part1 part1.xz

then extracting it with:

unxz part1.xz

Now when we run file on part1, we get an RLE file, which is a type of image file.

We concatenate three parts of the file together into one RLE file with:

cat part1 part2 part3 >> puzzlyboxxy.rle

Then to convert it to a png file, we need to convert it to a pnm first with:

rletopnm puzzlyboxxy.rle > puzzlyboxxy.pnm

Then convert it to apng file with:

pnmtopng puzzlyboxxy.pnm > puzzlyboxxy.png

Then I copy the file to my public_html directory for website viewing with:

cp puzzlyboxxy.png ~/public_html/tacocat.png

Which reveals our final image below:

Apparently there was no class today. I waited around until amost 4:00 PM until someone had said class was cancelled today, so yeah.

I missed today because I was in the hospital.

Today we talked about polyphasic sleep and how to read in a hex editor all the data Matt had collected over several months while working on this.

I was actually expecting a run of the mill “syllabus review first day” which isn't what we got today which was a welcome surprise, because usually just running through the syllabus is a very dry and boring day and repeated between all the other classes. What we DID do is talk a little bit on what we would be doing this semester in Systems Programming, which is pretty much writing video games! :)

We are aiming for writing 3 games throughout the semester, the first one will be an 8 bit atari-esque game that we are writing in groups. My group currently consists of Dan Shadeck and Zach Golden and myself and may include Mike Merrick too. We started looking at 8-bit games and thought about what we might make, I suggested an 8-bit top down Grand Theft Auto (lol), which I had ideas for how I might approach that, ultimately as a group we landed on Frogger only to find out another group had already claimed it. So we moved to another one we discussed, Donkey Kong. So my group is planning on trying to take on Donkey Kong. I know that we need floors and collision detection for our Mario guy (don't know if he was called that back then in the original Donkey Kong or not but tha'ts where he came from)and also collision detection with the barrels that need to be rolling down the floors. Another thing I know we need is Mario's ability to jump and have gravity act upon him to bring him back into the collision with the current floor that he's on. Also the barrels need to roll from floor to floor. Just some of my own musings on this since we picked it at the end of class. I think we are still discussing if we are planning on using mercurial and bitbucket or git and github for version control on this. I personally am equally comfortable with either, I guess we'll iron that out next class.

In today's class our group, again consisting of Dan Shadeck, Zack Golden, Mike Merrick and myself, first looked at git, as I needed to give a quick overview of basic usage of git and github to a couple of us. After all of us had cloned and made a change, a commit, a push, and a pull we moved on to game planning. We are planning for our Donkey Kong game which I'm unofficially calling Super Mega Awesome Donkey Kong. We decided we need to agree on game mechanics as we had some uncertainty as to what aspect exists in the original game and as to which version was the original game and lastly what exactly we wanted to do feature wise in comparison to the real game. Ultimately we are stripping features and adding them as we go, time permitting. I think we decided we need to work on our map (the world that mario climbs the floors and ladders first) for people to start working on other parts that work on that map. Then a subset can work on say mario's movement left and right and up the ladders and later add jumping. Another subset can work on the barrel rolling aspect and we can see how it goes from there, tentatively speaking.

I currently have SDL2 installed and working on all of my machines, including the Arch Linux box at the LAIR. We as a group started working on trying to design our Donkey Kong map first, meaning the floors and ladders. Although we hit some major snags with basic output in SDL2. The tutorials we are using are on lazyfoo.net but we ran into some snags with the tutorials. We also ran into issues with the windows being destroyed and we wanted it to stay open. I feel like we are hitting a huge wall learning SDL2 at the moment and I'm frustrated and second guessing my ability to even be able to accomplish this. I was confident that I could progress a game towards a working Donkey based on my exposure to SDL1 last semester in C, early in this venture. After today's class I fear that we may not produce any workable game at all, and that we'll spend the next month learning SDL2. One of our group members dropped the class today as well, so we are down to 3 members (like every other group) leaving us with just Zack Golden, Dan Shadeck, and myself. We decided as a group to independently work through the first 8 tutorials on lazyfoo.net. As of right now none of us are capable of even displaying a rectangle or triangle or any other shape on the screen, and we're depending on that to be able to start making our square that starts as “mario” and a floor so we could start dealing with the jumping mechanic and then how gravity will act on mario as he is pulled back to the floor, which adds collison detection as a new issue. But all of this is miles ahead of us if we cannot output a single square or rectangle on the screen, which is where we currently are blocked. I am genuinely frustrated and worried about this class at this exact moment,

Today, surprisingly, we had a bit of a huge jump in progress in our game development of “Super Mega Awesome Donkey Kong” Dan was sick, but Zack and I started hammering out some code to get some geometric shapes drawn on screen and we ended up plotting the wnetire map for the level, or world, or whatever. We have our 4 regular floors drawn, ladder blocks (teal)drawn in correct locations, a 5th partial floor with the princess block (pink)(win condition) and dokey kong block(orange/brown) and then a mario block (red). Next on our agenda is getting mario moveable so that he can move left and right on floors, up (and maybe down) when in the ladder zone. Then beyond that adding the jumping ability to mario and the gravity force that pulls him back down to the ground. Then we can look into the barrels donkey kong throws adn other enemies and hammers, etc.

Current code state:

1

/************************************************************
 *
 * Super Mega Awesome Donkey Kong
 * a.k.a. Dankey Kang
 * a.k.a. Dunkey Kung
 * a.k.a. Kunkey Dung
 *
 * Developers:      Zack Golden
 *                  Matthew Page me@matthewjpage.com
 *                  Dan Shadeck
 *
 ***********************************************************/
 
#include <SDL2/SDL.h>
 
int main(int argc, char ** argv)
{
    bool quit = false;
    SDL_Event event;
 
    SDL_Init(SDL_INIT_VIDEO);
 
    SDL_Window * window = SDL_CreateWindow("Super Mega Awesome Donkey Kong", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
 
    SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
 
    while (!quit)
    {
        SDL_WaitEvent(&event);
 
        switch(event.type)
        {
        case SDL_QUIT:
            quit = true;
            break;
        }
 
                //Clear screen
                SDL_SetRenderDrawColor( renderer, 0x00, 0x00, 0x00, 0x00 );
                SDL_RenderClear( renderer );
 
                //Donkey Kong Floors and Ladders
                SDL_Rect Floor1 = { 20, 440, 600, 10 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Floor1 );
 
                SDL_Rect Ladder1_2 = { 560, 340, 20, 100 };
                SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Ladder1_2 );
 
                SDL_Rect Floor2 = { 20, 340, 600, 10 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Floor2 );
 
                SDL_Rect Ladder2_3 = { 60, 240, 20, 100 };
                SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Ladder2_3 );
 
                SDL_Rect Floor3 = { 20, 240, 600, 10 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Floor3 );
 
                SDL_Rect Ladder3_4 = { 560, 140, 20, 100 };
                SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Ladder3_4 );
 
                SDL_Rect Floor4 = { 20, 140, 600, 10 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Floor4 );
 
                SDL_Rect Ladder4_5 = { 240, 60, 20, 80 };
                SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Ladder4_5 );
 
                SDL_Rect Floor5 = { 200, 60, 100, 10 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
                SDL_RenderFillRect( renderer, &Floor5 );
 
                //Mario block
                SDL_Rect Mario = { 310, 405, 20, 35 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0x00, 0x00, 0xFF );
                SDL_RenderFillRect( renderer, &Mario );
 
                //Donkey Kong himself
                SDL_Rect Donkey = { 60, 40, 60, 100 };
                SDL_SetRenderDrawColor( renderer, 0xDD, 0x51, 0x00, 0xFF );
                SDL_RenderFillRect( renderer, &Donkey );
 
                //Princess Peach (win condition)
                SDL_Rect Peach = { 210, 25, 20, 35 };
                SDL_SetRenderDrawColor( renderer, 0xFF, 0xAA, 0xDD, 0xFF );
                SDL_RenderFillRect( renderer, &Peach );
 
                //Update screen
                SDL_RenderPresent( renderer ); 
 
    }
 
    SDL_RenderPresent(renderer);
 
    SDL_Quit();
 
    SDL_DestroyRenderer(renderer);  
    SDL_DestroyWindow(window);
 
    return 0;
}

Another very productive day for our game development. After tackling using a png file for our mario in “Super Mega Awesome Donkey Kong” and getting some basic movement accomplished over the weekend, today we fixed the mario leaving a trail issue as referenced here on our github repo:

https://github.com/danshadeck/spg1/issues/2

Today, to solve the mario leaving a trail issue, we decided to finish our function that draws the map, so that we can call it over and over as needed to redraw the map, this would cause a lot of uneeded overhead if this was a bigger project, then we might need to use a blanking sprite to follow mario and clean up after him. We also added sprites for the princess and donkey kong to the game. Next on our agenda is to add up and down movement in the ladder regions and only for the length of from one floor to the next. Also we want to explore the moveable sprites for mario so that he moves his arms and such while walking and possibly has back to you while climbing ladder. Another feature due soon ont he horizon would be adding and implementing the jump even for mario.

Here is the current state of our code:

1

/************************************************************
 *
 * Super Mega Awesome Donkey Kong
 * a.k.a. Dankey Kang
 * a.k.a. Dunkey Kung
 * a.k.a. Kunkey Dung
 *
 * Developers:      Zack Golden
 *                  Matthew Page me@matthewjpage.com
 *                  Dan Shadeck
 *
 ***********************************************************/
 
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
 
//map() function declaration
void map(SDL_Renderer * renderer)
{
    //Clear screen
    SDL_SetRenderDrawColor( renderer, 0x00, 0x00, 0x00, 0x00 );
    SDL_RenderClear( renderer );
 
    //Donkey Kong Floors and Ladders
    SDL_Rect Floor1 = { 20, 440, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor1 );
 
    SDL_Rect Ladder1_2 = { 560, 340, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder1_2 );
 
    SDL_Rect Floor2 = { 20, 340, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor2 );
 
    SDL_Rect Ladder2_3 = { 60, 240, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder2_3 );
 
    SDL_Rect Floor3 = { 20, 240, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor3 );
 
    SDL_Rect Ladder3_4 = { 560, 140, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder3_4 );
 
    SDL_Rect Floor4 = { 20, 140, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor4 );
 
    SDL_Rect Ladder4_5 = { 240, 60, 20, 80 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder4_5 );
 
    SDL_Rect Floor5 = { 200, 60, 100, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor5 );
 
    //Mario block
    //SDL_Rect Mario = { 310, 405, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0x00, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Mario );
 
    //Donkey Kong himself
    //SDL_Rect Donkey = { 60, 40, 60, 100 };
    //SDL_SetRenderDrawColor( renderer, 0xDD, 0x51, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Donkey );
 
    //Princess Peach (win condition)
    //SDL_Rect Peach = { 210, 25, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0xAA, 0xDD, 0xFF );
    //SDL_RenderFillRect( renderer, &Peach );
 
    //Update screen
    SDL_RenderPresent( renderer ); 
}
 
int main(int argc, char ** argv)
{
    //variables
    bool quit = false;
    SDL_Event event;
    int x = 40;
    int y = 405;
 
    //initialize SDL
    SDL_Init(SDL_INIT_VIDEO);
    IMG_Init(IMG_INIT_PNG);
 
    SDL_Window * window = SDL_CreateWindow("Super Mega Awesome Donkey Kong",
        SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
    SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * image = IMG_Load ("mario.png");
    SDL_Surface * image2 = IMG_Load ("donkey.png");
    SDL_Surface * image3 = IMG_Load ("princess.png");
    SDL_Texture * texture = SDL_CreateTextureFromSurface(renderer, image);
    SDL_Texture * texture2 = SDL_CreateTextureFromSurface(renderer, image2);
    SDL_Texture * texture3 = SDL_CreateTextureFromSurface(renderer, image3);
    SDL_FreeSurface(image);
    SDL_FreeSurface(image2);
    SDL_FreeSurface(image3);
 
    SDL_SetRenderDrawColor(renderer, 0, 0, 0, 0);
 
    map(renderer);
 
    //main game loop
    while (!quit)
    {
        SDL_WaitEvent(&event);
 
        switch(event.type)
        {
        case SDL_QUIT:
            quit = true;
            break;
        case SDL_KEYDOWN:
            switch (event.key.keysym.sym)
            {
            case SDLK_LEFT:  x=x-5; break;
            case SDLK_RIGHT: x=x+5; break;
            //case SDLK_UP:    y=y-2; break;
            //case SDLK_DOWN:  y=y+2; break;
            }
            map(renderer);
            break;
        }
 
 
        SDL_Rect dstrect = { x, y, 20, 35 };
        SDL_Rect dstrect2 = { 60, 40, 60, 100 };
        SDL_Rect dstrect3 = { 210, 25, 20, 35 };
 
        //SDL_RenderClear(renderer);
        SDL_RenderCopy(renderer, texture, NULL, &dstrect);
        SDL_RenderCopy(renderer, texture2, NULL, &dstrect2);
        SDL_RenderCopy(renderer, texture3, NULL, &dstrect3);
        SDL_RenderPresent(renderer);
 
    }
 
    //cleanup SDL
    SDL_DestroyTexture(texture);
    SDL_DestroyRenderer(renderer);  
    SDL_DestroyWindow(window);
    IMG_Quit();
    SDL_Quit();
 
 
    return 0;
}

which can be found on the repo here on github:
https://github.com/danshadeck/spg1

Today we started working on ladder zones. We also had a little disagreement about the direction the game is going in. Ultimately I was wondering are we actually recreating Donkey Kong exactly or making a Donkey Kong like game? This stems from one group member's desire to have the barrel rolling be believeable (barrels not rolling on level surface vs a sloped surface) and having the actual floors and laddders structure of te map be as close to the real game as possible so as to actually use the image of the game level from original game as the background and having mario move accordingly on that background. While I don't necessarily object to this, we have at this point 27 days left until this project is due (including weekends and our upcoming break week), and we have spent 17 days thus far on this project (also including weekends). Granted some of the time spent was merely choosing a game and getting some general stuff out of the way, settign upa repository and gettign everyone access to it and startign to learn SDL2. I still feel we are essentially 1/3 of the way through the alloted time to produce this and while it woudl be great to fully implement a more realistic representation of classic Donkey Kong, we still have major hurdles still to get through.

We don't have moving sprites yet for mario, let alone princess or donkey kong himself. But we also still need to finish off the solution for all the ladders, which today in the course of and hour and a half to 2 hours we solved for one, which we may end up looping for 3 of our 4 ladders on our self designed map *IF* we stay with that. But we also have barrels to still do, the path of Barrels and the randomization of the barrel paths, we still need to implement the mario jump feature, we still need collision detection on the outer edges of the map so as to not be able to walk right off the game. We need collision detection for mario and the barrels to create a death. We need a win condition with getting to the princess. We need hammmers to smash said barrels. Even staying with our current map, I'm not sure how or if we will get to all of this before March 4th , 27 days from today. My reasoning stems from the fact that everythign I've listed represents a ton of work and shifting around what we're working on is going to add to this workload, liek for now, we know the EXACT dimensions of our self created map and can start working from there to solve the above problems, which even when knowing all of these dimesnsiosn takes a lot of time. Adding more floors, angled floors, nmore ladders, on out background image map woudlc hange everythign to dimensions we have yet to determine. And while if we had the time to do it, I woudl be all for pursuing that, I genuinely feel that we have more than enough on our plate with our current skilsets of the the team members to keep us more than occupied on this project until the deadline.

That being said, today accomplishing the restricted ladder movement from floor 1 to floor 2 felt good to get him closer to being able to traverse up the entire map. We have yet to see what the team consensus on design decisons becomes. But another current state of our code:

1

/************************************************************
 *
 * Super Mega Awesome Donkey Kong
 * a.k.a. Dankey Kang
 * a.k.a. Dunkey Kung
 * a.k.a. Kunkey Dung
 *
 * Developers:      Zack Golden
 *                  Matthew Page me@matthewjpage.com
 *                  Dan Shadeck
 *
 ***********************************************************/
 
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
 
//map() function declaration
void map(SDL_Renderer * renderer)
{
    //Clear screen
    SDL_SetRenderDrawColor( renderer, 0x00, 0x00, 0x00, 0x00 );
    SDL_RenderClear( renderer );
 
    //Donkey Kong Floors and Ladders
    SDL_Rect Floor1 = { 20, 440, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor1 );
 
    SDL_Rect Ladder1_2 = { 560, 340, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder1_2 );
 
    SDL_Rect Floor2 = { 20, 340, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor2 );
 
    SDL_Rect Ladder2_3 = { 60, 240, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder2_3 );
 
    SDL_Rect Floor3 = { 20, 240, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor3 );
 
    SDL_Rect Ladder3_4 = { 560, 140, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder3_4 );
 
    SDL_Rect Floor4 = { 20, 140, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor4 );
 
    SDL_Rect Ladder4_5 = { 240, 60, 20, 80 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder4_5 );
 
    SDL_Rect Floor5 = { 200, 60, 100, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor5 );
 
    //Mario block
    //SDL_Rect Mario = { 310, 405, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0x00, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Mario );
 
    //Donkey Kong himself
    //SDL_Rect Donkey = { 60, 40, 60, 100 };
    //SDL_SetRenderDrawColor( renderer, 0xDD, 0x51, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Donkey );
 
    //Princess Peach (win condition)
    //SDL_Rect Peach = { 210, 25, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0xAA, 0xDD, 0xFF );
    //SDL_RenderFillRect( renderer, &Peach );
 
    //Update screen
    SDL_RenderPresent( renderer ); 
}
 
int main(int argc, char ** argv)
{
    //variables
    bool quit = false;
    SDL_Event event;
    int x = 40;
    int y = 405;
    int ladderflag = 0;  //restrict left/right movement while on ladder
 
    //initialize SDL
    SDL_Init(SDL_INIT_VIDEO);
    IMG_Init(IMG_INIT_PNG);
 
    SDL_Window * window = SDL_CreateWindow("Super Mega Awesome Donkey Kong",
        SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
    SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * image = IMG_Load ("mario.png");
    SDL_Surface * image2 = IMG_Load ("donkey.png");
    SDL_Surface * image3 = IMG_Load ("princess.png");
    SDL_Texture * texture = SDL_CreateTextureFromSurface(renderer, image);
    SDL_Texture * texture2 = SDL_CreateTextureFromSurface(renderer, image2);
    SDL_Texture * texture3 = SDL_CreateTextureFromSurface(renderer, image3);
    SDL_FreeSurface(image);
    SDL_FreeSurface(image2);
    SDL_FreeSurface(image3);
 
    SDL_SetRenderDrawColor(renderer, 0, 0, 0, 0);
 
    map(renderer);
 
    //main game loop
    while (!quit)
    {
        SDL_WaitEvent(&event);
 
        switch(event.type)
        {
        case SDL_QUIT:
            quit = true;
            break;
        case SDL_KEYDOWN:
            switch (event.key.keysym.sym)
            {
            case SDLK_LEFT:  x=x-5; break;
            case SDLK_RIGHT: x=x+5; break;
            case SDLK_UP:
                if ((x<570) && (x>550))
                {
                    if ((y>305) && (y<415))
                    {
 
                             y=y-5;
                    }
                }
                break;
            case SDLK_DOWN:  
                if ((x<570) && (x>550))
                {
                    if ((y>300) && (y<405))
                    {
 
                             y=y+5;
                    }
                }
                break;
            //case SDLK_UP:    y=y-5; break;
            //case SDLK_DOWN:  y=y+5; break;
            }
            map(renderer);
            break;
        }
 
 
        SDL_Rect dstrect = { x, y, 20, 35 };
        SDL_Rect dstrect2 = { 60, 40, 60, 100 };
        SDL_Rect dstrect3 = { 210, 25, 20, 35 };
 
        //SDL_RenderClear(renderer);
        SDL_RenderCopy(renderer, texture, NULL, &dstrect);
        SDL_RenderCopy(renderer, texture2, NULL, &dstrect2);
        SDL_RenderCopy(renderer, texture3, NULL, &dstrect3);
        SDL_RenderPresent(renderer);
 
    }
 
    //cleanup SDL
    SDL_DestroyTexture(texture);
    SDL_DestroyRenderer(renderer);  
    SDL_DestroyWindow(window);
    IMG_Quit();
    SDL_Quit();
 
 
    return 0;
}

We as a group had collectively decided to sit on our game this weekend and not do any work on it, since we had spent so much time working on it up until this point. Also we had been neglecting work for other classes whiel being so gung ho on workign on this game. So very little has changed since last Thursday. However today in class, all of us were there, Zack Golden, Dan Shadeck, and myself so we did do a little with trying to implement the ladderflag condition that locks mario on the ladder while goubng up or down on the ladder so that he doesnt have free left and right movement. We had this broken up to this point, But today with some of Matt's guidance we got it to restrict mario's left and right movement while on the ladder, however this introduced a new flaw. The old way we could have mario go up the ladder and then get off and move around and then retreat back down the ladder, say if a barrel was coming and he needs to elude it. But with this new method, moving the check outside of the key events has currently left mario where once he gets up the ladder, he can't go back down. This might need some tweaking and some more experimentation. It feels liek we haven't solved much today, but really if we are going to loop the ladders, we need everything surrounding the first ladder to be solid before we loop it. We could always crank more if statements to create the other ladders, I guess time will tell. As this games allotted development time is circling the drain. I believe we have 21 days left to work on it by my calculations, this figure includes not only weekedns but the full week we have off next week as well. Current code from the game:

1

/************************************************************
 *
 * Super Mega Awesome Donkey Kong
 * a.k.a. Dankey Kang
 * a.k.a. Dunkey Kung
 * a.k.a. Kunkey Dung
 *
 * Developers:      Zack Golden
 *                  Matthew Page me@matthewjpage.com
 *                  Dan Shadeck
 *
 ***********************************************************/
 
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
 
//map() function declaration
void map(SDL_Renderer * renderer)
{
    //Clear screen
    SDL_SetRenderDrawColor( renderer, 0x00, 0x00, 0x00, 0x00 );
    SDL_RenderClear( renderer );
 
    //Donkey Kong Floors and Ladders
    SDL_Rect Floor1 = { 20, 440, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor1 );
 
    SDL_Rect Ladder1_2 = { 560, 340, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder1_2 );
 
    SDL_Rect Floor2 = { 20, 340, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor2 );
 
    SDL_Rect Ladder2_3 = { 60, 240, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder2_3 );
 
    SDL_Rect Floor3 = { 20, 240, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor3 );
 
    SDL_Rect Ladder3_4 = { 560, 140, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder3_4 );
 
    SDL_Rect Floor4 = { 20, 140, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor4 );
 
    SDL_Rect Ladder4_5 = { 240, 60, 20, 80 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder4_5 );
 
    SDL_Rect Floor5 = { 200, 60, 100, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor5 );
 
    //Mario block
    //SDL_Rect Mario = { 310, 405, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0x00, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Mario );
 
    //Donkey Kong himself
    //SDL_Rect Donkey = { 60, 40, 60, 100 };
    //SDL_SetRenderDrawColor( renderer, 0xDD, 0x51, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Donkey );
 
    //Princess Peach (win condition)
    //SDL_Rect Peach = { 210, 25, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0xAA, 0xDD, 0xFF );
    //SDL_RenderFillRect( renderer, &Peach );
 
    //Update screen
    SDL_RenderPresent( renderer );
}
 
int main(int argc, char ** argv)
{
    //variables
    bool quit = false;
    SDL_Event event;
    int x = 40;
    int y = 405;
    int ladderflag = 0;  //restrict left/right movement while on ladder
 
    //initialize SDL
    SDL_Init(SDL_INIT_VIDEO);
    IMG_Init(IMG_INIT_PNG);
 
    SDL_Window * window = SDL_CreateWindow("Super Mega Awesome Donkey Kong",
        SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
    SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * image = IMG_Load ("mario.png");
    SDL_Surface * image2 = IMG_Load ("donkey.png");
    SDL_Surface * image3 = IMG_Load ("princess.png");
    SDL_Texture * texture = SDL_CreateTextureFromSurface(renderer, image);
    SDL_Texture * texture2 = SDL_CreateTextureFromSurface(renderer, image2);
    SDL_Texture * texture3 = SDL_CreateTextureFromSurface(renderer, image3);
    SDL_FreeSurface(image);
    SDL_FreeSurface(image2);
    SDL_FreeSurface(image3);
 
    SDL_SetRenderDrawColor(renderer, 0, 0, 0, 0);
 
    map(renderer);
 
    //main game loop
    while (!quit)
    {
        SDL_WaitEvent(&event);
 
	//setting boundaires for ladder flag
	if ((x<570) && (x>555))//x-coordinate range
        {
            if ((y>305) && (y<415))//y-coordinate range
            {
                ladderflag=1;//activated flag
            }
            else
            {
                ladderflag=0;//deactived flag
            }
        }
        else
        {
            ladderflag=0;//deactived flag
        }
 
        switch(event.type)
        {
        case SDL_QUIT:
            quit = true;
            break;
 
	///movement with arrow keys
        case SDL_KEYDOWN:
            switch (event.key.keysym.sym)
            {
            case SDLK_LEFT:
                if (ladderflag == 1)//restricted movement on ladder
                {
                    x=x;
                    break;
                }
                else//no restriction
                {
                    x=x-5;
                }
                break;
            case SDLK_RIGHT:
                if (ladderflag == 1)//restrict movement
                {
                    x=x;
                    break;
                }
                else//freedom to move
                {
                    x=x+5;
                }
                break;
 
            //movement up and only while on ladder
	    case SDLK_UP:
                if (ladderflag == 1)
                {
                	y=y-5;
                }
                break;
            case SDLK_DOWN:
                if (ladderflag == 1)
		{
			y=y+5;
		}
                break;
            }
            map(renderer);
            break;
        }
 
 
        SDL_Rect dstrect = { x, y, 20, 35 };
        SDL_Rect dstrect2 = { 60, 40, 60, 100 };
        SDL_Rect dstrect3 = { 210, 25, 20, 35 };
 
        //SDL_RenderClear(renderer);
        SDL_RenderCopy(renderer, texture, NULL, &dstrect);
        SDL_RenderCopy(renderer, texture2, NULL, &dstrect2);
        SDL_RenderCopy(renderer, texture3, NULL, &dstrect3);
        SDL_RenderPresent(renderer);
 
    }
 
    //cleanup SDL
    SDL_DestroyTexture(texture);
    SDL_DestroyRenderer(renderer);
    SDL_DestroyWindow(window);
    IMG_Quit();
    SDL_Quit();
 
 
    return 0;
}

We as a group decided to take today off from working on our game (instead I worked on my Linux form scratch, see my HPC Fundamentals entry for today ) especially since we plan to meet over break next weak AT LEAST 2 times to just spend all day working on code. We'll see how far we get on 1,000 red bulls and ruining Zack's house. Our game still has plenty that we still need to work on, including still fixing ladder movement all the way up to the win condition, adding the jump feature, adding barrels, and adding the hammers. Not sure how we are going to get all of that done before the deadline for this project, but we'll see, a whole week off is a lot of potential time. I'll have a clearer picture of whether or not we'll be “done”, whatever that means, after we get back from break.

Today Zack and I tried getting all the ladders to work together again with still no success. So after we consulted Matt with this issue, he suggested using a struct for thw ladder to define the ladder ranges and then be constantly checking to see if marios is in any of those ladder ranges. I think I follow this, but to be honest I knwo I'm not necessarily comfortable with the concept of a struct, my entire experience with them was directly from Matt in C/C++ class last semester. I think Zack and Dan are probably on the same level of unfamiliarity with it as well. But I'm willing to try it. This is the start of our struct, still very unfinished:

struct ladder {
    int xleft;
    int xright;
    int ytop;
    int ybottom;
    int ladderflag;
};
 
int i;
struct ladder ladarr[2]; //laddar array
for (i=0;i<2;i++)
{
    ladarr[0].xleft=555;
    ladarr[0].xright=570;
    laddar[0].ytop=305;
    laddar[0].ybottom=415;
    ladarr[1].xleft=40;
    ladarr[1].xright=65;
    ladarr[1].ytop=205;
    ladarr[1].ybottom=310;
}

We also created an array of these coordinates. Our current ladder coordinates are:

Ladder 1:
xleft:555
xright:570
ytop:305
ybottom:415

Ladder 2:
xleft:40
xright:65
ytop:205
ybottom:310

Ladder 3:
xleft:555
xright:570
ytop:105
ybottom:210

Ladder4:
xleft:220
xright:245
ytop:25
ybottom:110

We still have nothing close to functional in regards to this struct and array, but I beleive the idea is that it will set the ladder variables and check to see if mario is in a ladder zo ne over and over within the game loop and when he is it will turn on a ladderflag.

One thing we did effectively solve is the ability of mario to walk off the end of the floors. We added this chunk fo code that if he walks off any floor on either end, it pulls him back, like an invisible wall:

if (y==25)
{
    if (x>280)
    {
        x=280;
    }
}
else
{
    if (x<20)
    {
        x=20;
    }
    if (x>600)
    {
        x=600;
    }
}

We still have a LOT of work to do to make this seem like a functioning game. But it also seems that the deadline is not necessarily as firm as previously expected.

I didn't come in today because:

Today we looked at our code in depth with Matt, more specifically at dealing with our ladder functionality. We modified some of the code and retried multiple versions of the code. We still don't have a functional ladder struct for managing ladder movement, I feel like we are close though, but we're still missing something. Thankfully we have more time than we originally expected to work on the code.

I'm not sure if I mentioned it earlier or not but over the one weekend we created an end credit sequence and used SDL2 to animate an ending animation that was taken from a gif. After searching the internet for how to display an animated gif file through SDL2, I discovered most people had issues getting an animated gif to display anythign other than just one frame fo that gif. So I had the gif broken up into its individual frams and then created a loop int he game to create the animation that we use for our end game sequence.

The current state of our very mangled, very commented out as disabling parts, code:

/************************************************************
 *
 * Super Mega Awesome Donkey Kong
 * a.k.a. Dankey Kang
 * a.k.a. Dunkey Kung
 * a.k.a. Kunkey Dung
 *
 * Developers:      Zack Golden
 *                  Matthew Page me@matthewjpage.com
 *                  Dan Shadeck
 *
 ***********************************************************/

#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>

//printlocation() function declaration
void printlocation(int x, int y, int ladderflag, int floorflag)
{
    printf("X: %d  Y: %d\n", x, y);
    printf("ladderflag: %d  arrayflag: %d\n", ladderflag, floorflag);
}

//map() function declaration
void map(SDL_Renderer * renderer)
{
    //Clear screen
    SDL_SetRenderDrawColor( renderer, 0x00, 0x00, 0x00, 0x00 );
    SDL_RenderClear( renderer );

    //Donkey Kong Floors and Ladders
    SDL_Rect Floor1 = { 20, 440, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor1 );

    SDL_Rect Ladder1_2 = { 560, 340, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder1_2 );

    SDL_Rect Floor2 = { 20, 340, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor2 );

    SDL_Rect Ladder2_3 = { 60, 240, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder2_3 );

    SDL_Rect Floor3 = { 20, 240, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor3 );

    SDL_Rect Ladder3_4 = { 560, 140, 20, 100 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder3_4 );

    SDL_Rect Floor4 = { 20, 140, 600, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor4 );

    SDL_Rect Ladder4_5 = { 240, 60, 20, 80 };
    SDL_SetRenderDrawColor( renderer, 0x55, 0xDD, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Ladder4_5 );

    SDL_Rect Floor5 = { 200, 60, 100, 10 };
    SDL_SetRenderDrawColor( renderer, 0xFF, 0xFF, 0xFF, 0xFF );
    SDL_RenderFillRect( renderer, &Floor5 );

    //Mario block
    //SDL_Rect Mario = { 310, 405, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0x00, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Mario );

    //Donkey Kong himself
    //SDL_Rect Donkey = { 60, 40, 60, 100 };
    //SDL_SetRenderDrawColor( renderer, 0xDD, 0x51, 0x00, 0xFF );
    //SDL_RenderFillRect( renderer, &Donkey );

    //Princess Peach (win condition)
    //SDL_Rect Peach = { 210, 25, 20, 35 };
    //SDL_SetRenderDrawColor( renderer, 0xFF, 0xAA, 0xDD, 0xFF );
    //SDL_RenderFillRect( renderer, &Peach );

    //Update screen
    SDL_RenderPresent( renderer ); 
}

int main(int argc, char ** argv)
{
    //variables
    bool quit = false;
    SDL_Event event;
    int x = 40;     //real mario start
    int y = 405;    //real mario start
    //int x = 400;  //start mario testing
    //int y = 105;  //start mario testing
    int ladderflag = 0;  //restrict left/right movement while on ladder
    //int floorflag = 1;   //stating whether mario is on a floor, to be used in conjunction with ladderflag

    struct ladder {
        int xleft;
        int xright;
        int ytop;
        int ybottom;
        int ladderflag;
    };
    
    int i;
    struct ladder ladarr[2];    //laddar array

    ladarr[0].xleft=555;
    ladarr[0].xright=570;
    ladarr[0].ytop=305;
    ladarr[0].ybottom=415;
    ladarr[0].ladderflag=0;

    ladarr[1].xleft=40;
    ladarr[1].xright=65;
    ladarr[1].ytop=205;
    ladarr[1].ybottom=310;
    ladarr[1].ladderflag=0;

    //initialize SDL
    SDL_Init(SDL_INIT_VIDEO);
    IMG_Init(IMG_INIT_PNG);

    SDL_Window * window = SDL_CreateWindow("Super Mega Awesome Donkey Kong",
        SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
    SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * image = IMG_Load ("mario.png");
    SDL_Surface * image2 = IMG_Load ("donkey.png");
    SDL_Surface * image3 = IMG_Load ("princess.png");
    SDL_Texture * texture = SDL_CreateTextureFromSurface(renderer, image);
    SDL_Texture * texture2 = SDL_CreateTextureFromSurface(renderer, image2);
    SDL_Texture * texture3 = SDL_CreateTextureFromSurface(renderer, image3);

    SDL_SetRenderDrawColor(renderer, 0, 0, 0, 0);
    
    map(renderer);

    //main game loop
    while (!quit)
    {
        SDL_WaitEvent(&event);

        map(renderer);

        /*
        if ((x<245) && (x>220))
        {
            if ((y>25) && (y<110))
            {            
                ladderflag=1;
            }
            else
            {
                ladderflag = 0;
            }
        }
        else
        {
            ladderflag=0;
        }
        */

        /*
        //floorflag check
        if ((y==405) ^ (y==305) ^ (y==205) ^ (y==105) ^ (y==25))
        {
            floorflag=1;
        }
        else
        {
            floorflag=0;
        }
        */

        //win condition
        if (y==25)
        {
            if (x==230)
            {
                quit = true;
            }
        }

        /*
        if ((x<570) && (x>555))
        {
            if ((y>105) && (y<210))
            {            
                ladderflag=1;
            }
            else
            {
                ladderflag = 0;
            }
        }
        else
        {
            ladderflag=0;
        }
        */

        /*
        if ((x<65) && (x>40))
        {
            if ((y>205) && (y<310))
            {            
                ladderflag=1;
            }
            else
            {
                ladderflag = 0;
            }
        }
        else
        {
            ladderflag=0;
        }
        */

        for(i=0;i<2;i++)
        {
            if (((x+5)<ladarr[i].xright) && ((x+5)>ladarr[i].xleft))
            {
                if ((y>ladarr[i].ytop) && (y<ladarr[i].ybottom))
                {            
                    ladarr[i].ladderflag=1;
                    printf("Ladder flag is affirmative!!!\n");
                    ladderflag=i;
                }
                else
                {
                    ladarr[i].ladderflag = 0;
                    ladderflag=-1;
                    printf("Broken!\n");
                }
            }
            else
            {
                ladarr[i].ladderflag=0;
                ladderflag=-1;
                printf("Broken!\n");
            }
        }

        //suicide prevention
        if (y==25)
        {   
            if (x>280)
            {
                x=280;   
            }
        }
        else
        {
            if (x<20)
            {
                x=20;
            }
            if (x>600)
            {
                x=600;
            }
        }

        switch(event.type)
        {
        case SDL_QUIT:
            quit = true;
            break;
        case SDL_KEYDOWN:
            switch (event.key.keysym.sym)
            {
            case SDLK_LEFT:
                if ((ladderflag != -1)) //&& (floorflag == 0))
                {
                    x=x;
                    break;
                }
                else
                {
                    x=x-5;
                }
                break;
            case SDLK_RIGHT:
                if ((ladderflag != -1)) // && (floorflag == 0))
                {
                    x=x;
                    break;
                }
                else
                {
                    x=x+5;
                }
                break;
            case SDLK_UP:
                        if (ladderflag != -1)
                        {
                            y=y-5;
                        }
                break;
            case SDLK_DOWN:  
                        if (ladderflag != -1)
                        {
                            y=y+5;
                        }
                break;
            }
            map(renderer);
            printlocation(x,y,ladderflag, ladarr[i].ladderflag);
            //break;

        }
       

        SDL_Rect dstrect = { x, y, 20, 35 };
        SDL_Rect dstrect2 = { 60, 40, 60, 100 };
        SDL_Rect dstrect3 = { 210, 25, 20, 35 };

        //SDL_RenderClear(renderer);
        SDL_RenderCopy(renderer, texture, NULL, &dstrect);
        SDL_RenderCopy(renderer, texture2, NULL, &dstrect2);
        SDL_RenderCopy(renderer, texture3, NULL, &dstrect3);
        SDL_RenderPresent(renderer);
                
    }

    //cleanup parts not used for win message
    SDL_DestroyTexture(texture);
    SDL_DestroyTexture(texture2);
    SDL_DestroyTexture(texture3);
    SDL_DestroyRenderer(renderer); 
    SDL_FreeSurface(image);
    SDL_FreeSurface(image2);
    SDL_FreeSurface(image3);
/*
    //win message
    SDL_Renderer * renderer2 = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * imageend = SDL_LoadBMP("end.bmp");
    SDL_Texture * textureend = SDL_CreateTextureFromSurface(renderer2, imageend);
    SDL_RenderCopy(renderer2, textureend, NULL, NULL);
    SDL_RenderPresent(renderer2);

    SDL_Delay(2000);

    //cleanup SDL
    SDL_DestroyTexture(textureend);
    SDL_DestroyRenderer(renderer2);
    SDL_FreeSurface(imageend);
*/

/*
    //win message part 2
    SDL_Renderer * renderer3 = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * imagetest1 = SDL_LoadBMP("test1.bmp");
    SDL_Texture * texturetest1 = SDL_CreateTextureFromSurface(renderer3, imagetest1);
    SDL_RenderCopy(renderer3, texturetest1, NULL, NULL);
    SDL_RenderPresent(renderer3);
    SDL_Delay(2000);
    SDL_DestroyTexture(texturetest1);
    SDL_DestroyRenderer(renderer3);
    SDL_FreeSurface(imagetest1);

    //win message part 3
    SDL_Renderer * renderer4 = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * imagetest2 = SDL_LoadBMP("test2.bmp");
    SDL_Texture * texturetest2 = SDL_CreateTextureFromSurface(renderer4, imagetest2);
    SDL_RenderCopy(renderer4, texturetest2, NULL, NULL);
    SDL_RenderPresent(renderer2);
    SDL_Delay(2000);
    SDL_DestroyTexture(texturetest2);
    SDL_DestroyRenderer(renderer4);
    SDL_FreeSurface(imagetest2);

    //win message part 4 (occasionally skips)
    SDL_Renderer * renderer5 = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * imagetest3 = SDL_LoadBMP("test3.bmp");
    SDL_Texture * texturetest3 = SDL_CreateTextureFromSurface(renderer5, imagetest3);
    SDL_RenderCopy(renderer5, texturetest3, NULL, NULL);
    SDL_RenderPresent(renderer5);
    SDL_Delay(2000);
    SDL_DestroyTexture(texturetest3);
    SDL_DestroyRenderer(renderer5);
    SDL_FreeSurface(imagetest3);

    //win message part 5
    SDL_Renderer * renderer6 = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * imagetest4 = SDL_LoadBMP("test4.bmp");
    SDL_Texture * texturetest4 = SDL_CreateTextureFromSurface(renderer6, imagetest4);
    SDL_RenderCopy(renderer6, texturetest4, NULL, NULL);
    SDL_RenderPresent(renderer6);
    SDL_Delay(2000);
    SDL_DestroyTexture(texturetest4);
    SDL_DestroyRenderer(renderer6);
    SDL_FreeSurface(imagetest4);
*/

/*
    //mario gif sequence
    int counter = 0;
    int delay = 50;
    while (counter < 20)
    {
        //A sequence
        SDL_Renderer * rendererA = SDL_CreateRenderer(window, -1, 0);
        SDL_Surface * imageframe0 = IMG_Load ("marioframe/frame_000.png");
        SDL_Texture * textureA = SDL_CreateTextureFromSurface(rendererA, imageframe0);
        SDL_RenderCopy(rendererA, textureA, NULL, NULL);
        SDL_RenderPresent(rendererA);
        SDL_Delay(delay);
        SDL_DestroyTexture(textureA);
        SDL_DestroyRenderer(rendererA);
        SDL_FreeSurface(imageframe0);

        //B sequence
        SDL_Renderer * rendererB = SDL_CreateRenderer(window, -1, 0);
        SDL_Surface * imageframe1 = IMG_Load ("marioframe/frame_001.png");
        SDL_Texture * textureB = SDL_CreateTextureFromSurface(rendererB, imageframe1);
        SDL_RenderCopy(rendererB, textureB, NULL, NULL);
        SDL_RenderPresent(rendererB);
        SDL_Delay(delay);
        SDL_DestroyTexture(textureB);
        SDL_DestroyRenderer(rendererB);
        SDL_FreeSurface(imageframe1);

        //C sequence
        SDL_Renderer * rendererC = SDL_CreateRenderer(window, -1, 0);
        SDL_Surface * imageframe2 = IMG_Load ("marioframe/frame_002.png");
        SDL_Texture * textureC = SDL_CreateTextureFromSurface(rendererC, imageframe2);
        SDL_RenderCopy(rendererC, textureC, NULL, NULL);
        SDL_RenderPresent(rendererC);
        SDL_Delay(delay);
        SDL_DestroyTexture(textureC);
        SDL_DestroyRenderer(rendererC);
        SDL_FreeSurface(imageframe2);

        //D sequence
        SDL_Renderer * rendererD = SDL_CreateRenderer(window, -1, 0);
        SDL_Surface * imageframe3 = IMG_Load ("marioframe/frame_003.png");
        SDL_Texture * textureD = SDL_CreateTextureFromSurface(rendererD, imageframe3);
        SDL_RenderCopy(rendererD, textureD, NULL, NULL);
        SDL_RenderPresent(rendererD);
        SDL_Delay(delay);
        SDL_DestroyTexture(textureD);
        SDL_DestroyRenderer(rendererD);
        SDL_FreeSurface(imageframe3);

        //E sequence
        SDL_Renderer * rendererE = SDL_CreateRenderer(window, -1, 0);
        SDL_Surface * imageframe4 = IMG_Load ("marioframe/frame_004.png");
        SDL_Texture * textureE = SDL_CreateTextureFromSurface(rendererE, imageframe4);
        SDL_RenderCopy(rendererE, textureE, NULL, NULL);
        SDL_RenderPresent(rendererE);
        SDL_Delay(delay);
        SDL_DestroyTexture(textureE);
        SDL_DestroyRenderer(rendererE);
        SDL_FreeSurface(imageframe4);

        counter++;
    }
    */

    SDL_DestroyWindow(window);
    IMG_Quit();
    SDL_Quit();


    return 0;
}

Today in class we officially decided to close the first project up, despite not really being done and start fresh with a new coding project. We are lookign at really doing two things at once, one set of thigns woudl be rewriting some command line utilities liek chmod and ls, the other would be workign on the next game, of which essentially we are all in the same project adn group for this game. The idea being that some people may be more core to the development of the game, whereas people who may be doing more with the command line utilities may be coming in when issues and bugs occur and being a fresh set of eyes t try to resolve issues in the game.

The game idea we are plannign to implement is a top down space game, where we hava a galactic map with agrid and sectors from which the spaceship can fly to a sector and then fly around and fight enemy ships in that sector, and possibly int he future adding things like docking at bases, and myabe buying and seeling commodities or getting missions.

We set upa repo for this game and gave access to everyone in the class here on github:
https://github.com/robgraves/lairspace

Dan Shadeck and I after the last games clutter in our repo of us each having our own subfolder that we had working version for the code in, decided to learn how to manage branches, and merging testing branches into the master branch and vice versa. After maybe and hour or so of reading some tutorials and testing it, I think we have a pretty good handle on it so that we can do this for this next game project, to use version control's branching properly.

In todays class we started organizing our repo for the new game project. We have a few examples from the asteroids teams code as the basic movement for the lairspace game will be similar to the asteroids game, having asteroids serve as a prototype for that game. We also creted soem directories in our repo, one for images, one for source code, and one for binaries (which in retrospect might be unnecessary as how many binaries are we gonna have for this game?).

We also looked at the Makefile from the asteroid team a littl ebit and the one we had used for donkey kong, and we decided to just tweak the donkey kong one and add stuff as necessary when needed. Also we wrote up the barebones basic code to get a ship image to display on a window in our base code, however, the image was stretched to alarger size than the roginal, which we haven;t figured out why yet. But being our first real day working on this game, I feel like we got some decent framework stuff down and started.

I didn't actually work on anything related to SysProg or the LAIRSPACE game today. Instead I worked on some fallen behind math homework I had built up, and made a little progress on that. Also worked on writing up an instruction for HPC Sys & Net class for the NES simulator, 0x60 RTS Return from Subroutine. I also started looking into some Java books on pdf with Dan to try to learn some Java to help us with Joe's class in Comp Org and when Casper showed up we tried writing up a Nand class and RsNandLatch class.

Today we talked a little bit about our game, lairspace but didn;t really do much more with it. We had a side diversion of trying to express the importance of the LAIR on posterboard which may become soemthing we all collectively work on between all LAIR classes for something to give to the President of the college and their minions. Current state of the lairspace code:

1

#include <stdio.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
 
int main(int argc, char ** argv)
{
    bool quit = false;
    SDL_Event event;
    const int SCREEN_WIDTH = 640;
    const int SCREEN_HEIGHT = 480;
 
    SDL_Init(SDL_INIT_VIDEO);
    IMG_Init(IMG_INIT_PNG);
 
    SDL_Window * window = SDL_CreateWindow("LAIR SPACE", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, 0);
    SDL_Renderer * renderer = SDL_CreateRenderer(window, -1, 0);
    SDL_Surface * image = IMG_Load ("../img/playerShip.png"); 
    SDL_Texture * texture = SDL_CreateTextureFromSurface(renderer, image);
    SDL_RenderCopy(renderer, texture, NULL, NULL);
    SDL_RenderPresent(renderer);
 
    //game loop
    while (!quit)
    {
        SDL_WaitEvent(&event);
        switch(event.type)
        {
        case SDL_QUIT:
            quit = true;
            break;
        }   
    }
 
    //cleanup
    SDL_DestroyTexture(texture);
    SDL_DestroyRenderer(renderer);
    SDL_FreeSurface(image);
    SDL_DestroyWindow(window);
    IMG_Quit();
    SDL_Quit();
 
    return 0;
}

Today we didn't really work on the LAIRSPACE game at all. However, David Woodcock and myself had a mini discussion about how our team from the previous game, the Donkey Kong team, used textures to blit our images, whereas his team did something else, he was going to push a version of lairspace that blits the image the way his team, the asteroid team, did theirs so that we can determine what route we want to take.

I'm actually at a point right now with both of these two LAIR classes on Tuesday/Thursdays, where I'm not entirely sure what to do. Like in the case of this class, Systems Programming, we started workign on Donkey Kong in a very small team of 3 of us and met regularly outside fo school and I pushed real hard to try to make us get stuff done, so that we made some progress. At beginnign of March this game came to a close and we shifted as a class to a new game, LAIRSPACE, whcih the whole class is in the same group. Which is the first issue, I find its harder to collaborate with a larger group of people. I was almost thinking I was gonna go the route of the people who worked on rewriting system tools like ls or chmod as that sounded more interesting to me than trying to write another game that we probably won't finish. Also since I pushed so hard and wrote so much code directly for Donkey Kong, I figured I'd change roles and be one of the non day to day coders and be one of the people who came in and tried to solve bugs after the fact. But without any real existing code that becomes moot, also no real sign of starting on the linux tools code writing, is that still happening?

*Writing unix tools*

Function calls are like library calls

System calls go to the kernel or operating system
-like malloc() asks the kernel to allocate memory for us.

*Concurrency* -Multiprocessing
-spawn child processes like Apache webserver.

-Multithreading - provided by OS -multiprocessing on the function level, like when a game has a finction runnign sound, another one running network, another handling input.

*file descriptors*

cat 0< in
ls 1> out
ls 2> err

we looked at the man page for chmod which defaults to page one, then we looked at the page 2 for chmod to see more system programming.

man 2 chmod

noted the mode_t

we went into /usr/include and searched for stat.h with:

find . -name stat.h

found the actual system calls for lab46 64 bit debian at /usr/include/x86_64-linux-gnu/unistd_64.h

The kernel handles all the files int he filesystem, when you wna tto change somethign, you are askign the kernel to make those changes.

We rewote a chmod,, I called mine chmoddy.c:

1

/********************************
 * Matthew Page
 * System Programming
 * 03/26/2015
 *
 * chmoddy.c - rewrite chmod
 *
 *******************************/
 
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
 
int main(int argc, char **argv)
{
    int i=0;
    int j;
    char c;
    int mode=0;
 
    if (argc != 3)
    {
        fprintf(stderr, "Error! Incorrect argument count!\n");
        exit (1);
    }
 
    //mode = atoi(argv[1]);
    while(*(*(argv+1)+i) != '\0')
    {
        c = *(*(argv+1)+i);
        if (c >= '4')
        {
            mode = mode | S_IRUSR >> i*3;          
            c=c-4;
        }
        if (c >= '2')
        {
            mode = mode | S_IWUSR >> i*3;   
            c=c-2;
        }
        if (c >= '1')
        {
            mode = mode | S_IXUSR >> i*3;    
        }
        i++;
    }
    chmod(argv[2], mode);
    return (0);
 
}

Today I believe we worked on our own ls command in class.

I missed this day due to being in the hospital, etc.

Today we worked on the stat command I think.

I missed today as well.