Differences

This shows you the differences between two versions of the page.

--- base:dots_and_plots [2023-02-08 16:03] – [BitMap Memory Layout] bepp
+++ base:dots_and_plots [2024-01-19 15:18] (current) – [Plotting in any pixel] tww
@@ Line 288: / Line 288: @@
 ===== 320 pixel wide plotter =====
-Assuming you have read and understood the 256 pixel plotter above, the next step is to enlarge the plotter to plott across the whole screen (320 pixels). For Y, nothing has changed though.
+Assuming you have read and understood the 256 pixel plotter above, the next step is to enlarge the plotter to plott across the whole screen (320 pixels). For Y, nothing has changed though as Y_Max = 199.
-This can be done in many ways and totally depends on your needs in terms of speed vs. memory (as always). One method is to use 16 bit addressing along the X-Axis but for a "fixed frame" plotter as this, it's a bit overkill. We actually only need 1 bit (same as the sprites) to indicate if we are crossing the 256th border.
+This can as always be done in many ways, but we actually only need 1 bit (same as the sprites) to indicate if we are crossing the 256th border.
-So let's for the sake of simplicity say that Carry = the 9th X-Bit. Then when the routine is called, simply check if Carry is set and use a different routine to handle plotts above 256 pixels. Basically, you'll need one more set of Y-Coordinates.
+So let's for the sake of simplicity say that CARRY = the 9th X-Bit. Then when the routine is called, simply add 256 to the Y-Position calculation if the CARRY is set at the cost of 2 bytes / cycles:
-If memory is your concern, you can manually add 256 to the Y-Position calculation for some decreased speed instead.
-Here are two examples illustrating how this is done (Both examples assume subroutine call with .X, .Y and CARRY is preloaded):
-**Speed Version**
 <code>
-Plott:
+    lda Y_Table_Hi,y
-    // This part is same regardless of X-Pos
+    adc #$00             // Adds 1 to HiByte (256 pixels) if CARRY is set
-    lda Y_Table_lo,y
-    sta $fb
-    bcs !+
-        // This is the normal Plotter for x < 256
-        lda Y_Table_Hi,y
-        sta $fc
-        ldy X_Table,x
-        lda BitMask,x
-        ora ($fb),y
-        sta ($fb),y
-        rts
-!:  // This part plotts over 256 border and uses a new Y-Table_Hi
-    lda Y_Table_Hi+256,y  // Same as Y_Table_Hi + 1 (which practically means 256 pixels)
     sta $fc
-    ldy X_Table,x
-    lda BitMask,x
-    ora ($fb),y
-    sta ($fb),y
-    rts
-</code>
-This adds 2-3 cycles vs. the 256 pixel restricted plotter and 256 bytes with additional tables + 18 bytes as a result of a larger routine.
-**Memory Version**
-<code>
-    lda Y_Table_Hi,y
-    bcc !+
-        adc #$00      // Adds 1 (256 pixels) to HiByte
-!:  sta $fc
     lda Y_Table_lo,y
     sta $fb
@@ Line 341: / Line 307: @@
 </code>
-And this one adds 3-4 cycles vs. the 256 pixel restricted routine. But it only adds 4 bytes in total.
+The indexing into the Bitmask and X_Table does not need any additional handling as once you add 256 pixels, the X-index will wrap around and fetch legit values again (i.e position $100 means Index X = 0 which will give #%10000000 as bitmask and #$00 as X_Table (offset)) and plott correctly at the 256th pixel.
-So in the end you'd need to decide if that 1 cycle pr. pixel is worth 270 bytes more of tables & code.
 ====== Plotting Pixels in HiRes Charmap ======
@@ Line 535: / Line 499: @@
 </code>
+The tables are written out in full, but normally one would generate these as illustrated in the Hi-res version above.