BrianBeuken

This sounds very promising, thanks nanochess, I'm back home this week and will try this again on my hardware and report back to you Brian

Hi all I wonder if I can get some collective help for a strange problem I am having. i've been working on a CV game for some time now, its a collection of mini games and a menu system to tie them together and code wise its all done and dusted, it works perfectly on every emulator I have found, but when I test it on hardware I get a very strange and apparently random corruption of my sprites but only on some of the games, and not always the same ones. I am using the correct terminators in the sprite list I send to the video. and I even make an extra effort to ensure the sprite attrib memory is filled with 192's before I dump my sprite list. but on some of my sub games, the sprites just go crazy.. I can reposition the games and the issue vanishes, though will crop up in another game or not appear again unless I add a few bytes of code. I don't have enough memory now to actrually just add padding until it stops so I have to find a fix.. I've re-written my sprite manager several times now, assuming I'd made some error, but the problem keeps coming back at some other point no matter what methods i use to build the sprite patterns (games usually have 2-3 16x16's to make a game char) The games are arranged to minimise sprite flicker but if it does occur it alters priority to reduce the flicker.. Its very frustrating, the only thing I can think of is if there is some area of ROM or RAM that I am not supposed to be accessing, though I see nothing in the docs that suggest that. So anyone know what is going on? I really want to get this game out on cart but until I can be sure it works on hardware I can' t release it. .

The only real advantage, is running in RAM allows you to use self modifying code which was useful in the early Z80 days on computers to save variable space and make some routines a little faster (direct load of a register is faster than a memory load) several clock cycles can be saved in loops, but with the CV having such a small amount of RAM and its video being tied to the TI chips access clock, there's not a lot to be gained from these kind of code gymnastics. But am sure someone will find a good reason to do it.

I would contest the statement that hand written assembler would only be marginally faster, but it really does depend on the code, and what you were trying to do.. I like C, I would really like to try it out on the CV soon. I'm very curious to see how well the SDCC works.

It does waste a lot of memory, but if the project does not need speed or memory its just far simpler and faster to express coding concepts in C. The stack isn't such a mystery, but yes you do need to take control of it as with all things in assembler, the coder rather than the compiler is in charge, with great power...etc..

do you have any links/sources for it? goggle is failing me?

Although C and other compilers do exist for CV it produces rather slow and bloated code. Originally all CV games were written in Z80 assembler, which is harder to code from scratch but over time you build up libraries of common routines and functions which with macros can result in reasonably fast coding. C will let you produce your code quicker, but CV is a fraction of the speed of the lowest level PC, so you should use the fastest most compact coding system possible, which is assembler.

Thanks, I hadn't tried to use CVgraphictoolkit for bitmaps, it does seem to do the job, I'll test it out.

Hey all, I'm in the very final phases of my project, a port of a classic C64 game, which I will let my publisher tell you about when its ready, but I have been trying to touch up some of the artwork and finding it such a chore. I know we have the IPCH toolkit which is very useful on a character by character basis, but really quite limited when it comes to designing full screens or small sections of screen, sometimes you just want to draw a line from a to b on screen and let the internals take care of the chars I am painfully aware the 2 colour system on the TMS chips and the grouping of 8 chars per colour is problematic, but are there any art packages around, perhaps even on MSX that will let me draw screen based art, swapping to new character group and producing finally a character set and name table I can then use in games? If not, is this something others would find useful if I wrote one? cheers and watch this space for more details

I just checked the uridum video and yes I do understand this concept for horizontal scrolling which is relatively simple but eats ROM (there's always a compromise( I'm really looking to find a way to do smooth 8 way scroll, all the examples quoted show only a vert or horizontal system, apart from the Burning rubber game which makes a damn good attempt at 8 way using simplified graphics to allow for reduction of work. Back in my Spectrum/Amstrad days we just used to dump recalculated screens to the visible screen but that's not practical on a low RAM, char map based screen.......creates an interesting and difficult proble

ok but all this really allows you to do is create a (near) screen size character map that you can dump a bitmap to? I assume scrolling is then done by dumping to via x and y offsets into that buffer....but that's going to require a massive RAM buffer that's not available on the standard CV..hmmm So what are these undocumented features?

I assume you are only writing to the VDP during the vblank refresh then? that's a good example of 8 ways scroll but yes it highlights how simple the graphics need to be so you're not redefining hundreds of chars.

hmmm yes very nicely done on vertical or horz scroll, but none of those techniques would allow for a true smooth 50hz 8 way scroll unless the graphics were incredibly simplified. Writing extensive bitmaps is extremely time costly and that's the principle needed to get uridium and other 8 way scrollys to work... does the SGM provide scrolling?

How would you handle the scrolling on CV since the TI chip does not support any kind of native scrolling?

neat and fast thanks...

Nah the tracks not that hard, just need to use some sensible character mapping and limit the amount of scrolling....which is where the cars start to be a pain since you can't really map it into the charset properly......that needs some planning. I'll have a ponder on it for a few weeks, and might get into it when I've finished my current project.

might be worth having a crack at then, is it something a lot of CV users would want to have? Couldn't imagine getting the rights to use the name but not harm in doing an homage. biggest issue as I see it is the 4 sprite per line issue is insurmountable, but apart from that its fairly simple to do.

hmmmm so PP was never produced on the CV?

Thanks, I'll use that, I was aware of the timer and user input, it provides an unpredictable seed creating a better sequence. All help much appreciated, I've been away from Z80 for a long time an missing my old library routines so little snippets like this are a big help. Brian

Thanks Guys this is very helpful I'm currently not really using the BIOS beyond getting control pads and that Random number, R is of course usable but limited and I do occasionally need multiple random values in one routine making R less useful, I may just use my own random systems, but I do want to try and use the sound player for my music, since I don't have a decent music engine...I'll have to see, but the map is very helpful help me avoid crashing into the systems RAM. I appreciate the help. Brian

I note that the system is using the upper part of its 1K to do system stuff, ie, $73C8 I thought that low part of RAM was being used so I have my ram starting at $7100. I think I may have that wrong now, can you give me some info on the system RAM usage? Brian

Aha, that is indeed the problem, I bypassed the colecovision screen, thanks so much for this little gem of wisdom.

Hi guys can any one advise me on the use of the RAND_GEN routine, it does not seem to produce a result, returning 0 each time, I assume that is because it needs a random seed set somewhere but I can't locate where that seeding is done. in the meantime I'm using the R register but would very much like ot use the system routine RAND_GEN equ $1FFD thanks Brian

thanks

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