Jump to content

Photo

xb256 - Limit charset definition?


16 replies to this topic

#1 gekido_ken OFFLINE  

gekido_ken

    Space Invader

  • 33 posts

Posted Fri Nov 30, 2018 7:00 AM

Hi!
I've a problem with xb256 charset.

 

I'm using Piropaint together with Magellan to develop a complex image for TI99, always falling within 256 characters.
But if the image conversion exceeds the character set beyond the "U1" zone on Magellan, the code released by Magellan is not fully respected and the drawing includes non-redefined characters but with the default charset.
The problem arises with Classic99. I do not know if the problem is also found on other emulators, but I do not care. I would like to continue on Classic99.
 
Some idea?
 
 


#2 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,832 posts
  • Location:Silver Run, Maryland

Posted Fri Nov 30, 2018 8:30 AM

 

Hi!
I've a problem with xb256 charset.

 

I'm using Piropaint together with Magellan to develop a complex image for TI99, always falling within 256 characters.
But if the image conversion exceeds the character set beyond the "U1" zone on Magellan, the code released by Magellan is not fully respected and the drawing includes non-redefined characters but with the default charset.
The problem arises with Classic99. I do not know if the problem is also found on other emulators, but I do not care. I would like to continue on Classic99.
 
Some idea?

 

I'm on the road, so can't check the manual, but XB does not use the entire 256 set of characters. 

 

...lee


  • RXB likes this

#3 Retrospect OFFLINE  

Retrospect

    Stargunner

  • 1,108 posts
  • Location:Wakefield, England

Posted Fri Nov 30, 2018 8:52 AM

When using Magellan make sure you set it to XB256 output, I think I saw some sort of option like that in there. By default it might be XB's 112 definable chars.



#4 RXB OFFLINE  

RXB

    River Patroller

  • 3,405 posts
  • Location:Vancouver, Washington, USA

Posted Fri Nov 30, 2018 5:55 PM

 

Hi!
I've a problem with xb256 charset.

 

I'm using Piropaint together with Magellan to develop a complex image for TI99, always falling within 256 characters.
But if the image conversion exceeds the character set beyond the "U1" zone on Magellan, the code released by Magellan is not fully respected and the drawing includes non-redefined characters but with the default charset.
The problem arises with Classic99. I do not know if the problem is also found on other emulators, but I do not care. I would like to continue on Classic99.
 
Some idea?
 
 

 

Normal version 110 XB only uses characters 30 to 143 at most.

RXB allows you characters 30 to 159 but when using characters above 143 will interfere with sprites if not careful.


Edited by RXB, Fri Nov 30, 2018 5:55 PM.


#5 gekido_ken OFFLINE  

gekido_ken

    Space Invader

  • Topic Starter
  • 33 posts

Posted Fri Nov 30, 2018 9:26 PM

I'm talking about XB256, not XB.
In Atariage's resource for TI99, it is explicitly stated that with XB256 it is possible to redefine 256 characters in screen2, and 28 sprites from the redefinition of the charset in screen1.
With Magellan set for XB256, the character sets are shown, each of 8, from L1 to L4, from 1 to 16 and from U1 to U12.
When I go to redefine the characters in the "Ux" sets, they are not displayed with the new pattern but with the one corresponding to the one from 1 to 16, but with a reverse character.


#6 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,275 posts
  • Location:Lansing, NY, USA

Posted Fri Nov 30, 2018 9:52 PM

In Atariage's resource for TI99, it is explicitly stated that with XB256 it is possible to redefine 256 characters in screen2, and 28 sprites from the redefinition of the charset in screen1.

 

This is exactly correct. (Why else would it be called XB256?) In the program 256DEMO  you can see 256 unique characters on the screen plus 28 double sized  and magnified sprites. 

I have never used Magellan, so I have no insight on how to use it with XB256, but I believe it can do what you want. Start by trying Retrospect's suggestion in post 3.


Edited by senior_falcon, Fri Nov 30, 2018 9:52 PM.


