Gigatron Hackers

Any chance you can send me the code, it looks like sprite memory is being overwritten, there's bound to be some memory allocation bugs in the compiler for ROMvX0.

I sent the code via your email. Did you receive it OK ?

I've got it, haven't had a chance to look at it yet, just got back from work. Public holiday tomorrow so I'll have a good look at it after some sleep.

No hurry. Just wanted to confirm it arrived in case the spam gods got it

I tracked a major bug to this part of the code in DrawCentralCavern This code overwrites vCPU code memory causing undefined behaviour, I didn't really continue checking for other bugs once I found this.

I'm in the process of adding a vCPU code overwrite detector in the emulator that will be enabled by default when the debugger is enabled, I will let you know when it's done.

Sorry, I don't see the problem. W=8 so maximum J*W = 152 and maximum I*W=104. These are within the screen area of 120 X 160 pixels are they not ?

The tiles are 8 X 8 pixels that are being drawn.

There is no issue until sprites are drawn.

Blits unfortunately have to be a multiple of 6 pixels, (it's how Marcel gained such good speed and efficiency with his original Blit routines).

This means if you are blitting a width of 8 horizontal pixels, the blit routine is actually blitting two strips of 6 pixels, hence an extra 4 garbage pixels.

There is a way to have blits be non-multiple's of 6 pixels and that is to use the OVERLAP option during a LOAD BLIT, this specifies an offset to push the last 6 pixel wide strip in. Unfortunately you have to draw your images with this offset separating them, if you look at PucMon and it's ghost .tga files, you can see how there are two 6 pixel wide strips with a 3 pixel overlap/offset that pushes the strips together to do a 9x9 blit.

OK, I got it now. My graphics are actually 12 bits wide. I completely missed that when I was programming. It should only affect the bottom right corner tile as the screen memory is contiguous ?

I could also make my tiles 6 bits wide which probably would be better

The screen memory is contiguous, but unless you free the offscreen areas using the FREE command, then the compiler will stuff as much code and data, (including sprite data which HAS to go into offscreen areas), into the offscreen areas.

This means that if you draw anything past x position 159, (on purpose or by accident), you will overwrite code and or data, (including sprite data).

The only time you should ever really need to FREE the offscreen areas is if you want your blits/sprites to slide/clip offscreen or if you want to horizontally scroll your screen.

Making your tiles 6 pixels wide or a multiple of 6, will save a lot of headaches.

One more:

You are using FREE STRINGWORKAREA and then later on in the code using string functions like MID$ etc.

FREE STRINGWORKAREA frees the buffers used by the string functions and make the RAM used by those buffers available to other code and data, if you then use any string function which makes use of those string buffers, (which is most of them), then you will get corrupted code/data.

So only use FREE STRINGWORKAREA if you can guarantee that you won't be using any string functions.