+rbairos Posted March 7 Share Posted March 7 Hey Everybody. Thought I'd start a new thread for this specific topic. So I've gotten someone to help test MovieCart on PAL, and we found a problem right away: The kernel doesn't seem to be working. You can see the correct vs incorrect screen shots below. The 'i' column in movie is duplicated "Miovie" Granted, this startup screen is still NTSC format: width: 80 height: 192 vsync: 3 blank: 37 overscan: 30 total lines: 262 I would expect this to roll, but not mix up the kernel like that. I do use the undocumented 8-bit sprite shift, and I assume this works on PAL ant NTSC, since it works on Stella and Gopher? It's still the same horizontal number of pixels per line right? The cart firmware runs at the same speed, updating the data bus on address changes as before. It doesn't change its timing. The only provisions I make for PAL are all in the MVC file: width: 80 height: 242 vsync: 3 blank: 37 overscan: 30 Total Lines: 312 (Plus I use a different color palette and write out the frames to the file every 25th vs 30th of a second). Any idea what I may be overlooking? Worst case, I go out and get a PAL Atari, and find a way to watch it on LCD. Thanks very much. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 7 Share Posted March 7 (edited) How about PAL-60? Less vertical resolution but also less flicker. I suspect a timing issue (e.g. due to page penalties). Can you post the code with addresses? Edited March 7 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 7 Author Share Posted March 7 @Thomas Jentzsch : Don't original PAL Atari's output PAL-50 though? An early implementation is in stella. The code is very low-level, but it was mirrored around V1 hardware at the time: https://github.com/stella-emu/stella/blob/master/src/emucore/CartMVC.cxx (For comparison, here's the same kernel implemented in V2: https://github.com/lodefmode/moviecart/blob/main/firmware/core.c ) Strange thing is above kernel plays these PAL encoded examlpes fine on unreleased stella: https://github.com/lodefmode/moviecart/tree/main/examples Thanks. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 7 Share Posted March 7 49 minutes ago, rbairos said: @Thomas Jentzsch : Don't original PAL Atari's output PAL-50 though? Yes, but they can do PAL-60 as well. And most PAL CRTs (except for very old ones) and all modern TVs can display this. 49 minutes ago, rbairos said: An early implementation is in stella. The code is very low-level, but it was mirrored around V1 hardware at the time: https://github.com/stella-emu/stella/blob/master/src/emucore/CartMVC.cxx (For comparison, here's the same kernel implemented in V2: https://github.com/lodefmode/moviecart/blob/main/firmware/core.c ) Sorry, but in that format I do not think I can provide much help. 49 minutes ago, rbairos said: Strange thing is above kernel plays these PAL encoded examlpes fine on unreleased stella: https://github.com/lodefmode/moviecart/tree/main/examples Yes, I had checked these too. A vague(!) idea: The CPU frequency of a PAL console is slightly lower than for NTSC. Could this be relevant? And have you considered it? Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 7 Author Share Posted March 7 13 minutes ago, Thomas Jentzsch said: Yes, but they can do PAL-60 as well. And most PAL CRTs (except for very old ones) and all modern TVs can display this. Sorry, but in that format I do not think I can provide much help. Yes, I had checked these too. A vague(!) idea: The CPU frequency of a PAL console is slightly lower than for NTSC. Could this be relevant? And have you considered it? So PAL-60. That's basically just outputting fewer lines then? Yah, I should dig up the original ASM format. Thought the timing might be traceable on the stella debugger. Re: Different CPU frequency. Thought about it, but not sure where it may apply. The pixel clock isn't directly tied to the CPU clock in PAL systems from my understanding? Maybe there's some edge case that falls the wrong way in this setup. That would surprise me though. If anything, the microcontroller should have a little more time to update each pixel then? Thanks, Rob Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 7 Share Posted March 7 (edited) 41 minutes ago, rbairos said: So PAL-60. That's basically just outputting fewer lines then? Yes, NTSC number of lines, PAL colors 41 minutes ago, rbairos said: Yah, I should dig up the original ASM format. Thought the timing might be traceable on the stella debugger. The debugger crashed with MVC. But I only had to add one missing line of code. Now I saw the code. But I did not see what could have caused the problem. I also tried all odd TIA settings in Developer/TIA, but nothing seemed to cause the problem. But if I disable VDELP1, then it looks like this. Looks similar, no? Then I checked your code, but the writes to VDELP1 look fine. Hm... 41 minutes ago, rbairos said: Re: Different CPU frequency. Thought about it, but not sure where it may apply. The pixel clock isn't directly tied to the CPU clock in PAL systems from my understanding? No, 1 CPU cycles == 3 pixel. I do not know your hardware, but if you have your own clock, this might cause problems. 41 minutes ago, rbairos said: If anything, the microcontroller should have a little more time to update each pixel then? No, slightly more, since the CPU clock is slightly lower. But your error looks like an too early write. What makes me wonder are the artifacts at the very left. These shouldn't be there at all. Edited March 7 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 7 Author Share Posted March 7 18 minutes ago, Thomas Jentzsch said: Yes, NTSC number of lines, PAL colors Sneaky standard! But settable on the MovieCart encoder by users. I could add it as a default though. 18 minutes ago, Thomas Jentzsch said: But if I disable VDELP1, then it looks like this. Looks similar, no? Interesting, I should get you an MVC of the theatre title screen image, then we would know for certain. The card has a clock, but only to drive the microcontroller that monitors the address/data bus. Maybe the changes aren't as clean as it needs. 18 minutes ago, Thomas Jentzsch said: What makes me wonder are the artifacts at the very left. These shouldn't be there at all. Don't follow. When you disable VDELP1, you're not seeing what you expect? Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted March 7 Share Posted March 7 13 minutes ago, rbairos said: Interesting, I should get you an MVC of the theatre title screen image, then we would know for certain. Can you post the theatre title screen ROM here. Or if not, can you post it to me privately please? 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 7 Share Posted March 7 13 minutes ago, rbairos said: Interesting, I should get you an MVC of the theatre title screen image, then we would know for certain. I wouldn't mind. 13 minutes ago, rbairos said: Don't follow. When you disable VDELP1, you're not seeing what you expect? No, I mean your PAL screenshot and these artifacts on the left. Looks like an 11th column. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 7 Share Posted March 7 BTW: Are you sure your tester's console's TIA is fine? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 7 Share Posted March 7 11 minutes ago, JetSetIlly said: Can you post the theatre title screen ROM here. Or if not, can you post it to me privately please? Me too, please. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 7 Author Share Posted March 7 Tester will test more in the upcoming days, but I can ask. Think things are mostly in storage. I'll try to reconstitute the theatre image into a file again. Might take me a little bit. It's all separated C byte arrays at the moment, in the firmware code. Tonight I'll write #0 to VDELP1 in a moviecart and take a photo of the title screen as well. 1 Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 7 Author Share Posted March 7 Here's the NTSC output with VDELP1=0. Very close, but not 100% sure it's a match. Maybe. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 8 Author Share Posted March 8 And here's 1 second worth of the title screen. title.zip Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 8 Share Posted March 8 Wow, that one got zipped by a factor of 82. Of course the static image plays a major role here, but have you thought about adding some simple compression like run-length encoding? Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted March 8 Share Posted March 8 8 hours ago, rbairos said: And here's 1 second worth of the title screen. Thanks. I don't believe this is a PAL TV issue. It looks like a more fundamental problem to me but without knowing more about the user's console I wouldn't be confident in saying what it might be. I assume that the specific MovieCart cartridge work okay in a different console? 18 hours ago, rbairos said: Worst case, I go out and get a PAL Atari, and find a way to watch it on LCD. Is there person watching it on an LCD TV? I honestly wouldn't trust those things to reproduce an image from an RF signal. Or has the console been modded? That might be an explanation. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 8 Author Share Posted March 8 6 hours ago, Thomas Jentzsch said: Wow, that one got zipped by a factor of 82. Of course the static image plays a major role here, but have you thought about adding some simple compression like run-length encoding? I've thought about it alot. Originally it was a non-starter as the 64MIPs microcontroller wouldn't have the cycles. But even now with 100MHz, there's a big benefit to knowing each frame is at a fixed position. Makes shuttling easier. Technically Im using around 2.5K per field, but I rounded that up to 4K thinking it might be easier on the SDCard access. I might end up using a RLE though in the future if I move to a higher definition graphics system. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 8 Author Share Posted March 8 5 hours ago, JetSetIlly said: Thanks. I don't believe this is a PAL TV issue. It looks like a more fundamental problem to me but without knowing more about the user's console I wouldn't be confident in saying what it might be. I assume that the specific MovieCart cartridge work okay in a different console? Is there person watching it on an LCD TV? I honestly wouldn't trust those things to reproduce an image from an RF signal. Or has the console been modded? That might be an explanation. This is the first time the movie carts been tested on a PAL Atari, and I believe its a PAL TV as well. I think he'll be able to find another setup to test. By fundamental problem, you mean with the TIA or with the kernel? I think I'll dig up the old kernel test code, then maybe we could try it on a Harmony cart or something, to make sure the kernel is sound at least. Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted March 8 Share Posted March 8 3 minutes ago, rbairos said: By fundamental problem, you mean with the TIA or with the kernel? Hardware. Possibly the TIA. I can't think of a reason why the kernel would behave any differently on a PAL machine. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 8 Author Share Posted March 8 15 minutes ago, JetSetIlly said: Hardware. Possibly the TIA. I can't think of a reason why the kernel would behave any differently on a PAL machine. Me too. Fingers crossed. I'll rebuild the test ASM file, and maybe people with Harmony or Plus , or Uno Carts can try it on their setups this weekend. Should have thought of that earlier. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 10 Author Share Posted March 10 @Thomas Jentzsch I've just written a little stand-alone bin for both PAL and NTSC versions of the kernel if you are interested: Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 10 Share Posted March 10 27 minutes ago, rbairos said: I've just written a little stand-alone bin for both PAL and NTSC versions of the kernel if you are interested: Saw it. How does it work on the PAL test console? Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 10 Author Share Posted March 10 11 minutes ago, Thomas Jentzsch said: Saw it. How does it work on the PAL test console? My tester has only tested the moviecart so far, not the stand-alone bin demo I just posted. Results are mixed on different 2600 PAL JRs. 1 works, 2 are mixed up as in the earlier post. And another sometimes works, sometimes mixed up (though it has a long history of that) and may be a cause of overheating. They haven't been tested with original carts yet though. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 11 Share Posted March 11 On 3/7/2024 at 6:34 AM, rbairos said: I do use the undocumented 8-bit sprite shift Do you mean an early HMOVE to go left by 8? Many PAL Atari Jr's and some PAL 7800's don't work with early HMOVE's. Quote Link to comment Share on other sites More sharing options...
+rbairos Posted March 11 Author Share Posted March 11 14 minutes ago, Omegamatrix said: Do you mean an early HMOVE to go left by 8? Many PAL Atari Jr's and some PAL 7800's don't work with early HMOVE's. Dang!! That might be the issue then. I posted the 4k bin files above if anyone wants to test on their 7800 or PAL Jr on Harmony's etc. So question is, can the kernel be modified to not use the early 8-bit shift left? Aaack.. Stuff I tried early in this project. But alternatives may be: A) Alternating columns instead of alternating checkerboards. (flicker would be more noticeable) B) Three line kernel that takes 3 passes to fill (even worse flicker 50/3 = 16.7Hz to fill screen) C) Find cycles somewhere (impossible), but I suppose updating audio only 7.6KHz vs 15.7 KHz would be fine if it helped. Is there a known list models support early 8 bit shift left or not? Should this be an option on Stella @Thomas Jentzsch ? 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.