F-Cycles

Does a long press versus a short press on Reset cause the RAM to be more corrupted (or does the corruption came from running the beginning of the inserted cartridge)? Sorry, I know I am kind of picky in details about how things work. And yes, I would have to step back after exploring how things work to get a trade-off of what I should do and not do... I don't know Daniel if you saw one of my other post.. about the sprites. Got my first piece in asm coded last night by using your sprite sample on YT. This morning I post my src code + .rom files + png.

Hum.. so really getting a different value upon boot-up seem to be limited... probably too limited for the work & result I was thinking about. It's good to know why they have initialize memory as otherwise it should be the closest to what it could be. Does the reset button actually a hard reset or soft reset? does it keep the content of the memory RAM and/or video RAM?

In the BlueMSX emulator, the RAM and VRam seem to be initialize with zeros. I am looking to see if I can get my hand on a Coleco.. if so, I could buy the cartridge with 32 Megs SD... (wonder if I should get 2 of these SD)... the registers in BlueMSX seem to be init with 00 or FF. Hum... will have to get my hand on the real hardware as I am getting more and more questions... I am asking one of my friend which I believe he has 3.. but maybe only one which work properly!?

I am looking for something on Coleco Vision... a random value. Not, a random sequence value from a generator. But a value which when you power on the machine, within less than a second.. a value can be read which might be different from a previous boot. As you can imagine, if this exist, then it could open the door to a different title screen from one boot to another...

Good to know! So, it give me hope to use it then. Oh, I found it.. look to the thread: Eye on Coleco, But Many Questions... a quote from PkK:

Hum.. Sorry I post my reply to the thread... 'Fun with VDP status register' I try to delete it after posting it.. so I could put it here. But, well.. at least it kind of related with the topic of video processor.

Attached source code + .rom files. ---> Oupss.. sorry, I post my src code + screen shot in wrong thread.. 1. 1 Sprite in 32x32 (by setting the MAG flag to 1) + changing colors --> In the emulator, I never saw one line with 2 colors. 2. 1 Sprite and modifying the X position from 0 to $D0. --> In the emulator, I never saw on one scan line, the 2 sprites. 3. 1 Sprite and modifying the X position.. increment the value initially set to $0 and decrementing the 2nd value which was set to $d0. --> That one was made for fun... 4. 2 Sprites at fixed position and modifying the MAG flag... --> I never saw in one scan line, one which will be MAG ON and the 2nd sprite being MAG OFF... Those tests flickers a lot... so they might be very hard to see on the real hardware at normal speed. I recommend to use a camcorder (60 FPS) then look at the frames in slow motion. sprite_tests_by_fcycles.zip

Thanks for this test! Yes very useful. I though also this status value would be changing according to the scanline we are. I read somewhere that collision bit was not working on Coleco Vision which get old.. because of some power problems which are minor!? I would like to know if that's true... Hum.. the collision in your test seem to happen only when the pixels which are on are touching each other? Well, I am testing in an emulator (BlueMsx)... Maybe on the real hardware the collision happen as soon the 2 square overlap!? Is that what you observe? Sorry I end up with more questions than answer.. ^_^

I have started to look to the video chip and especially the VDP Block Diagram. I don't have a real hardware and my tests are limited to be running in BlueMSX. So far, my test show that a single sprite can have a different color per scan line and a single sprite can be 16 pixels by 192. But that's not that interesting with the 32 sprites already available... unless to show a screen with 48 sprites - did anyone had ever done it? - (since 192 pixels height is 12 sprites and 4 sprites per line x 12 sprites = 48 sprites on screen). In fact, all values seem to be stored for each scan line... Which I am not sure it's the case on the real hardware for all values!? Because the VDP has 8 internal registers. Some of these registers may be connected directly to other gates to produce the desired results... That's my guess so far. I target especially the register which magnify the sprites (which does not need to read any values from the RAM to be effective). This bit could be directly connected via a line to a logic gate and as soon the bit toggle, it may produce a change in the circuitry... in my test, I place 2 sprites one on the left side of the screen and one on the right side of the screen. The distance between the two was $D0 which is 208 pixels... which give about 138.6 T (CPU) clocks in between the two (enough for the few instructions needed). I then attack the register 1 toggling the bit. The result is that I see one scan line show the 2 sprites magnify by 1x and next scan line magnify by 2x and so on (few scanline has double 1x or 2x), as I did not try to be in sync with the HSYNC. I pause the emulator a couple of time and never notice for the same scan line a different result for the 2 sprites. I would like to know if someone has done some research about that MAG bit or the SIZE bit? Thanks Best Regards,

Thanks Kiwi! Any suggestion for a compiler? I wonder if there is one for the Z80 which also output some memory maps information, like how many bytes a function take. Is there any profiling tools? to know how many clock cycles take from one point to another in the code...

Hello everyone, I am newbie on this forum & in the world of Coleco Vision programming. I found few things about the documentation & compiler for a Z80, but I am not sure if that's what people use for assembly language programming. The compiler I get is call: tniASM (v0.45). And for documentation, so far I saw videos of NewColeco, got some data sheet of the Z80, also video and sound chips. I have few information about the BIOS, but I would say that's mostly what I feel is missing... Does a memory map of the BIOS exist? Or anyone has the original .asm file? The project I start to work on is converting a C64 game: Doriath to the Coleco Vision. You can read some articles I wrote, here... http://fcycles.blogspot.com/ And as always, Thanks for reading... --- F-Cycles