bugbiter Posted December 25, 2014 Author Share Posted December 25, 2014 Hello Steven, merry Christmas to you and your family too! I have seen this glitch before, but only on atari 800 emulator. Altirra and any real Atari never show this behaviour. I would have fixed this already if I knew how to step through code in atari800 on a scanline basis like altirra can. I guess there is some issue with STA WSYNC timing on Atari800 that gets the display kernel out of sync and the scanlines do not get their correct Gr.9/Gr.11 switches. Maybe I will alter the wsync timing a bit and see if that changes it to the better. Thanks a lot for the Christmas package! I will definitely run the slideshow in the background Martin 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 25, 2014 Share Posted December 25, 2014 Sorry I didn't catch this sooner. I was adding some pictures to the Christmas collection I made last year and on some pictures I noticed a glitch. The problem only occurs with BGPVWR16 (as far as I can discover). Earlier versions are fine. See the problem below. candle30-15.pngcandle30-16.png as seen with BGPVWR15 as seen with BGPVWR16 The problem is at the top of the picture. (Click the thumnails for a better view). Generally 2 to 4 scanlines have wrong data. The problem is more frequent with pictures that aren't letterboxed. -SteveS I unfortunately have to work tomorrow, but not until midnight. I will try to work on the convertor a bit tomorrow, and get a new release out before the new year. Quote Link to comment Share on other sites More sharing options...
bugbiter Posted December 27, 2014 Author Share Posted December 27, 2014 Hi Guys, here's a new version that fixes the glitch that occurs with Atari800 Emulator. I just left out the sta wsync in the very first scanline of the display kernel. That gives the routine more time. Somehow Atari800 has some timing differences here, so the time critical code scrambled up a bit. Everything should be fine now. There is still a small artifact with Atari800 in the very first display line when you press option to stop interlacing... But I have no clue what the Emulator does there.. Otherwise nothing has changed except for the version number :-) bgpvwr22.xex Quote Link to comment Share on other sites More sharing options...
Gunstar Posted December 28, 2017 Share Posted December 28, 2017 (edited) Ok, this thread happened during some years when I didn't have a working Atari, so I totally missed this converter and viewer stuff.. This seems fantastic! I think I might give Rastaconverter a rest for a bit and do some 256 color conversions... Edited December 28, 2017 by Gunstar 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 28, 2017 Share Posted December 28, 2017 Ok, this thread happened during some years when I didn't have a working Atari, so I totally missed this converter and viewer stuff.. This seems fantastic! I think I might give Rastaconverter a rest for a bit and do some 256 color conversions... Let me know if you want a copy of my latest converter. I don't think I ever released the PC tool, as it was not done (still isn't). 1 Quote Link to comment Share on other sites More sharing options...
Gunstar Posted December 28, 2017 Share Posted December 28, 2017 I sure would! Thanks! Quote Link to comment Share on other sites More sharing options...
bugbiter Posted December 29, 2017 Author Share Posted December 29, 2017 (edited) Hi Gunstar!You'll want the latest release of the viewer. It supports SpartaDos subfolders now.I've also written a converter for the real Atari itself which takes a windows Bitmap picture as a source.. it's of course slower and more cumbersome than Stephen's converter which can do a JPG directly, but there are some features that are not (yet?) implemented by Stephen.However, the new viewer is downward compatible to BGP files made with Stephen's converter.Here You'll find the latest release package in post #302:http://atariage.com/forums/topic/252742-abbuc-softwarecompetition-2016/page-13?hl=abbuc Edited December 29, 2017 by bugbiter Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 29, 2017 Share Posted December 29, 2017 Hi Gunstar! You'll want the latest release of the viewer. It supports SpartaDos subfolders now. I've also written a converter for the real Atari itself which takes a windows Bitmap picture as a source.. it's of course slower and more cumbersome than Stephen's converter which can do a JPG directly, but there are some features that are not (yet?) implemented by Stephen. However, the new viewer is downward compatible to BGP files made with Stephen's converter. Here You'll find the latest release package in post #302: http://atariage.com/forums/topic/252742-abbuc-softwarecompetition-2016/page-13?hl=abbuc I really need to get back to this. Had a very bad year and work has just been grinding me non stop. I began implementing the new version 3 header, but I have not implemented the CIN mode pictures. Speaking of, is there anywhere I can take a look at the CIN format specifications (besides looking at your Atari converter)? Quote Link to comment Share on other sites More sharing options...
bugbiter Posted December 29, 2017 Author Share Posted December 29, 2017 Hello Stephen, There is an Excel file with the format specs for both APAC and CIN type in the folder in that post #302. - sorry I can't attach it directly right now. What else would you need? Maybe some explanations about algorithms?..I found the CIN conversion is quite more complex than apac.. did I give you the source codes yet at all ? 1 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted December 29, 2017 Share Posted December 29, 2017 Hmmm, I think there is a small "error" (or typo) in the BGP - CIN details (excel file with the format specs)... xsize: horizontal size of the CIN picture (0 to 156) Afaik, normal Gr. 15 and CIN pics have 160 pixels, with overscan up to 176 pixels I guess, so it should be: xsize: horizontal size of the CIN picture (0 to 176) or am I wrong here ?!? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 29, 2017 Share Posted December 29, 2017 Hello Stephen, There is an Excel file with the format specs for both APAC and CIN type in the folder in that post #302. - sorry I can't attach it directly right now. What else would you need? Maybe some explanations about algorithms?..I found the CIN conversion is quite more complex than apac.. did I give you the source codes yet at all ? I'll check the post you are referring to. I don't recall seeing the sources to your converter. Quote Link to comment Share on other sites More sharing options...
bugbiter Posted December 29, 2017 Author Share Posted December 29, 2017 Hmmm, I think there is a small "error" (or typo) in the BGP - CIN details (excel file with the format specs)... xsize: horizontal size of the CIN picture (0 to 156) Afaik, normal Gr. 15 and CIN pics have 160 pixels, with overscan up to 176 pixels I guess, so it should be: xsize: horizontal size of the CIN picture (0 to 176) or am I wrong here ?!? You are right. 88max with apac and twice that with cin. I should correct that. Thanks! Quote Link to comment Share on other sites More sharing options...
bugbiter Posted December 29, 2017 Author Share Posted December 29, 2017 I'll check the post you are referring to. I don't recall seeing the sources to your converter. I just discovered an old PM with the sources that I sent you about a year ago. Check it out - I'll gladly repost it if necessary 2 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.