newcoleco

My presentation during ADAMCon summer 2015 was about my work on data compression and my upcoming tool for it. For the moment, the research and development process is still going. When the first beta version of this new is done, I'll let it know here.

Thanks for improving a product already quite impressive. As I experiment with the compiler, I've not notice a huge size optimization in my projects but sure realise that my devkit needs to evolve to exploit its new features and improvements. Sad to say that "--oldralloc" is now buggy, so I'm no more using it. CC3 is using oldralloc as a quick way to compile source code by default. While trying each of my demo projects in the devkit, I've found this bug : My demo source code "Chateau du Dragon" returns an error only if using the oldralloc : "MAIN.C:390: error 9: FATAL Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/z80/ralloc.c' line number '1354' : isSymbolEqual (sym, OP_SYMBOL (IC_RESULT (ic)))". The line 390 is simply "pause();" just before the end of the "void bataille(void)" routine. So to avoid this error, I simply use instead the --max-alloc-per-node parameter instead with a small value (slider closer to Normal than Slow). Keep us infomed about your incredible work. Thanks a lot PkK!

Well, my current tests shown : if cleverly segmented, yes exomizer do beat my proposed data compression in all the samples I've tried. With that said, I'm happy with the results. And a tool using this compression is coming next month.

Sorry for delay again.

