Want to write a chapter in our book?

Working Title: Casebook on Gaming in Academic Libraries
An ACRL Monograph
Editors:
Amy Harris, University of North Carolina at Greensboro, a_harri2@uncg.edu
Scott Rice, University of North Carolina at Greensboro, serice2@uncg.edu

Deadline for proposals: August 31, 2007
Expected publication: Summer 2008

Gaming in all its forms is making its way into academia. “Casebook on Gaming in Academic Libraries” will provide case studies and reports of best practices and experiences in the many ways in which academic libraries have chosen to become part of this trend.

“Casebook on Gaming in Academic Libraries” will include three sections to encompass the variety of ways gaming has been incorporated into academic libraries.
Section 1: “Gaming as Marketing”
­ How is gaming used to bring students into the library and make students aware of other library services?
Section 2: “Gaming and Collections”
­ How have academic libraries started augmenting their collections with hardware and software?
Section 3: “Gaming and Teaching”
­ How is gaming used for teaching information literacy skills in academic libraries? How does gaming fit into the academic classroom?

Possible topics may include but are not limited to the following:
Information literacy games
Game night hosting
Student orientation games
Games in information commons
Game software and hardware collections
Games to train staff

Submissions
Individuals interested in contributing a chapter are invited to e-mail a proposal to the editors on or before August 31, 2007. Proposals should be 400-600 words and include information about your name, affiliation, a working title, and abstract. Authors of accepted proposals will be notified of acceptance by September 14, 2007. Full chapters will be expected by January 15, 2008.

Plus4 SD/MMC

SO, I've spent much of the day soldering away, and I've almost got the MMC part connected up. It's hard going though, and to top it all I think my soldering iron needs a new tip - again. The more I do of this, the more I wish I had that milling machine so I could just make a new board! Soldering in the sockets etc. is nothing, but stripping and soldering the wires is a nightmare!

Any-hoo, once I've done the last few wires, I'll try the code I have for reading the card and see how close I got...chances are it'll need lots of tweeking to get it working right.

SD/MMC+Clockport Prototype

So here we go again....I've started the SD/MMC+Clockport interface. While it should be fairly simple, I've not connected a clockport before, and I need to decode the lines pretty much down to the byte this time; for both the clock port and the MMC interface. This means the board is pretty full so I won't be able to add the RAM to this test one,but if I was making a proper board, theres nothing saying I couldn't do it on that. While I couldn't see any real use for a RAM only interface, this one I can (with or without the extra RAM). Having an MMC card slot and a clockport on a card would be pretty cool, and allow all manner of C64 apps to be ported, along with allowing the +4 onto the Net - or simply better comms to the PC. But best of all really is that anything that someone makes for the C64's Clockport, would be usable on the Plus4 (with a little relocation - something +4 guys are pretty good at!).

Of course, if I added some RAM (128k,256k or 512k extra) it would mean that any clockport applications (like a TCP/IP stack or game) could make use of it, since you'd know everyone else running it would have the extra RAM as well. The only thing that worries me is the physical size of the interface. The C64 one is full of surface mount stuff - professionally done, but I guess this wouldn't be....

Oh well... first things first - lets get a working prototype and then worry about the rest of it!


Edit: Oh! And the little voltage regulator at the top, was just to see if I could solder one on without making a complete hash of it!

Getting orginised.

Yup, not been doing much.... A load of chips/parts have arrived so I've spent a couple of days sorting out my parts bin into some sort of order. I got fed up with not having the chips I needed/wanted, so I'm slowly trying to buy a few of everything (common chips at least), buit this means making some space for things.

I've also managed to source some pin headers for the clockport stuff, so Im going to start wiring up a SD/MMC+Clockport interface for the Plus4 next then I can start to have some REAL fun!!

I still need to finish doing the basic directory on the MMC, but that shouldn't be a big issue, and then loading a file should simply be a matter of getting the inital cluster from the directory entry, and reading it in.

I'm kinda looking forward to playing with the clockport the most, as it could mean some cool off the shelf toys for folk. The ethernet contoller looks the most fun, and I have the UDP slave source here to try out. Could be good!!!

I'm off to SigGraph in SanDiago next friday (3rd Aug), so I'll be back on XeO3 at that point, and I hope to get some stuff done on the plane again; but as usual it depends on how close the bloody seats in front are!

MMC Success!!

And here you go!! The ROOT directory in all its glory! I'm not parsing past the end of the 1st sector, but thats okay for now. I can now plug in any card (I have 3; 32Mb, 256Mb, 2GB - all FAT16) and I can display the ROOT directory of each of them. I guess the next thing to do is load a file from it..... or I could finish displaying the root directory, and sub directorys of course. But loading a file is pretty exciting stuff :)

I dont really want to get too far into it, as the main goal is to do a Plus4 version, not a C64 one. Although the code will be identical so its not wasted work.

