gekido_ken Posted November 30, 2018 Share Posted November 30, 2018 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? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 30, 2018 Share Posted November 30, 2018 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 1 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted November 30, 2018 Share Posted November 30, 2018 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted November 30, 2018 Share Posted November 30, 2018 (edited) 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 November 30, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted December 1, 2018 Author Share Posted December 1, 2018 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 1, 2018 Share Posted December 1, 2018 (edited) 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 December 1, 2018 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted December 1, 2018 Author Share Posted December 1, 2018 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted December 1, 2018 Share Posted December 1, 2018 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? Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted December 1, 2018 Author Share Posted December 1, 2018 (edited) This is the Magellan project. Let see on buttom left the charset and the "zones" This is the result on TI99 in XB256... ...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 December 1, 2018 by gekido_ken 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 1, 2018 Share Posted December 1, 2018 (edited) 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 December 1, 2018 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted December 1, 2018 Share Posted December 1, 2018 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. Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted December 1, 2018 Author Share Posted December 1, 2018 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!!! Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted December 2, 2018 Author Share Posted December 2, 2018 That's all works....for now! Thanks to everybody! https://youtu.be/JrOzOLVGhkc 4 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 2, 2018 Share Posted December 2, 2018 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. 3 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted December 2, 2018 Share Posted December 2, 2018 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 2, 2018 Share Posted December 2, 2018 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. 3 Quote Link to comment Share on other sites More sharing options...
LASooner Posted December 5, 2018 Share Posted December 5, 2018 I ran into this exact same landmine when I made the Nightstalker splash screen. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.