Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by RevEng

  1. ...As for the GPIO, it's fully utilized, but you can use the SPI bus or repurpose some of the pins to the SPI bus if you ensure the devices currently on the bus are deselected.

    I don't know how far final board design is, but is there any chance you can breakout the SPI bus somewhere on the board so one could "easily" add a pinheader?


    While driving home I put together the fact that Harmony has an SPI bus with the fact that controls that plug into an Wiimote are SPI as well.


    Anybody up for 4 player joystick-based Atari 2600 homebrew?

  2. +1 on the annoying door thing.


    you should check to see if the guy opened a Virtual Console account and if there are games stored in memory that you will have to transfer over to your own Nintendo account. I don't know how Nintendo handles that.


    Actually, the Wii keeps an encrypted "ticket" for any downloaded games on its system flash, so you can redownload them at a later date. The games belong to the Wii, not an account, so there's no need to transfer them.


    This is handy in this case, but a pain-in-the-ass in the case of a Wii owner buying a replacement Wii. Nintendo will not transfer the VC games from the old Wii to the new Wii. (with the sometimes exception of when a Nintendo tech actually works on your Wii and replaces it because he can't fix it)

  3. From the article...


    "Obviously this is a play on the old, "For a good time, call 123-4567". In the Atari systems, the main CPU is a 6502 and contains an instruction named JSR. This stands for Jump to SubRoutine - it is the computer assembly language equivalent of "CALL". The final "91BD" is a computer memory address, written in hexadecimal (base 16). In decimal, this number is written 37309. As of the initial writing, I do not yet know what the significance of this number is, if any. In the game's code (see below), memory location 91BD contains data, not instructions, so if you actually did a JSR 91BD in this game, you would not get very far. Maybe the game's designer can shed some more light on this topic, after he reads this article to "refresh his memory" [no pun intended]."

  4. The silent cooling is a bonus. The fan noise from my 4-switcher is driving me bonkers!


    Just some friendly ribbing xXUlTiMaTe-SiNXx. ;)


    I think a lot of the gang here are pretty hardware capable, though you'd probably clean up on fleabay if you could pull that off.

  5. My question to you guys is there anything I should look for when I test it out?

    Be sure to go into the Wii settings menu - the circle button labled "Wii" at the bottom of the main screen. If the Wii has taken an update from the wrong region it can be "partially bricked" where this menu won't come up. (it can be fixed, but it's a hassle you may not want to deal with).


    The GPU thing was mentioned. If that's a problem you'll see dark "static" during certain parts of games.


    Double check that the nunchuck works and centers correctly. Generally they're pretty rugged, but my kids managed to kill one, so it's not impossible.


    The DVD drive should be fairly silent. I've had one go bad and it became quite loud.


    Other than that, there's not much else in the way of common problems.


    You should also know that with a bit of work it's possible to run homebrew on the Wii, including a version of Stella and other classic console emulators.

  6. ...it's sitting on a small upside-down wire basket and there is a window air conditioner that is constantly blowing cold air on it from behind.

    Murphy has a sense of humour, you know. You've significantly increased the likelyhood of a death by air-conditioning condensation or from a fall from a small upside-down wire backet.


    Double points if you slip on the condensation and knock it off the basket. ;)

  7. Just thought I'd share that I found this TOP853 eprom programmer that seems to work well with 27c128 eproms which are often used in 16k homebrew 2600 carts. Doubtlessly other sized chips in the same family will work too, though I haven't tested them.




    BTW, I didn't buy it through the above link (went through ebay) so that's not an endorsement of them. They were just the first hit in google.


    Nothing much more to say about the programmer, other than it's small, runs on USB power, and seems to work just fine. It only does 5v chips, so it's probably not the most flexible programmer you can buy. Also the manual and software is in broken english, but it was easy enough to figure out without even cracking the manual.


    With this programmer and some choice selections from the AA store (socketed cart, a few eproms) you're ready to burn your own for ~$100. (but don't forget to factor in an eprom eraser, or buy a lot of eproms!)


    Of course, if you're only looking to test out your code on real hardware you'll hopefully be able to grab a harmony cart later this year instead.

  8. post-23476-1246808567_thumb.png


    I'm in! :)


    I like that each game plays out the exact same pattern as the last. If it were randomized I would feel a good game might be the consequence of a lucky sequence.


    I usually play up along the top wall moving side to side, which means I only need to see incoming objects from one direction. Anybody use a different strategy?

  9. I am impressed that you were able to get it done in 2k and it looks just like the 4k version too. You were sure busy doing this and the multigame loader as well.

    Thanks. You mentioned earlier in the thread that it wouldn't be worth the effort to get it working in 2k, and truer words were never spoken.


    There's no reason to prefer a 2k rom over a 4k one these days, and I think in the end I spent about 8 hours of code refactoring and squashing all of the bugs I introduced. It was a lot more time and effort than I thought it would take, and my source is a bit ugly from the hacks, but once I was on the mountain I was determined to reach the top.


    The multigame loader wasn't a whole lot of work, but yeah, it's been a busy weekend. And now I need to spend some time and shoot for the "3 digit Miss-it club" :)

  10. Wow, it really *does* fit in 2k! Nice job, RevEng! But I went to compile it, and it didn't like the negative numbers. How do I fix that?

    I'm not sure why it's not working for you... I used the 1.0 bB from batari's site patched with the patches linked in the last post here: http://www.atariage.com/forums/index.php?s...02127&st=25


    If you're not at the same level, that's a good place to start.


    Ha, i got 67 ! :lol:

    A faster score-counter would be nice...

    I'm not much better. To test out the objects that come out later I needed to disable the collision detection. Otherwise I'd never know if the missle moving code worked correctly. :)

  11. A short while back I posted a simple game-selecting bank-switch menu in this thread: http://www.atariage.com/forums/index.php?showtopic=143328


    Due to a few PMs I got with questions, I went ahead and cleaned it up a little to hopefully make it a bit self-explanatory. (and also made the joystick selection UI a bit easier)


    The source has compile-time options for 16k/4-bank or 32k/8-bank carts (since those are the easiest to get) but it should be pretty easy to modify for other schemes. In the save vein, this time around the source includes the bankswitching code as assembly code rather than binary data.



    score_graphics.asm.txt (remove the ".txt" and put in the same dir as the .bas file.)




    The attached bin has *no* games stuck to it presently. To do this, concatenate 3 files onto gameselect.bas.bin. In linux/cygwin/MacOS/*BSD use "cat file1.bin file2.bin file3.bin >> gameselect.bas.bin". In DOS/Windows-CMD I believe something like the following should work "copy /b gameselect.bas.bin+file1.bin+file2.bin+file3.bin full_gameselect.bas.bin"


    As is, it should work with bB bins and *some* assembly-generated bins. The latter depends on if the game co-incidentally uses a hotspot location for its regular data. Since the F6/F4 hotspots are near the end of the cart, games that are packed to the gills with data are likely to crash. Nothing to be done in that situation, short of dissassembling the bin, modifying it, and re-assembling it.


    Question: can I disassemble a bin and just move data from $1FF6 to another location, like $3FF6 or $FFF6?

    Answer: no. because of it's shortage of address lines, when the 2600 tries to access $FFF6, the exact same cartridge lines are used as when it tries to access $1FF6, $3FF6, $5FF6, ... , $DFF6. Programmers use those "high" locations in their code to differentiate between their banks/locations logically, but physically they are equivalent to a 2600. For more info, read the stella hardware docs.


    Question: where are all the cool graphics and stuff?

    Answer: Its bB and you have the source code. You know what to do!

  12. Here's my 2 cents...




    ...better make that my 2 k's. :cool:


    It took a *lot* of rework to collapse this puppy into 2k. There's nothing terribly inefficient about the original source, but the bB multisprite kernel has a lot of functionality packed into it to use it in a 2k game. A multisprite bin with nothing more than a looping drawscreen takes up ~1160 bytes!


    I avoided any changes to the bB kernel, as I felt that would have cheated the spirit of the thing. I was sorely tempted to try to rework the playfield drawing routines to try and squeeze the storage used for that... so many precious bytes to draw a box!!! :) But in the end I was able to make it work without cheating.


    Techniques used:

    • I simplified the direction/bounce code by using directional xy vectors for each object, instead of the existing single vector. This traded-off ram for code.
    • For similar objects, I looped through arrays and called common functions.
    • I grouped together variable assignments of the same value and put them on single line with the : operator. This removes redundant register=constant assignments in the assembly code.
    • I used shared sprite data.
    • The last thing I did was to play with the positioning of routines around the shared sprite data, to minimize the wasted padding due to the sprite data's location requirements.

    If anybody wants to add something, you have at least 54 bytes of rom free. If anybody spots any bugs, fix 'em yourself... after all this code bumming I'm sick of looking at it. :P

  13. I believe he means what happens in "official" 2-player tetris, not his program.


    But AFAIK there is no official 2 player tetris. Some clones have the game end when one of the players lose, other have you play it out.


    One feature some have, which you may choose to copy, is if you get a tetris it causes your opponent to have his stack move up and random blocks inserted on the bottom rows.

  14. Keep holding up or keep holding down. It cycles through the numbers.


    Admittedly the UI could be improved - I was just going for a quick proof of concept. It will likely be more friendly if you shorten the jdelay=60 assignments to 20 or 30, and also add in a line that sets jdelay=0 if there's no joystick input.

  15. I think it's more complicate than that with a bB compilation, because of the way bB stuffs the kernel, the player graphics, and the playfield definitions all in one bank.


    It's no more complicated for 4k bB binaries than it is for other 4k binaries. For a proof-of-concept, here is the beginnings of a simple bank-switching menu program written in bB. I decided to jump to the reset vector rather than jump to $1000 as I mentioned earlier - in case the two differed in bB and it had some special reset-cleanup. Not sure if this is the best approach or not, but it works. If you want to use this with other non-bB bins, then you might care to change the last $FC and $FF bytes to $00 and $10.





    source files...




    To build your own menu, compile gameselect.bas, then concatenate 3 files onto gameselect.bas.bin. In linux/cygwin/MacOS/*BSD use "cat file1.bin file2.bin file3.bin >> gameselect.bas.bin". In DOS/Windows-CMD I believe something like the following should work "copy /b gameselect.bas.bin+file1.bin+file2.bin+file3.bin full_gameselect.bas.bin"


    It would be fairly simple to embellish this program to include unique player/playfield graphics for each game selected. I leave this as an exercise to the reader. ;)


    Feel free to take this program and use it as your own.

  • Create New...