F-Cycles

In fact, by reading these information before doing the transition of the first 16 sprites to the last one (while keeping the 16 sprites in middle intact), the information of the 48 sprites could be kept. For the multicolor extended mode, as you can see I did not bother to create a software to convert existing image, so I just write a routine to have different color patterns which I could check visually to ensure that I display what I expect. This multicolor mode is using only768 bytes for names and 4 x 1536 bytes for colors. So a total of 6912 bytes. But because of the alignment of memory, 4x2Kb + 1Kb = 9 Kb. I was thinking to explore a way to store 2 images and make them flicker in that mode which take less memory than vmode 2. Also, sprites could be use in overlay to improve some part of the image. Well, as you can see more work could be done but probably something interesting could appear all of that work. As for more than 4 sprites per line... I think this cannot be done because the information of the 4 sprites to display are copied from the VRAM to internal register and then use during the drawing of a line. I try to work with the X position of 1 sprite, hoping to see a copy of it further on the same line... tried on the real hardware and each pictures I took with my camera show only 16 lines on screen (while if I would have 17 or more, that would have reveal that the hardware did update it's x position during a scanline).

I was waiting for a ColecoVision hardware for few weeks, but strangely I got 2 hardware last week. First, a ColecoVision (last Saturday) was let to me in order to experiment and test my stuff. Then, at work.. I was asked to do something on a new piece of hardware which will be considered the 8th generation of video game console. It's a strange feeling to have to discover things on nearly the two extremes of gaming console within a week. ^_^ In the picture below, you will see 3 of the 4 software I wrote which run on the real hardware (NTSC) and BlueMSX emulator. The 4th one is a simulated extended color for later study. So far, there seem to be a wrong timing in BlueMSX. I believe the emulator is coded with 60 FPS instead of 60/1.001 = 59.94... FPS. Which cause different synchronization behavior between the software simulation and hardware. But I have not made test to confirm this just notice that the timing is different. I did wrote an email on their forum.. but no reply yet.

Well, who know maybe there will be a stage or a hidden Easter egg which will look like NES. But.. look like he got his eyes more on a Super Famicom... (SNES) when he was in Super Potato store. Maybe that's a hint for something?

Fan of MegaMan...? look at this project... http://www.kickstarter.com/projects/mightyno9/mighty-no-9

My first mock-up...and comparison between the original game on C64 and the Coleco Vision version to come... So far, got one comment from Kiwi that I should explore other video mode (than Mode I). Hopefully I could improve these current mock-up which are currently: Rev. A! more screen shots on: http://superdoriath.blogspot.ca/2013/08/doriath-on-colecovision-mockup-iv.html

Hehe.. thank you. Well, I think I still have a lot to experience regarding compression to be consider an expert. but I like playing with numbers...

there is few videos on NewColeco Youtube's channel like this one: http://www.youtube.com/watch?v=2dHoBzpOE6s I don't know any sprite editors... but on my side, for the graphics I will be using my favorite paint software and parse the image file+adapting the data for my game in a custom tool.

ok.. it's not related to the topic.. but just for those who could be curious to know what I bake? I use fresh blueberries bring yesterday from a blueberry farm and reduce it and use it in between... it's the dark part of the cake.

Oh, the dictionary I was refering is: let's take back your example... "AAAAAAAAAABCABCABC" I was creating a dictionary for Word 0: "ABC" and Word 1: "AAAAA" and then said.. [ABC,AAAAA] + 11000. which 1 = word 1 = AAAAA and 0 = word 0 = ABC. So the dictionary was holding a word. And that word could be bit-coded.. like.. A = 0 B = 10 and C = 11 [0 10 11, 00000] 11000... so a total of 15 bits for this string (which exclude here the word length, the character definition and the fact that the text (the part which refer to the dictionary) should be at least byte align! However, you can see that the complexity of the algorithm can increase as the text refer to a dictionary which need to be parse entirely until a word is found and then you need to refer to another bit table to get the 8-bit symbol. Just to get the real number out... it will look like that, where memory address are written byte_address.bit_address (example: 2.3 = address $2 bit 3): $00.0 : 'A' (8-bit), 'B' (8-bit), 'C' (8-bit) // 3 ascii code ordered by popularity. $03.0 : 011 (length of word 0 which is 3, max length: 7 chars) 0 10 11 // word 0 $04.0 : 101 (length of word 1 which is 5) 0 0 0 0 0 // word 1 $05.0 : 11000 $05.5 : END OF FILE, 45 bits = Size 6 bytes (rounded up) By comparison, the system of using reference of a previous character could be: 0 + 8-bit = new character to write 1 + bit-coded = refer to a previous character. where 10 = (previous character), 110 (-2) and 111 (-3) To code: AAAAAAAAAABCABCABC we will have: A : 0 + 'A' // 9 bits followed by 9 A: 9 x 2bits = 18 bits B : 0 + 'B' // 9 bits C : 0 + 'C' // 9 bits ABCABC : 6 x 3 = 18 bits In total: 63 bits = 8 bytes (rounded up) Of course.. the 2 bytes saved in the first system is by far lost by the algorithm and the complexity increase (slower). One of the biggest problem I have with my algorithm.. is how to build the words.. you saw that I pick the word 'AAAAA' and not 'AA' or 'AAA'... as I could easily see this will be the most optimal one. But when words can be part of other words (like if I have the word ALMACT and the word MAC, is it better to pick a big word, the common part, both...? So I try a recursive function to just try all the possibilities but after 5 minutes.. it did about 0.02% of the work. So, for my test... I end up using an heuristic base on the length of the word and occurrence. And I stopped after seeing how much bytes when byte-coded (not bit-coded). I could then estimate that from 550 bytes it may go down to 400 something... but not below 400. Well, to be honest I was hoping to get the data down to less than 256 bytes.. maybe it could have reach 430 bytes.. with optimal bit code and everything. But you can see why I stopped there... as the complexity is too high even if for the tiles data it may also reduce the size too, but without a significant gain (like -40%), I think it's not worth it. The ZX7 will be a more suitable solution. ok.. back to the kitchen, I have a cake to bake!

Thanks NewColeco... well, I give a try last night where I was storing the 17 color values (starting with the most common) then I was coding bits to specify the color and another bit coding to specify the length. The size looked promising but the decompression routine show that my compression or decompression was buggy. I then, though.. why not creating a 2 tables data vector of same length: one for the color code and one for the length of each entry. Then, build a dictionary to reduce the redundancy. Without proper bit coding (assuming some worst case), the numbers I came with was 550 bytes. Seem that the length of the vectors (how many bytes to be written before switching for another byte value) take 2/3 of the compressed size...

When I look to those files and numbers... I feel I want to see how much I could reduce these size. Just looking at the color data, I wonder how much small it can get... seem very repetitive and simple. Anyone has better numbers than 675 bytes? Just by curiosity...

In my project, I also need a good data compression ratio. So far, I have achieve a ratio nearly 38:1. The original map for Doriath being 163,840 bytes down to 4,335. We cannot expect the same ratio for all kind of data. For a bitmap, there is already some modification which need to be made to display it on the ColecoVision. I guess there might be a graphic-style which will allow a better compression ratio but with a different look for the graphic. Few years ago, I was interested in filled shape animation which was made on Amiga in 1992 on 1 floppy disk (State of the Art by SpaceBalls). I created a tool which was using Beziers curves... with a system of extrapolated keyframes, hoping to be able to draw an overlay over videos... http://www.youtube.com/watch?v=P4POrYrKo0M Although I have not look to what the 2 .bin look like... I would say that probably adapting the original data is a key to control a compromise between the pictures and the size. Also, with a game like strip poker, I think a file which could benefit from re-using blocks of graphics to hide/show parts could help. I know having beziers curves on Coleco Vision sound like be crazy! Especially with 1 Kb of RAM. But.. sadly.. what is the most though is once you get a system that work.. an editor, software, optimization... then you have to draw the data from the pictures. And this drawing stuff consume so much time that I understood why that kind of vector graphics never took out. 3D editors like 3DSMax is the works of thousands of people (editor + plug-ins + motion capture + artists.. ) and it is still time consuming. However, my suggestion remain.. to work with the source of data is probably a good way to get different size and in some case the graphic result might be interesting & artistic... without falling into a Strip Poker a-la Picasso! lol!

Thank you HardHat!! I download them and did a quick look. The repair manual is very interesting with different type of garbage screen on boot-up. Wow, you got those manual since 1988?! Where did you first get them?

Look like it could become a Level Editor feature for a game...

Yup, that make it even more challenging... I think it's mostly the Read which are slower than the Write (as the read need to query the byte and return it to the video chip, which place it to the bus for the cpu). While the write, goes only in one direction.

There is always a trade off between : complexity of the map, algorithm complexity, size of memory and processing time. The map usually has to be not only good looking, but interested in it's feature to offer a good game play. The algorithm written to compress the data should tend to stay simple but take the advantage of the feature of the map. As a rule of thumb for optimization, I use the one which said... to first look to what is the "biggest" (for compression) or "slower" (for processing time). I like the fractal approach where tiny stuff (pixels) form bigger objects (tiles) to form even bigger objects (meta-tiles), to form bigger objects (screen), to form.. [a couple of iteration later....] the Universe! Otherwise, I like the idea of using the Video RAM for something else than storing video... so, storing uncompressed data is cool!

I have look to your glitches in the video... I took 2 screen shots, the one on the left is the worst I notice while the one on the right is not so bad. In both cases, what I notice is that the screen was draw but some data byte were missing. Causing tiles to be shifted on left (or on the previous line). In the documentation of the video processor, here is what I think would explain these glitches. I highlight the important stuff in that case. Ok, it might be too small to read, but I think the attachment can be download..? As it said, there are extra delay when the screen get draw especially for mode I & II which are the longest delay. The 2 us can move up to 8us. Moving the music after, in fact caused probably most of the write to happen at a less busy stage of the VDP. If write byte were cruched by another write byte being written (let's say you write at every 5.5 us instead of 8us).. this will cause the byte to have not been written and the write address to stay the same. Causing the trailing of data we see. As they mention the 2us - 8us vary according to what the VDP is doing.. so even if your write routine seem solid like rock, it depends of the receiver, here the VDP. Probably adding nop between two writes could have fix it too. Another issue which is what I first though, could be to write data below the screen being updated too late (leaving data from the previous screen). But in this case the current and previous frame to be draw on screen were the same.

From the video chip datasheet. The chip is not lock while it render, but there are additional delay to response any request made by the CPU. These delay seem to vary according to the video mode. I guess it also vary if we are in the visible area or not (horizontal & vertical). Hum... but as I did not test anything on a real hardware... my talk goes more with what I read from the manufacturer of the chip than experimentation.

Well, apparently it get updated more than a screen line... I asked on BlueMSX forum and someone point me to this article: http://www.danielvik.com/2010/04/cycle-accurate-computer-emulation.html But, I agree with you.. I should test on a real hardware.

What about the eprom programmer? Is it expensive? where to buy it? I was looking last night for an oscilloscope.. I think a Rigol DS1102E 100 MHz is a good one...!? http://www.rigolna.c...s1000e/ds1102e/ But, I didn't see good price to buy & ship in Canada... kind of get 50% more expensive here (600$ instead of 399$!).

Well, to tell you what I got in mind... is to have a title screen which look exactly as the one generated by the BIOS on boot-up. But, after few seconds... it may start doing something unexpected. Let's say.. I have 2 animations + the standard screen which I end up with 3 different scenario for my boot-up screen: A plain one, the normal Coleco Screen with ~12 seconds delay (don't remember exactly the delay...) A common one, an animation which let's say happen 70% of the time A rare one, an animation which would happen only 5% of the time. So, far... the idea of using corrupted RAM on startup and also to use a counter of frames (as you mention) which could be a byte read back on soft reset seem the way to go. The counter of frames will vary from 0 to 255 and the RAM state on startup is either 0x00, 0xFF (in emulator or using special cartridge with multi-games on it) or a value within the range [0x00, 0xFF] on the real hardware. Then, I could read this byte (the counter of fframes) on startup, increment by 1 (to move up 0xFF to 0). A value from 0 to 191 will do the common one, 192-242 will do the plain one and 243-255 will do the rare one. So, for emulators.. the common one will happen unless the person do a soft-reset which in that case the 2 others could happen. On the real hardware, with corrupted memory.. you could just power-on and one of the 3 will happen. But the odds will be based on the odds to get a value within the range of each. I mean by that.. even if I place ranges to get 70%, 25% and 5%... if the odds on the real hardware for a value from 243-255 is 1% instead of 5%... the animation will happen only in 1% of the case. That's why reading the user input in this case would not work. I mean, it would for a soft-reset, but not for a power-up... the decision has to be taken before the user start touching. I guess most people wait and don't touch anything on boot-up? Or maybe it's me who is too calm and just wait! Hehe...

Hum.. corrupted ram or previously written data can lead to what I was needed. But.. then the only thing which is harder to measure is to know odds of such a system. For each chip manufacturer integrated to the existing hardware, what are the odds of each bit to be flipped to '1' versus '0', is there any effect that affect the odds of values around the bit. What could be the variation in production process? If the odds are around 50% with +/- 10% margin... then it's pretty easy to get along with. But if those values vary among systems from 1 to 99% with +/- 40% margin.. then it's like the randomize pattern could be very fair or not fair at all. In other word, on some system the result will be dictate to be almost the same each time. But, the fact that software reset does also work in emulator, which let the value intact... while on the real hardware the values will be slightly affected (which is still good for what I may do --- a kind of Easter egg idea!). Only the cartridge with boot-up that erase the RAM will affect it.

The over temperature is an interesting hypothesis. Pooling RAM value to be read on the video chip give him more work to be done. Temperature usually vary according to exponential curve... When you see the fail occuring.. can you try to shoot air pressure on the chips to lower the temperature down?

Well.. for now, it's something I look to see what can be done. My tests last night bring me doubt at the emulator, even if programmer told me it's quite accurate, which I believe for playing games... but I think it's not accurate enough to study hw glitches and limitation. About the variation, how many machines does exist which has different revision/hardware component, ...? When I look to screen shots of Gulkave it does seem that some color attributes were changes while the screen render to text above and below? Unless it's using mode 2? Yup.. you see me coming.. like a real demoscener.. haha! Well, so far it's more test stuff I am looking at as I know even on C64 it's pretty tricky.. and that kind of thing need to be ported for PAL/NTSC. But most of these tricks are there for so long that they are well documented now. On Coleco, I feel there are many things which could be done but I don't know how well these things were tested. I don't know if I would have my hands on a real hardware. If so, I guess I will try few things on it. Otherwise, I may go with a very secure way and just use the hardware as mention in the specification.

Does sdcc can also compile pure .asm code? It's early in my project to be definitive about how I would go. But, writing some asm for a z80 will be a very good way of learning what the machine can or cannot do. I am a bit concern about using a technique which is time critical... Here is a seminar which talk about it for the C64... It consist of writing code by taking clock cycle and pixel cycle for each scan line into account.