djmips

Preamble: I did some C64 programming back in the day, some of it was pretty cool too. I have the listing of a version of my 32 sprite multiplexing routines and I'm planning on typing it in (or OCR) and see if I can get it running again. It wasn't really using any amazing tricks but the dynamic zone calculation code was quite good for the time I think. Some of my colleagues were doing things that were supposed to be impossible like putting sprites in the borders. I understood how that worked but I'd only heard rumours that there was a pretty cool way to do smooth horizontal scroll without needing to do a coarse scroll in character map and colour memory. Several of the games I did had pretty decent (I thought) scrolling routines but yes the big overhead was the shifting of the entire character map memory and colour memory every eighth shift as the hardware smooth scroll registers only shifted the screen eight pixels before they reset. Now it turns out that the fancy smooth scrolling techniques operated on a similar fashion as the techniques to put sprites in the borders in that you tricked the simple hardware that was waiting for some condition like a particular line and then change what it was waiting for to something earlier after it had already past the earlier check. This meant the check never triggered and lets say a border was never enabled. In the smooth scrolling case, if you use a similar trick to get the VIC 2 chip into thinking it's time to start a new line and you time it to happen, say in the middle of the screen you can force the entire screen to be shifted over by that amount. It's pretty cool since you can scroll a lot without having to have to copy every eighth scroll position. This is especially nice in bitmap mode. Apparently it was invented by a demo coder in 1987 here -> http://www.pouet.net/prod.php?which=19753 How did I find out about this, well it's probably on the net somewhere but a nice fellow put together what appears to be definitive lecture on the C64 video hardware at some hacker conference or something. In any case he also covers the 6502 in quite a bit of detail partially based on the work of this Hungarian fellow (amazing) http://impulzus.sch.bme.hu/6502/6502/ although he regurgitates this again in a better and more complete 6502 talk that is tied in with the amazing http://visual6502.org/ which if you haven't seen the site or heard about this. shame shame shame. The links to the talks are 6502 -> http://www.pagetable.com/?p=517 Ultimate C64 talk -> http://www.pagetable.com/?p=54 All these cool C64 tricks are explained in much more technical detail here for those who are interested -> https://sh.scs-trc.net/vic/vic_article_3.14.htm#3.14.6 Well it's too late to not be guilty of being sidetracked on the C64 and 6502 stuff but that stuff is very cool and the visual6502 guys have also reverse engineered and gate level simmed the TIA chip as well! THE 2600 dollar Question. Now finally to my question to the 2600 home-brew / tech community. Is there some equivalent trick maybe maybe maybe on the 2600 TIA that would allow some way of doing horizontal smooth scrolling of playfields? There was some discussion at one time on the Stella list but I only vaguely recall the discussion. I'm fairly un-optimistic that there will be a solution found that could be done software only but perhaps even something crazy that worked on a fancy cart would be an interesting but even that seems unlikely.

Just joined these forums so sorry if I'm a little late to this party Here's a couple of my favorites First the counter eor something with its self you get 0 eor something with 0 you get its self lda counter inc counter eor counter and #$F0 eor counter sta counter Of course you can insert bits from one byte into another byte (not just from a changed version of itself) Used eg for setting pixels ========= haven't read this thread for awhile (thanks to vdub to resurrect it so I would actually see some of the cool additions) This is more likely the original Ackerman 'hack' for incrementing only the low 4 bits of a byte without requiring any additional memory. I think the other 'bad' version must have been my own idle mind playing around with other ideas. Thanks bogax.

The game had been in development limbo for years. Meanwhile, I'd done several revisions of label and manual artwork for it, and had kind of grown attached to the concept (rock/paper/scissors presented in a ridiculously overblown style). Billy had lost interest in finishing it, and said it was okay if I found someone else to work on it. So I asked Bob, since he'd already done a nifty rendition of some music for it, and he was willing to take it on. The rest, as they say, will eventually be history. Bob, my perennial 2600 collaborator has invited me to join the project; how could I say no, after all the help he has given me in the past. It is my pleasure to help finish up this game. - David

