More updates – things are moving along nicely. All the songs are done now, and any bugs that I can find have been fixed up, so Shredz64 is good to go now. I made an image of the NTSC version of it, I need to make a PAL version as well, but I need to test out the PAL values a little more before thats ready.

Additionally, I uploaded a new version of firmware to the PSX64 that has a couple fixes in it. First, I put the lines out to the C64 into a high impedence state now when they’re not active, which allows you to type on the keyboard when the joystick is plugged on (before it would keep the lines high in a low-impedence state, which would block most keyboard input due to the way the CIAs work). It was irritating as you’d have to unplug the adapter while typing, then plug it back in when it was time to use it. No more of that. Also, I moved the encoding of the lift-up sensor from the pot that handles the strumming to the pot that handles the whammy bar. This allows the user to strum while lifting the guitar up, which wasn’t possible before. This is pretty necessary, as when you activate shred mode, you want to be able to play while the guitar is still lifted up, lest you miss some buttons coming quickly. This is much more important than being able to lift the guitar up while using the whammy bar, especially since the whammy bar is only used in edit mode.

So two things left to do with the next PSX64 prototype – I need to add diodes in on both the DC plug so people can’t plug an adapter with reverse polarity in, and also add diodes to the power on the digital pots. For some reason, it appears that the adapter still works when you don’t have it plugged into DC power. The only power is coming from the C64 5v line (and logic lines). The logic lines go directly into the MCU, so I don’t think that is the issue, but the 5v line goes into the digital pots to drive the pot pins on the C64. I think the digital pots are leaking this power up through their Vdd line into the rest of the circuit, which is bad – most 9 pin joystick ports put out max 50 mA, and the total power consumpution of the interface (and any playstation adapters plugged in) is more than this. If someone accidentally forgot to plug in dc power, it would work fine and they wouldn’t realize it, but there would be a chance of damaging the device/computer. Hopefully by blocking current in the opposite direction of the power pin of the digital pots it will fix this. We’ll see, I have an order in for more playstation extender cables to build another prototype. Once that design checks out, I’ll put the schematics up and get PCBs printed.

I’ve been working every night on this, but I haven’t had time to update the blog until tonight. First off, I have notes done for 4 songs now, so 6 more to go. I’ve noticed that I’ve made every song I’ve done so far akin to hard/expert level on Guitar Hero in complexity, so I’m going to tone it down for the last 4 songs or so to more like medium level. Since you can’t choose different levels, this at least gives a good mix of difficult songs and easier songs, and then if people want harder/easier for the other songs, they can simply make their own notes (and upload them for others :)).

Also, I quickly found out that the note editor still needed some design issues worked out. I found that unless I was dealing with a tricky part, it was actually easier to record at full speed than in 1/3X slow-mo, as in slow mode you’re always hitting the button too soon, and its so slow you can’t always tell if the sounds you’re hearing are the actual note or just a weird effect before the note, or another note, just due to the way people generally craft SIDs to get lots of good sounds out of 3 channels. So I reversed the functionality of the whammy bar. When you’re not pressing it, the song plays at full speed – the harder you press it, the slower the song goes. So fully depressed it goes at 1/3X slow-mo and half depressed its at 1/2X. Also – I found a constant need to wipe out all notes after a certain point – like, I would finish a section up, and the next section would start up, and I wouldn’t be ready and I’d play notes waay off base and then I would need to delete 5-6 of them. So, I changed the functionality of the full-clear to clear past the current point. E.g. if I was at tick 5600 and I hit the Green,Red,Yellow and Blue and strummed up, it would delete any notes recorded after tick 5600 and restart the song. This still allowed me to use it as a full song clear – if I wanted to fully clear the song, I simply did this right when the song started, so everything past tick 1 was deleted. Double the functionality!

In PSX64 news, I have the plans into Eagle and I’m working out the two issues I was having – both (I believe, I need to wire up a test on a protoboard) are due to sinking lines off the atmega8 instead of floating them. We’ll see – I’m looking to get it debugged and some safety features put on (i.e. diodes) and it put off for a prototype PCB printing asap so we can get some boards printed up. I suspect I will have the fixes and final plans done by this weekend, so I’ll be putting the plans and firmware up soon for those handy with a soldering iron.

