paladina Posted February 23, 2010 Share Posted February 23, 2010 Hello, ok I need some help with correction of Display List,I cannot find the correct adress to do right poke. Its Graphics 24 ( in Turbo Basic with 256 X pixels (poke 559,33), but when I load the picture in memory, there is wrong HI DL adress, can anybody help please a give me correct POKE to do this right? There is my example in ATR and the old pic in WAR1 (320*192) and the new what I will WAR2 (256*192) with POKE 559,33 DL 41014 112 41015 112 41016 112 41017 79 41018 80 41019 161 . . 41113 79 41114 0 there is the HI adress that is my problem (you see in picture WAR2) then what for POKEs please? 41115 176 . . 41213 65 41214 54 41215 160 Thx. PALADINA high8.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 23, 2010 Share Posted February 23, 2010 yeah... the damned 4k boundary crap... never get that right... need others to answer that... but I am starting my bitmap's always at $x010 which makes life easier... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 23, 2010 Share Posted February 23, 2010 Well, with the narrow playfield, DMA is covering less ground so your jump over the 4K boundary has gone out of sync. From your DL data base address, you'll need another LMS on the 129th line (assuming you've arranged your screen data to begin exactly on a 4K boundary, which you haven't as far as I can tell - unless I'm doing my sums wrong). So, the LMS at the top of the DL should point to the start of a 4K boundary, then 128 lines later, you need another LMS which points to the data 4096 bytes higher up in memory. Quote Link to comment Share on other sites More sharing options...
analmux Posted February 23, 2010 Share Posted February 23, 2010 (edited) I wouldn't change the location of the Display List. Just change two bytes. Just point to different starting addresses. The first LMS instruction (79,80,161) is the start of the 0th graphics line, and the second LMS instruction (79,0,176) is the start of the 94th graphics line. This means, from address 80+256*161 there are 94*40 bytes until you will reach the 4kb boundary. Thus 80+256*161 = 176*256 - 94*40. Recomputing to lines of width 32: 176*256 - 94*32 = 42048 = 64+256*164. Thus, change first LMS instruction (79,80,161) to (79,64,164). The 2nd LMS doesn't need any change. Also: Change zeropage vector 88,89 to this new address of start-of-screen: poke 88,64 and poke 89,164. Then do BGET #1,DPEEK(88),192*32. (I suppose the picture is contained in some raw data-file with size 192*32 bytes. Then all you need to do is the BGET command to another point in screen memory). Edited February 23, 2010 by analmux Quote Link to comment Share on other sites More sharing options...
pavros Posted February 23, 2010 Share Posted February 23, 2010 (edited) POKE 41114,16:POKE 41115,173 .. but there will be "4k boundary crap", as Heaven said, in 118th scan line Edited February 23, 2010 by pavros Quote Link to comment Share on other sites More sharing options...
analmux Posted February 23, 2010 Share Posted February 23, 2010 POKE 41114,16:POKE 41115,173 This won't give the desired result. There'll be a wrap-around when Antic gfx-address pointer will reach page 176. It will flip back to page 160. Quote Link to comment Share on other sites More sharing options...
pavros Posted February 23, 2010 Share Posted February 23, 2010 Yes, that's true. Just edited my previous post. Quote Link to comment Share on other sites More sharing options...
raster/c.p.u. Posted February 23, 2010 Share Posted February 23, 2010 (edited) Change your program 15 POKE 41018,64:POKE 41019,164 1110 EK=42048 Then your videoram will be from $a440 (42048) with regular 4K boundary at $b000 (45056). (You can run state file in attachments, then break it and list the adjusted source.) hi8.zip Edited February 23, 2010 by raster/c.p.u. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 23, 2010 Share Posted February 23, 2010 Best solution - construct your own Display List. The other problems you'll have is that the OS plot/draw routines will become useless to you because they only work on standard width screens. And your picture will need to be constructed with the 32 byte width in mind, but it looks like you've already taken care of that. Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. The thing to be careful of is to make sure your DList doesn't cross a 1K boundary. Quote Link to comment Share on other sites More sharing options...
TMR Posted February 23, 2010 Share Posted February 23, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? Quote Link to comment Share on other sites More sharing options...
atariksi Posted February 23, 2010 Share Posted February 23, 2010 yeah... the damned 4k boundary crap... never get that right... need others to answer that... but I am starting my bitmap's always at $x010 which makes life easier... Yeah, starting at offset 16 ($010) is the best for normal screen as this gives 4080 bytes remaining which is evenly divisible by 40 bytes/line and the next 4K block starts at offset 0. It also is evenly divisible by 48 (wide screen) giving 85 scanlines followed by another contiguous 4K block. Quote Link to comment Share on other sites More sharing options...
atariksi Posted February 23, 2010 Share Posted February 23, 2010 Best solution - construct your own Display List. The other problems you'll have is that the OS plot/draw routines will become useless to you because they only work on standard width screens. And your picture will need to be constructed with the 32 byte width in mind, but it looks like you've already taken care of that. Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. The thing to be careful of is to make sure your DList doesn't cross a 1K boundary. I though OS used those zero page variables like DeltaR (location 118), DeltaC (location 119,120), RowInc (location 121), ColInc (location 122), etc. for plot/draw stuff so setting those should help for wide screen or narrow mode. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 23, 2010 Share Posted February 23, 2010 I though OS used those zero page variables like DeltaR (location 118), DeltaC (location 119,120), RowInc (location 121), ColInc (location 122), etc. for plot/draw stuff so setting those should help for wide screen or narrow mode. AFAIK, altering those locations won't make the OS routines work with narrow playfields. In any case, I believe those page zero locations are just internal working registers for the OS graphics routines. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 23, 2010 Share Posted February 23, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? Quote Link to comment Share on other sites More sharing options...
atariksi Posted February 23, 2010 Share Posted February 23, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? If you're in narrow mode, ANTIC will do 40 byte lines if HSCRL is enabled (bit 4 of DL). Here's some code to prove it: 10 GRAPHICS 8 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,159:DR. 257,159:DR. 2,0 60 ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 The only problem is display starts at 2,0 and goes to 257,0 and that's with horizontal scroll register set to 15 color clocks. Scroll is being done without VBI so there's some jerkiness. Quote Link to comment Share on other sites More sharing options...
TMR Posted February 23, 2010 Share Posted February 23, 2010 What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? Not with a 32 byte wide display no, it steps through in 40 byte blocks - if the display is 40 or 48 bytes wide it'll be counting 48 bytes with the scrolling on. Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 23, 2010 Share Posted February 23, 2010 DELTRAR etc are working variables for line-draw. HScrol would be best - should have thought of that in the first place. Although you then need to adjust any screen coordinates - screen locations will actually be (X+32) Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 24, 2010 Share Posted February 24, 2010 What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? Not with a 32 byte wide display no, it steps through in 40 byte blocks - if the display is 40 or 48 bytes wide it'll be counting 48 bytes with the scrolling on. ah... my fault... haven't remembered the +8 rule... I am using most of the time "fullscreen" or "overscan" screens... Beyond Evil is the only one which uses 40 byte static screen... but mainly because of the C64 port... Quote Link to comment Share on other sites More sharing options...
paladina Posted February 24, 2010 Author Share Posted February 24, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? If you're in narrow mode, ANTIC will do 40 byte lines if HSCRL is enabled (bit 4 of DL). Here's some code to prove it: 10 GRAPHICS 8 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,159:DR. 257,159:DR. 2,0 60 ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 The only problem is display starts at 2,0 and goes to 257,0 and that's with horizontal scroll register set to 15 color clocks. Scroll is being done without VBI so there's some jerkiness. I think this ist the best way, but I need this in gr 24 (no text window down) and for second, what is the screen adress?? In this program is good that I can use TEXT and PLOT, but how to load picture direct do screen memory? (as in my exaple at start of this topic) thx to every one Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 24, 2010 Share Posted February 24, 2010 Screen address as usual is PEEK(88)+PEEK(89)*256 The problem with loading picture is that if your pic is based on 32 byte width, it won't display properly in the 40 byte mode. You could either redo the pic for 40 byte mode, leaving blank area 32 pixels either side, or have an I/O routine that reads 32 bytes, skips 8, then repeats. If you're dealing with full-screen (no text window), then you can just adjust the loop accordingly. Instead of T TO 166, you'll probably need 198. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 24, 2010 Share Posted February 24, 2010 10 gr. 24 20 scr=dpeek(88) 30 open#1,4,0,"d:filename.pic" 40 i=0 50 repeat 60 bget #1,scr,32 70 bget #1,$0600,8 80 scr=scr+40 90 i=i+1 100 until i=192 110 close#1 999 do:loop Quote Link to comment Share on other sites More sharing options...
atariksi Posted February 24, 2010 Share Posted February 24, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? If you're in narrow mode, ANTIC will do 40 byte lines if HSCRL is enabled (bit 4 of DL). Here's some code to prove it: 10 GRAPHICS 8 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,159:DR. 257,159:DR. 2,0 60 ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 The only problem is display starts at 2,0 and goes to 257,0 and that's with horizontal scroll register set to 15 color clocks. Scroll is being done without VBI so there's some jerkiness. I think this ist the best way, but I need this in gr 24 (no text window down) and for second, what is the screen adress?? In this program is good that I can use TEXT and PLOT, but how to load picture direct do screen memory? (as in my exaple at start of this topic) thx to every one As Rybags suggested, use T ending at 198 for fullscreen. Here's a modified version that does it for you: 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Screen address of graphics memory is at $8150 (assuming a 48K+ RAM Atari); that's 33104 decimal. It's at location PEEK(DL+4) and PEEK(DL+5) in little endien (LSB,MSB) format if you're making this work on all Ataris <48K or >=48K. Quote Link to comment Share on other sites More sharing options...
atariksi Posted February 24, 2010 Share Posted February 24, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? If you're in narrow mode, ANTIC will do 40 byte lines if HSCRL is enabled (bit 4 of DL). Here's some code to prove it: 10 GRAPHICS 8 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,159:DR. 257,159:DR. 2,0 60 ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 The only problem is display starts at 2,0 and goes to 257,0 and that's with horizontal scroll register set to 15 color clocks. Scroll is being done without VBI so there's some jerkiness. I think this ist the best way, but I need this in gr 24 (no text window down) and for second, what is the screen adress?? In this program is good that I can use TEXT and PLOT, but how to load picture direct do screen memory? (as in my exaple at start of this topic) thx to every one As Rybags suggested, use T ending at 198 for fullscreen. Here's a modified version that does it for you: 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Screen address of graphics memory is at $8150 (assuming a 48K+ RAM Atari); that's 33104 decimal. It's at location PEEK(DL+4) and PEEK(DL+5) in little endien (LSB,MSB) format if you're making this work on all Ataris <48K or >=48K. 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO TEND:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Forgot to put TEND in the FOR loop. Quote Link to comment Share on other sites More sharing options...
paladina Posted March 18, 2010 Author Share Posted March 18, 2010 (edited) Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? If you're in narrow mode, ANTIC will do 40 byte lines if HSCRL is enabled (bit 4 of DL). Here's some code to prove it: 10 GRAPHICS 8 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,159:DR. 257,159:DR. 2,0 60 ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 The only problem is display starts at 2,0 and goes to 257,0 and that's with horizontal scroll register set to 15 color clocks. Scroll is being done without VBI so there's some jerkiness. I think this ist the best way, but I need this in gr 24 (no text window down) and for second, what is the screen adress?? In this program is good that I can use TEXT and PLOT, but how to load picture direct do screen memory? (as in my exaple at start of this topic) thx to every one As Rybags suggested, use T ending at 198 for fullscreen. Here's a modified version that does it for you: 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Screen address of graphics memory is at $8150 (assuming a 48K+ RAM Atari); that's 33104 decimal. It's at location PEEK(DL+4) and PEEK(DL+5) in little endien (LSB,MSB) format if you're making this work on all Ataris <48K or >=48K. 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO TEND:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Forgot to put TEND in the FOR loop. Hello again, in this way I use the last DL, and load picture, but I need little more help to repair my DLI for colors, when I use it with this,then its crash. 200 FOR I=1536 TO 1562:READ D:POKE I,D:NEXT I› 210 DL=PEEK(560)+256*PEEK(561)› 220 FOR I=0 TO 14:READ B:POKE DL+B,143:NEXT I› 230 POKE 161,0:POKE 512,0:POKE 513,6:POKE 54286,192› 240 GOTO 240› 250 DATA 72,173,80,6,24,105,16,141,80,6,141,10,212,141› 255 DATA 24,208,201,240,208,5,169,0,141,80,6,104,64› 260 DATA 17,29,41,53,65,77,89,104,116,128,140,152,164,176,188› thx for help Edited March 18, 2010 by paladina Quote Link to comment Share on other sites More sharing options...
atariksi Posted March 18, 2010 Share Posted March 18, 2010 Another solution, although a bit wasteful with RAM - have a DList that has an LMS for every Mode F line, and have each line 40 bytes ahead of the last. That means the OS routines will still work. What about enabling horizontal scrolling, the display can be 32 bytes wide but the machine'll still be counting 40 per scanline and the original display list will know where to look i think...? does Antic not count 48 bytes then? If you're in narrow mode, ANTIC will do 40 byte lines if HSCRL is enabled (bit 4 of DL). Here's some code to prove it: 10 GRAPHICS 8 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,159:DR. 257,159:DR. 2,0 60 ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 The only problem is display starts at 2,0 and goes to 257,0 and that's with horizontal scroll register set to 15 color clocks. Scroll is being done without VBI so there's some jerkiness. I think this ist the best way, but I need this in gr 24 (no text window down) and for second, what is the screen adress?? In this program is good that I can use TEXT and PLOT, but how to load picture direct do screen memory? (as in my exaple at start of this topic) thx to every one As Rybags suggested, use T ending at 198 for fullscreen. Here's a modified version that does it for you: 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO 166:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Screen address of graphics memory is at $8150 (assuming a 48K+ RAM Atari); that's 33104 decimal. It's at location PEEK(DL+4) and PEEK(DL+5) in little endien (LSB,MSB) format if you're making this work on all Ataris <48K or >=48K. 1 MODE=24 2 TEND=166+(MODE>15)*32 10 GRAPHICS MODE 20 DL=PEEK(560)+256*PEEK(561) 30 FOR T=3 TO TEND:POKE T+DL,15+16 40 IF T=99 OR T=3 THEN POKE T+DL,79+16:T=T+2 50 NEXT T:POKE 559,33 55 C.1:PLOT 2,0:DR. 257,0:DR.0,191:DR. 257,191:DR. 2,0 60 IF MODE<16 THEN ?"PRESS BRK TO STOP SCROLL" 70 POKE 54276,ASC(CHR$(T)):T=T+1 80 FOR DELAY=1 TO 100:NEXT DELAY 90 GOTO 70 Forgot to put TEND in the FOR loop. Hello again, in this way I use the last DL, and load picture, but I need little more help to repair my DLI for colors, when I use it with this,then its crash. 200 FOR I=1536 TO 1562:READ D:POKE I,D:NEXT I› 210 DL=PEEK(560)+256*PEEK(561)› 220 FOR I=0 TO 14:READ B:POKE DL+B,143:NEXT I› 230 POKE 161,0:POKE 512,0:POKE 513,6:POKE 54286,192› 240 GOTO 240› 250 DATA 72,173,80,6,24,105,16,141,80,6,141,10,212,141› 255 DATA 24,208,201,240,208,5,169,0,141,80,6,104,64› 260 DATA 17,29,41,53,65,77,89,104,116,128,140,152,164,176,188› thx for help What's POKE 161,0 for in the above? DLI looks suboptimal; better to use 16 values instead of 15 and let adc #16 wrap around the color or use VCOUNT or self-modifying code and forget about ABS location at 1616. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.