Wow, just through sheer good fortune I got to meet in person with cd_w. Since vdub_bobby is close by, the three of of us got together last night to talk shop and have a beer. :-) cd_w on the left and vdub_bobby on the right. Chris was visiting Seattle and just happened to be doing work at my company. Through some small talk about homebrew he found out that I was there. It's a games company and he was a little surprised to find me there. I have now met in person almost every person who I've collaborated with on various 2600 projects. I almost met Tommy in Portland but in that case bad fortune somehow kept us in different areas of the show over the course of two days. Seems impossible but it happened. :-) Hey guys, that was a lot of fun! It may have been the beer but I agreed to help vdub_bobby with RPS and I think also vowed to help cd_w with his projects as well. :-) Cheers! - djmips -

Yes the original could get stuck in "loops" if both players were good. And they could cooperate and just bounce it back and forth and presumably leave the machine. I've updated the download to include a cfg file that will default the stella controls to mouse and keyboard (arrows) The 'cfg' file you included is a disassembler configuration file, used by the internal Distella code to represent how the disassembly should look. If you want to include automatic setup for the game itself, you need to include a .pro file (game properties are stored in the .pro file). I see, well, so I would have to include a 'stella.pro' file with the configuration below. But that leaves a problem I don't know how to solve, which is that I don't know to feasibly append this to the user's stella.pro on multiple platforms or provide a way of launching with a -propsfile option. It seems that the Stella app is biased against paddle games it doesn't know about. "Cartridge.MD5" "3e21b5356ea6d61a5fedb5493534c62a" "Cartridge.Name" "apong.bin" "Console.SwapPorts" "YES" "Controller.Left" "PADDLES" "Controller.Right" "PADDLES" ""

Yes the original could get stuck in "loops" if both players were good. And they could cooperate and just bounce it back and forth and presumably leave the machine. I've updated the download to include a cfg file that will default the stella controls to mouse and keyboard (arrows)

I'm not sure where this latest version compares to the last I posted but the most recent changes are: - selectable game to 11 or game to 15. - game once again starts at 0-1 at boot-up demo mode - serve ball position slightly more acurate to Arcade Other changes from the posted version are probably: - added attract mode - serve delay like arcade pong - speed increase depending on hit count like arcade - rewrote paddle hit logic to be more like arcade - score is higher res - adjusted ball speeds to be like arcade Hopefully this is a better version but bug reports are appreciated. EDITS: (I have noticed a bug in this release, sometimes the ball can bounce off of the right paddle and not switch directions, that is it will bounce off to the right for a point for the left paddle) Additional release notes: In this version I moved the default for the the paddles to be in the second port. In Stella this is: P0 Controller Paddles in Right Port. The selection for games to 11 or 15 is the Player 0 difficult switch. I've added apong.zip which contains the apong.bin.cfg for stella which defaults the controls - mouse or left/right arrow for left paddle, up/down arrow for right paddle. apong.zip

No chance of a single-player option. The purpose is to make an accurate recreation of the original Arcade Pong with no bells and whistles.

AHA! I had forgotton about this. I will take a look at this and see where things are.

I've just recently repaired a bunch of Jr.'s One of them didn't respond to any of the usual repairs. I had several working Jr's and I swapped in the motherboard of the one that only had a reset/select problem. This showed me that the problem was on the circuit and not with the switch hardware. I still haven't determined the problem but in the worst case it might be a bad IO chip. That unit is working perfectly otherwise. Regarding the switch install/removeal. There are three pieces sandwiched together. They are all registered with each other with small plastic pegs. When you take it apart you flip them up off the plastic pegs and pull out. Keep in mind the sandwich order. When reassembling; you may put them back in one at a time and hold them on the pegs until the last piece is on.

Hey, nice cloth physics!

Clicking the links brings you to his vimeo account. http://vimeo.com/jordanmechner

Wow. I didn't realize that there was boss fight music otherwise I would have used it! I don't think I have that boss fight music. I didn't use the selection music because I only had one boss.