#7 gekido_ken OFFLINE  

gekido_ken

    Space Invader

  • Topic Starter
  • 33 posts

Posted Fri Nov 30, 2018 10:09 PM

This is exactly correct. (Why else would it be called XB256?) In the program 256DEMO  you can see 256 unique characters on the screen plus 28 double sized  and magnified sprites. 

I have never used Magellan, so I have no insight on how to use it with XB256, but I believe it can do what you want. Start by trying Retrospect's suggestion in post 3.

Magellan does nothing but export a listing for XB256 that defines the screen you designed, first defines the colorset, then the charset and applies everything through READ and DATA.
I have always used Magellan but I have never used a massive use of the charset, so I have never detected this problem.


#8 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,943 posts
  • Location:Denmark

Posted Sat Dec 1, 2018 1:12 AM

 

Hi!
I've a problem with xb256 charset.

 

I'm using Piropaint together with Magellan to develop a complex image for TI99, always falling within 256 characters.
But if the image conversion exceeds the character set beyond the "U1" zone on Magellan, the code released by Magellan is not fully respected and the drawing includes non-redefined characters but with the default charset.
The problem arises with Classic99. I do not know if the problem is also found on other emulators, but I do not care. I would like to continue on Classic99.
 
Some idea?

 

Perhaps you could post an example that shows the issue?



#9 gekido_ken OFFLINE  

gekido_ken

    Space Invader

  • Topic Starter
  • 33 posts

Posted Sat Dec 1, 2018 10:39 AM

This is the Magellan project. Let see on buttom left the charset and the "zones"

 

 

magellandraw.jpg

 

 

This is the result on TI99 in XB256...

 

result.jpg

 

 

 

 

...and this is the code generated by Magellan...

REM COLORSET DECLARATIONS

100 DATA -3,16,2,-2,2,16,-1,15,6,0,15,2,1,16,2,2,16,2,3,2,15,4,2,15
110 DATA 5,2,15,6,15,2,7,15,2,8,16,15,9,16,2,10,2,15,11,16,2,12,15,2
120 DATA 13,15,2,14,15,2,15,15,2,16,15,2,17,2,15,18,16,2

REM CHARACTER DATA