Lastly, with the game mere days away from “complete completion” (e.g. all the note data recorded), I’ve been readying both a nice wordpress version of this blog for more behind-the-scenes stuff as well as a beautiful site developed by my girlfriend Leah for Synthetic Dreams (since the current website is a bit lame). All plans, downloads (game and songs), and purchase info for the PSX64 will be available between those two sites within the next week or so. I hope everyone enjoys the game as much as I do! 🙂

I started recording note data tonight, but I quickly ran into a weird problem that I hadn’t seen before, mainly because I hadn’t previously been loading in so many songs (in the past I’d loaded in 4-5, now I’m loading in 10). Anyway, after a debug session of good length I found a just plain stupid mistake I’d made with pointer arithmetic – it happens to us all sometimes. The issue was I was saving high score data into the area of RAM where I’d copied the kernel into, and needless to say things weren’t working right.

Anyway, fixed that and got the notes recorded for 1 song, 9 more to go. Most will be fairly easy to record for, but there are a few SIDs from the demo scene that will be a little more difficult. Hopefully it won’t be too bad overall.

Okayyyy, so I added a little more in. I got more space by taking all the text for the credits screen out of the program and putting it onto disk, then writing a very lightweight loader for it to pop directly into screen memory. That freed up 300 bytes. I needed space as I wanted to add support for playing PAL SIDs on NTSC systems at the right speed and vice versa. Don’t get too excited, it only works for SIDs that have the system speed specified in the file (which isn’t all of them by any means), and it doesn’t alter the frequency, only the playing speed. So NTSC users playing PAL songs will hear the song at a slightly higher frequency, but the song will still play the right speed (and the notes will go at the right speed). Not a big deal, but there were a few really great SIDs I’m including in the game that are PAL and have their system speed specified in the file, and they sounded so much better at their right speed, so it was worth it just for those (and future) SIDs.

So, I will be distributing a NTSC binary and a PAL binary of the game. They’re the exact same thing except a few constants defined which allow what’s mentioned above to work right. Again, this is only for a very small subset of SIDs, but at least its a help for those.

Stick a fork in it, it’s done. Well, the program is anyway, I still need to record button data for all of the songs. That will take me a week or so. I’m sure there are bugs in the game, I haven’t done a super in depth testing session yet. However, while having to fight 3 times tonight to reclaim 200 bytes from the heap, I realized that only having (less than) 64K to work with is kind of a blessing. It definitely prevents feature creep, which is a pet peeve of mine, even when I cause it. I was thinking of including a easy/medium/hard selection on each song, but the amount of code involved would push me waaay over, especially considering I have 7 bytes free in memory right now. Really, it comes down to if I ever want to make major additions to the game, I’ll have to take the note editor out and put it in its own executable. For now though its nice to have both the game and the editor in the same program, and until I need the space that’s how it will remain.

More updates when the note data has been recorded!

I pretty much finished up the note editor tonight, except a few bugs in the delete function. Due to memory issues (e.g. I am completely out, I really had to go through every inch of code, substitute bytes for words under all (possible) circumstances, reduce the maximum number of notes (which was too large anyway)) and due to usability, I changed the way the editor works slightly from whats listed in yesterdays entry. Its mostly the same, with a few differences:

1. Instead of strumming up and pressing keys to delete those keys and strumming down and pressing keys to add notes, you just always strum down and hit the buttons you want. If there are no notes there, it creates them, and if there are notes there, it deletes them (i.e. xor). This saved a LOT of coding and actually makes there fewer things to memorize on the note editor.
2. I changed it so you press the first four buttons and strum up to clear all notes from the song. This is easier than trying to hit all five buttons.
3. The whammy goes from 1/3rd speed to full speed – not to double speed.

Everything except for a few bugs in the delete functionality works like a champ – the whammy bar functionality is pretty neat, I’m glad I could include it in the game, even if just in the editor – it at least works well as a fast forward. The only part I’m not too pleased with is due to speed requirements while recording, notes can’t be recorded in their final organized order – they have to be thrown into the end of the array and then packed when completely finished – or when the song is restarted. It takes about 15 seconds to pack, so whenever you want to restart the song in edit mode it takes 15 seconds. Not a huge huge deal, but a little irritating. I tried to optimize the algorithm, but when push comes to shove, its just a sort over 5 arrays of about 150 items each, it just simply takes a little while on a 1mhz processor. At least I don’t have to reload it off disk again though, its all done in memory until the save is performed.

I’ll be fixing up the bugs tomorrow, off to bed now!

