Omegamatrix

Neat! There might be a few different routines out there but I don't know of any. You could also do this to compress your routine further: ; BCD value $0 - $99 is in A. Returns binary number 0-99 in A BCDtoBin2: sta Temp and #$0F tax eor Temp lsr sta Temp lsr lsr adc Temp stx Temp adc Temp rts

The engine car is awesome!

Are the pieces moving or static? I think 30Hz flicker will be okay. If you have a black screen keep the luminance low to make it more tolerable.

I tried installing a few different types of 32 bit linux using VirtualBox about a month ago but couldn't get anything to work. From what I read it might be a problem with my graphic drivers. I tried several things to make it work, but none were sucessful. I'm interested in if you can use the 64 bit builds now and not have problems with compiling code for the ARM. If that will work I will try a newer version of linux, and worst case buy a different PC (which I need).

How is this progressing? I am really looking foreward to this game. It's on my short list of best 2600 homebrews ever.

This is top notch. This will be one of my favorite 2600 games. Well done!

Neat! I've too made ramless programs, but never thought about making a game before. Pong is good choice for that. I remember at least one discussion that was had about methods of extra storage. This post captures most of that.

This is a good game! Lots of fun.

This is a superb idea to breathe new life into these games. Truthfully, I never have a manual around, and I usually just play the default version. Converting games that have a lot of variations is a huge improvement. Maybe I will look into Video Olympics because there are 50 variations. I'm pretty sure I have not tried a lot of them. Paddle games are more involved to make a menu screen, but certainly workable. Standard joystick games though would be easier to bang out.

Yes it has! Actually a few of the roms in the thread you posted has this conversion. But the rom you probably want is in the link below. It has the most work done to it. http://atariage.com/forums/topic/67442-stone-age-cce/?p=2909578

I was talking about doing disassemblies to see the exact differences, and grouping the roms that way. From the Missile Command output for Clonespy you posted can you say which hacks were built from the no-initial rom, and which were built from the initial rom? It's easy to determine that from a disassembly that can compile into each version. Ultimately though I'm trying to make a simple relationship diagram like this: I did that for Challege about 11 years ago.

Really interesting, especially as it gives a perspective of the enviroment people were in when making these hacks: The article points out that: Fair to say they were worried of their own government and lived in a controlled and restricted society. We see so much pirating of images and games from them, and I always thought it was because they weren't worried about foriegn governments or just didn't care. That thought may still be true, but today I have a more pleasent thought about their attitude. Perhaps at some of level their pirating was driven by a means of takining in Western Culture where that they could. Maybe their government would not take notice of banned material as long as it was not directly referenced, and its appearance was smothered in patriotic rhetoric for their government.

The Adventurer's Gameplay is very interesting. I love Funvision stuff. Can anyone make out the games on the top of the box? Unfortunately the picture is a little small.

It can be chipped away a little by looking at certain features. In general you want to compare all known versions of game including all of the hacks. Here are some things that can be looked at: Size of Display: PAL games can have more visible lines available then NTSC. If you see a game that fills the screen in PAL format but has areas that are off the screen in NTSC than it hints the game was a programmed as PAL. Colors: PAL and NTSC have different color palletes. For example value $1E is yellow in NTSC, but $1E is white for PAL. If the color values are the same between a PAL and NTSC version than look at each game to see what makes sense. Is the sky color blue and the grass green in one version? Does the character have a flesh color for skin in one version and not the other? Music: If there is a known melody in a game, and the music data is unchanged between versions, than which one sounds like it is playing correctly? A good example of this is Challenge. Play the PAL HES version and compare it to the NTSC Zellers version. The music plays way too fast in the NTSC version but sounds correct in the PAL version. Changed Code: This is comparing all known versions of a game to group roms that share identical code changes. Corrupted instructions (from bit rot), bug fixes, and garbage data are very useful for tracking differences. Grouping the roms together by those differences will form a nice pattern of relationships. Scanline Count: Looking at the scanline count alone is not conclusive as a lot of Atari games were off spec. However if you find the PAL version is on spec and stable, but the NTSC version is rolling because too much time is being spent in Overscan or Vblank than the game might have been programmed as PAL. Hope that helps.

Alright! Some good work here. Ballblaɀer I took a look at the roms and found some of the 2K games were dumped as 4K. Please use these roms instead for those: 2K roms.zip In terms of whether sometimes PAL games were hacked into NTSC, that has happened before. Sometimes you will even find that a game gets hacked into a PAL format, and then hacked back into NTSC by a different company. Colors are ususally something that can be looked at to see if a game started as NTSC or PAL. Sometimes they don't get changed.

