GroovyBee Posted August 2, 2010 Share Posted August 2, 2010 (dunno if the 7800 uses all 4k chunks). I'm not sure what you mean. Can you expand on that a bit? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 3, 2010 Share Posted August 3, 2010 I just checked the "stall" (as we call it) code and unfortunately I have to correct myself again. Yes, there are a few bytes at the end free, but those are required to preserve some variables for the menu which "stalls" when selecting a new page too. We could overwrite those variables when loading a game or we could use different RAM code when loading a game (so we don't need those variables anymore). Option one won't help much, since we cannot reuse the existing checks at $D0 and for the 2nd option there isn't enough space in ROM. I suggest that there are two 7800 auto detect signatures used. The original 7800 one and another one which is based on the RAM kernel. There we have to find a way to change a bit or so without changing the functionality. And this byte and another one should be used for the 7800 detection when loaded from Harmony. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 4, 2010 Author Share Posted August 4, 2010 I just checked the "stall" (as we call it) code and unfortunately I have to correct myself again. Yes, there are a few bytes at the end free, but those are required to preserve some variables for the menu which "stalls" when selecting a new page too. We could overwrite those variables when loading a game or we could use different RAM code when loading a game (so we don't need those variables anymore). Option one won't help much, since we cannot reuse the existing checks at $D0 and for the 2nd option there isn't enough space in ROM. I suggest that there are two 7800 auto detect signatures used. The original 7800 one and another one which is based on the RAM kernel. There we have to find a way to change a bit or so without changing the functionality. And this byte and another one should be used for the 7800 detection when loaded from Harmony. If I'm understanding you right, then something like this? START: sei ldx $D0 ; initial test for 7800 (using old algorithym) cpx #$2C bne .testForHarmony ldx $D1 cpx #$A9 bne .testForHarmony beq .startClearLoop ; always branch, 7800 detected and the carry is set too .testForHarmony: ldx byteA cpx #HARMONY_BYTE_A ; - this doesn't tell you if it's a 7800... it's just tested for extra confirmation of a Harmony cart. It'll be the same bne .not7800 ; value for the harmony whether it's a 7800 or not. However, it is a more uncommon value overall (i.e. not #$FF or #$00) ldx byteB ; - this byte changes to indicate a 7800 has has been detected!! It is also an uncommon value cpx #HARMONY_BYTE_B beq .startClearLoop ; 7800 detected, and the carry has been set automatically .not7800: clc ; 2600 detected, clear the future flag .byte $2C ; BIT opcode, skip 2 bytes RESET: lsr consoleType ; move previous 2600/7800 detection into carry .startClearLoop: cld ldx #0 txa .loopClear: dex txs pha bne .loopClear rol consoleType ; move 7800 detection into bit 0 I also got rid of the illegal NOP (bit won't trigger anything bad in this case!) Even though the illegal NOP worked fine for me on a couple of real 7800's, I kept thinking about maybe it's not a good thing to use until it gets locked into 2600 mode. I was also quite pleased to find out that I don't have to set the carry. If the compare instruction is true for an equal, the carry is always set. Also does anyone else find it annoying that the forum software is not defaulted to black text for code boxes? I guess it is hunting for key-words like a text editor, but for comments it is just plain awful to read. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 4, 2010 Author Share Posted August 4, 2010 Okay, I'm a bit slow. You can save a few bytes by checking a value that both the Harmony and 7800 have in common first like Batari suggested. START: sei ldx $B8 ; this byte is the same value on both the 7800 and Harmony cpx #$85 bne .not7800 ldx $D1 ; this byte is unqiue to a 7800 cpx #$A9 bne .testForHarmony bcs .startClearLoop ; always branch, 7800 detected and the carry is set too .testForHarmony: ldx specificRamInTIA ; - this byte changes to indicate a 7800 has has been detected!! It is also an uncommon value cpx #HARMONY_7800_FLAG beq .startClearLoop ; 7800 detected, and the carry has been set automatically .not7800: clc ; 2600 detected, clear the future flag .byte $2C ; BIT opcode, skip 2 bytes RESET: lsr consoleType ; move previous 2600/7800 detection into carry .startClearLoop: cld ldx #0 txa .loopClear: dex txs pha bne .loopClear rol consoleType ; move 7800 detection into bit 0 This code seems a lot more economical now. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 4, 2010 Share Posted August 4, 2010 (edited) A couple of things: I think the code I posted earlier is the "test" version, as it appears to exit with a console switch and not the BIT $1FF4 on the actual version. Here is the correct code: 1C 16 3F 1F 07 03 16 04 3C 7E 5F 3F 03 05 00 00 3C 7E FB B0 F2 20 00 00 3C 78 F4 F0 F0 D0 60 00 3C 7E FF FF FF FF 7E 3C B5 80 85 5B B5 A0 85 5C CA 85 42 85 42 10 F1 4A 85 41 A2 80 A9 9E E8 E8 87 BB A9 98 87 A9 A0 F6 98 E9 7D 69 03 D0 05 2C F4 1F 50 20 2A 0A 85 42 85 40 88 D0 EB A0 06 84 41 A9 0A 85 46 49 B8 85 47 E0 9E D0 04 46 DE 85 E2 BA D0 B4 18 6C FC FF 85 5B 86 60 86 61 88 A9 Second thing is I don't think we need to change any code. The normal stall code looks something like this: bit $1ff4 bvc exit ... exit: clc JMP ($FFFC) We pull D6 low to pull out of the stall and that causes the bit instruction to set V=0 and pull out of the stall. Maybe we pull D7 low for 2600 and high for 7800, and change the stall code for loading a game to this: bit $1ff4 bvc exit ... exit: clc bpl is_2600 lda #$2c sta $d0 lda #$a9 sta $d1 is_2600: JMP ($FFFC) This will require pre-detecting the 7800 in the boot code, free RAM in Harmony, and 10 bytes for 2 values or 6 bytes for one value when loading a game - there appear to be 8 bytes free. It might work with one but not sure about two. Edited August 4, 2010 by batari Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 4, 2010 Author Share Posted August 4, 2010 Fantastic!! I hope this will work (sure sounds promising!). Great job guys!! Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 4, 2010 Author Share Posted August 4, 2010 Two possibilities jump out to me for clearing the carry, and storing to 2 locations all within 7 bytes. There are many more possibilities, but none very good. These aren't great either, but better than getting #$04, etc... LDA #0C STA $C2 ASL ; carry clear, #$18 STA $C8 LDA #$12 STA $BB ASL ; carry clear, #$24 STA $BF ;and you still have $B8 (#$85), and $CD (#$D0) the same between Harmony and 7800 Of course you could clear the carry, load once and store in two locations within 7 bytes. Lots of duplicate values in the code including ($24, $85, $8D, $A9, $CB, $D0). Or you could rely on $B8 or $CD for one of the bytes, and just load one extra in and clear the carry. I'm waiting to see if Thomas can work some magic though, and not free up 2 bytes but 12!! I'll keep trying here to see if there is something I can work for $D0 and $D1 too. Edit: I forgot the branch. Still need bytes!! Double Edit: If the stack pointer is at $FF you could use PLA to get #$A9 and save a byte. Then you just need one more byte. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 4, 2010 Share Posted August 4, 2010 (edited) You still need the branch of course, but the carry needs to be cleared whether a 2600 or 7800 is detected. Anyway, I just noticed that $D0/$D1 contain $F4/$1F which is the operand containing address we check to pull out of the stall. We don't really have to use $1FF4 - we chose that value since it was unlikely to come up randomly during the weird stuff the 2600 did during startup. $1F2C would work just fine and save a byte. Therefore, we can do this: bit $1f2c bvc exit ... exit: clc bpl is_2600 lda #$a9 sta $d1 is_2600 JMP ($FFFC) Edited August 4, 2010 by batari Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 4, 2010 Author Share Posted August 4, 2010 Alright then! If everything works then it's problem solved on multiple levels. All the old hacks will now work without modification, and there is still is a couple of bytes free if stuff needs to shift around in the future. Anyhow I'll wait and try it out whenever it's ready. Too late for me tonight though. I wanted to say thank you to you Batari and Thomas for putting time and effort into this. I think it'll be well worth it. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 4, 2010 Share Posted August 4, 2010 You still need the branch of course, but the carry needs to be cleared whether a 2600 or 7800 is detected. Anyway, I just noticed that $D0/$D1 contain $F4/$1F which is the operand containing address we check to pull out of the stall. We don't really have to use $1FF4 - we chose that value since it was unlikely to come up randomly during the weird stuff the 2600 did during startup. $1F2C would work just fine and save a byte. Therefore, we can do this: bit $1f2c bvc exit ... exit: clc bpl is_2600 lda #$a9 sta $d1 is_2600 JMP ($FFFC) No space for that. Sorry. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 4, 2010 Share Posted August 4, 2010 You still need the branch of course, but the carry needs to be cleared whether a 2600 or 7800 is detected. Anyway, I just noticed that $D0/$D1 contain $F4/$1F which is the operand containing address we check to pull out of the stall. We don't really have to use $1FF4 - we chose that value since it was unlikely to come up randomly during the weird stuff the 2600 did during startup. $1F2C would work just fine and save a byte. Therefore, we can do this: bit $1f2c bvc exit ... exit: clc bpl is_2600 lda #$a9 sta $d1 is_2600 JMP ($FFFC) No space for that. Sorry. When you say there's no space, what are you referring to? This would be needed only when loading a game, so maybe the last 8 bytes of RIOT RAM aren't needed. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 4, 2010 Share Posted August 4, 2010 No space for that. Sorry. When you say there's no space, what are you referring to? This would be needed only when loading a game, so maybe the last 8 bytes of RIOT RAM aren't needed. It's 7 bytes in NTSC and 5 bytes in PAL BIOS. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 5, 2010 Share Posted August 5, 2010 No space for that. Sorry. When you say there's no space, what are you referring to? This would be needed only when loading a game, so maybe the last 8 bytes of RIOT RAM aren't needed. It's 7 bytes in NTSC and 5 bytes in PAL BIOS. If we have to, we can change $D0/$D1 to $2C/$58, and we could do this (carry is always set upon entry) bit $582c bvc exit ... exit: bpl is_2600 rol $d1 is_2600 clc JMP ($FFFC) That's just 4 extra bytes. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 5, 2010 Author Share Posted August 5, 2010 Is the carry always set before you ROL then? The solution looks good to me. Edit: nevermind I just re-read your post and you said it was. But if not you could always stick a SEC in before the ROL and still be at 5 bytes, which would be enough for both PAL and NTSC versions. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 15, 2010 Author Share Posted August 15, 2010 Hi Batari, Thomas. Any news on this? Is everything good? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 25, 2010 Share Posted August 25, 2010 Hi Batari, Thomas. Any news on this? Is everything good? Everything fine here, except that RL is killing my time. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 27, 2010 Author Share Posted August 27, 2010 Hi Thomas, Thanks for the update! I was only a little worried about the silence. Quote Link to comment Share on other sites More sharing options...
supercat Posted August 30, 2010 Share Posted August 30, 2010 Would there be any difficulty with using some of the ARM's RAM to hold code to set up the RIOT RAM the way programs are going to expect it? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 31, 2010 Share Posted August 31, 2010 Would there be any difficulty with using some of the ARM's RAM to hold code to set up the RIOT RAM the way programs are going to expect it? You mean, after stalling, the PC would switch to ARM RAM, there we overwrite the 128 bytes ZP RAM and then switch to the game? Not sure if that's possible. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted December 4, 2010 Author Share Posted December 4, 2010 Hi guys, Just giving this a friendly three month bump. I hope at some point there will time to make this happen. Quote Link to comment Share on other sites More sharing options...
GeneralMurdock Posted January 11, 2011 Share Posted January 11, 2011 Hi guys, Just giving this a friendly three month bump. I hope at some point there will time to make this happen. Hi, I`ve been considering buying a harmony cartridge for the past months. I would like to know if it work in the 7800 to play 7800 games and 5200 and 2600 games. Does it work ? Quote Link to comment Share on other sites More sharing options...
+Mitch Posted January 11, 2011 Share Posted January 11, 2011 Hi guys, Just giving this a friendly three month bump. I hope at some point there will time to make this happen. Hi, I`ve been considering buying a harmony cartridge for the past months. I would like to know if it work in the 7800 to play 7800 games and 5200 and 2600 games. Does it work ? It will play 2600 games on a 7800. If the proto Harmony 2 comes out it will play 2600 and 7800 games on a 7800. Mitch Quote Link to comment Share on other sites More sharing options...
GeneralMurdock Posted January 13, 2011 Share Posted January 13, 2011 Is there a flash cartridge for the 5200 ? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 13, 2011 Share Posted January 13, 2011 Yes. There's also such carts available for the 8-bit computer platform (not to mention SIO2PC). BTW, I entered your full question in Google just as you wrote it and the top result was here: http://www.atarimax.com/usb5200/documentation/ Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 4, 2011 Author Share Posted March 4, 2011 Just giving this thread a little nudge. It's been six months since work was being done on this project. Have things changed for the better yet? I hope. 1 Quote Link to comment Share on other sites More sharing options...
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.