One of the small fixes I made today was allowing the notes to start scrolling before the song starts – e.g. if the first note appears on the board when the song starts, if this is immediately once the playboard appears, it wouldn’t give the player time to press it. In this way, there is a 2 second lead in when it shows the first note scrolling down the board, and when it hits the bottom is when the song starts (assuming the first note was recorded when the song starts). You wouldn’t think this would be such a hard thing to implement, but because of a lot of little things it was way too much time. The devil is always in the details. Anyway, its working now.

Also, I think I figured out a way to implement a usable note editor on the C64. Using the following features, I think it will work even with the limitations of SID files:
1. When editing a song, it loads whatever note data it has for a song. If no note file is found, it just starts with blank. Notes are shown on the board just like in regular play mode.
2. Song plays at 1/4th speed to allow recording notes a bit easier. However, the more the whammy bar is pressed, the faster the song plays, up to double speed (e.g. fast forward).
3. If the player strums down while pressing buttons, those buttons are recorded at that position in the song.
4. If the player strums up while pressing buttons, those buttons are deleted at that position in the song (if they’re there. If they’re not nothing happens).
5. If the player strums down while pressing no buttons, the song is saved.
6. If the player strums up while pressing no buttons, the song restarts (since its pretty much impossible to “rewind” a sid, restarting and then using the fast forward function is a good alternative, especially considering SIDs aren’t that long generally.
7. If all 5 buttons are pressed and player strums up, the entire song is blanked out and restarted.

I think this will allow the player to keep restarting and recording things just the way he/she likes them and then continue on to the next section and do the same, and finally save. I think this will work and I won’t have to make a windows editor, which I really didn’t want to do (because of wanting this to be done and wanting to keep everything on the C64 platform). Anyway, work on the note editor will start this week! It will probably take me a couple days. Then I’ll be picking out sids and recording notes (now that I have a nice note editor), which will take a couple days. I have a vacation coming up on the 25th, so by the end of that week, everything should be done (except firmware updates on the PSX64) and a video should be up! We’re almost there!

Well, some good news and some bad news. The bad news is I can’t figure out any good way of silencing or changing the frequency of SID data being played. I’ve tried silencing the SID right before/after/both each call to the player interrupt, and the most I can achieve is it making the song sound crackly. I’ve tried turning filters on and lots of other stuff, but unfortunately since the play interrupt is doing its own thing and playing the data the way it wants to (which is also using the SID and its filter in unique ways for every song), and I cant touch the SID chip until after its done, I can’t figure out a way to intercept data before it hits the SID registers. There’s always an option of running NMIs off CIA2 at a really high frequency which could interrupt the IRQ playing the SID file (could someone confirm the behavior/possibility of an NMI interrupting an IRQ?), but then I was thinking that the speed necessary to ensure the NMI hit the SID fast enough would completely eat up the processor, and the SID would still probably start playing something for a millisecond first that would make it sound like crackle or whatever. SID files are a blessing and a curse. They’re a blessing because there are a ton of them out there, and allow this game to be a possibility, and are low-sized ways of playing songs. They’re a curse because there’s no “outside” way of affecting them – short of reprogramming the SID you can’t really touch it. And building a mini emulator to examine instructions in the SID in realtime is pretty impossible as well. So, this may spell doom for the whammy bar doing anything or audible feedback when you get a note wrong / miss it.

The GOOD news is this really doesn’t take away from the game as much – and the game is pretty much done! There are still a few little bugs to fix and graphical improvements to make, but it’s rockin’ right now – and it’s actually fun to play! A few bugs fixed tonight, the shredocity meter was decreasing at an accelerated rate when a CIA timed SID was playing – this was because I was decreasing the shredocity meter relative to song “ticks”, and ticks weren’t constant for CIA timed songs. I moved the decrease code over to an interrupt triggered by Timer B on CIA1, which is fixed regardless of the speed of the song, so life is good there.

So what’s left now? Here’s the OFFICIAL LIST (not necessarily in order):

1. Fix up random little bugs
2. Make some more minor graphic improvements. Nice titles for each screen, maybe some (simple) fretboard artwork if I can manage it.
3. Make a practical note editor for Windows. Again, the curse of SID files, but you can’t rewind or preanalyze these things on a C64 (it will be hard enough to do on a fast machine). I’m leaving the “mini note recorder” in the game though, you can bang out notes for a new song quickly (just don’t make mistakes!)
4. Decide on the final lineup of SIDs to be included on the disk, and record notes for them. This includes trying to get ahold of the authors just to get a blessing. I’ve got some cool songs so far, they’re fun to play. HVSC is a freaking awesome resource.
5. Setup a place on the website for people to share their note files for SIDs with other people, so we can build up a library of songs.
6. PSX64 stuff. I have a few safety fixes to add, a few things I need to update in the firmware, then I’m going to get some prototype PCBs printed, tested, some enclosures manufactured, put the schematics up, sell premade units, etc.
7. Put a video up of Shredz64 in action!

Things are moving very quickly now, so I don’t expect any of it to take much longer. My poor C64 programmers reference guide has definitely gotten a beating the last few months.

Worked on this pretty much all day today and got a ton done, the game is 90%-95% done at this point. I fixed up bugs in the “3D” routines so things go at the right speed and there aren’t any weird flashes of sprites (was a issue before that was just distracting while playing). Also added the crowd meter, had to create a few extra custom characters in the game set for it, but made it a thin bar ala Rockband as its easy to work with. It will turn red when in danger, yellow when in the middle and green when doing good (e.g. 0-33, 33-66, 66-100). Also fixed a bug so you can’t go past 100% (I forgot to limit it so if you kept doing good it would just keep adding bars until it went off the screen).

Also moved the score to the top middle of the screen, added a comma to make it centered with the fretboard. Then I added the shredocity meter, and did the same kind of thing I did with the crowd meter, except it only has two color modes, cyan when you’re in the lower 50%, and purple when you’re in the upper. When the meter turns purple, you can enter “shred mode” (official name to be determined later 😉 ). Also made a score multiplier that increases up to a maximum of 4X for every 8 notes you get right in a row. If you get a note wrong, it goes back to 1X. Put this underneath the shredocity meter.

Allsooo – I have it throw in shred notes every period of time indicated by purple notes on the board. If you hit these notes, your shredocity goes up. Then, when you’re in the purple, I have it detect if you lift the guitar up, then it goes into shred mode. At this point, it doubles whatever your multiplier is (so maximum of 8X), flashes all the notes rapidly (through all 16 colors), and turns the border red. Then it slowly decreases the shredocity meter until its back down to 0 and shred mode ends.

Everything works great, the only issue is, the way I encoded lifting up the guitar into the PSX64 interface, it doesn’t allow you to strum while the guitar is lifted up. This was a stupid oversight on my part and easily fixed, but I need to go back and write the fix into the firmware and reupload to the PSX64. I’ll do that when I’m done with the game, as I have a few more things to do with the interface that I want to tackle at the same time.

So anyway, below is a picture of how everything looks (with a crowd score in the middle, no shredocity, no score and a 1X multiplier)

That’s about as good as this game is going to look (which really isn’t too bad), but I apologize to the people who were hoping for bitmap graphics on the game screen. There are a few reasons why this can never happen, but the biggest is memory. Bitmaps take up 8K, and I just don’t have 8 extra kilobytes and I never will. I got away with it on the loading screen as I load the bitmap into the same memory space I reserve for SID data later on. I can’t do that on the game screen, as it needs the SID data at this point, so I would need to allocate 8K in a bank OTHER than bank 0, which is all the juicy RAM where my program actually executes. It would also require overwriting my custom character sets and reloading them each time, and would severely limit how many different kind of SIDs the program could play, and they’re just too damn slow to load. It’s not happening. I’ve got lots of characters left over in my game set so I can definitely add more graphics via 8×8 character blocks, but that’s it. I’m not displeased with the graphics above though, if you see it in action (which you will pretty soon!) it looks pretty good.

So, what’s left to do? There’s still a tiny bug I missed on the song selection screen that doesn’t refresh the score display portion of the screen right. Then there’s just adding audio clues that indicate a bad note was hit. This is going to be tricky given the nature of SID data, the fact that its executable code and not just music data. I’m going to have to do some fancy ETL (to use a database term) work with the SID registers, e.g. save the values, tranform them to a scratch or whatever, then reload the original values. We’ll see how that goes. I’d also like to include whammy functionality for fun, which also is the same kind of save/transform/load functionality. Then that’s really it for the base game. The song editor needs a lot to make it actually reasonably functional, but I’m not sure what to do at this point as SIDs dont give you a lot of room for editing, seeming as though you can’t really rewind or pre-analyze on the C64. I’ll figure something out. But it won’t be long now, only a few things left!