Another big thanks to TNT for helping be get started with this....

Another Session: Information Literacy through a Unique Education Gaming Applications

By Annie Downey and Kristin Boyett from the University of North Texas

At the beginning of a three-year, three-quarter of a million dollar project to build an RPG.

Incorporates 3 Educational Elements: Information Literacy, Online Education, Educational Gaming

Game requires full participation- experiential learning, inquiry-based learning

Game design concept:
Character driven
Problem solving
First-person
Linear
Modules build on one another

Game can't be lame. They're sacrificing some learning to avert lameness.

Program requirements:
Student logins
Ability to save
Monitoring capabilities

Evaluation Plan:
Usability testing during development
Focus groups
Game designers on UNT faculty
Student evaluations (cross-compared with traditional LI)

Personnel:
Annie, Kristin, Programmer (hired at competitive salary), team of part-time/student programmers, faculty advisers

Budget: huge

My summary: Grants are cool. This definitely gave us some things to think about when we work on the Next Big Thing. Again, it's also nice to see that gaming has room for everyone, from the huge money projects to our little game.

Keynote Speech: Big Fun, big learning: Transforming the world through play

Good morning! Another live-blog from the land of Gaming, Learning and Libraries, this one by Gregory Trefry from GameLab (created Diner Dash- cool game!).

Held Come Out & Play Festival in NYC last year.

Real-life city-wide games, like Human Pong

Alternative Reality Games: large online games (like I Love Bees)

Big games are also partly social experiment: Huge pillow fight in a square in Toronto

The Canon:
PacManhattan- people strap Pac Man suit on and run around Washington Square with ghosts chasing you, marked off areas and used cell phones to call when he arrived in
Mogi-Mogi- people pick up virtual objects using cell phones
Big Urban Game- people took big balloons around city, anyone could join (in Twin Cities)
The Beast- tie-in with movie AI. Microsoft thought they designed 6 months of content, people on online bulletin boards solved in 3 days
Space Invaders- projected on a building in Manhattan, used motion-detecting cameras for movement (could we do this on the side of Jackson Library? AH)
Journey to the End of the Night- Kind of like Zombie Tag. People had to run all over NYC and try to avoid capture
You Are Not Here- paper with NYC map on one side and Baghdad on the other, had to hold paper up to sun and find places in Baghdad by going to places in NYC, when people arrived they learned about a place in Baghdad
Payphone Warriors- Identified 30 or 40 payphones in the city and people had to make a call from each one. Like Capture the Flag.

His Trip to the Library: Hadn't been in a while, went to NYPL (it was closed)
Library Assets: many locations (game board!), Collections (photos, etc.), Spaces (built-in territory to capture), Content, Persistence, Unique Identifiers (scanners would be cool), Referees (librarians), Tools (copiers, computers, wifi), Display (to keep track of the game), Refreshments

