VRAM addressing issues

[BrianBeuken]

I am having a small problem that I can't quite explain

 

I am dumping a charset to VRAM_PATTERN in order to dump a screen anything from 10 to 40chars ..this seems ok, but when I then try to dump an ascii charset at VRAM_PATTERN+(128*8 ) I seem to be tagging the ascii to the end of the screen charset and not locating it at VRAM_PATTERN+(128*8 )

 

I am using WRITE_VRAM with DE containing the target in VRAM but it seems to be ignoring the 2nd write...Am I missing some reset needed before using WRITE_VRAM??

Edited April 11, 2014 by BrianBeuken

[BrianBeuken]

No one?

I notice some demos have an in a,($bf) after a WRITE_REGISTER call...what does it do?

 

B

[Tony Cruise]

Are you disabling the VDP interrupts before doing your write to VRAM? Anything other than a couple of bytes needs to ensure that the VDP interrupt is disabled while doing the copy.

So other than initial screen setup it is a good idea to only do VRAM reads and writes in the interrupt routine.

See my assembler template for some more examples.

[BrianBeuken]

Hi Electric,

 

I'm not disabling the interrupt as it does some other housekeeping tasks and I want to keep it running to prevent lags, but I have put a flag on it to prevent the routine downg VRAM access during the interrupt if the main code is accessing it. I wrapped the WRITE_VRAM routine with a set and clear system for that flag so that VRAM writes and int access do not occur at the same time. The VDP int mainly handles the sprites motion and animation updates.

 

My code does need to do quite a bit of access to VRAM, for scrolling systems and sprite anims, so I need to be able to access at will. I discovered if I set up my font early in the code and didn't try to set it after I had dumpd a screen charset my font went in, but later in the code tis still being a pain, I am working around it for now, but dislike things not behaving as I expect them

 

where can I see your template to see if I am missing something?

 

B

[+nanochess]

Maybe you're stuck with a known bug in WRITE_VRAM:

 

 

WRITE_VRAM AND READ_VRAM

It works as advertised for byte counts less than 256 (00h-FFh) and for byte counts that are multiples of 256 (100h, 200h,...). For other values, it substracts 256 (100h) from the actual byte count. Programmers should deal with this problem by always sending numbers of bytes that are less than or even multiples of 256 (100h). They should not deal with it by padding their byte counts as this may lead to cartridges that fail when the bug is fixed. Note : PUT_VRAM and GET_VRAM call these routines, so take care.

 

I got this from the Colecovision Coding Guide http://www.theadamresource.com/manuals/technical/ColecoVision%20Coding%20Guide.pdf

[Tony Cruise]

Hi Electric,

 

I'm not disabling the interrupt as it does some other housekeeping tasks and I want to keep it running to prevent lags, but I have put a flag on it to prevent the routine downg VRAM access during the interrupt if the main code is accessing it. I wrapped the WRITE_VRAM routine with a set and clear system for that flag so that VRAM writes and int access do not occur at the same time. The VDP int mainly handles the sprites motion and animation updates.

 

My code does need to do quite a bit of access to VRAM, for scrolling systems and sprite anims, so I need to be able to access at will. I discovered if I set up my font early in the code and didn't try to set it after I had dumpd a screen charset my font went in, but later in the code tis still being a pain, I am working around it for now, but dislike things not behaving as I expect them

 

where can I see your template to see if I am missing something?

 

B

It's in another topic called Colecovision Assembler Template. It includes replacement code to do all VDP actions, rather than using the BIOS routines.

[BrianBeuken]

Ahhh that bug may very well be the problem, thanks I will check this out shortly and report back to you

Edited April 18, 2014 by BrianBeuken

[BrianBeuken]

Maybe you're stuck with a known bug in WRITE_VRAM:

 

 

I got this from the Colecovision Coding Guide http://www.theadamresource.com/manuals/technical/ColecoVision%20Coding%20Guide.pdf

thanks