Hello Ballblazer, This is great! Even though the other roms matched some previous dumps can you please post them? Thank you for helping with the Bit Corp dumps.

Don't put code in the hotspots. In this case the hotspots ar $FFF6-$FFF9, so JMP CLEAN_START will trigger an unintentional bankswitch. Also, you can have data before the hotspots ($FFF5) and it can be read and used as normal. However If you had code in $FFF5 then you have to be wary that as soon as the instruction is read the PC has incremented so that would trigger $FFF6. This is non-impacting if you are already in bank 0, but would of course be a bug if you were in other banks. I often just leave a buffer byte before the hotspot or just have data there. Example: rts ; $FFF5 will switch to bank 0 as PC increments to $FFF6 triggering the hotspot .byte 0 ; $FFF6 bank 0 hotspot .byte 0 ; $FFF7 bank 1 hotspot .byte 0 ; $FFF8 bank 2 hotspot .byte 0 ; $FFF9 bank 3 hotspot

I didn't look at what you're doing, but consider this: - You will have a certain bank that has your initialization code, whether it be bank 0, bank1, etc... - Don't count on your game starting in the same bank each time. Instead plan on it starting in a bank that is randomly selected. - The first thing your game must do is bankswitch to the bank that holds your initialization code. Every bank that does not hold the initialization code must do this. - Once you have bankswitched to the correct bank you must get to that code.

I wasn't responding to your post, and actually I didn't read your post. This was just a general idea of mine of not splitting the homebrew categories into more pieces, and combining a couple of the previous categories.

I liked everything. To me splitting the homebrews into more categories is will miss a lot of elements. For example if a game is 8K assembly then it does not fit the 4K category, best BB category, or ARM category. Every person will have a different opinion so you won't get very far. My suggestion is to combine the best of BB into the Best Homebrew category and increase the entries to 20. To even the playfield with the judging I would note if the game is ARM, BB, extra ram, and so in brackets beside the title to give an idea of the construction. Example: GameA (Assembly, 4K) GameB (ARM CDF, extra ram, 32K) GameC (Assembly SC, extra ram, 32K) GameD (BB, 16K) GameE (Assembly, 1K) GameF (BB DPC+, extra ram, 32K) GameG (Assembly 3E, extra ram, 32K) .... Since this would now be a large category, maybe award 1, 2, 3 place trophies.

It's not needed in practice if you check the firebutton once a frame.

The way the memory map works DEC COLUP0 would read CXBLPF, decrease by 1, and then write that value to COLUP0. Only bit 7 of CXBLPF is used, so the other bits might be whatever is floating on the bus. Here is a document I got somewhere years ago on the memory map. GoodTIAMemoryMap.txt

There's lots of different wasy to go, and what you choose really depends on your situation. If your sprites are all the same height then you might consider using AND (),Y You will want to move the loading of your graphics to the end of the scanline to deal with any extra cycles from crossing boundaries. i.e lda (graphics),Y ; 5/6 and (drawMask),Y 5/6 sta WSYNC sta GRP0 This method does eat up rom for the AND mask table, but is generally easy to implent and not too slow.

Thanks for the confirmation with Warplock. Based on your both of your dumps being the same I am going to recommend that this NTSC dump of Warplock be marked as the good rom. The one that is currently in Rom Hunters collection should be marked as a bad dump because we can't source where it came from. While it could possibly be an alternate I would say that it is a very low probabilty. It is much more likely to be a bad dump and it should be replaced with yours. Thank you for your help in finding this. Well done! With Beany Bopper that new rom does not look good. The instructions make no sense because one byte is corrupted. DEC (%11000110) got changed to SEI (%01111000). The arguement of DEC is $81 which is the opcode for STA indirect X. Anyhow the next few instructions changed simply because of that one byte being different. ;old dec $81 ; $C6,$81 ldx #$00 ; $A2,$00 ;new (DEC changed to SEI) sei ; $79 sta ($A2,X) ; $81,$A2 brk ; $00

This is where it gets interesting. The PAL Gameworld rom also has $08 at $FF40. I didn't look what this byte is for, but it makes me wonder if $0A is actually the correct value. A 1 bit difference is suspectable. At this point I would really like it if a retail copy NTSC Warplock was dumped to see what we find.