500 DATA 0,"EE484C484E000000",1,"FFFFFFFF0F0F0F0F",2,"F0F4F2F202023E20",3,"F0F4F2F2F2F2F2F2"
510 DATA 4,"0004030000000000",5,"2020E00000000000",6,"02423E0000000000",7,"08080C0A0C000000"
520 DATA 8,"7F3F1F0F07030100",9,"DF5F5FBF7FFFFFFF",10,"F1F7F3F7F7FFFFFF",11,"B7B7B7B7B1FFFFFF"
530 DATA 12,"B1B5B1B7B7FFFFFF",13,"1155157571FFFFFF",14,"F1F7F1FDF1FFFFFF",15,"B555115155FFFFFF"
540 DATA 16,"FF00FF0000000000",17,"0000000000000000",18,"0000000000000000",19,"0000000000000000"
550 DATA 20,"0000000000000000",21,"0000000000000000",22,"0000000000000000",23,"FF00FF0000000000"
560 DATA 24,"0000001000000000",25,"0000000001060B17",26,"0000007EC77FFFFF",27,"00000000C0F0E8E4"
570 DATA 28,"071F377F57DBFDFF",29,"3FDFEFD7D7EBE8E8",30,"F7FFFBFFFBFF7E00",31,"E2E2C48830C00000"
580 DATA 32,"0000000000000000",33,"88888888EE000000",34,"EEA8A8A8EE000000",35,"E0A0A0A0E0000000"
590 DATA 36,"E444444444000000",37,"EEAAEE22EE000000",38,"0A0A0A0A04000000",39,"EE8ACE8CEA000000"
600 DATA 40,"E484E424E4000000",41,"EAAAAEAEEA000000",42,"0E020E080E000000",43,"44A4A4A444000000"
610 DATA 44,"E0A0E0A0E0000000",45,"0F0F0F0F0F0F0F0F",46,"2020202020202020",47,"F2F2F2F2F2F2F2F2"
620 DATA 48,"F0E6D0C288A8A090",49,"001CC30000000000",50,"00007F3E1C180808",51,"0073000000000000"
630 DATA 52,"0FA7031B090D0D05",53,"3F1F1F373767C70F",54,"EEEDEBF7EFDFBF80",55,"817E7F7E7CB9FF00"
640 DATA 56,"A0A0A0A0A0A0A080",57,"000000000001000E",58,"0848D89810303070",59,"05050D0901290909"
650 DATA 60,"FEF303030307FDFB",61,"FFEFE087F7FFFFFF",62,"F5F5FAFAFDFDFEFE",63,"010182824245A5A5"
660 DATA 64,"6140C0C0C0808080",65,"FF00000000000000",66,"60606060C0C0C0C0",67,"0101000000000000"
670 DATA 68,"3E3E1F9F9F1F0F4F",69,"A7B75F5F5FAFAFAF",70,"FDFDFAFAF5F5EBEB",71,"5757EBEBF5F4FAFA"
680 DATA 72,"85808588904F30CF",73,"0100018244AB44FF",74,"4000402011EA11FF",75,"5000508804FA04FF"
690 DATA 76,"1501152341BE4CF3",77,"1515282850D0A0A0",78,"4040A0A050502828",79,"0202050502080D30"
700 DATA 80,"B080000000000080",81,"0101010202020910",82,"4040408080804020",83,"0202020101010204"
710 DATA 84,"8080804040409008",85,"0101000000000001",86,"4040A0A04010B00C",87,"3E2E7F5F5F7F5F2F"
720 DATA 88,"FF00FF0000000000",89,"0000000000000000",90,"0000000000000000",91,"0000000000000000"
730 DATA 92,"0000000000000000",93,"0000000000000000",94,"0000000000000000",95,"0000000000000000"
740 DATA 96,"EE8A8A8AEE000000",97,"EAAAEA8484000000",98,"E4A4E4C4A4000000",99,"EA8A8EAAEA000000"
750 DATA 100,"E040404040000000",101,"E42AEA8AE4000000",102,"444A4A4A44000000",103,"EE8ACE8C8A000000"
760 DATA 104,"0080C06030100008",105,"0D0D0E0E0E0E0E1E",106,"A290C1E7F8FFFFFF",107,"3877EF3FC0FF00FF"
770 DATA 108,"00FFFFFF00FF00FF",109,"07FBFDFD05FD05FF",110,"FFFFFF870178FEFE",111,"FFFFFFFFFFFF7F7F"
780 DATA 112,"EE888C88EE000000",113,"EE88E828EE000000",114,"AEA8A8AAEE000000",115,"E48A8EAAEA000000"
790 DATA 116,"0000000000000000",117,"0000000000000000",118,"0000000000000000",119,"0000000000000000"
800 DATA 120,"0002040505090908",121,"FF02040810204080",122,"EF5F5F5F5F5F5F5F",123,"F7F7F7F7F7F7D7D7"
810 DATA 124,"FAF2F2F2F2F6F6FE",125,"C402F8FCFCFCFCF9",126,"007C53542B291515",127,"0000FF00FFFFFFFE"
820 DATA 128,"373B5E4F40404090",129,"8FFE03FF00000000",130,"0F1FFFFF00000000",131,"FFFFF0FF00010FFF"
830 DATA 132,"ECCC7AF20282C2C1",133,"1C7C3CBCBCBC9858",134,"0000000000000101",135,"B40201060BF4B850"
840 DATA 136,"1F0000FF10AF9088",137,"FF3F00FF44AB4482",138,"3F3F00FF11EA1120",139,"FEFF00FF04FA0488"
850 DATA 140,"70E000FE41BE4123",141,"2040B068140F1D0A",142,"28285050A3AC536C",143,"020C33CC30C00000"
860 DATA 144,"70A0C11254A8A0A0",145,"0020180700000000",146,"000000FF00FF0000",147,"0000037800E00000"
870 DATA 148,"0E8503482A150505",149,"5826D90601000000",150,"14148A6A956D1A06",151,"000000000000031F"
880 DATA 152,"000000010FFFFFFF",153,"01003EFFFFFFFFFF",154,"C0FF00FFFFFFFFFF",155,"40E000FBFFFFFFFF"
890 DATA 156,"3F007FC0FFFFFFFF",157,"F000E7FFFFFFFFFF",158,"0000FEFFFFFFFFFF",159,"00003FFFFFFFFFFF"
900 DATA 160,"FFFF3F0000000000",161,"F0FFFC0000000000",162,"03FF010000000000",163,"FDF8FF0000000000"
910 DATA 164,"FC00FF0000000000",165,"FF7FFF3F00000000",166,"FFFFFFFFFF030000",167,"FFFFFFFFFFFF1F01"
920 DATA 168,"FFFFFFFFFFFFFFFF",169,"0103070F1F3F7FFF",170,"0000000000000000",171,"0000000000000000"
930 DATA 172,"0000000000000000",173,"0000000000000000",174,"0000000000000000",175,"0000000000000000"

