Jump to content

Sheddy

Members
  • Content Count

    803
  • Joined

  • Days Won

    1

Posts posted by Sheddy


  1. 16 hours ago, 55five66six said:

    Seems like the average file size is around 22k. Does anyone know the breakdown as far as how much of the filesize is the viewing application vs the converted image? 

     

    13 hours ago, Rybags said:

    RC generates a kernal that does the colour changes - a fair bit of it is consecutive NOPs so it's not real big on efficiency re saving memory.

    Possibly some saving could be had by changing some of them to instructions that use less memory but have the same delay effect.

     

    The remainder aside from the screen data, I'd guess probably not much.  Unsure if the display list is hardcoded or programatically generated but that's a few hundred bytes at most.

    The display list is hard coded and it's pretty big at around 750 bytes. Rest of the viewer is only about 100 bytes or so.

    Making RastaSlide I found compressing the kernel and picture tended to gave a smaller file size than changing to fewer instructions in the kernel and also compressing!

    • Like 1
    • Thanks 1

  2. On 9/2/2021 at 4:38 PM, drpeter said:

     

    A further manifestation of RastaConverter's player repositioning bug

     

    I've recently stumbled across another consequence of the player repositioning bug in RastaConverter- one that seems to occur less commonly, but also is obvious when you think about it.

     

    It's the reverse of the usual situation, the one where RastaConverter assumes a repositioned player will be displayed in its new position on the same line but actually it is not- allowing pixels from COLBAK or a player with lower priority to unintentionally 'show through' instead.

     

    This 'new' type of error can occur when RastaConverter repositions a player after it has already triggered but not yet displayed at its current HPOS (i.e. during the 5-6 colour-clock delay between these 2 events). RastaConverter is not aware the player has already triggered, and that it will now therefore be displayed at its existing 'old' HPOS position regardless. It assumes that the repositioned player will NOT be displayed at its 'old' HPOS, thereby allowing COLBAK or lower priority players to appear, but in fact any such pixels end up obscured by the player displaying at its 'old' position regardless of the repositioning.

     

    @Sheddy will be including this new observation in the annotations of disassembled Rastaconverter .xex files output by Rastaslide (output.png.rp).

     

    In the meantime, I have updated my tutorial on the subject, again.

     

     

    Tutorial Walkthrough_Ver4.pdf 4.53 MB · 16 downloads

     

    RastaSlide - RastaConverter Slide Show Maker - version 2.7

    Changes in version 2.7
    - Includes Drpeter's version 4 "Tutorial Walkthrough" for artefact correction
    - Added detection of an extra cause of HPOS line artefacts described in that guide
    - Folders of slides can be added now as well as folders of RastaConverter pictures
    - PMG file output in same MADS hex data format as RastaConverter

     

     

    sheddy_peacock_feather_before.pngsheddy_peacock_feather.png

    RastaSlide 2.7.zip sheddy_peacock_feather.xex

    • Like 6
    • Thanks 2

  3. The fixing guide is all down to @drpeter. Very comprehensive tutorial and technical background on RastaConverter. I think this is the latest version:

    I added some timing info comments and "line artefact detection" to RastaSlide disassembler to help with manually fixing artefacts although we still end up with false positives. So there is a base to build on an automatic fix attempt. I haven't come up with an approach that is simple enough for me to implement confidently yet though.


  4. RastaSlide - RastaConverter Slide Show Maker - version 2.6

     

    Changes in version 2.6
    - Fixed bug on optimized kernel trailing loads getting undone, and to the wrong line
    - Optimizer removes player colour writes(leaving last) when there is no player data

     

    The bug caused minor visual differences at the bottom of a very few RastaConverter pictures as slides so recommend to updatesheddy_heart_in_sand.png.ac94f897129f5d9d2086cfe2f5ec5657.png

    RastaSlide 2.6.zip sheddy_heart_in_sand.xex

    • Like 8
    • Thanks 2

  5. RastaSlide - RastaConverter Slide Show Maker - version 2.5

     

    Changes in version 2.5

    - Optimizer now removes HPOS writes when there is no player data for their range, for
      small compression gain and reducing false positives of possible artefacts using
      "#disassemble optimized"
    - Fixed bugs with false positive detection of possible artefacts excluding real ones
    - Timing and artefact comments only produced with disassembly tools and not slide add
    - Fixed problems displaying 3 pictures made with a very early(beta?) RastaConverter:
      "cliff", "purple_nurple" and "sakuras2b"

     

    sheddy_umbrella.png.a0bbeaa50319ff4caa302d310d13873d.png

    sheddy_umbrella.xex RastaSlide 2.5.zip

    • Like 11
    • Thanks 2


  6. RastaSlide - RastaConverter Slide Show Maker - version 2.4

     

    Changes in version 2.4
    - Removed false positives of possible artefacts on duplicate writes by "#disassemble" 
    - Includes Drpeter's latest version 3 "Tutorial Walkthrough" for artefact correction

     

    Thanks to Drpeter for our messaging about the false positives which I hadn't given enough thought about in the above case.

    RastaSlide 2.4.zip

    • Like 4
    • Thanks 1

  7. RastaSlide - RastaConverter Slide Show Maker - version 2.3

    Changes in version 2.3
    - Remove intermediate "#disassemble optimized" files which otherwise get used to build
    - Added detection for newly discovered 6 colour clock HPOS thermal delay artefacts
    - Reduced false positives of possible artefacts (thanks to Drpeter)

     

    Very interesting this odd problem hasn't been noticed before. Could it be related to age of boards/chips too - Would a brand new Atari in 1979 have had the same issue?

    RastaSlide 2.3.zip

    • Like 3
    • Thanks 1

  8. 23 hours ago, Sheddy said:
    On 2/7/2021 at 5:54 PM, Sheddy said:

    Good question.

    Probably, change the Rastaconverter run address to be an ini address instead. Then assuming no source, remove the 1st 2 "ff" header bytes of the XEX file that is to be loaded afterwards and append it to the Rastaconverter XEX. Maybe you don't need to remove the header bytes though. Finding the run address of the Rastaconverter picture without source might be a pain. Can send you a bit more specific if you need.

    Kind regards

    Chris

    Run address is right at the end.

    E0 02 E1 02 00 58

    Change to

    E2 02 E3 02 00 58

    (Load $5800 into INI address $2E2, $2E3)

     

    Well, that doesn't seem to work. I thought it might be because Rastaconverter trashes DOSVEC, but changing it to use a different zero page still crashes after the picture is done. Must be missing something dumb as

    Actually it does work. It was just too quick to notice! Problem was I chose another Rastaconverter picture to be the XEX test to load after the 1st picture. Because the 2nd picture loads instantly in the emulator, still having the space bar pressed from exiting the 1st picture causes the 2nd to exit immediately...

    Anything except another Rastaconverter picture XEX to load after will probably be just fine. 

     

    • Like 1

  9. On 2/7/2021 at 5:54 PM, Sheddy said:

    Good question.

    Probably, change the Rastaconverter run address to be an ini address instead. Then assuming no source, remove the 1st 2 "ff" header bytes of the XEX file that is to be loaded afterwards and append it to the Rastaconverter XEX. Maybe you don't need to remove the header bytes though. Finding the run address of the Rastaconverter picture without source might be a pain. Can send you a bit more specific if you need.

    Kind regards

    Chris

    Run address is right at the end.

    E0 02 E1 02 00 58

    Change to

    E2 02 E3 02 00 58

    (Load $5800 into INI address $2E2, $2E3)

     

    Well, that doesn't seem to work. I thought it might be because Rastaconverter trashes DOSVEC, but changing it to use a different zero page still crashes after the picture is done. Must be missing something dumb as RastaSlides are chained together in the XEX in the same way

    • Like 1

  10. 3 hours ago, Philsan said:

    @Sheddy Chris, what is the easiest way to add a Rastaconverter image to an existing XEX?

    I want the image to load, then when I press space bar, XEX is loaded.

    Good question.

    Probably, change the Rastaconverter run address to be an ini address instead. Then assuming no source, remove the 1st 2 "ff" header bytes of the XEX file that is to be loaded afterwards and append it to the Rastaconverter XEX. Maybe you don't need to remove the header bytes though. Finding the run address of the Rastaconverter picture without source might be a pain. Can send you a bit more specific if you need.

    Kind regards

    Chris

    • Like 1
    • Thanks 1

  11. RastaSlide - RastaConverter Slide Show Maker - Version 2.2


    Changes since version 2.1
    - Fixed "#build centred output" issue where pictures built don't display in RastaSlide
    - Disassembler changed to deal with existing "#build centred output" pictures

     

    Yeah, I didn't check my own centered pictures worked in RastaSlide. Duh.

    They work fine as stand-alone pictures and add OK with no error, but don't display properly in the slide show.

    I'd advise anyone using RastaSlide to make centered pictures to update to this version

     

     

    RastaSlide 2.2.zip

    • Like 8
    • Thanks 1
×
×
  • Create New...