Update Error in the previous results. Oops! Corrected results suggest a compression ratio between MegaLZ and Exomizer, or similar to Exomizer ; it depends on the data to compress and the way you approach the case ( "naive or "clever" ). What I mean by "clever" is mostly because it needs human intervention (or maybe highly advanced algo with a lot of computations) to cut the dataset into subsets where the sum of the bytes for each compressed subset is smaller than the the whole dataset compressed as one set. With mode 2 pictures, groups are quite easy to detect and this particular case can be automated (duh!) : PATTERN and COLOR tables. Working on the final format so results may change again in my next post. No evaluation tool for the moment. Another thing. Most of the mode 2 pictures we do use in our projects are relatively simple graphics, with unused data. Many times we get values 00 and FF for the pattern which make one of the nibbles for the color code totaly meaningless (unused). There is also some cases where consecutive color codes may be just alternate version of the same 2 colors if the pattern codes where coded differently. This situation cause the graphic tool to generate arbritary color codes that are not used anywhere else in the picture that creates more variations of bytes possible for color than needed, making the picture harder to compress for no good reason. [youki] smurf challenge (naive) 1155 or (clever) 1136 bytes [rion] unreal (naive) 6329 or (clever) 6204 bytes Lena (naive) 8803 or (clever) 8601 bytes

Dan0 is a Run Length Encoding with a bit of my magic composed of a somewhat adaptive Huffman and the possibility of re-using part of another data table to reduce even more the number of bytes to be encoded. It's a bit complicated to explain and my tool based on this format isn't for everyone (no interface, you modify my tool coded in java and use jdk to compile and run it each time) but it works. Essentialy, all raw part of a RLE is a potential for saving more bytes by saying : "hey! I've seen this byte not long ago, let's just encode a reference to it in a few bits instead of encoding it raw". Since it's RLE based first, the decoding process is relatively fast, faster than all the lz77 based ones, which can be a big deal for some projects, Even if Dan0 isn't the best compression, it has a potential benifit for some projects, it depends of the needs. The compression I propose today is based on LZ77 with the option of a fixed Huffman that helps in some cases to get a great compression. Mixing LZ77 with Huffman isn't a new idea, it is used in many formats like Deflate in WinZip. Since my work is based on my ColecoVision projects, this custom compression do give great compression for me, I just assume it should works great for your projects too.

For me, graphics in ColecoVision projects is what takes the most space and what can be compressed the most. So, I've been working on data compression from time to time but most seriously during the last month, trying to figure out the secrets of a good compressor and data format based on what others made to save memory space without the need of a too big decompressor and no extra (cpu) memory. My research resulted into 2 realisations : Run Length Encoding is fast but isn't good enough even if you encode it in a clever way, Huffman is good but you need a variation of LZ77 to really perform great compression and it's the base for the popular compressors in the homebrew scene and modern computers compressors including WinRAR, WinZip, GZip and 7Zip. I tried to do my own compression based on LZ77 with the option of an extra bits saving with a fixed Huffman. At first coding the compressor gave me headaches because a greedy LZ77 compression algorithm doesn't give the best compressed size. I went back to the source, reading papers about LZ77, and finaly I understood what I was doing wrong and code an algorithm for getting the best compression every time even if it means taking a long time to process. When the first results came out, I was shocked to discover that this simple change from greedy to a better strategy algorithm made my own compression format going from "as good as Pletter and ZX7" to "a bit better than Exomizer". So before yelling "Victory!", I've done more tests and I started to write a paper based on my research, showing not only what I've learned but also compression tests on real graphics. The following tables are in my paper, the size of the decompressors mentionned are from the ones I've encounter and do decompress directly into VRAM to respect the rule of no extra memory needed. 1st : decompression routine size 2nd : compressed data size of the Smurf Challenge title screen by Youki 3rd : compressed data size of the pixelart Unreal by Rion 4th : compressed data size of Lena (used in many computer science papers, original photo in Playboy) Run Length Encoding 43 1994 14814 14562 PuCrunch 297 1438 6780 9358 Bitbuster 173 1262 6588 9188 APLib (commercial) 289 1227 6556 9138 Pletter 241 1235 6476 9081 ZX7 128 1234 6474 9079 MegaLZ (commercial) 110 1243 6486 8960 Exomizer 250 1130 6236 8694 My own compression 200 1144 6136 8515 These 3 pictures in PC format (PATTERN 6144 bytes + COLOR 6144 bytes) : 3 sample pics in PC format.zip Victory? Not yet, I still have to code a lot including a tool using my own format. Please leave a comment

Nice to see progress on this project. Neat idea to make the player disappear after awhile of bouncing.

Quick update I'm not taking any new order obviously to complete the orders still in process. If Toby wants to take new orders it's his choice and it's fine by me... so fine in fact that I've decided today to give all the files, source code included, to him so he can make his own version if he wants to... and figure out how to. During this project, I learned more about data compression and I composed nice music again. To me, Strip Poker project is done, expect no sequel or news about it from me.

I saw this issue after my presentation, it has to do with my logic behind it to trigger playing the sound or not. I'll fix that later.

Since the output file can be easily manipulated for your own needs, anybody can make a tool to convert the data into something usable by their projects, not necessary Coleco projects. Anyway, I've added a button "EXPORT" to generate a data file in Coleco BIOS sound format to be used with SDCC. It fits with my toolkit, just need to add the sound labels into the sound table and I'm ready to use these sounds. More sound formats can be added in this tool or simply consider to make your own tool to convert the sound data. I'll try to focus on adding functionalities like an "UNDO" button. Have fun!

This was presented during the 26th edition of the ADAMCon in Cleveland, at 11 o'clock Friday July 25, 2014. Link Blog (download) : http://newcoleco.dev-fr.org/p4219/2014-07-19-draw-your-coleco-sound-effects.html DOWNLOAD CVSoundFX.zip Give it a try and if I see a clear interest to use this tool , new functionalities wilit will be part of the toolkit with some improvements. Story My previous presentations about the sound chip inside the ColecoVision console got some attention. Unfortunately, nobody seems to have done anything with this information. I was thinking : "Maybe this is too technical, I need an even more family friendly approach." For this year ADAMCon, I was invited to talk about sound effects and instead of showing again a bunch of numbers they might forget, I've decided to create this tool for everyone who want to have fun making their own Coleco sound effects. Technical Information Coded in Java 1.6, this tool allows to draw frequencies and volumes as you want and save your creation. It's simple and a lot of fun just giving it a try and say "I can do Coleco sound effects! Listen!" Please note that the resulting file ( .sfx ) is a text file with the following structure : MODE [0 = tone, 1 = periodic noise, 2 = white noise] SIZE [120 by default, number of entries ( period + attenuation ) in this file, 120 @ 60Hz = 2 seconds] START [0 by default, it's the index value where the selection starts] END [119 by default, it's the index value where the selection ends] sound data ( each period and attenuation values )

- Update - A few copies of Strip Poker were shipped, but the vast majority haven't shipped yet. Solution : Toby will deal with shipping and production of Strip Poker. As soon as possible, I put everything in a box and ship it to Toby. He will receive by email the list of orders and the ROM file. I was trying to find a solution for many months. Why? I was pretty down, since we are adjusting our lives at home after our mother died -and- I've promised signed copies, and I'm pretty sure I don't have enough shells to sign but hoped to get more and sign but... anyway, it's not important anymore, I'm sure we will figure out a way to make me sign the missing shells. Now we have plan. The over due shipping cartridges issue should be resolved quickly. My apologize to Coleco fans waiting for that game, it was a very long delay. Have a nice time playing Strip Poker on ColecoVision in the near future!

My passion for the ColecoVision started during the holidays. My brother got the console as a gift, and I had a Commodore VIC-20. My brother loved playing arcade games and he enjoyed playing Donkey Kong for weeks at home, but started to want more games. So, my brother brang cartridges from friends, bought Q*Bert lose that way. He also used my computer with tapes copied from friends and this way played even more games. Meanwhile, I was more interested into learning how to use the computer, code my own things, with the help of listings from the user manual and various books, but not magazines. By looking at games on the various tapes my brother had I've learned how was coded some games and made my owns. A few years later, my brother got a Commodore 64 and hundred of floppy disks and a dozen of magazines. We both tried to type the listings in these magazines, mostly games, but also some utilities which increased my capacity to make new games and improved my programming skills even more. It took me a long time to code my own games using sprites (VIC-20 has no sprites, but C64 do have sprites) but this last piece of graphic capability helped me to figure out how to code the various cool games I was playing during years on the ColecoVision. During university, my brother gave me the ColecoVision console and games, and since then haven't played ColecoVision again... but I do play, it's plugged and ready whenever I want. Happy holidays!

Short version : Not possible because of nudity(?) Long version : http://www.scubbly.com web site makes it very clear that my account might get closed if any offensive material including pornography ends up being in my virtual shop and lose every single cent/penny/yen that might be in there. The reason is no age check mechanism is in the web site, therefor the content might be appropriate for all age. You might argu that kids might not know what is ColecoVision and how to play a ROM file, but that doesn't matter.

Not all shipped, no, it's in progress.

I don't have better tools for my DAN0 format, but my interest switched to ZX7 format and I'm planning to create at least one tool programmed in Java with a simple GUI.

Go ahead, it's a good idea. I was expectig Dale to do it at first but like everyone noticed Dale is really too busy to deal with anymore projects.

Got package today, cartridge production started slowly but surely now. Thanks again Harvey!

Note : It all depends on how I feel about these games, "memorable?", "impressive?", "great graphics,animations?", "good music and sounds?", "great gameplay?", "fun factor?", "guilty pleasure?", "nostalgia?", ... A game can be really fun and not be impressive at all, so it's all about opinion so I took time to write this TOP 3 with comments to explain my choice. 1. GhostBlaster (Impressive fluid scroller plateform game, Colorful, Very good music and sounds, and it's one of my greatest achievements as a CV homebrew game, and it's also a collaborative project with levels made by Dale and others) 2. Burger Time (Arcade game, Nostalgia factor, Graphicaly well done, top favorite commercial CV games among gamers) 3. Donkey Kong (Nostalgia factor, not because it's a port of an arcade game but because it came with the console that made me enjoy and want to create my own CV games)