REM MAP DATA

REM MAP #1
REM MAP #1 WIDTH, HEIGHT, SCREEN COLOR
900 DATA 32,24,1
REM MAP #1 DATA
910 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
920 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
930 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
940 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
950 DATA 32,8,32,1,2,3,32,168,168,8,32,32,32,8,32,169
960 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
970 DATA 32,88,32,45,46,47,32,88,32,32,32,32,32,88,88,88
980 DATA 32,32,32,32,32,32,32,24,32,32,32,61,32,32,32,32
990 DATA 116,16,116,4,5,6,116,16,16,32,32,32,116,16,16,16
1000 DATA 116,32,32,32,32,32,32,32,32,32,32,32,32,32,24,32
1010 DATA 32,17,32,32,32,32,32,17,32,32,32,32,32,17,32,17
1020 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1030 DATA 32,19,19,19,117,16,117,19,19,19,117,16,117,19,32,19
1040 DATA 117,16,117,32,32,32,32,32,32,32,32,32,32,32,32,32
1050 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1060 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1070 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1080 DATA 32,32,32,32,32,32,32,24,32,32,32,32,32,32,32,32
1090 DATA 32,32,32,32,96,97,98,99,100,101,102,32,32,32,32,32
1100 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,24,32
1110 DATA 32,32,7,9,10,11,12,13,14,15,0,33,34,35,32,32
1120 DATA 32,32,32,25,26,27,32,32,32,32,32,32,32,32,32,32
1130 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1140 DATA 32,32,32,87,104,105,32,32,32,32,32,24,32,32,32,32
1150 DATA 32,32,32,36,37,38,39,40,41,42,43,44,32,32,32,32
1160 DATA 32,32,28,29,30,31,32,32,32,32,32,32,32,32,32,32
1170 DATA 32,32,32,7,9,103,15,112,113,35,114,115,32,32,32,32
1180 DATA 32,32,106,107,108,109,110,111,32,32,32,32,32,32,32,32
1190 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,24,32,32
1200 DATA 32,32,48,49,50,51,52,53,32,32,32,32,32,32,32,32
1210 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1220 DATA 120,121,122,89,123,89,124,125,32,32,24,32,32,32,32,32
1230 DATA 32,32,24,32,32,32,32,32,32,24,32,32,32,32,32,32
1240 DATA 54,55,56,57,58,89,59,60,32,32,32,32,32,61,32,32
1250 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1260 DATA 126,127,128,129,130,131,132,133,32,32,32,32,32,32,32,32
1270 DATA 32,32,32,61,32,32,32,32,32,32,32,32,32,32,32,32
1280 DATA 62,63,64,65,66,67,68,69,32,32,32,32,32,32,32,24
1290 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,24,32
1300 DATA 134,135,136,137,138,139,140,141,111,32,32,24,32,32,32,32
1310 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1320 DATA 70,71,72,73,74,75,76,77,78,32,32,32,32,32,32,32
1330 DATA 32,32,32,32,32,32,24,32,32,32,32,32,32,32,32,134
1340 DATA 142,143,144,145,146,147,148,149,150,111,32,32,32,32,24,32
1350 DATA 24,32,32,32,32,32,32,32,32,32,24,32,32,32,32,79
1360 DATA 80,81,82,32,32,32,83,84,85,86,32,32,32,32,24,32
1370 DATA 32,24,32,32,32,32,32,32,32,32,32,32,151,152,153,154
1380 DATA 155,156,157,158,159,160,161,162,163,164,165,166,167,32,32,32