woah... Way to come late to the party. Thanks for the nice review for BLiP football. As always, Bob, did a great job on the graphics and kernel. A little insight, my first home computer was a Kim-1 (it was 6502 based and had a calculator keypad and 7 segment display) and I always wanted to write this football game for the Kim-1 when I was a child but I was never quite good enough and I moved onto the Apple and C64 by 1980. This version for the 2600 was a whimsical idea to do an emulator of a more primitive system on a more advanced hardware. I'm not sure that anyone gets the joke but me. I came up with the idea of doing Fanfare for the Common Man but it was Tommy Montgomery who arranged it for the 2600. It always makes me smile whenever the cartridge starts. It is so ridiculous. Now that I have a micro KIM from Briel Computers, at some point this year, I am finally going to move this game over to the KIM-1. - David

Nice! I just played it on the Cuttle Cart and it was very entertaining. Nice work for a single day.

It was/is an awesome title kernel from cd-w. I had to basically understand his routines from Juno first in order to adapt this for the Mega Man titles. Once again, I spent more time in Gimp editing the graphics before exporting as PCX files and using PCX2GRP to export to source code. Some of the big issues were the monochrome aspect of Atari graphics. I modified the kernel to update colors from a table as I recall so I think I had to fit some extra cycles in there. Incorporating the titles was one of the biggest problems of getting it to work on a 'real' cartridge. Since the titles module had no understanding of bBasic's zpage usage, I had to make sure that they worked together and that bBasic was setup correctly after the titles returned. In the end I had to save and restore playfieldpos around the call to the title screen code which also had to clear zero page before starting. It was kind of drastic but it worked. Getting the music driver working with bBasic was mainly just making sure that they had no conflicts in zpage usage. After initializing the driver I make sure that I call the update from the main loop. It was pretty smooth integrating this work from vdub_bobby and his brother.

This should be pretty easy to accomplish. I have posted the source in http://www.atariage.com/forums/index.php?showtopic=146936

about that boss.... He was the last thing to go in on a very tight schedule. He didn't receive much balance tuning. Since the whole work was more of an 'art' piece in a way, it somehow made it a statement if not about life sometimes but then maybe the perceived difficulty of Mega Man games. He could use some more work.

I don't know. Maybe if I had some help getting some more levels made and I'd have to see if Albert was interested.

Yeah, this is nice. I've looked through a few of the sources and I'm sure they will come in handy some day.

It works on an 'actual' 2600.

OK, now here is the source for those who would like to play with it, add more levels, program some more enemies or just use it for your own creations / inspiration or answer some questions ( jrok ) There's probably something useful in there somewhere? Contents of Zip build.bat -> builds the game collision.s bcollision.s and ecollision.s -> three copies of the same subroutine for different banks I think and the 'e' version is for ElecMan The collision subroutine checkPos (and variants) checks the playfield data directly for collision versus an x,y position mmm.s -> Music player source and song data logo.s -> Title screen code and art header.bas -> variable declarations including how to use Super Chip RAM (at least the way I did it anyway) mm.bas -> The game - you might notice that I drop into ASM in a few places because I was working around a compiler bug or I just thought I could do it better or it's easier for me or executes faster in ASM. MegaManSource.zip

I like your game. Very cool and imaginative. I really like blue skies in a game. The scrolling hillside is very Atari. Nice horse animation.

I really like what you've done here. It's a format game tech that I've been thinking about myself ever since I made the Amiga Ball demo and of course I'd seen Andrew Davie's kung fu babies as well. Very good. It would have been very impressive in the day.

I thought I'd start a thread regarding some of the things I did to make Mega Man 2600 with bBasic and share a few tech things that came out of this. (Binary is here) It was made very quickly in the Summer 2007 so some things are a little fuzzy. So it turns out that I did nothing special for the sprites, they all did fit in with the kernel. Here is the bank map for Mega Man. I recall that I developed the Main game first and then branched the code to do the boss battle and then folded it all back in together. I didn't have time to make the Mega Man code a proper subroutine so it appears that his main control code is replicated in my haste. If I had more time I could reduce the code size. Bank Free Available Used 1 MegaMan Game 3781 43 3738 2 Music 3781 3065 716 3 Title 3781 900 2881 4 Screen transitions 3781 3317 464 5 Unused 3781 3781 0 6 MegaMan + Boss AI 3781 874 2907 7 Elec Man 3781 1810 1971 8 Graphics Kernel bBasic 3781 868 2913 30248 14658 15590