cd-w

I guess there is only a problem when moving from one 6502 family processor to another. However, as the Atari is a fixed platform, this shouldn't be a problem. I am still a bit reluctant to use them though ... Cheers, Chris

That is a good question, and I am still rather undecided on this issue My current stance is that I will try to avoid using them unless absolutely necessary. Is it actually known that the common illegal opcodes (DCP, DOP and LAX) will work on all 2600 hardware including the 7800? Chris

This is great stuff - much clearer than the sctech document. Many thanks, Chris

Thanks, and I should actually be going to PhillyClassic show this year if I can get my holidays sorted out. Chris

OK, I see that isn't going to work, since you also need the colour data for the sprites I was thinking that the multisprite kernel just allowed you to use all of the sprites (including the missiles and ball), but not more than one copy of each. Chris

I can see this will be a difficult one to solve! It sounds like you need some kind of packing algorithm which splits the code from the data, and stores the data in the correct place in each page. Alternatively, if you only allowed a ROM-based PF with the multi-sprite kernel, you could use the extra RAM to store the sprite data and avoid the alignment issues. My assumption is that the ROM-based PF data wouldn't need to be carefully aligned. You would only store 2 sprite frames in RAM (Player 0 & 1) and copy any new sprite data from ROM->RAM between screens. This would give you two kernel options: A high-detail ROM-based PF with more sprites. A low-detail RAM-based PF with fewer sprites. I hope this is reasonably clear? Chris

Eric, Thanks for writing this explanation - it cleared up a lot of questions for me on why the Supercharger does things in such a peculiar way! Chris

Thanks. What address range should I use to avoid spurious writes, or is this not possible? EDIT: Ok, I just noticed that you wrote $10xx and not $1xxx! Changing the start to $1100 fixed the problem. Sorry for all the basic questions, but I am rapidly finding out that the supercharger is a rather strange creature Chris

Hi Eckhard, Thanks - I hadn't fully appreciated the difference between ORG and RORG. I have now added RORG $1800 to Bank 1/2 and RORG $1000 to bank 3 and it seems to work. At least, it works when I don't set the write-enable bit. Is it necessary to start with write disabled, and then enable it when you actually want to perform a write access? Chris

I have decided to try my hand at programming for the Supercharger (thanks to a certain contest ). However, I seem to have got stumped at the very start The attached file is my attempt to configure the SC with a 4K contiguous section of writeable memory (Bank 3+1) and display a simple PF testcard. The code loads OK, but seems to crash immediately after this point. I suspect the problem is with my understanding of the memory map. On a related note, are there any actual SC programming examples beyond the cryptic sctech document? Any help appreciated! Chris sctest.zip

Really? I must have missed it. 917600[/snapback] From the screenshot, I think it is the breakout clone in this thread. Chris

This is a neat little minigame I think it could use some spot sound effects, and possibly a change of colour between different levels, but it plays perfectly. Have you considered including the source code? Chris

Thanks - I hadn't really considered releasing it on a stand-alone cart. I haven't done this before, so I'm not entirely sure what is required. I guess I should speak to Albert and see if he agrees. Chris

Hi Manuel, Thanks for your encouraging comments. They inspired me to fix the last few known issues in Hunchy 2 this evening. I should be posting the final version to the Homebrew forum soon, but I have sent it to supercat to check over first. I am hoping to include this on the upcoming minigame multicart collection (with batari and vdub_bobby). I do already spend far too much time playing games Cheers, Chris

Absolutely, and given that our city is currently overrun by tourists I appreciate it all the more

This is a very nice demo. If you have the space, you could select randomly from a number of different pre-set paths - this would make the movements less predictable? Chris

Thanks, but I am sure that your story is more interesting than that! You must have had some struggles getting to grips with the 2600, as the tutorials and techniques like switchdraw have only been recently made available? Chris

Hi Thomas, Thanks for the suggestions - I will see if I can fit them in somehow, though I am very close to the 4K limit. The end of game sequence only happens when you complete the game (at level 15), not when you run out of lives. I have attached a modified version to this message which goes straight to the final level just so you can see what it looks like. Thanks, Chris hunchy2end.zip

There is a bit of a delay before the games appear on the minigame page (I think they are being done by hand). I am also planning to submit Hunchy 2 soon. With reference to the subject title, it certainly is a good year for homebrews so far - there seem to be new releases every few weeks, particularly thanks to batari basic. Chris

Thanks - the level designs took a very long time to do! I was also surprised how much variety I was able to put into the game. For each of the 8 screens, I started with an initial sketch on graph paper. I then tightened the design into a 16x12 grid with a limited set of tiles. Then I coded each screen in-turn, and finally I tweaked the design by playing through the level many times. The PF priority is set above the sprites as the bells and missiles are drawn on every line, even if they are not required. The PF is used to hide the unused missiles and bells behind the left border. I couldn't find the kernel cycles to disable the missile sprites properly, or to switch the PF priority in the game area. The timing of the micro-jumps on level 4 is certainly tricky - you need to jump when your feet are over the edge of the platform and not before. Cheers, Chris

Thanks. The jumping while dead is a feature (i.e. I didn't have space left in the code to prevent this). To pass this level, you need to time your jump so that you are positioned further up the rope, and the missile will pass underneath you. Chris

Great little game, and surprisingly different from the full "Go Fish!". I think the difficulty curve and arcade feel are just about perfect Chris

OK, here is another release of Hunchy II. I am calling this the "supercat special edition" as it contains a great end of game sequence coded by supercat. The main changes this time are: Cool end of game sequence. Practise mode: you can skip levels using SELECT when the Left Difficulty Switch is in Position A. Various gameplay tweaks and bugfixes, and a slightly better PAL version. Let me know if you find any bugs in this release, as I am hoping (fingers crossed) that it is ready for the minigame compo now (i.e. this is now the release candidate). Chris h2v08.zip

Hi Zach, Glad you like it! Thanks for the suggestion, but I have reached the point where I don't want to fiddle with the kernel any more I don't think it will be possible in any case as some of the lines are used for sprite repositioning, and this requires the entire line. Chris

You mean a larger version like this Chris