Righto, quick summary of the task :

Generating a lookup table containing the memory location of the immediate left byte for each line of the mode 5 screen. First entry bottom row of the screen, last entry top row of the screen.

My reasoning for generating the table is that looking up the start address of the row will be the quickest method, as discussed here in the forums already by others, and rather than waste 512bytes in my executable, I'll get the program as part of it's environmental setup to generate the table in two low pages. Speed is not important, the setup code area to be working space or other when the core of the program is executing.

Great stuff.

I have a start value of &7EC7 - the byte at bottom left of the screen containing pixels (x,y) = (0,0) (1,0) (2,0) (3,0), at 'number', low byte, high byte as expected and you can see from the snippet below. The loop that decreases the value by 1 each time works fine, then for the eigth step which is a step of 313 (320 bytes per line as per the memory layout used in the Beeb), I do the following, as the odd one is already dealt to in my singles loop - sloppy, but I'm not to worried about elegance right now, I only have to reduce it by 312.


(My appologies for the kiddie comments, I don't usually comment individual instructions, just looking real hard at what is going on now).

My problem seems to be that if 'number' contains 0, the first subtract does not appear to unset the carry flag so that the second SBC will add 1 + NOT(C). Checking for negative fails too - I've tried right down to inserting 'cmp #0:bne skip:dec number+1:skip' at the obvious place, and I know that the cmp is superfluous...

I have a BASIC program to focus on the table generation - it was the easiest way for me to see what was going on. I've attached a copy for you to download and laugh at. Slight difference is that for this one it double steps (every two lines) while I was playing with alterations to responses to flags and working out if there was something strange going on in BeebEm - there is not, it's me.

This is for a horizontal line drawing routine rather than a sprite plotter - I can draw the lines fine, and other things I thought were more complex at the time, now I am just going round in circles with this simple stuff

Some guidance would be greatly appreciated - and let me know where I've been a fool so I'll try harder next time.

Thanks.

A quick glance suggests that the problem is that you are not adjusting the high byte of number in the part of the code where you subtract 2. You need something like:


because, for example, if number started off as &6006, then by the end, it needs to be &5FFE. When you then subtract &138, you then get the correct next value of &5EC6.

Ah, I see, because my loop runs 'one too many times', I am not being left with 0 in the low byte, but 255. Your suggestion above spots this over-run and deals to it.

I've altered the logic a fraction, starting with a value one higher than I want, then reduce it before I enter the value in the table and now it all runs properly without adding those few correction instructions.

Greatly appreciated, I wasted two weeks just on this.

Just a question though - why are you building the table from the bottom up? I think the code is far simpler if you start at the top of the screen and work down - then you don't have to bother adjusting the high byte for each line within a character block, and the operation of the code is a little easier to understand.

I could be wrong, but I don't think it is any easier either direction the table is generated. Start value would be &5800 instead of &7EC8 and the value is incremented instead of decremented, addition of 314 instead of subtraction.

Conceptually, bottom left is now (0,0) same as I learned in school. At the absolute worst, I get the same results from a BASIC mock up as my program so I'm headed in the right direction - so to speak.

You are right about the way I have written this though. Very unpleasant to work out what is to be achieved. Reminds me of a quote, I can't recall who to attribute it to "Of course it's difficult to read, that's why it's called code". I guess I just got lucky that it works too.