Screen Memory - Moving screen address up one line

[Firefox]

One thing you might do is Joffa Smith's trick for drawing sprites (e.g. Cobra) where they only appear with 2-pixel precision. That means you always know you can copy at least two lines of your sprite image with just a simple INC Hi-Byte between rows, before needing to resort to such fiddly maths. And he'd even store every second line of his sprites in reverse byte order, so he could copy one row with INC L between bytes, INC H to move down a row, then copy another line of bytes in reverse order with DEC L, then be ready to do this fiddly add-one-line-to-the-screen-addess function, now being back at the left-hand edge of the sprite. (That is assuming the screen address is in HL, and you're doing some sort of masked copy rather than a simple LDI).

That's a pretty cool bit of thinking!

[Ast A. Moore]

Not sure if any of these might help. Found these in my archives.

Code: Select all

     (UP_HL)              
 
    HEX  |  OP CODE       
    _____|________________
    7C   |  LD   A,H      
    25   |  DEC  H        
    E607 |  AND  #07      
    200A |  JR   NZ,BREAK 
    7D   |  LD   A,L      
    D620 |  SUB  #20      
    6F   |  LD   L,A      
    3804 |  JR   C,BREAK  
    7C   |  LD   A,H      
    D608 |  SUB  #08      
    67   |  LD   H,A
          BREAK  ...      
    _____________________
     16b - 27/49/59t
	

Uh, I don’t think SUB $08 is going to work. You really need to add 8 to H, not subtract it from it.

[Joefish]

Another option is to use a linear back-buffer where the next line address is simply the current line +32. And you re-order it when copying the whole thing to the main screen.

There's an even more advanced (and mind-boggling) trick, mainly for doing plotting points and lines for 3D stuff, where you have a 256 x 256 pixel back-buffer, which allows you to define your screen in columns, not rows. So the first 256 bytes is the first 8-pixel wide column of the screen (plus a few extra rows), the next 256 bytes is the next 8-pixel-wide column, and so on. That way if your address is HL then DEC L and INC L move you one pixel row up and down, and DEC H and INC H move you one screen byte left and right. Again, you resolve it all when copying from the buffer to the display.

[1bvl109]

After some study the arrangement makes sense. If you are writing software with text output, having a display organised into character rows of 8 pixel lines is useful.

But is this really the reason? Has anyone ever asked any designer of the machine? I mean, it seems to be a question which urges itself on you, once you see, what's going on, doesn't it? According to this https://retrocomputing.stackexchange.co ... map-layout it might be a problem caused by cheapness of the hardware in the first place and might have been solved otherwise

even with a linear layout, the ULA could have used page mode to optimize accesses, but it would have needed to read 16 pixels ahead rather than just 8 each time, which would have made the required circuitry larger and the ULA potentially more expensive. Alternatively, the RAM chips could have been organised with their address lines mapped into a different order than the one the processor expects; this would have worked (and, I believe, was the solution used in the Apple II for refresh, which is a similar problem).

[AndyC]

I suspect that whatever made the hardware cheaper would have been the key driver. Getting the cost down as low as possible was a big deal for Sinclair and it's fairly obvious from the ROM that concerns about optimal speed were far from the top priority.