5 Ideas:
Secret Agent (scavenger hunt)- secret meeting spots, ask referee a question, avoiding detection (to avoid disturbing others, say if referees catch you, you'll lose points), collect codes (like DaVinci Code), Level Up (higher level after a certain number of tasks)
Then and Now (citywide photo hunt)- take old photos and ask students to take pictures of what it looks like now
Rent Control- the real real estate game- uses old rent maps
Abolish (ARG)- narrative about ending slavery
Babel! (Code breaking)- students in teams have to figure out a message
Dewey's Demons (collect creatures generated by codes)- web-based game where checking out books give them codes which can give them characters

Process: Look around the world, Give normal activities goals, Simple ways to track moves, Playtest, playtest, playtest

My summary: I want to create a big game for our library. Now. That would definitely improve the fun quotient of our freshman library tour.
Oh yeah, and project an old arcade game on the library tower.

Come out and play, September 28-29

MMC progress...

Well, I'm slowly progressing with my MMC card reading, I've gotten sector reading working okay, and from there read the boot sector with the partition information and then onto the FAT Mast Boot Record. However, I'm struggling to get from there to the root directory. The only info I have says that I use the root FAT+ReservedSectors+FatSectorSize = DirRoot, and while this works for one card, it appears to be coincedance.

Once I can get the root directory, it should be plain sailing to load a file. Each Directory entry points to a base sector (or cluster) and from there you use the FAT to cluster hop, reading in the file. I have to confess, I thought sectors were allocated rather than clusters and that sectors were resizable. But it appears that its the number of sectors in a cluster that changes. oh well, its much the same I guess.

Once I have a file loading, I'm going to build a Plus4 interface - or add it to my MemoryCard expansion, Im not sure...I guess it would be easier to build a seprate interface, although Im having a little trouble figuring out the best way of reading the card. The only way I can figure is using 2 flipflop buffers, one for in and one for out. However, the ChipSelect on the card may help with this, I havent sat down and worked it out yet.

Another Session: Making Book: Gaming in the Library

By Natalie Gick, Simon Fraser University

GamesRoom is in it's third iteration

GamesRoom v1: TechBC
Student Initiative: for game design, other areas of study, future employment

GamesRoom v2: SFU Surrey
PCs, Consoles and TVs
Students using GamesRoom started using other library services

GamesRoom v3: New campus
About 500 sq. ft.
Gaming equipment and shelving, soundproof

400+ games
3 day loan
Boxes shelved, games behind shelf
Lock or loan (TVs are locked down, everything else is checked out)

Also have a guitar and a driving wheel

PC Games
Over 100
4 hour loan (for in-library use)

Gameboy Advance and Nintendo DS

Legacy Systems: Reproduction arcade game with lots of old games

Copyright and Loans
PC Games: Click-through licenses, compromise is 4 hour loan period
Console games: DVD-like
Permission to Loan: who owns rights?, asking was largely unsuccessful

Partnerships/Collaboration: Library, School of Interactive Arts and Technology, Academic Computing Services (buy and support), Student Games Club (3 liaisons to library)

Management: Pre-load (can run out of space), now hybrid (pre-install some, students install others, regularly re-image)

Multiplayer gaming: Games Night in the labs (sponsored by Games Club), computers are reimaged the next day

Online Gaming: uses too much bandwidth

Selecting Games: Students, Gaming Research Group, Faculty & Graduate Students, Librarian Jamie Anderson (use Metacritic, Game Developer Choice Awards, BAFTA, School Library Journal to help)

Purchasing Games: Amazon, Best Buy, Baker & Taylor, EB Games, Library Acquisitions (Platform, version, direct link to game)

Cataloging: Searchable platform (538 System Requirements) or Local MARC field (made searchable, created authority file for platform names), game Key is suppressed in local field

Challenges: Equipment failures, Noise, Monopolized (not enough women), Abuse of privileges

Code of Conduct

My summary: What a fantastic idea for libraries! A space that's completely fun for students to use to blow off steam. That is a great way of doing outreach.

Next Techsource Session: Gaming in the Library: From Collections to Services and Beyond

By Lisa Hinchcliff from UIUC

Gaming Initiative:

Collections
Games are an important text of our culture, trying to create a historic collection today
Needs assessment
Funding: used media and monograph money, Friends of Library, donations
Collection Storage: anything that would fit into lockable DVD case is on shelf, Guitar Hero guitar is at desk
Access and Use Policies: 1 week checkout (same as movies)
Licensing/Publisher Relations: game system games not a problem, PC games are a problem because of registration

Archiving
Game as Object (the game itself) vs. Game as Experience (game as people played it)
Vintage Games Donations
Emulation and Emulators (code)
XBox Live and Nintendo Virtual Console

Teaching and Research
Interdisciplinary and Multidisciplinary
Classroom Use and Support (games on reserve, loaded on library computers)

Outreach
Gaming News Blog
Gaming Nights
Librarians as Researchers and Teachers
Collaborations on Archival and Use Standards
Campus Gaming in Learning Symposium in Fall 2008

Summary: UIUC does cool stuff.

Gaming in Academic Libraries: The Why and How

This session is being presented by our friends down the road, Lynn Sutton and Giz Womack from Wake Forest, and Lori Critz from Georgia Tech.

Wake Forest heard about Game Night from Georgia Tech, as a marketing technique to reach freshmen who don't attend library tours. They also wanted to support innovation and creativity. They also see gaming as more than marketing, games were social networks before there were social networks.
Game Night Formats
Open Game Nights:
Two on Fridays in September from 7-11
One on Friday in February from 7-11

Tournament:
Held on a Friday in February from 3-6

Students registered in advance for both formats, they can come without signing up, but can't play

Resources:
Partners- Library IT Team Staff, Resident Technology Advisors (already established relationship)
Equipment- LCD Projectors (got old ones from campus IT), Screens, Students bring systems
Supplies- Food, Extension Cords, Tape and Sharpies (for labeling equipment), RCA connectors, Trophies

Marketing:
Email, flyers, word of mouth, student newspaper, flyers with lollipops attached, You Tube video

Costs:
First one- $425 (rented screens)
Subsequent ones- about $170 (have since purchased screens)

Survey:
Have surveyed students twice

• Students like the events
• Students like bringing their own consoles
• They like both open gaming and tournaments
• Keep mixing it up

Georgia Tech Gaming

Part of RATS (Recently Acquired Tech Students) Week
Get library staff involved with students
Brand library as center of technology

Marketing:
Facebook, flyers, posters

Planning:
Formed committee with IT and library (IT set up LAN, library handled everything else)

Used Unreal Tournament (1st person shooter)

Also included food, music, DDR, demos, GT improv group, A capella club, Anime Club, etc.

Set-up:
Projection Screen (rented for $500, about 12 feet wide)
Computer Stations- Game loaded on each machine, dusted each machine to limit overheating, headphones added

Tournament:
4-30 minute elimination rounds and finals
64 players per round
Finalists= Top 4 scorers for each round
Gamers could use own controller
Players pre-registered for time slots

Prizes:
Semifinalists won headphones, B&N giftcards, flash drives
Winner won 20 GB hard drives

Clean-up:
Took a lot of time

Gains:
Coolness factor
Face recognition
Partnership with IT
Subtle indoctrination
Clubs see library as good partner
Image boost for staff

Lessons learned:
Unreal Tournament had limited appeal to females and non-gamers
350 estimated hours of labor put in
Expensive
Not possible without volunteers

Today at GT:
Changed date away from fraternity rush (crowd increased to 700!)
Retro gaming (Donkey Kong, Pac Man)
Board games
Poker tournament
Speed dating
Ninja Tag
DDR

My thoughts:
This presentation was great. I enjoyed seeing how other universities do Game Night. I'm glad that our Game Night is very low-key in comparison. We don't do signups anymore, and the LAN tournament just sounds way too labor-intensive for me! Also, our experience with cleanup was vastly different than that at GT. After our first Game Night. I picked up one cup. I think the students so badly wanted us to do it again that they went out of their way to make sure things were picked up. Many of them also stuck around to help us clean up.

Also, I have to echo their emphasis on working with student groups. Our Game Night would be nearly impossible without the help of the Science Fiction Fantasy Federation, Student Government and the Campus Activities Board. SFCubed provides our game systems and does some marketing, SG helps with marketing, and CAB markets and checks IDs at the door. Without their help, we probably couldn't pull it off.

I'm already excited about our next Game Night on September 5!

Live from ALA Techsource Gaming Symposium!

I'm blogging live from ALA Techsource Gaming, Learning, and Libraries Symposium, where I'll be blogging for the next two days. Scott and I are speaking tomorrow morning, so if you're here, please come and see us!

Speed up!!

Well, thanks to a quick bit of spotting by TNT, Its down to around 11 seconds for 64k! Around 3 scanlines a byte - well cool... Thats actually usable as it is I'd say! And although it will slow down a bit (due to saving the output to the correct place, sector selction etc...) Thats still bloody good. Anyway, heres the brainwave TNT got...

GETBIT3 macro
        stx   port         ; Clock pulse
        sty   port         ;
        cpy   port         ; if Databit is 0, then Carry clear, else set.
        rol
        endm

Very cool indeed...Branchless, and 4 cycles per bit quicker... I NEVER would have spotted that one!!

MMC Reading...

Mmmmm....It just goes to show how well the MMC64 card was made. Currently I can load a full 64k in around 15 seconds (load is a loose term here...cycle through 64k of sectors is more like).

The MMC64 can load 61k in 3 seconds....damn thats fast! I think they allow proper access to it rather than SPI mode where the CPU "clocks" the bits in. I can probably speed that up by putting a PIC on there and having BYTE access to the card. But thats a LOT of work.

If I put a byte Read/Write port in there, then got the PIC to do the bit talking, then the Plus/4 could just read/write bytes. I guess that would be a x8 speed up (ish), but it might be a bugger to do. That would be almost on par with the MMC64 though, and with the higher clockspeed of the Plus4, I might even beat it.

I swapped the DataIn line from bit 3 (0-7) to bit 7, which meant I could use the BIT instruction to read it, there by freeing up the A register. So now I have a macro to read a bit like this...

GETBIT  macro
        stx   port      ; Clock pulse
        sty   port      ;
 
        asl             ; Shift incoming data to make space for new bit
        bit   port
        bmi  !skip   ; Bmi is reversed
        ora  #1
!skip
        endm

This is a special ReadSector() call used when reading the actual data (does 4096 BIT reads - 512 bytes), the write is longer and far slower, but doesn't get used nearly as much. Before I moved the bit from 3 to 7, I had to LDA, then AND, then deal with memory etc.... but by using BIT I can and the AND from memory without affecting anything else. I suspect this is about as fast as it can go via the user port.

MMC/SD reader....

Well, I've managed to get basic reading working, or rather the basic circuit and reading using the sample program. However, thats half the battle. I was struggling a little due to lack of proper chips, but I've managed to pick up the correct ones, so I'm back on track. I'll get the core Init/Read/Dir working, then I'll switch to the Plus/4 and see how I get on from there.

I suspect that I'll do it as an expansion card and not USER PORT plug-in though, as it allows me to download via my cable to program it - and perhaps even use my remote debugger which is partly written.

RR-Net and MMC cards

I've been playing with a cool little design for an MMC card reader on the C64, mainly so I can understand it and then try it out on the Plus/4. I've had to modify it a little as I dont have the chip he's using, but it should still work okay.

It's a user port based one so is easy to play with, but it did mean I couldn't use my download cable! Damn! However, now that I have an RR-NET, I found a cool little program called udpslave, which is exactly like my download program anyway, but over ethernet! Very neat. it also means you dont need a parallel port anymore, so I could use a laptop.

The more I look at these things the more I think it would be very cool to have on the Plus/4. Its another fairly simple addition I could add to the memory expansion I guess, as it only needs 4 bits of memory (3 out,1 in).

Its in situations like this though, that I'd KILL for a proper remote debugger! This is the reason you need to step through the actual code on the real machine...Oh well.. back to printing to the screen I guess.

Clockports, RR-Net's, SilverSurfer's.....

I just bought a RR-Net and SilverSurfer and have been playing with them a little, and I'm pretty impressed I have to say! Since both these products are modules that just "plug-in", they would work just fine on a Plus/4, and all you need is to be able to map the port into a set of hardware registers - a GAL would work just fine for that! You can do it pretty simply with a couple of other chips, but GAL's are really cheap, and make development really easy, so sod it :)