1390 CALL LINK("SCRN2")

REM LOAD COLORSET

1400 RESTORE 100::FOR C=1 TO 22::READ CS,CF,CB::CALL LINK("COLOR2",CS,CF,CB)::NEXT C

REM LOAD CHARACTERS

1410 RESTORE 500::FOR C=1 TO 176::READ CN,CC$::CALL LINK("CHAR2",CN,CC$)::NEXT C

REM DRAW MAP(S)

1420 CALL CLEAR
1430 RESTORE 900
1440 READ W,H,SC::CALL SCREEN(SC)::CALL CLEAR
1450 FOR Y=1 TO H
1460 FOR X=1 TO W
1470 READ CP::CALL VCHAR(Y,X,CP)
1480 NEXT X
1490 NEXT Y
1500 CALL KEY(0,K,S)::IF S=0 THEN 1500
1510 END


Edited by gekido_ken, Sat Dec 1, 2018 10:50 AM.


#10 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,275 posts
  • Location:Lansing, NY, USA

Posted Sat Dec 1, 2018 3:15 PM

It took me a while to find this, but the answer is simple. Here is part of your code from above:

890 DATA 156,"3F007FC0FFFFFFFF",157,"F000E7FFFFFFFFFF",158,"0000FEFFFFFFFFFF",159,"00003FFFFFFFFFFF"
900 DATA 160,"FFFF3F0000000000",161,"F0FFFC0000000000",162,"03FF010000000000",163,"FDF8FF0000000000"
910 DATA 164,"FC00FF0000000000",165,"FF7FFF3F00000000",166,"FFFFFFFFFF030000",167,"FFFFFFFFFFFF1F01"
920 DATA 168,"FFFFFFFFFFFFFFFF",169,"0103070F1F3F7FFF",170,"0000000000000000",171,"0000000000000000"
930 DATA 172,"0000000000000000",173,"0000000000000000",174,"0000000000000000",175,"0000000000000000"

REM MAP DATA

REM MAP #1
REM MAP #1 WIDTH, HEIGHT, SCREEN COLOR
900 DATA 32,24,1
REM MAP #1 DATA
910 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
920 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
930 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
940 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32

900 to 930 is overwritten by the map data. If you change the first lines 900 - 930  so they are 891 - 894 then the image is created properly.

 

This screen is a good candidate for using compressed data statements which are more compact and can create the screen in about 1 second in XB.


Edited by senior_falcon, Sat Dec 1, 2018 3:18 PM.


#11 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,943 posts
  • Location:Denmark

Posted Sat Dec 1, 2018 3:37 PM

You can specify the Map Data Line Number Start in Magellan when you do the export. You would expect that it suggested valid values automatically, but no.  :)  



#12 gekido_ken OFFLINE  

gekido_ken

    Space Invader

  • Topic Starter
  • 33 posts

Posted Sat Dec 1, 2018 4:08 PM

It took me a while to find this, but the answer is simple. Here is part of your code from above:

