Nukey Shay Posted January 22, 2005 Share Posted January 22, 2005 Is there a way for a program to detect if it is being run on a 2600 rather than a 7800? Quote Link to comment Share on other sites More sharing options...
+batari Posted January 23, 2005 Share Posted January 23, 2005 AH! a challenge! I looked around and the answer seems to be yes. Can't say for sure if it will work on an emulator, but on real hardware, the 7800 starts 2600 mode in a known, predictable state but the 2600 itself does not. On the 7800, memory contents are constant when booting 2600 mode. Best I can tell, it contains: 80: A9 00 AA 85 01 95 03 E8 E0 2A D0 F9 85 02 A9 04 90: EA 30 23 A2 04 CA 10 FD 9A 8D 10 01 20 CB 04 20 A0: CB 04 85 11 85 1B 85 1C 85 0F EA 85 02 A9 00 EA B0: 30 04 24 03 30 09 A9 02 85 09 8D 12 F1 D0 1E 24 C0: 02 30 0C A9 02 85 06 8D 18 F1 8D 60 F4 D0 0E 85 D0: 2C A9 08 85 1B 20 CB 04 EA 24 02 30 D9 A9 FD 85 E0: 08 6C FC FF EA FF FF FF FF FF FF FF FF FF FF FF F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF I'd say that a simple check of 2-3 bytes at the very beginning of your game before you do anything else should give a good chance of detecting the right console. However, this condition is only valid at startup so you'd need to leave these bytes unchanged so a reset wouldn't mess things up. This may not be a valid option if you clear memory somewhere or don't have any free memory. Also, I'd avoid the $FF's or $00's. Ok, so I don't know for sure if this is feasible, but it's the best i've got. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 23, 2005 Author Share Posted January 23, 2005 Now the challenge of getting a free bit in ram lda #00 tax sta VBLANK loop1: sta RSYNC,x inx cpx #$2a bne loop1 sta WSYNC lda #$04 NOP bmi skip1 ldx #$04 loop2: dex bpl loop2 txs sta $0110 jsr $04cb jsr $04cb sta RESP1 sta GRP0 loop3: sta GRP1 sta PF2 NOP sta WSYNC lda #$00 NOP bmi skip1 bit RSYNC bmi skip2 skip1: lda #$02 sta COLUBK sta $f112 bne skip3 skip2: sta CXCLR lda #$08 sta GRP0 jsr $04cb NOP bit WSYNC bmi loop3 skip3: lda #$fd sta COLUPF jmp $fffc NOP Any idea what this is supposed to be doing? Quote Link to comment Share on other sites More sharing options...
+batari Posted January 24, 2005 Share Posted January 24, 2005 From what I can tell, this code is copied to $0480 (valid 2600 RAM location) from the 7800's BIOS code, which was copied to 7800's RAM earlier. Based on comments I've found, the first thing the code does is disables the 7800's RAM. It makes sense to do this here. Other comments say "initialize TIA registers." Indeed it messes with some TIA registers after this, but I can't say for sure why all this is necessary. Maybe a 2600 game expects the TIA to be in a certain state upon startup, or maybe this is here just to prevent a frame of garbage on the screen before the game starts. At the end, it does an indirect jump to the reset vector which starts the game. Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted January 24, 2005 Share Posted January 24, 2005 Here's the original code with the original (and not very useful) comments: LOCK2600 LDA #$02 ;TURN SECURITY ROM ON STA INPTCTRL ;LOCK CART IN 2600 MODE, CART... LDX #$7F ;MOVE CODE TO RAM L2LOOP LDA SYNC,X ;MOVE INTO 6532 RAM STA $480,X DEX BPL L2LOOP JMP $480 ;AND EXECUTE OUT OF RAM SYNC LDA #0 ; this code goes into RIOT RAM at $0480 TAX STA 1 ; VBlank ZEROLP STA 3,X ; clear TIA registers from RSync to CxClr INX CPX #$2A ; CxClr - RSync + 1 BNE ZEROLP STA 2 ; WSync LDA #4 NOP BMI E ; branch never taken LDX #4 DEX DEX BPL DEX TXS ; set stack pointer = $FF STA $110 ; ResP0 shadow JSR DUMMY+1-SYNC+$480 JSR DUMMY+1-SYNC+$480 STA $11 ; ResP1 STA $1B ; ResM0 STA $1C ; ResM1 STA $F ; Pf2 NOP STA 2 ; WSync LDA #$00 NOP BMI E ; branch never taken BIT 3 ; CxP1FB BMI OUT E LDA #2 STA 9 ; CoLuBk STA $F112 BNE DONE OUT BIT 2 ; CxP0FB BMI LF823 LDA #2 STA 6 ; CoLuP0 STA $F118 DUMMY STA $F460 ; note DUMMY+1 = RTS instruction BNE DONE ; branch always taken LF823 STA $2C ; CxClr LDA #$08 STA $1B ; GrP0 JSR DUMMY+1-SYNC+$480 NOP BIT 2 ; CxP0FB BMI E DONE LDA #$FD STA 8 ; CoLuPf JMP ($FFFC) ; jump to reset vector of 2600 cartridge I'm really not sure why they felt the need to do all that stuff when you weren't even supposed to rely upon the startup state of the TIA chip anyhow. Another bit of 7800 startup trivia is the stack pointer is set to $16 when starting up a 7800 cartridge. Which is an address in the stack area that won't contain RAM. If you forget to set the stack pointer, you will likely have Bad Things happen, especially because you will be writing to TIA registers. Oddly enough, the time that I forgot, JSRs and RTSes still worked fine. I'm not sure why. Decimal mode is also enabled on startup of a 7800 cartridge, but I didn't forget my CLD. Quote Link to comment Share on other sites More sharing options...
Aaron Posted February 10, 2005 Share Posted February 10, 2005 So have you found this technique to work reliably? I was interested in trying to detect the 7800 a while back, so I might have to steal it... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 10, 2005 Share Posted February 10, 2005 So you have the RAM contents, the contents of A,X, SP and some collision flags. That should be more than enough information to be 100% sure. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2005 Author Share Posted February 10, 2005 So have you found this technique to work reliably? I was interested in trying to detect the 7800 a while back, so I might have to steal it... The only way to be sure would be to burn a cart and test it on both consoles (emulation and other hardware can't guarantee anything)...but I can't see why it shouldn't work if those values are always present following a 7800's powerup. Steal away Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 11, 2005 Author Share Posted February 11, 2005 Additional thanks goes to Tony Wong...who burned and tested the routine for me using a 6-switch and an original model 7800. It works Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 11, 2005 Author Share Posted February 11, 2005 BTW the code sample in question is shown here...the one above is not the detection routine I'm referring to. Sorry if that was misunderstood Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted February 13, 2005 Share Posted February 13, 2005 I think the problem is... if you could detect that your cartridge was running in 2600 mode on a 7800... what would you DO with that knowledge? The boot process locks out the 7800 mode completely, so all this would do is let you amaze people by *gasp!* telling them they were really using a 7800! (Because of course they can't actually look at the console to figure that out, nuh uh.) It's the other tricks (2600 code on a 7800 cartridge board with the extra address lines for 32K of non-bankswitched space, 7800 code on a 2600 cartridge with the entire 4K space signed, a 7800 game that switches over to the TIA and uses that instead of MARIA) that are much more interesting. Hmm. I thought about that 7800 code on a 2600 cart thing for moment, and I think the problem is that the internal RAM will cause address conflicts. Too bad, because this could be pretty cool. Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted February 13, 2005 Share Posted February 13, 2005 Hi there! I think the problem is... if you could detect that your cartridge was running in 2600 mode on a 7800... what would you DO with that knowledge? Basically you'd know wether you should run code for the B/W(2600) or the pause(7800) switch. Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted February 13, 2005 Share Posted February 13, 2005 Oh, so there is something different about the consoles! Doh. I forgot entirely about the pause switch change. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 13, 2005 Share Posted February 13, 2005 Oh, so there is something different about the consoles! Doh. I forgot entirely about the pause switch change. And I had some people reporting, that Thrust would show some graphic problems. Some 7800 consoles seem to have a slightly different timing of the PF graphics. Though changing the kernel depending on the console is usually not possible. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 14, 2005 Author Share Posted February 14, 2005 I think the problem is... if you could detect that your cartridge was running in 2600 mode on a 7800... what would you DO with that knowledge? Basically you'd know wether you should run code for the B/W(2600) or the pause(7800) switch. Yup. In order for the color/B&W switch to really act like a pause switch (which it won't without a routine), the program needs to keep track of it's status...and EOR a bit in ram every other change (you can't use every change, because then it wouldn't have any effect at all...it would just EOR when the switch is read as being in the B&W position, and then EOR again when it springs back to the color position). Every other change works good for the 7800 where the switch springs back automatically...not so well on the 2600 (because you'd have to flip the switch back to color manually). So this short routine is a solution to both...branching off to seperate routines depending on the console type. And it only costs 2 bits in ram and roughly 30 bytes of romspace (depending on what you reuse later). And I had some people reporting, that Thrust would show some graphic problems. Some 7800 consoles seem to have a slightly different timing of the PF graphics. And it's not the only one. I hear that Pesco has similar artifacts on a 7800. Though changing the kernel depending on the console is usually not possible. No, but if worst comes to worst, you could just duplicate the areas that are too tightly coded...and branch off to them seperately. Lotta redundancy, but whatever gets the job done Thankfully, Rom is not expensive as it was in the past...so you could just bump up to the next chip size if space becomes an issue. Quote Link to comment Share on other sites More sharing options...
Doran Posted March 19, 2005 Share Posted March 19, 2005 Ram contents the same on DevOS modd'd 7800s ? Quote Link to comment Share on other sites More sharing options...
Doran Posted March 19, 2005 Share Posted March 19, 2005 Also need to consider what running from a CC2 might do to this whole mess. Quote Link to comment Share on other sites More sharing options...
+batari Posted March 19, 2005 Share Posted March 19, 2005 Just for kicks I made this bin. Run it on a CC2 or a dev system to see if it properly detects the console. Will display 2600 or 7800 on the screen. I've just tested on a 2600 emu, so someone would need to test on a regular 7800 to see if the program actually works... I think it will though... dc.zip Quote Link to comment Share on other sites More sharing options...
+Mitch Posted March 19, 2005 Share Posted March 19, 2005 Just for kicks I made this bin. Run it on a CC2 or a dev system to see if it properly detects the console. Will display 2600 or 7800 on the screen. I've just tested on a 2600 emu, so someone would need to test on a regular 7800 to see if the program actually works... I think it will though... OK, I tested it out on the CC2 with a standard 7800 and it detected it correctly. I also burned it to a cart and tested on a 2600 six switch, 2600 jr, standard 7800, dev OS 7800 and standard PAL 7800, all of them detected correctly. Mitch Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted March 19, 2005 Author Share Posted March 19, 2005 As it should. All of them wouldn't be altering the values that the 7800 leaves in Ram on powerup...unlike, say, an emulator that never put the values there to begin with. In the case of the latter, it's simple enough to have the program default to "2600 mode" (i.e. where a non-springback switch is assumed)...because: A) The emulator used for a 2600 game is likely to BE a 2600 emulator (as opposed to a 7800 emulator). B) Emulators usually use seperate keys for each switch's on/off position anyway. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.