Anyways.... TNT kindly provided me with a link to the data, so I thought I'd post it here (so I dont lose it mainly...).

                  CLOCK PORT 

                   +--+--+ 
         GND       | 1| 2|   VCC (+5V) 
                   +--+--+ 
         /INT      | 3| 4|   /SPARE_CS 
                   +--+--+ 
         /RTC_CS   | 5| 6|   /PWR_BAD 
                   +--+--+ 
         /IORD     | 7| 8|   /IOWR 
                   +--+--+ 
         A3        | 9|10|   A2 
                   +--+--+ 
         A1        |11|12|   A0 
                   +--+--+ 
         D7        |13|14|   D6 
                   +--+--+ 
         D5        |15|16|   D4 
                   +--+--+ 
         D3        |17|18|   D2 
                   +--+--+ 
         D1        |19|20|   D0 
                   +--+--+ 
         GND       |21|22|   /RESET 
                   +--+--+ 
 
 
 
Connection to C64 Expansion Port 
---------------------------------
 
 
  Clock Port Signal   |   Expansion Port Signal 
----------------------------------------------------- 
            GND      <=>  GND (22 and Z, not 1 and A) 
            VCC      <=>  +5V (2 and 3) 
            /INT     <=>  /NMI 
            A0-A3    <=>  A0-A3 
            D0-D7    <=>  D0-D7 
            /RESET   <=>  /RESET 
 

