newcoleco

Thank for all your kind replies! I've read again my long letter and it's not in perfect english. Regardless, I gave news about me and it felt really good, overdue perhaps but it's done now. Your messages about paid work intrigue me, please send me more details by email if possible. Happy Easter everyone!

Hello everyone, Daniel Bienvenu aka NewColeco here. Some may not even know who I am, it's ok, I expected it since I kinda left the active scene for a few years. I'm sorry for not giving much news for the past years. After my mother died of cancer in 2013, my life felt apart. I'm struggling with a debt and no job, but my immediate family is supporting me (for now) and I should be back on my foot soon unless something terrible happens. I'm not aware of every new ColecoVision game, new technology, and big events, but as I see the homebrew community is well diverse and active. My personal opinion about the ColecoVision homebrew scene hasn't changed. I am all for exploiting the game system as being more than an arcade machine at home, make the "your vision is our vision" slogan means also exclusive titles, originality, exploring new genres, new games. I don't know if we are done already with the variety but I really want to see more games like tower defense, worker placement, storytelling, choose your own adventure, simulation, physics games like a pinball simulation or bridge builder game, hack and slash, roleplaying, social games, cards and board games, Yahtzee, UNO, Battleship, "Would you rather?"... but I'm just a dreamer. I've missed my own celebration time of 15 years anniversary in 2015 of my first ColecoVision game published in cartridges: it was DACMAN v1.0 during the CGE2K in Las Vegas at John Dondzila table and I believe only 6 to 8 copies were sold of this buggy version that a week later I've fixed as DACMAN v1.3. Also, 1997 was the year people started to notice my presence on the internet, with my website hosted by the university that I dedicated to emulation and games, with one of my tools being ICVGM, my graphics editor, a DOS version coded in QuickBASIC with mouse support and could edit characters, tiles, screen, and also sprites if you opened it with John Dondzila's Purple Dinosaur Massacre ColecoVision ROM file. So I've been into ColecoVision homebrew scene for 20 years already, and this year 2017 is also the 35th anniversary of the game system itself and I'm very enthusiast about it. During the past 17 years or so, I've started numerous projects that I've not even finished, and every year I say to myself that it is time to go back to this and this project. I've done that with one successful title Jeepers Creepers that I started in 2001 and finally completed years later after multiple attempts, adding and improving the project slightly through time. Sadly, due to multiple computer failures, I've lost a lot of data including source files of my projects, backup of my websites, my documents, making me almost restart from scratch if it wasn't for some copies here and there of some files including the SVN server hosted by Dale Wick. Lately, someone asked me for Easter Bunny game, the Canadian's Minigame version, and I couldn't find the source files at all... I sent the devkit version and the person seems not happy, I'm sorry. During years 2015-2016, I've coded another data compression format to be used in our future homebrew games and you may have experienced it already without knowing it. My previous attempt was named DAN0 and used in some homebrew projects such as Smurf Challenge, and I think also in Gamester81's CV game (don't quote me on this), and last year I released DAN1 to compress a bit more data, allowing to get even more fancy graphics into our projects. I know that memory space seems not to be an issue anymore with bank switching method used in modern CV game cartridges, but I love the challenge of optimization and data compression is sure not a simple one with space versus speed dilemma. I'm working on a DAN3 version using a slightly different algorithm that seems to compress (in average) more than DAN1, but it depends highly on the source data itself. I am happy to see the ColecoVision homebrew community growing, I see new faces, new programmers, and new ColecoVision fans. I hope to release something in cartridge this year, but I make no promise. I proposed a social experiment using Twitter and I think I just don't get what Twitter is for to get such poor results, but I've made contact with some in there that makes me think it's not a fail. And I am sorry that you guys cannot download much from my website (they have been deleted binary files for unknown reason), and cannot purchase Flora and the Ghost Mirror file anymore on Scubbly (they are shutting down the website). You can ask me or a friend for these files I've made during years, I don't mind that you copy but I would appreciate you do only for personal use, in a homebrew fan spirit way, don't make fake cartridges and sell on eBay to exploit ColecoVision fans - it's so wrong. Practically all my CV games are copied all around the world, downloadable on various sites, and I'm sure you will find someone to help you get the missing files that you are looking for. Thanks for the donation on my Paypal account, Steve G., I've no idea what is that for and who you are but I appreciate it. For the ones curious about it, I've received a donation last month, less than $20, no message, nothing, I am wondering if I've missed or forgot something. This 2017 Easter time, I'm getting rid of loads of PC vintage stuff. I'm not using eBay, my digital camera is broken anyway, so taking picture and typing descriptions for everything is out of the question. I know there is a strong vintage computer enthusiasts group in Quebec city where I live and I would like to make a deal with some of them to come get this stuff (or just part of it) for very cheap in a win-win way. For example, I have a bunch of PC games on floppies and CD-ROM discs still complete in box, one even claim to be the very first SVGA PC game that looks like a chess game and is playable on a 286 PC with EGA/VGA video card using their own SVGA driver that somewhat worked to display the higher resolution that we now take for granted on modern PC. I'm looking for a job, even a tiny contract, I try to pay my bills, life as usual for me. Follow me on Twitter and be part of the social experiment #colecome @DanielBienvenu Thanks everyone and have a nice day! Daniel Bienvenu

More votes coming in, the poll tend to indicate a need for Quality Assurance, a team of testers available to try our projects at diverse stages, especially before publishing to avoid embarrassing bugs. Since Atarimax Multicart allows to try a ROM file on real hardware, distributing binary files to QA volunteers, agreeing to terms and conditions, should be a good way to keep our hobby going and gain professional quality level. I've worked for a video game company for about 7 months and they used different tools to record and keep track of bugs found by testers with all kind of details including common tags for the kind of bug and where it was, a short description on the manipulations to reproduce the bug, screenshots and short video clips, the hardware used to test, build version tested with the bug in it, build version with the bug fixed, and so on. It is not easy to test a video game in a QA team; have to check if the bug is already reported, try to reproduce the bug and figure out by elimination what really is going on, the timing and the manipulation to make it happen. A second tester can add to a bug description already listed, helping to pinpoint the issue, helping the developers to understand the bug better and fix it. Is there a retro-gaming QA team who can (or will) test our ColecoVision homebrew projects? Or is this too much professional thinking and better just keep things as it is now between trusted friends? My opinion is to open up the possibility, say to ColecoVision fans "Do you have a multicart? Wanna test our games?" and see the reaction, and perhaps set up a bank of potential testers and get things started this year.

As for me, it really depends on the project, but most of the time I do have an alpha version done quickly with most if not all the graphics that I need, then it's lots of back and forth by adding elements and see if it integrates nicely or not. If there is a lack of space, I try to optimize the size of the code (coding in ASM instead of C helps) and the data (reusing data, converting with a different compression method) or simply get rid of what is not necessary. For example, Jeepers Creepers started very quickly with the idea, most of the graphics and a first version of the controls and logic. After years on the back burner, the project was finally completed in a one-week full-time schedule: improved title screen, improved controls, tweaked difficulty levels, tweaked game logics, added a new screen level, optimized overall size and speed. There is a magic potion in the graphics data (check the ROM file) but I decided during the last day that this game element was unnecessary instead of sacrificing bits of code and data here and there to a game already enjoyable and good. Another example, Reversi was done very quickly with the graphics and most of the sounds in place. The longest part was optimizing the AI speed; the min-max (or alpha-beta) algorithm was taking so long that the first versions of the game took 2 to 3 hours to play a single game at the highest difficulty level. I had to recode part of the AI, optimize with ASM codes, I probably goofed a bunch of times, and finished with a reasonable speed under an hour per game which is still long but way better. Exhausted, I ended the project and published as-is. A second version of the game simply added a bonus game to the ROM named Diamond Dash. There are games that I planned to do and all I have is notes on paper or a folder name to remind me that I wanted to try something about this game mechanic, or this game theme, or this game genre, ... For these games, I guess the longest part was the idea and calculating if it was feasible in the memory space and graphics capability of the ColecoVision game system.

Ok, I added Testing in the list, kinda assumed it in the Alpha and Beta phases.

What do we struggle with the most when creating a new ColecoVision homebrew project? Of course, the answers depend on the person experience, the game idea, the tools and materials available, and so on. I would like this poll to show a full view of a game project from start to finish. Since a conversion doesn't worry about the game idea and most of its code and data, try to think about a ColecoVision project made from scratch and what is most troublesome in a full project. Let's exchange on this topic, give tips and tricks, perhaps find ways to reduce the bottleneck time parts. Maybe this can show where we should focus our effort on, even find or make some missing tools in our toolbox. Vote and reply why you voted that way! Let's begin our talk!

SC22PC - Convert MSX Screen 2 bitmap pictures into ColecoVision bitmap pictures by Daniel Bienvenu aka NewColeco January 2017 Description This tool extracts the PATTERN and COLOR tables (6K each) from a MSX .sc2 file and save it into a neat 12K .pc file. Technical Infomation MSX .sc2 file is essentially a memory dump of the seven (7) video registers followed by 14K graphics data in video ram, aka VRAM. Technically, that includes also sprites which can be used to patch the picture to avoid color clash effect. ColecoVision .pc file is simply the bitmap screen, composed of 3 charsets, made of two (2) tables: PATTERN and COLOR. No sprites data. Note: It is possible to use .sc2 file into ColecoVision projects, but be sure to consider three (3) things: the video register flag "4K/16K" has no impact on MSX computers but does on ColecoVision game system, the VRAM data is the important part, a good lossless data compression should be applied on VRAM data to save memory space. MSX Screen 2 Sample Download SC22PC - Version 0.1 (EXE, SRC, BATCH FILE) : sc22pc-alpha20170115.zip Links MSX Screen 2 .sc2 files MIF - Convert pictures to MSX Image Format (Win32 command-line and GUI) Multipaint - Convert and Draw pictures for various systems including MSX SC2 Pixel Polizei - Draw pictures for various systems including ColecoVision and MSX

PC2BMP - Convert ColecoVision bitmap pictures into Microsoft 16 colors bitmap files by Daniel Bienvenu aka NewColeco January 2017 Technical information Simply put, it generates a valid BMP file, 256x192 pixels, 16 custom colors, 4 bits per pixels, according to BMP file format specifications. The color palette used here is a compromise between colors a bit washed out calculated with the TMS9928 video chip technical information and colors too saturated used on several emulators. Also, this color palette makes a distinction between transparent and black colors with its black color being slightly brighter (RGB values 8, 8, 8 for black, and 0, 0, 0 for transparent). Usage pc2bmp [-y] source.pc -o destination.bmp Samples Yuki's ColecoVision Smurf Challenge - extracted from original project as a .pc file and converted to .bmp youki smurf challenge.bmp Rion's ZX Spectrum Unreal - converted from ZX .scr file to .pc with scr2pc and then to .bmp rion Unreal.bmp Download PC2BMP Version 0.1 (EXE, SRC, BATCH FILE): pc2bmp.zip

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. 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

Let me know how it goes for you, I will wait to see how things go with popular opinion. Hopefully I get more comments before it's too late.

This news is affecting homebrewers including Nanochess and myself. You may or may not know it but, November 2013, I used Scubbly website to release Flora and the Ghost Mirror game as a digital copy downloadable (to play on an emulator or a special game cartridge like the Atarimax's Coleco Multicart) while cartridges of the game were not yet ready. Newcoleco's store on Scubbly: http://www.scubbly.com/store/newcoleco/ Nanochess' store on Scubbly: http://www.scubbly.com/store/nanochess-digital-store/ According to Scubbly's blog post on January 1st, 2017, their service will shut down around summer time. Scubbly's blog post: http://www.scubbly.com/blog/2017/01/01/important-message-for-all-account-holders/ What should we do next? Find another website offering the same easy service with protection for both buyers and sellers and low fees? - OR - Abandon the idea of providing digital copies of our new games in an online store? Any idea? What do you think? Please share and comment.

To reply to my own blog post, I've asked myself the follow question: "Will I recognize these movies by looking only at a single iconic frame?" In my mind, I imagined an iconic image from each movie: the shadow of Nosferatu walking up stairs, the female robot in Metropolis, the monster in Frankenstein, King Kong at the top of the skyscraper, Chaplin being pushed around giant gears, etc. And so, here's my list once limited to the ones I will surely recognize: 1922 Nosferatu 1927 Metropolis 1931 Frankenstein 1933 King Kong 1936 Modern Times 1940 Pinocchio 1941 Dumbo 1941 Citizen Kane 1942 Bambi 1959 Ben-Hur 1960 Psycho 1964 Goldfinger 1964 Mary Poppins 1964 Fantomas 1968 The love bug 1971 The Big Boss 1971 Dirty Harry 1972 The God Father 1973 The Exorcist 1975 Jaws 1975 Rollerball 1976 Rocky 1976 King Kong 1977 Crime Busters 1977 Star Wars 1978 Halloween 1978 Grease 1979 Alien 1980 Airplane! 1980 The Shining 1982 The Thing 1982 Blade Runner 1982 Tron 1982 Annie 1983 Octopussy 1983 Flashdance 1983 WarGames 1983 James Bond 007 1984 Amadeus 1984 Ghostbusters 1984 Gremlins 1984 Dune 1984 The Terminator 1984 Police Academy Total: 44 titles And movies titles I may add: 1963 The Birds 1976 Network 1978 Superman 1979 Rocky II 1982 E.T. 1982 First Blood 1982 Rocky III Total: 7 titles

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: The set of 4 different sizes to encode offset values becomes { 1, 4, 8, max } where max value is set by the user. The capability to store sequences of literal bytes is removed. 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 *

Hello everyone, I am new to posting a blog here so I decided to give it a try, please leave a comment. I have done an experiment with friends during the whole month of December 2016. We gradually made a list of memorable movies released before 1985. Memorable movies are famous for good and bad reasons such as iconic scenes, innovations. The list grew up to over 130 movies and surprisingly none of us, as individuals, saw at least half of these movies. Do I really know my cinema classics? Is it possible to see all these movies? I have made a second list (see below) limited to titles with less than 15 characters (including spaces and symbols if any). With this restriction, the list sure is incomplete and still some titles seem not really memorable in my humble opinion. What do you think? Which ones surely are famous memorable movies? Which ones are missing respecting the restrictions (less than 15 characters and before 1985)? Please leave a comment. ^_^ LIST of MEMORABLE MOVIES released BEFORE 1985 with LESS THAN 15 CHARACTERS (SPACES AND SYMBOLS INCLUDED) 1921 The Kid 1922 Nosferatu 1927 Metropolis 1931 City Lights 1931 Frankenstein 1933 King Kong 1936 Modern Times 1940 Pinocchio 1941 Dumbo 1941 Citizen Kane 1942 Casablanca 1942 Bambi 1953 The Wild One 1959 Ben-Hur 1960 Psycho 1961 Yojimbo 1962 Lolita 1964 Goldfinger 1964 Mary Poppins 1964 Fantomas 1967 Cool Hand Luke 1968 The love bug 1970 M*A*S*H 1971 The Big Boss 1971 Daisy Town 1971 Dirty Harry 1972 The God Father 1973 Magnum Force 1973 The Exorcist 1974 Female Trouble 1975 Jaws 1975 Rollerball 1976 The Enforcer 1976 Rocky 1976 Taxi Driver 1976 King Kong 1977 Crime Busters 1977 Star Wars 1978 Halloween 1978 Grease 1979 Alien 1979 Mad Max 1979 Apocalypse Now 1980 Super Fuzz 1980 Fame 1980 Airplane! 1980 The Shining 1980 Xanadu 1980 Brubaker 1981 Excalibur 1981 Mad Max 2 1982 The Thing 1982 Blade Runner 1982 Tron 1982 Annie 1983 Octopussy 1983 Videodrome 1983 Scarface 1983 Flashdance 1983 WarGames 1983 James Bond 007 1984 Don Camillo 1984 Amadeus 1984 Ghostbusters 1984 Footloose 1984 Starman 1984 Gremlins 1984 Dune 1984 The Terminator 1984 Police Academy Total: 70 titles

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 : 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%) Total = 2129 bytes Dan1_10 (adapted) : const byte TILtitle3DAN1_10[] = { // tile size dan1 compressed 947 bytes (53%) const byte COLtitle3DAN1_10[] = { // color size dan1 compressed 784 bytes (61%) 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 : const byte TILtitle3Plet[] = { // tile size pletter compressed 1259 bytes (79%) const byte COLtitle3Plet[] = { // color size pletter compressed 794 bytes (87%) Total = 2053 bytes Dan1_12 (original) : const byte TILtitle3DAN1_12[] = { // tile size dan1 compressed 1248 bytes (79%) const byte COLtitle3DAN1_12[] = { // color size dan1 compressed 799 bytes (87%) Total = 2047 bytes Dan1_11 (adapted) : const byte TILtitle3DAN1_11[] = { // tile size dan1 compressed 1233 bytes (79%) 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.

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.

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

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.

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.

I used the exact method in wav2cv to create a voice saying "no no no" in Coleco Reversi; you can hear it when you try to play an invalid move.

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.

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.

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.

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.

This web site has a lot of tools for Coleco development : http://www.colecovision.dk/tools.htm