+rbairos Posted October 8 Author Share Posted October 8 4 hours ago, RevEng said: It's basically a "cart isn't inserted" check. Due to bus capacitance causing a bit of hang-time on the last driven data bus value (when there's nothing driving the bus anymore) a naive check for no cart rom (e.g. look for all FF, look for all 0, check the same location many times, etc) often fails to actually catch a no cart rom condition. That last-driven value is usually the last byte of the opcode's operand. By using a different base address but reaching the same final address with different indexes, gcc forced the last-driven value to be different. Ah okay, now I understand. So updating the 7800 BIOS looks to be a major surgery, definitely not consumer plug-n-play friendly. Sounds like what I need to do is Make FE-- output a constant zero or something until the kernel is first activated. That should work right? Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 9 Share Posted October 9 1 hour ago, rbairos said: Sounds like what I need to do is Make FE-- output a constant zero or something until the kernel is first activated. That should work right? Yep, that should work. Quote Link to comment Share on other sites More sharing options...
+karri Posted October 9 Share Posted October 9 Great! I am happy to test this on my 7800 PAL. As I am going to have small Furnace Tracker workshops at eJagfest I was planning to run small video clips on MovieCart on my 7800 PAL with the original tunes I will be converting to TIA game music. Like: And how they sound on a TIA. YaketiSax.mp3 zbb.mp3 2 Quote Link to comment Share on other sites More sharing options...
+karri Posted October 11 Share Posted October 11 I encoded both clips to mvc format. But for some reason the PAL60 clip turns red to purple. NTSC clip: YaketySax.mvc PAL60 clip: YaketyP.mvc Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 11 Share Posted October 11 1 hour ago, karri said: I encoded both clips to mvc format. But for some reason the PAL60 clip turns red to purple. You must tell the emulator to use PAL colors. 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted October 11 Share Posted October 11 1 hour ago, Thomas Jentzsch said: You must tell the emulator to use PAL colors. Thanks! I got all 3 videos to work with correct colours. - NTSC worked by default - PAL 50Hz worked by choosing MVC and PAL in GameSelection - PAL 60Hz also needed the tick box in autodetect PAL60 palette Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 11 Share Posted October 11 2 minutes ago, karri said: - PAL 60Hz also needed the tick box in autodetect PAL60 palette That worked? Wow! Quote Link to comment Share on other sites More sharing options...
+rbairos Posted October 13 Author Share Posted October 13 On 10/7/2024 at 9:03 PM, RevEng said: I know the PAL bios comments say that, but it's not quite what it's doing. It's comparing FE00-FE7F to itself using two different base addresses, and indexes set to compensate. If the compared values don't match, then it jumps to the internal game. Okay, so I found the bios listing for PAL that I think is the original implementation of what you describe above: ;Runs at 2307 ;Check if there is a cartidge in the slot FEAB: A9 16 lda #$16 ;Enable cartridge FEAD: 85 01 sta $01 ; FEAF: A0 FF ldy #$FF ;Compare FE00-FE7F with FE80-FF00 FEB1: A2 7F ldx #$7F ;if they aren't the same start Asteroids FEB3: BD 00 FE lda $FE00,x ; FEB6: D9 80 FD cmp $FD80,y ; FEB9: D0 E9 bne $FEA4 ; FEBB: 88 dey ; FEBC: CA dex ; FEBD: 10 F4 bpl $FEB3 ; However what does '2307' mean here? It looks like it resides in FEA- to FEB-.. Does that mean I can't drive that range of addresses with my own ROM code? What does happen if there is periodic bus contention in these cases? Is it dangerous? Thanks. Quote Link to comment Share on other sites More sharing options...
+karri Posted October 13 Share Posted October 13 If I understand this correctly so: $FE00,7F = FE7F $FD80,FF = FE7F So both ways to get to the byte are the same. If there is a cart then the value is the same. If there is just a floating bus then the values differ and you can start Asteroids. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted October 13 Author Share Posted October 13 Just now, karri said: If I understand this correctly so: $FE00,7F = FE7F $FD80,FF = FE7F So both ways to get to the byte are the same. If there is a cart then the value is the same. If there is just a floating bus then the values differ and you can start Asteroids. Right, that part I understand, but the code doing the bios testing is itself is in : FEAB for example. Does that mean a cart can't have code in FEAB ? which byte goes on the BUS, the cart's FEAB or the BIOS's FEAB ? The bios listing I found goes from FE3D to FEFA, overlapping with the cart region its testing? Quote Link to comment Share on other sites More sharing options...
+karri Posted October 13 Share Posted October 13 I believe that "runs at 2307" means that the code is copied in RAM and run from there. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted October 13 Author Share Posted October 13 54 minutes ago, karri said: I believe that "runs at 2307" means that the code is copied in RAM and run from there. Hmmmm. I do notice the bpl and bne use relative addressing. If that's the case, then I think I may have a 7800 PAL solution forthcoming. 1 Quote Link to comment Share on other sites More sharing options...
+rbairos Posted October 14 Author Share Posted October 14 5 hours ago, karri said: I believe that "runs at 2307" means that the code is copied in RAM and run from there. One more question. What about the region check? Something MovieCart needs to worry about ? Those were only enforced for PAL ? Can I just define a specific values in FFF8/FFF9 to make it look like PAL always? Thanks Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 14 Share Posted October 14 2 hours ago, rbairos said: One more question. What about the region check? Something MovieCart needs to worry about ? Those were only enforced for PAL ? Can I just define a specific values in FFF8/FFF9 to make it look like PAL always? Thanks You don't need to worry about that check, since you're looking to run in 2600 mode. The region byte is checked to see if running in 7800 mode should be rejected. 1 Quote Link to comment Share on other sites More sharing options...
+-^CrossBow^- Posted Monday at 02:54 PM Share Posted Monday at 02:54 PM @rbairos mentioned this earlier in the thread, but I was the one who was having issues with stuttering and skipping in movie playback with the introduction of the multi movie selection being added in. However, it seems that the SDcard I was using in my movie cart was the culprit. Last night while testing for issues related to SDcards for a completely different console, I decided to try using one of my higher quality Lexar brand SDcards on my movie cart and sure enough, the stuttering video and audio issues I was getting don't seem to be present anymore. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted 12 hours ago Author Share Posted 12 hours ago On 10/21/2024 at 10:54 AM, -^CrossBow^- said: @rbairos mentioned this earlier in the thread, but I was the one who was having issues with stuttering and skipping in movie playback with the introduction of the multi movie selection being added in. However, it seems that the SDcard I was using in my movie cart was the culprit. Last night while testing for issues related to SDcards for a completely different console, I decided to try using one of my higher quality Lexar brand SDcards on my movie cart and sure enough, the stuttering video and audio issues I was getting don't seem to be present anymore. That's good to know. I'm also having trouble securing reliable SD cards recently. I did find a batch of name-brand that works well though. I suspect the published specs on some sources aren't always accurate. Quote Link to comment Share on other sites More sharing options...
+-^CrossBow^- Posted 12 hours ago Share Posted 12 hours ago Just now, rbairos said: That's good to know. I'm also having trouble securing reliable SD cards recently. I did find a batch of name-brand that works well though. I suspect the published specs on some sources aren't always accurate. Yes... I've actually purchased more of those Lexar SDcards. They still have issues using them in my Jaguar GD cart but seem great for everything else. 1 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.