This should be really easy, and although you won't get NMI's, things like RR-NET don't use them anyway, and you can always POLL the hardware instead - pretty neat. I might even try and add it to my RAM expansion, as I need to decode other stuff there anyway.

Web site....

I've just "upgraded" to the new blogger template stuff, so some of the site may not look right, but I can't spot anything wrong just now. It has however allowed me to poll's on the bar to the right, and the 1st one is the RAM expansion. Please be honest when polling because it may well cost me money down the line.

Ram Expansion - Running test

I decided to see if normal games would actually RUN with the expansion installed, so I connected the last address line needed and wrote a special uploader for it, then modified XeO3 to use the RAM expansion instead of normal RAM, and here you go! It runs fine! No difference at all!

Theres no funny read,write or timing errors - it just works! Im not sure how Graphics would work there... You would have to set the TED bit for getting data from ROM instead of RAM, and if you switched bank, it would change instantly. However, if you keep the TED data in the lower half (or possibly top 16k), then you can use most of the RAM for "data". My sprite cache for example could be huge with this!! We could have LOTS of character set data - altering it as we scrolled through the level, or have the SID/TED music loaded into there freeing up normal RAM. Lots of things you could do... Also...16K of SID music per level would be well cool...

Of course....to get SID music, I'd have to do a SID add on with the RAM!! Not impossible, particually if I just copied SOLDER's - which already works great.

Super Expansion....

I've thought about this before, and Im still tempted by it; doing a super expansion for the plus/4. One with Extra RAM, SID and MMC all built in. this would be pretty cool, to the extent that someone might even code something for it!! Having simple access to mass storage (MMC) would also let you fill the extra RAM with ease, and mean your not bound by disk loading times etc.

Still, thats a long way off happening (if ever), but it would be pretty cool I think. I wonder how many people would want one? Could be fun!

Emulators...

I was just reading TNT's paradriod page, and read a great idea there, Emulator profilers. That is, using an emulator to give readings of things like memory usage, and general speed settings. This is a wonderful idea!! Having realtime profile information, just like proper development. I'll have to add this to Minus4 soon.

Plus/4 External RAM expansion.

