Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

newcoleco

Members
 View Profile  See their activity

  • Content Count

    1,351

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by newcoleco

  1. Posted · Edited by newcoleco

    SCR2PC - Convert ZX Spectrum bitmap pictures into ColecoVision bitmap pictures

    by Daniel Bienvenu aka NewColeco

    January 2017

     

    There are lots of cool ZX Spectrum pictures released as .scr or .mlt files and tools to make them.

     

     

    Technical Information

     

    ZX Spectrum bitmap screens are 256x192 pixels, same for the ColecoVision.

    ZX Spectrum graphics files are composed of PATTERN and COLOR data tables, same for the ColecoVision.

    ZX color palette is composed of 15 colors, same for the ColecoVision, but the colors are not the same. The video chip TMS9928 inside ColecoVision do not have two different magenta and two different cyan colors.

    ZX PATTERN and COLOR data are structured differently, bytes in a different order between them and different than how ColecoVision handles it.

     

    Considering all the similarities and differences, I've coded the following simple graphics converter tool.

    This converter support both .SCR and .MLT files and can generate PATTERN and COLOR data into two files instead of one .PC file.

    This solution is a CLI (command line interface) written in C.

     

    CV Paint 2 can load and ZX Spectrum pictures as well but is no more supported.

     

     

    Example

     

    ZX Spectrum Space Harrier title screen by MAC, 2014.

     

     

    post-3651-0-43058100-1483931783.gif

     

    post-3651-0-44089400-1483986255.png

     

     

    Download

     

    SCR2PC Version 0.3 (EXE, SRC, BATCH FILE): scr2pc.zip

    Change log:

    • Fixed typos

     

    SCR2PC Version 0.2 (EXE, SRC, BATCH FILE): scr2pc.zip

    Change log:

    • Added multiple palettes

     

    SCR2PC Version 0.1 (EXE, SRC, BATCH FILE): scr2pc.zip

     

     

    Various Links

     

    Convert PowerPaint pictures into PC files

    Simple ColecoVision PC viewer (in Java)

    Atarimax Coleco Ultimate SD Multicart

    Gallery: ZX Art

    Tool: Image to ZX Spec v2.0

    post-3651-0-43058100-1483931783_thumb.gif

    post-3651-0-44089400-1483986255_thumb.png

    • Like 8

  2. Posted · Edited by newcoleco

    DAN2 Lossless Compression

    by Daniel Bienvenu aka NewColeco

     

    A variant of DAN1 Compression Format

    Based on LZ77 data compression, multiple offset sizes, unary code and elias gamma.

     

    The project started after Alekmaul remarks and test data during December 2016.

     

     

    Technical information

     

    Three (3) differences compared to DAN1:

    1. The set of 4 different sizes to encode offset values becomes { 1, 4, 8, max } where max value is set by the user.
    2. The capability to store sequences of literal bytes is removed.
    3. The END OF DATA code is 17 bits long instead of 18.

    The data format changed a little, making it incompatible with the original DAN1 format.

    The first bits is an unary code to set the maximum of bits for offset values ( 0 = 10 bits, 10 = 11 bits, 110 = 12 bits, etc.)

    The second byte is the first raw byte to copy as literal.

    The rest of the data format follows similar to DAN1 specifications, except there is no sequences of literals (RLE) and also the END code is shorter by 1 bit.

     

     

    Comparing DAN1 and DAN2

     

    In term of speed, the compression and decompression are virtually the same speed as DAN1.

    In term of size, the decompression routine is slightly bigger than DAN1, +7 bytes according to my z80 data compression library.

    The expected improvement in compression ratio is only due to the possibility to adjust the maximum number of bits to encode offsets.

    Test samples from Exomizer
    test1.bin (audio wave file)
    • Original: 202762
    • ZX7: 223933
    • DAN1: 204208 (sequences of raw bytes help to not blow up in size)
    • DAN2 -m 16: 216898
    • Pletter: 221245
    • MegaLZ: 221136
    • Aplib aka APPACK: 219793
    • PUCrunch: N/A
    test2.bin (text file filled only with the letter q)
    • Original: 196608
    • ZX7: 19
    • DAN1: 18
    • DAN2 -f -m 10: 18
    • Pletter: N/A *error during compression*
    • MegaLZ: 2510
    • Aplib aka APPACK: 19
    • PUCrunch: N/A
    test3.bin (formatted text file with fields such as name and date)
    • Original: 111261
    • ZX7: 52035
    • DAN1: 48103
    • DAN2 -m 16: 37048
    • Pletter: 44563
    • MegaLZ: 47052
    • Aplib aka APPACK: 37094
    • PUCrunch: N/A

     

    Test samples from Alekmaul

     

    Robee Blaster Title (Pattern, Color, and Name version)

    • Original: 2024, 2024 and 768. Total 4816
    • ZX7: 970, 790 and 383. Total 2143
    • DAN1: 965, 793 and 385. Total 2143
    • DAN2 m -10: 947, 784 and 385. Total 2116
    • Pletter: 957, 787 and 385. Total 2129
    • MegaLZ: 972, 806 and 384. Total 2162
    • Aplib aka APPACK: 986, 806 and 384. Total 2176
    • PUCrunch -d -c0 -s: 940, 772 and 373. Total 2085

    Robee Blaster Title (Pattern and Color only version)

    • Original: 6144 and 6144. Total 12288
    • ZX7: 1257 and 793. Total 2049
    • DAN1: 1248 and 799. Total 2047
    • DAN2 -m 11: 1233 and 791. Total 2024
    • Pletter: 1259 and 795. Total 2054
    • MegaLZ: 1269 and 832. Total 2101
    • Aplib ka APPACK: 1273 and 825. Total 2098
    • PUCrunch -d -c0 -s: 1235 and 770. Total 2005

     

    Test Sample Bitmap Graphic II

     

     

    Download

     

    DAN2 (EXE, SRC, ASM) version BETA-20170106 : dan2-beta-20170106.zip

     

    Change Log for version BETA-20170106:

    • increased up to 16 bits max offset size value
    • fixed bug with default max bits
    • fixed bug occurring with test2.bin sample

     

    DAN2 (EXE, SRC, ASM) version BETA-20170101 : dan2-beta-20170101.zip * BUG FOUND , PLEASE DOWNLOAD NEWER VERSION *

    • Like 1

  3. Posted · Edited by newcoleco

    Solved.

     

    Somehow, it is space consuming to split into 3 tables (PATTERN, COLOR, NAME) instead of just 2 (PATTERN, COLOR) assuming we talk about a bitmap screen. When using only 2 tables, DAN1 performs as expected, getting better results than Pletter. When using 3 tables under 2048 bytes each, DAN1 is using more bits than needed to store offset values. A solution is to adapt and there are some ways to make it.

     

    For this problem, I considered a simple variation of DAN1 using a reasonable number of bits to store offset values adapted to the data, which in this case a maximum of 10 bits will do the trick. The results are :

     

    With 3 tables

    Pletter :
    1. const byte TILtitle3PLE[] = { // tile size pletter compressed 957 bytes (52%)
    2. const byte COLtitle3PLE[] = { // color size pletter compressed 787 bytes (61%)
    3. const byte MAPtitle3PLE[] = { // map size pletter compressed 385 bytes (49%)

    Total = 2129 bytes

     

    Dan1_10 (adapted) :
    1. const byte TILtitle3DAN1_10[] = { // tile size dan1 compressed 947 bytes (53%)
    2. const byte COLtitle3DAN1_10[] = { // color size dan1 compressed 784 bytes (61%)
    3. const byte MAPtitle3DAN1_10[] = { // map size dan1 compressed 385 bytes (49%)
    Total = 2116 bytes
    As for if the picture was kept as a bitmap into 2 tables, DAN1 performs nicely, and sometimes only 11 bits max perform better. The results are :
    With 2 tables (assuming screen filled with all the possible characters to show a bitmap screen)
    Pletter :
    1. const byte TILtitle3Plet[] = { // tile size pletter compressed 1259 bytes (79%)
    2. const byte COLtitle3Plet[] = { // color size pletter compressed 794 bytes (87%)
    Total = 2053 bytes
    Dan1_12 (original) :
    1. const byte TILtitle3DAN1_12[] = { // tile size dan1 compressed 1248 bytes (79%)
    2. const byte COLtitle3DAN1_12[] = { // color size dan1 compressed 799 bytes (87%)
    Total = 2047 bytes
    Dan1_11 (adapted) :
    1. const byte TILtitle3DAN1_11[] = { // tile size dan1 compressed 1233 bytes (79%)
    2. const byte COLtitle3DAN1_11[] = { // color size dan1 compressed 791 bytes (87%)
    Total = 2024 bytes

     

    Since DAN1 source code is given, it is possible to change it by yourself and adapt the solution to your needs like I've done here to present these results. With more data and time, I may create a new software solution, perhaps as a new format and keep this one as is; it's at least something to think about.

  4. Posted · Edited by newcoleco

    Dear alekmaul,

     

    The behavior you are experimenting is normal for 3 reasons :

     

    1. The fixed set may be overkill and waste bits in some cases, but my tests tend to demonstrate that a set of 4 sizes is optimal (5 being too much). The static set of 1,4,8,12 bits size to encode the offset values is optimal for "large" ColecoVision graphics in average according to my sample set. An offset using 12 bits (value going up to 2^12) goes beyond the limit of a charset (size 2^11), making the highest bit totally useless and so increase artificially the size of the compressed data. Your picture has lots of repeated sequences very close to each other, within a charset distance maximum.

     

    2. Pletter has multiple options to encode offset values and uses the best fit one according to the data. DAN1 encodes offset values into the four fixed sizes 1,4,8 and 12 bits depending on their values. This set is in average ideal, but not adapted to the data. A workaround is to modify DAN1 to use a different set more adapted to the data used in your project, which is what I did in the slideshow demo in another thread and named it DAN1C (C simply means it was the variation C I tried that day and worked nicely).

     

    3. DAN1 is not a miracle solution, but is surely a great one.

     

    My sample set to develop DAN1 was a bunch of bitmap screens from ColecoVision projects, pixelated photos and converted ZX Spectrum pixel arts.

    I would love to see someone make an intensive test with hundred of data files related to 8bit homebrew projects. In fact, this would be very helpful to do the next generation of data compression tool.

    Extra note : I've used with success a variation named DAN1C (C variation) that uses 1,3,8 and 11 bits to encode offset values. This variation is briefly mentioned in another thread as an alternative that works better for some graphics like the slideshow demo. Compared to the original set of 1,4,8 and 12 bits, the variation tend to reduce even more simple data such as the color table and so give better results.

     

     

    Hi,

    I have a strange behavior with your compressor Daniel.
    i tried to integrate it in my tool (thanks for sharing source code), it works fine, but compression ratio is lower than a pletter compressor icon_eek.gif !

    Dan1 :
    const byte TILtitle3DAN1[] = { // tile size dan1 compressed 965 bytes (52%)
    const byte COLtitle3DAN1[] = { // color size dan1 compressed 793 bytes (60%)
    const byte MAPtitle3DAN1[] = { // map size dan1 compressed 385 bytes (49%)

    Pletter :
    const byte TILtitle3PLE[] = { // tile size pletter compressed 957 bytes (52%)
    const byte COLtitle3PLE[] = { // color size pletter compressed 787 bytes (61%)
    const byte MAPtitle3PLE[] = { // map size pletter compressed 385 bytes (49%)

     

    I tried (only the TIL part on my image) with your exe compressor, and it gave same size, 965 bytes.

     

    Do you think it is a normal behavior for Dan1 compression ?

     

    I added the c source file of the pletter compressor i used (entry point is int pletterCompress(byte *src,byte *dst,int n)

     

    Of course, for some pictures, your compressor is sometime better, but not all the time. It is just to inform you and to share information about compression icon_smile.gif

     

    i used this image for test

  5. Posted

    It happens it the middle of scene not during vram loading of the tiles or sprites.

     

    There is sprite patterns being changed but no new ones being loaded just changed to another already predefined pattern. I had a problem on my first project with sprite 48 for some reason. That always came in corrupted. I think it specifically happens when my tank is moving and changing sprite patterns.

     

    in fact if i cycle though the sprites in your ICVGM303 it'll crash when I get to sprite 48 often times. ?? I have no idea why. It's gremlin.

     

    I'm going to try a couple more things such as no sprite pattern changeing and see if it does any better.

     

    sure is frustrating. But like you said I'll be happy when it's solved and won't give up on it.

     

     

    I would be very happy to reproduce this error message with ICVGM on my computer. I've never seen this before.

  6. Posted

    This is just my guess based on my own experience.

     

    We all experience video corruption from time to time. This one reminds me of three cases I experienced long time ago in my projects : many times I just typed the parameters in the wrong order or typed the wrong data table name to be uploaded in VRAM, I also saw what updating VRAM in a bad timing can do and now I tend to use NMI for updating VRAM in batch, and I also saw corruption when uploading the sprites table in VRAM without the byte at the end saying where that table ends ($E0 aka 240) which normally is taking care of by using a library routine but I forgot that time this detail mentioned in the TMS 9918/9928 documentation.

     

    It's all good frustration to see a problem like this but so satisfying when it's finally fixed.

  7. Posted · Edited by newcoleco

     

    Oh, excellent! Did you use FFTs? Did you manage to take advantage of the noise channel? I went to your page to try and download, but the devkit is currently showing 404.

     

    Noise channel excluded (because I couldn't figure it out back then how to make it works with noise), WAV2CV works with FFT to extract frequencies from an uncompressed wave file. Did all the coding in VisualBASIC 5 I believe and it was a great practice for my computer knowledge of that time.

     

    As you know, transforming a wave sample into 3 channels beeping sounds is not great but it does work good enough for some cases like sound effects, music, but barely with voices.

     

    I am sure your tool reaches the next step and WAV2CV is probably available if you want to give it a try. Warning : it formats the conversion result into Marcel deKogel's sound data format which can be manually converted into other formats; more information in the documentations about ColecoVision programming I wrote a long time ago.

     

    Sorry for the inconvenience of my website losing its zip files, it seems to be a glitch or a new policy of the web hosting I'm using; I should fix that.

  9. Posted

    I'm trying to change text color using load_color

     

     

    Is there another way to change text color?

     

    The line "fill_vram0(0x2000,0x1800,0xf0);" is to set white color (15 aka F) and default background color (0) for the whole color table at video RAM 0x2000. The number 0x1800 is the size of the color table for Graphic Mode 2 aka Bitmap, which I usually reduce to only 0x800 as a text mode but some emulators don't like that.

     

    As for writing a line of text in one color and another line of text in a different color on the same screen :

    Because of the way the video chip works (TMS9928), a character has its pattern and color associated. The character number 65, which is the letter A, has its pattern at 0x0000 + 65*8 , and its color at 0x2000 + 65*8. And if you duplicate the pattern A for the character number 97 (which is ASCII number for 'a') but in a different color, that character will look like A but in a different color. And so printing "Aa" will look like "AA" but in different colors.

  10. Posted

    Patchsdcc.bat isn't in SDCC/include folder but I found it at cvdevkit folder.

     

    I run it. Now I can enjoy 10years program.

     

    Thanks so much.

     

    I get errors with Bunny, Diamond and Test but I still can run them.

     

    I've got blank screen when I run Chateau, Cosmoc and Testroller.

     

    Sorry for all the trouble.

     

    I should probably make a new video about the devkit and also test with the actual SDCC version and under Windows 10.

  11. Posted

    Just a few words before receiving tons of messages about how to use this tool and what's the difference between dan1vram and dan1rvram routines included in the zip archive file.

     

    DAN1 has two "flavors" : a normal one and a special with RLE coding for long strings of uncompressible data.

     

    You won't need the extra RLE coding most of the time because LZSS works just fine by itself.

     

    In the case you want to use the special RLE coding, use the flag ' -r ' to allow its usage during compression, which doesn't mean it will be necessary and used for your data.

     

    DAN1VRAM is for normally compressed DAN1 data.

    DAN1RVRAM* is for DAN1 data using special RLE coding.

     

    * : You can use DAN1RVRAM routine for both DAN1 normal data and DAN1 with RLE data.

     

    I hope this is clear.

     

    Please share and comment.

    I'm already getting suggestions about tools using DAN1 in various ways.

  12. Posted · Edited by newcoleco

    Maybe your game is simply trying to update sprites a bit too fast while the screen is refreshing, in this case, uses extra NOPs between commands 'IN' and 'OUT' to update VRAM instead of an 'OTIR' single command. Another way is to update sprites right at each NMI interruption to avoid updating them while the screen is redrawn, and if you already do this, it might be done just a bit too late; so put it right at start of the NMI if possible.

     

    That`s all I can say without looking at the code directly.

    • Like 1

  14. Posted · Edited by newcoleco

    Speech about DAN1 data compression was done at the ADAMCon 28, July 16, 2PM in Guelph, Ontario, Canada.

     

    I tried as much as possible to be clear without going into details.

    I've explained why I consider this format to be great for ColecoVision projects.

     

    Link to a copy of the presentation and related files soon.

  15. Posted · Edited by newcoleco

    There are lots of Coleco pictures around into PowerPaint format, some made with original software, some converted from JPEG or BMP files by using a picture converter such as BMP2PP by Marcel deKogel or Dither. These pictures .pp files are size 10K or 40K each and aren't in a format convenient for ColecoVision projects but are used by ADAMites for their Holidays special slideshow disks.

     

    You can convert PowerPaint files into Dale Wick's .pc files and use them in Atarimax Coleco Ultimate SD Multicart or view them with a simple viewer on your PC.

     

    How to add PP files into ColecoVision projects?

     

    Extract PATTERN and COLOR tables from PowerPaint files with this command-line tool.

     

    This tool has a lot of options (flags) to deal with each situation, even an integrated splitter to extract PATTERN and COLOR tables to be loaded into VRAM.

     

    Download (EXE) Version 1.1 : pp2pc.zip

     

    Source code available on demand. (on Dale Wick's SVN server)

  16. Posted

    Dale Wick's .pc format is simply the PATTERN and COLOR tables one after the other, 6K each, into a 12K binary data. A manipulation I like to do is to split into two files to be able to compress each table individually to add pictures into my Coleco projects.

     

    There are lots of ways to extract PATTERN and COLOR tables from .pc files and here is my simple solution.

     

    Just drag and drop .pc files on this tool to get two 6K files identified with extensions .pattern and .color in an instant.

     

    Download compiled EXE : pcspliter.zip

    Download source : pcspliter_src.zip

     

  17. Posted

    Sorry Daniel, I don't understand one thing. How do we use it with bmp file for example ?

    Is it currently only for raw files ?

     

    Short answer : It takes raw files. Not limited to pictures. This is not a BMP to CV converter.

     

    Long answer :

    No, it's not an image converter, It's a tool to compress raw data into this format I named DAN1. Data in VRAM can be many things such as fullscreen pictures, charsets, game levels, etc. For BMP files, try an image converter such as like BMP2PP or DITHER to transform BMP into a picture file. Extract the PATTERN and COLOR data tables into binary files and apply DAN1 compression. Add the compressed data into your project and use the appropriate code to setup the video chip right and see the result on screen.

  18. Posted

    I tried to use it in the upcomming CollectorVision: Star Command game, I used it to compress 16kb vram down to around 1600 bytes. I took very long time to compress, Using an I5 CPU. And the CPU did not use more then 33% all the time.

     

    I dont know if the decompressor is quicker then the one I usely use, but it works good and most importend no use of RAM.

     

    So I think from now one I will use the DAN1 if its allowed for Commercial use icon_smile.gif

     

    By the way the compressor said its PP2PC and a tool to extract bitmapped data icon_smile.gif

     

    Dont know if its the newest version it said beta-20160710

     

     

    Thanks for reminding me to clean up my code for the final release.

    PP2PC is another tool I made to convert PowerPaint pictures into Dale Wick's ".pc" files.

    I simply copy-pasted part of its code to implement options (or flags) such as "-v" to verbose all steps, "-h" to show help and "-r" to allow RLE encoding as "there is a string of uncompressed data here better not to try to compress it wastes memory space". I will explain all about DAN1 options (flags) in my speech.

     

    The compression tool tries to explore all possibilities and pick up the best solution for this format and that's why it's slow. I guess a quick no so optimized result for development purpose should be an option for this tool, giving more an idea of the space needed and decoding speed while programming and testing projects.

     

    If the actual dan1 decompression routine is a bit slow for your taste, I'm sure someone will come up with a faster version the more this tool used.

    Side note : Try "dan1 -r filename" to allow RLE markers if you consider your data to be difficult to compress such as highly dithered pictures.

  20. Posted · Edited by newcoleco

    What's your license terms? I could include it in my libti99coleco but my library is PD.

    You probably know I like sharing my tools and games for decades, making them available freely, so what's the good licence terms for what I do believe is right?

     

    Is freeware good? or perhaps gpl? or is lgpl applicable? i don't know. But what I do know is I make it available and hope it helps retro gaming enthusiasts like you and me.

  21. Posted

    DAN1 Compression tool version Beta 20160710 seems stable and perform at a good speed.

    Decompression routine is a bit slow in its small version and that's expected ( size vs speed dilema ).

    Overall results surpass or equal the majority of available data compression for 8bit systems.

    Mission Accomplished.

     

    I do a speech during ADAMCon July 15-17, 2016, Guelph, Ontario, Canada.

    Any questions? remark? comment?

    • Like 4

  22. Posted · Edited by newcoleco

    Can't get it to work. Just won't open. I updated my java to the latest version. Is it 32 bit maybe as I am 64bit

    Try compiling the JAVA source code included.

     

    Please note : This is a very simple program, no GUI with a file browser. You can drag and drop the .pc file on the executable or make your PC associate the .pc file extension to this program to open the pictures automatically when you double-click them.

     

    Enjoy!

  23. Posted · Edited by newcoleco

    Dale Wick's bitmap pictures also known as .pc files are the PATTERN (6KB) and COLOR (6KB) data to be loaded in VRAM on any machine using TMS9918/28 video chip to display a fullscreen bitmap picture. Because of its simplicity, this format was adopted in the AtariMax Ultimate SD ColecoVision Multicart product and used to show a screenshot preview of games or to simply display nice various fullscreen pictures such as pixelart.

     

    And here is a very simple program I wrote in Java to open .pc files on your PC computer.

     

    post-3651-0-78669200-1467655229_thumb.png

    Download (Java, Jar, Exe) : ColecoPictureViewer.zip

     

    Some pictures in PC format : SomePCPictures.zip

    • Like 4

  25. Posted

    @newcoleco thanks! it’s working now!

    https://www.dropbox.com/s/8juj36b271725j6/colecovision_dzx7_borielzxbasiccompiler_working_20160602.zip

    (now it’s a slideshow with 5 pictures for testing)

     

    i just needed to replace

    pop bc
pop de
pop hl
push hl
push de
push bc

    with

    pop bc                        ;- RET address
pop de                        ;- DE=dst
push bc                       ;- restore RET address

    it’s really amazing! thanks again icon_smile.gif

    (and thanks @einar as well, of course! it’s a really great compression method! 60kb of pictures into less than 29kb)

     

    I have checked your listing again and I have noticed that you forgot to disable NMI during decompression. This leads to glitches, artefacts in the picture, and do answer your post on another forum about glitches you see.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...