http://www.youtube.com/watch?v=PsO5QsHku6o I've no idea how to make a media link anymore... oh well, I've watched the video and it's really nice to answer the questions you received about this game in this short and sweet video.

Welcome to the club of homebrewers! Various things do occur with our games after it's published! There might be many fake copies of my games out there, I just don't know it, but what I do know is that when we publish a ColecoVision homebrew game we just lose control over it, more so if it's a port because of copyrights law. Back in 2001, a guy made his custom DACMAN cartridge by replacing the chips into a 24KB cart with my ROM file, and then he asked me if it was ok to do so. In that case, I appreciated to know it, and honnestly for personal usage it's ok, I really like the idea that my games are being played and enjoyed. In the other hand, I saw my games being sold at outrageous prices on eBay while copies were still on production and some people screamed at me that it's too expensive... like I've control on the price of my games being sold on eBay by resellers. More my name was associated with new ColecoVision games, more I felt that some malicious guys were watching forums just to jump on occasions to make money and pretend that my games were "EXTREMELY RARE PROTOTYPE". This phenoma of eBay auctions by resellers (of fake or real copies) is poisoning the homebrew ColecoVision scene because it profits only a few (if not just one) by exploiting ColecoVision homebrewers and fans. My answer for awhile was to raise up the price of my games, going from $20 for a complete in box (DacMan in 2000) to a $30-$40 for a lose cartridge (GhostBlaster in 2009)... in the vague hope that it will discourage resellers but really they know how to exploit the homebrew scene and make profit. Not publishing ROM files became the approach used by many CV homebrewers to counter this phenomena, but ROM dumping isn't that difficult to accomplish and at the end... it's just a question of time.

There it is : cvvhjump.zip

http://www.youtube.com/watch?v=_GZPGkORvP0 Let me know what you think. Cheers!

This one is one of the numerous DacMan version 1.3 published by John Dondzila and at the look of it... it is legit if you ask me. No problem there.