I've managed to get a proof-of-concept working; that is external RAM plugged in and working without any internal modifications at all. If I add a hardware banking register I could add up to 256 banks of 16k giving up to 4Mb RAM (although that would be a BIG stack of chips!). However, a 128,256 or 512k expansion would me much simpler. Its good to see it working, even if no one and nothing will use it!

Bearing that in mind.... I do wonder if its even worth doing any more on it as it simply wont be used! Oh well... its nice to know I was able to do it - it might be nice as a development tool though, and if I were to add an MMC card, then the extra RAM could be used as a buffer. The problem with using it as a devtool though is that the ram under it will be fried. Thats not very good, but if you were writing a program to actually USE it, then it wouldn't be a problem as you would never use the upper 32k of the machines native RAM.

Heres how I switch it on and use it....

     sei
     lda #$ff
     sta $fdda       ; Enable Upper and Lower external banks

And thats it really... The idea is that BANK 0 is always mapped to $c000-$ffff, while $8000-$bfff is user selectable via a register somewhere. And finally, heres the equations for the GAL.

 /WRITE = A15* /A14* PH2* /RW               ; WRITE Enable  (32-48k)
 /CS =    /C1LOW* A15* /A14* PH2* RW        ; Chip Select on READ access  (32-48k)
       +  A15* /A14* PH2* /RW               ; On WRITE access  (32-48k)
 /OE =    /C1LOW* A15* /A14* PH2* RW        ; Output ENable on READ access  (32-48k)

Memory Mapped LED - Phase 2!

If you remember a while back when I was doing my Plus4 LCD screen, I spent a lot of time simply mapping a BYTE into the Plus4 memory space(Blog HERE). Well, I finally found something that will assemble source files for my GAL's, so I decided to play with trying to get my RAM expansion idea working. The first thing I had to do yet again, was map a byte into memory, but this time it was FAR easier!

You can see from the pictures that theres a LOT less, and even less soldering! Fantastic! This is the one bit that really puts me off doing any hardware stuff, I really dont like soldering that much. Well, with these GAL's, a whole array of chips have collapsed into 1! Not only that, but theres a lot more pins available, so I can add even more functions, and reprogram it as need be! Brilliant!

I did know what they were able to do before, but I was unable to make them until today when I found a program called fgal.exe, which is basically a GAL assembler. Now I can simply assemble this line...

     WR = A15* A14* A13* A12* A11* A10* A9* /A8* PH2* /RW

.... and I've done all the work of those 4 other chips! Great stuff. Now I can actually try out the external 256k RAM pack idea I had, where I dont modify anything internally... could be neat if it works!

One thing that would be very cool, is a pass through connecter, but from what i hear, you dont get these edge connectors any more... pitty.

I'm thinking of saving up for a milling machine so I can cut/make my own PCB's easily, this would mean that once I design it, I can (more or less) press a button and get a prototype board out! These are pretty expensive, but I think it'll be great fun so I hope to have one by the Christmas holidays...I hope.

XeO3: Fire!!!

So here we go - I've got the basic weapons running, I can select a weapon and power level and shoot things, so all I need now is the incremental upgrades/downgrades. I've been changing the power levels Luca came up with to make a smoother increase/power level. We won't know for sure until the whole game's done, and we can see just how hard the levels should be.

XeO3: Weapons!

I've finally started to put the weapons systems in - or rather, I've run out of more interesting things to do, so I may as well put the weapons systems in. Theres nothing much there just now, I've just started putting the tables in place to control them, and now I need to think what else I need to add to them. Things like maximum repleish rate, power etc. I'll get these bits decided tonight, and then start on the actual code after that. It'll be interesting seeing the real weapons in place and gettting things powering up right, and when you get right down to it, weapons are the driving element behind the gameplay....

FEK!

And....bugger....My C128 has died on me. No idea why, just stopped powering up. FEK'in hell... Oh well...I'll probably butcher the PSU so I can use it, but I'll try and get another from ebay...bugger...NOT happy... I've NO idea why its dead, and not even sure how I could figure it out. At least it didnt take the SuperCPU with it!

I was also thinking about the sprites... Currently I store 3x3 chars and that lets me keep the sprites simple.....BUT....I "could" strip the lower 3 chars and add code to manage it. It would free up some 3.5k, but the code would be pretty complicated (like it isn't already!). I'll have to think about it, I'm not sure....

I think I'm going to finish my assembler, and then get bak onto XeO3 again.... Oh well...

65816: The power of 16bit.

I've been wondering just how much faster the SuperCPU actually is to a stock C64, and aside from the x20 jump you get from the raw clock speed, the new instructions and 16bit nature give you an even bigger boost - Alomst another x2! Heres a little example....

The scrolling in XeO3 takes a long time, every game cycle I do this:

         ldx  #39
ScrollLoop
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*00),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*01),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*02),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*03),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*04),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*05),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*06),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*07),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*08),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*09),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*10),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*11),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*12),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*13),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*14),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*15),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*16),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*17),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*18),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*19),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*20),x
         dex
         jpl  ScrollLoop1
         rts

