Tools & Docs for assembly programming...

[F-Cycles]

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

[Kiwi]

The very last pages have the memory location where the function are in the BIOS in this programming book.

 

http://www.gooddealg...programming.pdf

 

If you're programming in assembly, this resource will help you how to use the BIOS routine by loading values into the z80 registers and call the routine.

 

http://colecovisionz...rogrammers.html

 

If you need to set up the register in Assembly, this instruction book will help you.

 

http://map.grauw.nl/resources/video/texasinstruments_tms9918.pdf

Edited July 19, 2013 by Kiwi

[F-Cycles]

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

Edited July 19, 2013 by F-Cycles

[Kiwi]

I sent you a PM if you want to code in C.

 

http://z80.info/ has good resource on z80 chip. What I kinda understand, the CPU will halt at the end of the interrupt before entering the fresh CPU cycle instead of crashing. I'm still learning z80. TsiASM .45 what I use to compile Colecovision assembly project.

[PkK]

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

 

You definitely want to go with sdcc (http://sdcc.sourceforge.net) for the compiler; it is simply the best there is these days for the ColecoVision (also the IAR one sometimes generates smaller code for the Z80 than sdcc does). The linker sdcc uses emits a .map file that shows memory usage (code size and global variables).

 

Both my tools (http://www.colecovis...on/development/) and Daniel's are meant to be used with sdcc.

 

Philipp

[F-Cycles]

You definitely want to go with sdcc (http://sdcc.sourceforge.net) for the compiler; it is simply the best there is these days for the ColecoVision (also the IAR one sometimes generates smaller code for the Z80 than sdcc does). The linker sdcc uses emits a .map file that shows memory usage (code size and global variables).

 

Both my tools (http://www.colecovis...on/development/) and Daniel's are meant to be used with sdcc.

 

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.

[PkK]

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.

 

Well, sdcc is an compiler, which means it is meant to transform a higher language (in this case C) into asm. But it also comes with the sdasz80 assembler and you can use inline asm from within C functions (though I prefer to keep my asm stuff in separate files and do not use inline asm).

 

Philipp

[newcoleco]

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.

 

Now I see what you want to do and I would say that it's not something that is predictable on ColecoVision... and keep in mind that you might get some slight variations between Coleco and clones like the Dina or the Coleco ADAM computer.

 

You may argue that it's part of demoscene and can be used as a neat trick to add some magical effects and I would love to say "go for it" but I see it as a potential unpredicatble nitemare. Krew who made WATERLINE for ColecoVision blamed the poor way ColecoVision was built to explain some glitches... will you claim the same when you'll notice these glitches going on in your project?

 

When you try to modify the video RAM or just play with video registers while the videochip is busy rendering the screen it's running into trouble... it's the nitemare of corruption that every Coleco programmer wants to avoid and sadly no emulator simulates that; they all instead assume that no data is lost. On the real console, the result is partial lost of data who can either be the instruction telling which video register number you want to deal with, the data to set that video register to, or any part of the data you send to the video chip. For example, it happenned to me in the GhostBlaster project where I could see missing "characters" at the bottom of the game screen (last part of my graphic engine rendering) causing some shifting and so nasty video corruptions.

 

http://youtu.be/hSXVwCF5_ws

Edited July 23, 2013 by newcoleco

[F-Cycles]

Now I see what you want to do and I would say that it's not something that is predictable on ColecoVision... and keep in mind that you might get some slight variations between Coleco and clones like the Dina or the Coleco ADAM computer.

 

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.

[Tony Cruise]

I program all my titles only in ASM, using Context as the editor (as it allows both syntax highlighting and properly parses the output line from the assembler i.e. able to jump straight to error line).

I use tniasm (version 045) as the assembler and BlueMSX as the emulator as it seems to work fairly accurately.

My current MSX to Coleco conversions use a couple of the BIOS routines, but I am gradually replacing them with better performance versions that suit what I need. This also makes it easier for me to be able to reverse port the titles back to the MSX, original Spectravideo and Sega machines.

For more information on VDP tricks look at the development forums at msx.org, as the Coleco's video processor is pretty much the same, just perhaps has slower video ram causing more potential corruption issues.

[PkK]

Now I see what you want to do and I would say that it's not something that is predictable on ColecoVision... and keep in mind that you might get some slight variations between Coleco and clones like the Dina or the Coleco ADAM computer.

 

You may argue that it's part of demoscene and can be used as a neat trick to add some magical effects and I would love to say "go for it" but I see it as a potential unpredicatble nitemare. Krew who made WATERLINE for ColecoVision blamed the poor way ColecoVision was built to explain some glitches... will you claim the same when you'll notice these glitches going on in your project?

 

When you try to modify the video RAM or just play with video registers while the videochip is busy rendering the screen it's running into trouble... it's the nitemare of corruption that every Coleco programmer wants to avoid and sadly no emulator simulates that; they all instead assume that no data is lost. On the real console, the result is partial lost of data who can either be the instruction telling which video register number you want to deal with, the data to set that video register to, or any part of the data you send to the video chip. For example, it happenned to me in the GhostBlaster project where I could see missing "characters" at the bottom of the game screen (last part of my graphic engine rendering) causing some shifting and so nasty video corruptions.

 

http://youtu.be/hSXVwCF5_ws

 

All my games update video ram and registers while the graphics chip is rendering. When I first started programming it took some time to get things right, but I am quite sure none of the published games has any graphics corruption (at least not due to this issue).

 

Philipp

[Pixelboy]

All my games update video ram and registers while the graphics chip is rendering. When I first started programming it took some time to get things right, but I am quite sure none of the published games has any graphics corruption (at least not due to this issue).

 

Now I'm confused... Just last week-end, during AdamCon, newcoleco and another guy told me that the CV graphic chip is "locked" while it's rendering on the TV screen. So I'm left wondering what the term "locked" really refers to.

[F-Cycles]

Now I'm confused... Just last week-end, during AdamCon, newcoleco and another guy told me that the CV graphic chip is "locked" while it's rendering on the TV screen. So I'm left wondering what the term "locked" really refers to.

 

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.

[newcoleco]

Now I'm confused... Just last week-end, during AdamCon, newcoleco and another guy told me that the CV graphic chip is "locked" while it's rendering on the TV screen. So I'm left wondering what the term "locked" really refers to.

I never said it was locked but instead safe to update video at a specific moment which is, for programmers, right at the catch of the NMI, right at the start of the NMI routine... it is also safe if the screen is set to be off (screen_off), but during a game better not use that second option, only for displaying bitmap splash screens.

Edited July 24, 2013 by newcoleco

[PkK]

It can be done safely any time.

 

Philipp

 

P.S.: I can provide details later, if there is interest; have to catch a flight now.

[newcoleco]

It can be done safely any time.

Objection! If it was really safe at any time, then how can you explain my video showing that it isn't?

[PkK]

Well, has anyone seen graphics corruption in any of my games caused by accessing the graphics chip at any time? Even the demo programs that come with my tools access the memory graphics memory at any time. It can be done safely, but it takes a bit of extra effort (that the libcv/libcvu libraries can handle):

 

Basically there sre two issues:

1) The timing. My library has a fast function for writing to video ram, that takes 5.87 µs per byte (to be used when the screen is off or during the time you consider "safe"), and a slow one that takes 8.4 µs per byte (to be used at any other time). Using the wrong one leads to video memory corruption when writing, or wrong data when reading.

2) vint corrupting the setting of the graphics memory address; corruption here can again result in corruption of video memory or data read. Here the solution is to detect this corruption, and fix it.

 

Have a look at libcv/src/cv_set_write_vram_address.s, libcv/src/cv_memtovmemcpy_fast.s, libcv/src/cv_memtovmemcpy_slow.s and libcvu/src/cvu_memtovmemcpy.c for the details in how you can write safely to graphics memory any time.

 

Philipp

 

P.S.: libcv/libcvu can be found at http://www.colecovis...ent/libcv.shtml

[F-Cycles]

Objection! If it was really safe at any time, then how can you explain my video showing that it isn't?

 

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.

[hardhat]

There are electronic versions of the resources I tend to use here:

 

http://ann.hollowdreams.com/programming.html

 

With detailed docs on using the BIOS in the CV Programmers Manual. I've often wondered why more people don't use these docs. I've been using them since 1988 or thereabouts. But I guess they weren't widely available online or elsewhere.

 

Also my docs about making a SuperGame for the Adam are slightly relevant:

 

http://adamcon.org/~dmwick/mayan/

[F-Cycles]

There are electronic versions of the resources I tend to use here:

 

http://ann.hollowdre...rogramming.html

 

With detailed docs on using the BIOS in the CV Programmers Manual. I've often wondered why more people don't use these docs. I've been using them since 1988 or thereabouts. But I guess they weren't widely available online or elsewhere.

 

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?

[hardhat]

Coleco Adam user groups. Basically they come from Coleco then when to game development firms and then mysteriously were given to me by user group member with a comment like "I think this would be more useful to you." and the like.