890 DATA 156,"3F007FC0FFFFFFFF",157,"F000E7FFFFFFFFFF",158,"0000FEFFFFFFFFFF",159,"00003FFFFFFFFFFF"
900 DATA 160,"FFFF3F0000000000",161,"F0FFFC0000000000",162,"03FF010000000000",163,"FDF8FF0000000000"
910 DATA 164,"FC00FF0000000000",165,"FF7FFF3F00000000",166,"FFFFFFFFFF030000",167,"FFFFFFFFFFFF1F01"
920 DATA 168,"FFFFFFFFFFFFFFFF",169,"0103070F1F3F7FFF",170,"0000000000000000",171,"0000000000000000"
930 DATA 172,"0000000000000000",173,"0000000000000000",174,"0000000000000000",175,"0000000000000000"

REM MAP DATA

REM MAP #1
REM MAP #1 WIDTH, HEIGHT, SCREEN COLOR
900 DATA 32,24,1
REM MAP #1 DATA
910 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
920 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
930 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
940 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32

900 to 930 is overwritten by the map data. If you change the first lines 900 - 930  so they are 891 - 894 then the image is created properly.

 

This screen is a good candidate for using compressed data statements which are more compact and can create the screen in about 1 second in XB.

 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARRRRGHHHHHHHHHHHHHHHHH!!!!!!!!!     I'm DOOOOONK!!!!!!! 

Thanks!!! :P



#13 gekido_ken OFFLINE  

gekido_ken

    Space Invader

  • Topic Starter
  • 33 posts

Posted Sat Dec 1, 2018 6:10 PM

That's all works....for now!

Thanks to everybody!

 



#14 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,275 posts
  • Location:Lansing, NY, USA

Posted Sat Dec 1, 2018 10:51 PM

I'm not sure whether the program you compiled is the program listed in post #9 or whether you used compressed data statements. If you are not using them, here are some numbers that should convince you that compressed data statements are very useful:

 

Your program in post #9 uses 9358 bytes and takes 60 seconds to create the image.

 

After converting that to use compressed data statements the new program uses 1702 bytes and takes about 1 second to create the image. This is all while running in Extended BASIC!

 

After it is compiled, this program takes less than 1/4 second to create the image. As noted in another thread, with speeds like this there is hardly any need to blank the screen.



#15 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,169 posts
  • Location:Denmark

Posted Sun Dec 2, 2018 2:29 AM

Your program in post #9 uses 9358 bytes ...

 

After converting that to use compressed data statements the new program uses 1702 bytes ...

  

I seem to remember that you're getting rather good compression with XB256. Which method are you using? :)



#16 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,275 posts
  • Location:Lansing, NY, USA

Posted Sun Dec 2, 2018 9:08 AM

  

I seem to remember that you're getting rather good compression with XB256. Which method are you using? :)

I don't know anything about computers, so I came up with this method on my own, but I understand that it is a type of RLE compression. The data statements start with a two byte memory address that tells CWRITE where to write to in VDP ram.  Then there is a length byte. If it is 10 then the next 10 bytes are send to VDP ram. If it is -10 then the next byte is sent to VDP ram 10 times. Then another length byte, and so on until CWRITE is at the end of the string. This is fast but very simple. If there is a lot of repetition then there is a good amount of compression. If there is not much repetition then there is not much compression. So a screen with a lot of spaces would be much shorter; character definitions not so much.

 

Here's where most of the gain comes from:

 

10 DATA 32,32,32,112 - Each byte takes 4 or 5 bytes in the data statement - a comma, a length byte, and 2 or 3 bytes following the length byte. When that value is in VDP memory it is only 1 byte.

 

10 CALL CHAR(65,"0123456789ABCDEF") - CALL CHAR and the character number take up something like 15 bytes and then the hex string uses 16 bytes to change 8 bytes in the pattern table.

 

So you can see that even with no compression there would be considerable memory savings.



#17 LASooner OFFLINE  

LASooner

    Moonsweeper

  • 308 posts

Posted Wed Dec 5, 2018 5:01 AM

I ran into this exact same landmine when I made the Nightstalker splash screen.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users