This code is self-modified to address the new location of the back buffer, and I have to use a jpl (macro) since a normal branch is just out of reach, so this takes (40*21*9)+(40*7) = 7840 cycles. (this is approx as there are also page boundary crossings hidden in here.)

Now in 65816, I can do exactly the same but being 16 bit, the loop is half, and although we add a couple more cycles for LDA/STA, its still much quicker. So the loop is now (20*21*11)+(40*7) = 4900 cycles.

And now lastly, the 65816 has a block transfer instruction MVN+MVP which are like Z80's LDIR instruction, which means (BEST case) its now (20*21*7) = 2940 cycles. Now, although the block transfer would be broken up a little mode (to do lines mainly), its still only going to be around 3000. So not only is more than twice the speed as the 6502 version, but we have the new 20Mhz clock as well.

..............Bitmap blitting suddenly becomes REALLY interesting!!

Snasm: 65816

I've done most of the assembler stuff - not all, but most - to the point that I can now build simple programs. So I've built a simple 65816 program, and it appears to be falling over; and I've no idea why! These kinds of things suck coz I can't debug it at all - just try new things over and over until I get somewhere....

Heres the code....

        opt    prg
        opt    C64=START     ; Insert BASIC header, and jump to start of the code
        opt    A65816        ; Set 65816 assembler mode

 
        org $1000
START:
        longa off
        longi off
        sei
        clc            ; Set processor to 65816
        xce            ; Set 16bit processor mode 
 
        rep   #$30
        longi on
        longa on

        lda   #$0000
        sta   $20
 
Here:
        lda   $20
        ldx   #$1000
Here2:
        sta   $0400,x
        dex
        bne   Here2
 
        inc   $20
        jmp   Here   
 

If I dont put it into 16bit mode, it appears to work fine, but execute the rep #$30, and it dies.... I'm not sure why... If I didnt know better, Id say there was an interrupt going off - I wonder if the NMI's are still on....

Snasm: Addressing modes.

I've finished the last couple of new addressing modes the 65816 has, so tonight I'll start throwing in the new instructions which won't take long and then I can start having a play on the real machine and see what it can do. The idea of a fully software driven game appeals to me, as in bitmap mode you can do some pretty big sprites without losing all your background tiles.

However... A multiplex is still a great tool, and you should never discard useful tools.

SNASM: 65816...

Almost done with the addressing modes. Only 2 small ones to go, and I'll do them tomorrow.

     EOR (dp,X)
     EOR sr,S
     EOR dp
     EOR [dp]
     EOR #const
     EOR addr
     EOR >long
     EOR (dp),Y
     EOR (dp)
     EOR (sr,S),Y
     EOR dp,X
     EOR [dp],Y
     EOR addr,Y
     EOR addr,X
     EOR >long,X

So the only modes left are sr,S and (sr,S),y - neither which I've ever used but I'll put them in for completeness. This hasn't been nearly as painful as I thought it would be, 2-3 days at most. I've still to add all the extra instructions, but they're all just implied addressing (TXA etc.) and are just table modifications. MVN, MVP, PER and BRL are the only ones that need special work, and they won't take long.

Oh....I've been using THIS page as an opcode refrence - pretty good too.

XeO3: SuperCPU...

I'm just running the current version of XeO3 on the my C128 with the SuperCPU attached, and I still cant believe just how fast it is... The whole game (as it currently stands - scrolling, paths, animations, turrets) runs in around 20 scanline. Whats amazing is that XeO3 is designed to run in 2 frames so that its a nice slow paced scroller so thats basically 2 WHOLE FRAMES with nothing to do but fancy stuff!!! How cool is that!

With the turbo off, its taking about a frame - which is a lot. It just shows how much faster the Plus4 really is.

Im also really pleased with the downloader - Because it uses control lines and not timing code; it just works! AND I can switch the turbo on/off as it downloads without it doing something horrible!

The only current issue is that while everything runs, the background tiles aren't being drawn correctly - for some reason. That's a bit of a bugger...

Edit: I think part of the problem is that the C64 version has a multiplexor runing everyframe, and the sort is as well - when it doesn't have to be.

SNASM: 65816 support....

I've been adding more addressing modes during lunchtime, so now I can do full 16bit immediate mode stuff. This also means I had to put in 8/16 bit flow control using new LongA and LongI, so you can now do commands like this!

        LongA   off
        LongI   off
  
        lda  #$ff
        adc  #$55
        and  #$fe
        cmp  #$12
        eor  #$55
        ora  #$55
        sbc  #$55
        bit  #$55
 
        ldx  #$23
        cpx  #$55
        ldy  #$23
        cpy  #$55
 
 
        LongA   on
        LongI   on
 
        lda  #$ffff
        adc  #$5125
        and  #$fe34
        cmp  #$1112
        eor  #$5544
        ora  #$5555
        sbc  #$5566
        bit  #$5532
 
        ldx  #$2312
        cpx  #$5542
        ldy  #$2363
        cpy  #$5513

