Jump to content
IGNORED

Detecting the console


Nukey Shay

Recommended Posts

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...