base:dots_and_plots
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
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 ===== | ===== 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 |
- | 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 | + | This can as always |
- | So let's for the sake of simplicity say that Carry = the 9th X-Bit. Then when the routine is called, simply | + | So let's for the sake of simplicity say that CARRY = the 9th X-Bit. Then when the routine is called, simply |
- | 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** | ||
< | < | ||
- | Plott: | + | |
- | // This part is same regardless of X-Pos | + | |
- | | + | |
- | | + | |
- | bcs !+ | + | |
- | | + | |
- | lda Y_Table_Hi, | + | |
- | 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, | + | |
sta $fc | sta $fc | ||
- | ldy X_Table,x | ||
- | lda BitMask,x | ||
- | ora ($fb),y | ||
- | sta ($fb),y | ||
- | rts | ||
- | </ | ||
- | |||
- | 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** | ||
- | < | ||
- | lda Y_Table_Hi, | ||
- | bcc !+ | ||
- | adc #$00 // Adds 1 (256 pixels) to HiByte | ||
- | !: sta $fc | ||
lda Y_Table_lo, | lda Y_Table_lo, | ||
sta $fb | sta $fb | ||
Line 341: | Line 307: | ||
</ | </ | ||
- | 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 ====== | ====== Plotting Pixels in HiRes Charmap ====== | ||
Line 535: | Line 499: | ||
</ | </ | ||
+ | The tables are written out in full, but normally one would generate these as illustrated in the Hi-res version above. |
base/dots_and_plots.txt · Last modified: 2024-01-19 15:18 by tww