Great fun!! I found out from the forums on Lemon64 that I can happily run my SuperCPU on my C128 in C64 mode without fear of blowing it up, so I can probably start to test some of the output soon.

I was thinking of doing a bitmap scroller an actually blitting the bitmap on each frame - which at 20Mhz, should only take around 1/5th of a frame!! wow thats fast... I could then also do software sprites on top of that! The great thing being that the sprites would be much quicker (aside fom the 20Mhz stuff) since I dont have to copy character data around - AND you wouldn't be limited by the character set either -its a bitmap! Colour would also be possible with this as well I guess... and thats not even thinking about C64 hardware sprites yet either!

Theres surprisingly little added to the 6502, a couple of addressing modes (and I'm doing 24bit Absolute addressing just now), and a few extra instructions that take no effort at all really. So this shouldn't take that long at all to finish this....

Edit: Thinking a bit more about this....I really need to update my C64 emulator to allow 65816; development would go much quicker if I had an emulator to run it in... I'm not sure how much effort that would be, I've not looked at it in years - since I put it on the PS2/XBox really.

Paradroid!!!!

At long (long, long, long, long, long, long, long, long, long, long, LONG!) last... TNT has started a proper blog of his Paradriod update. Its basically a disassembled, updated (a lot) and then reassembled version of the original game. He's making heaps of improvements and its well worth a shot if you haven't already. You can find his blog HERE

I've decided to start the work of upgrading my assembler to be 65816 compatible (which is used in the SuperCPU) as I fancy having a little play with 20Mhz of power! I know - Im jumping around quite a bit, but that happens as I try and keep my interest going. I'll probably play with this at lunchtimes at work, so I hope it won't get in the way too much. The 65816 is very neat and I've used it a lot in the past when doing SNES work (Lemmings2), its got full 16 bit registers although you can swap them back and forth. Its also got access to a full 16Mb of RAM (which my Super CPU has!) which could make for some REALLY cool stuff - lots of space for buffers and tables here! Also Zero page becomes DirectPage and it can move!! In Lemmings2 I pointed zero page at my graphics so that the code ran faster! I'll need to look out my SNES assembler manual to see the syntax I used in that, but all in all - it should be pretty good fun!

Edit: So I've just added my first new 65816 instructions! yeeeeeeaaa!!

     inc a
     opcode [$00]
     opcode [$00],y

I'm so happy... :) This does 24bit indirect addressing through the direct page register (the new movable ZeroPage)

You know something....the THOUGHT of filling even 4Mb with C64 graphics/sound is frightning.... On the SNES I had a ROM disk system, and most of the memory was taken up with that, but here... its RAM...so you cna actually DO stuff with it - outstanding! I may have to update my C64 emulator to allow 65816 code as well...Mmmm... even simple stuff without the need to fallback to 1Mhz for custom chips would probably do - I dont think anyones done a SuperCPU emulator before....

The other thing I didn't realise is that the 65816 is also 65c02 compatable...which means I can probably add 65c02 to the assembler as well...

RetroEdit: Painting by numbers.

I got basic editing in last night, although I really do mean basic. I can paint with 2 pre-defined colours - which isn't very handy. Now I need to put all the really boring editor stuff in to allow you to select colours from a palette, swap between them, validate the system its on, and then swap between systems....I hate editors :)

(oh....then save it all)

RetroEdit: Editing...

I've almost got editing working, I can click on the bitmap and it draws a pixel into the right place. Theres still loads to do, but it shouldn't take long now. Once I get editing and saving working, i can let Luca lose on it and try it out - it should help him do later level sprites. I'm expecting great things from him once he gets a good editor, as hes already done amazing things with - well, crap editors!

XeO3: Squishing bugs!

I've had a really bugging..well...bug! for a while now in the front end; after you die and return there I seemed to be losing a layer of stars and I couldn't think what it could be! My first that was that one of the couters werent being reset and so a layer was in fact 2, but I couldn't see how that was possible. So I then though that perhaps some stars were black, and I just wasn't seeing them. This wasn't right either - although I did discover some were in fact being made black - but it was fairly even throughout all the layers. Once I fixed that I went back to hunting for the missing layer.... Turns out my first instinct was right and a counter wasn't being reset! The slowest speed only moves every other frame and was being toggled with $FF and getting checked to 0, but since I use the game data area it wasn't being cleared to 0, which meant the EOR #$FF was setting it from one zero value to another, and so it was moving at the same speed as the middle layer.

Glad I fixed that, its been bugging me for a while now....