Jump to content
paladina

HI MEMORY GRAPHICS 8

Recommended Posts

Hello,

 

ok I need some help with correction of Display List,I cannot find the correct adress to do right poke. Its Graphics 24 (8) 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

post-24943-126692900916_thumb.jpg

post-24943-126692901529_thumb.jpg

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by analmux

Share this post


Link to post
Share on other sites

POKE 41114,16:POKE 41115,173

 

.. but there will be "4k boundary crap", as Heaven said, in 118th scan line

Edited by pavros

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by raster/c.p.u.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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... :D

Share this post


Link to post
Share on other sites

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) :D thx to every one :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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



Share this post


Link to post
Share on other sites

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) :D thx to every one :D

 

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.

Share this post


Link to post
Share on other sites

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) :D thx to every one :D

 

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.

Share this post


Link to post
Share on other sites

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) :D thx to every one :D

 

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 :D

Edited by paladina

Share this post


Link to post
Share on other sites

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) :D thx to every one :D

 

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 :D

 

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.

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...