+mizapf Posted March 18, 2015 Share Posted March 18, 2015 I need the specification of the Extended Basic "long format" (INT/VAR 254). Although I can list files in TIImageTool in that format, it is not yet complete. This is the beginning of such a file: 000000: 0a ab cd c5 38 ca 2b f0 ed ff e7 ff 00 10 00 11 ....8.+......... 000010: 00 12 00 03 00 13 00 04 00 05 00 06 00 07 00 08 ................ 000020: 00 09 00 0a 00 14 00 15 00 00 00 00 00 00 00 00 ................ 000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000100: fe 2f 26 cc 55 2f 1c cc 61 2f 12 cc 69 2f 08 cc ./&.U/..a/..i/.. 000110: 7e 2e fe cb ef 2e f4 cc a4 2e ea cc 16 2e e0 cc ~............... 000120: bd 2b 52 ca 3e 2b 48 ca 4e 2b 3e ca 6a 2b 34 ca .+R.>+H.N+>.j+4. ... So the first bytes look like this: 0x0A, 0xABCD, start of Line Number Table, end of LNT, checksum (-(start XOR end)), memtop But in this first record we then have 0xFF, 0x0010, 0x0011, ..., whose meaning is unclear to me. Do we have some more information on that? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 18, 2015 Author Share Posted March 18, 2015 (edited) Never mind ... I guess I found it. Some sleep seems to be a good way to solve problems ... when I lay in bed this morning I thought "oh no, that's a FILE, not a PROGRAM, so ..." 0A = length of record First record: ABCD, startLNT, endLNT, Checksum, Memtop (10 bytes) FF = last record in this sector; all following bytes are ignored (never read) offset 100: FE = length of record 2F 26 CC ... Bytes of record ... The reason for this "last record marker" in the first sector is simply that the first record has 10 bytes, and the following record has 254 bytes, which do not fit into one sector, and records cannot cross sectors. The bytes I mentioned above are just some remainders from an earlier operation. Edit: And while we're at it, the values starting at offset 0x101 are the line number table: Line number 0x2F26 (12070) is at address 0xCC55 Line number 0x2F1C (12060) is at address 0xCC61 Line number 0x2F12 (12050) is at address 0xCC69 ... So the long format is basically the same as the normal format, except that the addresses refer to CPU RAM locations, not VDP RAM locations. Edit2: What I also found interesting is that the BASIC program lines in memory are ordered as they were typed in, not by their line number. The ordering according to the line number is up to the line number table only. It would be too inefficient to move large memory blocks in order to insert a line that was added later, considering that there is a table which already sorts them. Edit3: The checksum can be negated which turns on the Extended Basic LIST protection. As it seems, the example shown above happened to be LIST-protected. The standard calculation would be startLNT XOR endLNT. Edited March 18, 2015 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
HackMac Posted March 18, 2015 Share Posted March 18, 2015 Yes, you are the one! This file format is on my list to investigate to. The TiDisk-Manager have to know this format too. But currently the work on my tool is paused, because the summer brings me out side and I do a lot of work in the garden (I think the Yanks says back yard). I'm looking forward to a new post on ninerpedia. Thank you, Michael! Quote Link to comment Share on other sites More sharing options...
RXB Posted March 18, 2015 Share Posted March 18, 2015 I have posted the GPL source code on how XB does this. (And RXB source too.) RXB 2015 has a new feature: (EXAMPLE) SAVE DSK2.XBPGMTEST,IV254 Works just like: SAVE DSK2.XBPGMTEST,MERGE But loads into normal XB just like Program Image does. Cataloging XB Programs will be much more easy to see and not confuse XB Program Image with EA Program Image files. 2 Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 22, 2015 Share Posted June 22, 2015 (edited) Let's raise this again ... I'm currently implementing the long XB format as well, and I thought I understood the layout. But when I create a small test program using TI Image Tool neither MESS nor Classic99 will load it: >OLD DSK1.LXB * I/O ERROR 20 The raw program data looks like this (including the record length bytes): 00000000 0a ab cd ff c6 ff d1 00 17 ff e7 22 00 1e ff d3 |..........."....| 00000010 00 14 ff d7 00 0a ff dc 03 96 49 00 04 9c 49 b3 |..........I...I.| 00000020 00 0c 8c 49 be c8 01 31 b1 c8 02 31 30 00 |...I...1...10.| Other long programs from, say, the TI Game Shelf do work, however. Is there an actual minimum size requirement for long programs? Or what's the missing piece here? lxb.dsk Edited June 22, 2015 by ralphb Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 22, 2015 Author Share Posted June 22, 2015 Thanks for pointing out the issue. This is indeed a bug. The issue is that your BASIC program is too short. When it is long enough to take more than one sector, there won't be any problem. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 23, 2015 Share Posted June 23, 2015 (edited) Let's raise this again ... I'm currently implementing the long XB format as well, and I thought I understood the layout. But when I create a small test program using TI Image Tool neither MESS nor Classic99 will load it: >OLD DSK1.LXB * I/O ERROR 20 The raw program data looks like this (including the record length bytes): 00000000 0a ab cd ff c6 ff d1 00 17 ff e7 22 00 1e ff d3 |..........."....| 00000010 00 14 ff d7 00 0a ff dc 03 96 49 00 04 9c 49 b3 |..........I...I.| 00000020 00 0c 8c 49 be c8 01 31 b1 c8 02 31 30 00 |...I...1...10.| Other long programs from, say, the TI Game Shelf do work, however. Is there an actual minimum size requirement for long programs? Or what's the missing piece here? lxb.dsk You are correct. Here is the RXB data on: SAVE DSK2.TESTPGM,IV254 (This only works in RXB 2015 and no other XB has this feature.) From page 6 RXB 2015 E manual: SAVE FILES IN INTERNAL VARIABLE 254 OR PROGRAM IMAGE FORMAT _______________________________________________________________ RXB allows XB programs to load or be saved in two formats as previously, but now RXB allows more control of this feature. Normally XB will save files in Program Image format if these programs are small enough to fit in VDP memory. If these XB programs are larger then what will fit in VDP then XB programs will be saved in Internal Variable 254 format. RXB has a added feature added to save command. IV254 is the new feature. EXAMPLE: SAVE DSK3.TEST,IV254 This is from RXB 2015 E page S1 : SAVE command PAGE S1 ------------------------------------------------------------- Format SAVE DSK3.PRGM SAVE DSK2.PRGM,IV254 Description The SAVE command functions normally to save XB programs. An additional freature is IV254 may be specified after the SAVE command to convert to Internal Variable 254 format. The IV254 format makes it much more easy to tell an XB program from EA programs when cataloging a disk. Internal Variable files do take up one sector more then XB program format. It should be noted that XB programs smaller then 3 sectors can not be saves in IV254 format. Command Saves to DISK 2 in XB program | >SAVE DSK2.TEST image format TEST | | Saves to disk 3 in XB program | >sAVE DSK3.STUFF,IV254 Internal Variable 254 named | STUFF | | Saves to WDS1 in dirctory EXB | >SAVE WDS1.EXB.RB,IV254 XB program Internal Variable | 254 named RB | | | Options Allows better cataloging options for saving XB files. (As you can see above any program has to have a minimum size or can not be saved in IV254 format.) Edited June 23, 2015 by RXB 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 23, 2015 Share Posted June 23, 2015 At one time in RXB 2015 E I thought I could pad a file with zeros so any file could be saved in IV254 format, but OLD would have to be modified also in exchange for this feature. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 23, 2015 Share Posted June 23, 2015 Take a look at the topic "IV254" for a discussion about this format. There is a utility in post #21 that will save in IV254 format; if the program is too short it will be padded so as to force a save in IV254 format. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 23, 2015 Share Posted June 23, 2015 The issue is that your BASIC program is too short. When it is long enough to take more than one sector, there won't be any problem. OK, thanks for all the hints, that explains it. Padding is simple enough, so that problem is solved. But unfortunately the loader doesn't really do what I expected, i.e., it doesn't store the program at the address specified in the header. From my observation it seems that the file is loaded as-is at address >A040 and then copied again in memory so that it ends at >FFE7, adjusting the pointers in the line number table on the way. I was hoping for a simple way to to place stuff where I want, but it seems like I need to do another manual move. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 23, 2015 Share Posted June 23, 2015 What is it that you want to do? Why do you care where the program is kept? There is something you are not telling us..... Quote Link to comment Share on other sites More sharing options...
RXB Posted June 24, 2015 Share Posted June 24, 2015 OK, thanks for all the hints, that explains it. Padding is simple enough, so that problem is solved. But unfortunately the loader doesn't really do what I expected, i.e., it doesn't store the program at the address specified in the header. From my observation it seems that the file is loaded as-is at address >A040 and then copied again in memory so that it ends at >FFE7, adjusting the pointers in the line number table on the way. I was hoping for a simple way to to place stuff where I want, but it seems like I need to do another manual move. Well RXB has CALL MOVES("RR",NUMBYTES,FROMADDRESS,TOADDRESS) or CALL MOVES("V$",NUMBYTES,VDPADDRESS,VARIABLE$) or CALL MOVES("GR",NUMBYTES,GROMADDRESS,RAMADDRESS) G=GROM/GRAM ADDRESS R=RAM ADDRESS V=VDP ADDRESS $=STRING VARIABLE I know this would not work in normal XB but then everything is so complicated to do in normal XB. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 25, 2015 Share Posted June 25, 2015 What is it that you want to do? Why do you care where the program is kept? There is something you are not telling us..... Well, I was adding a feature to my xas99 cross-assembler to embed the generated code in an Extended BASIC program. (There are, of course, quite a few tools which do that already.) When compiling the code myself I can relocate it so that it fits the upper end of the XB token table, and everything works fine. But for arbitrary, existing images I cannot coax the XB loader into placing the tokens where I want them. And fudged header data is noticed by the loader and results in an I/O Error. If it were an actually useful feature I'd add some code to move the image from the token table to the final destination, but it's been more of a plaything anyway ... Quote Link to comment Share on other sites More sharing options...
RXB Posted June 25, 2015 Share Posted June 25, 2015 Well, I was adding a feature to my xas99 cross-assembler to embed the generated code in an Extended BASIC program. (There are, of course, quite a few tools which do that already.) When compiling the code myself I can relocate it so that it fits the upper end of the XB token table, and everything works fine. But for arbitrary, existing images I cannot coax the XB loader into placing the tokens where I want them. And fudged header data is noticed by the loader and results in an I/O Error. If it were an actually useful feature I'd add some code to move the image from the token table to the final destination, but it's been more of a plaything anyway ... In order to do this you are going to have to modify the XB ROMs as the Tables are hardcoded to be at a certain location. So not only would GPL in XB have to be modified but ROM also. A few routines in ROM do this in XB GPL code: *********************************************************** [0060] * Equates for XMLs [0061] 0000 SYNCHK EQU >00 SYNCHK XML selector [0062] 0003 SEETWO EQU >03 SEETWO XML selector [0063] 0070 COMPCT EQU >70 PREFORM A GARBAGE COLLECTION [0064] 0072 MEMCHK EQU >72 MEMORY check routine: VDP [0065] 0074 PARSE EQU >74 Parse a value 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0002 EQUATES EDIT-359 [0066] 0077 VPUSH EQU >77 Push on value stack [0067] 0078 VPOP EQU >78 Pop off value stack [0068] 0079 PGMCHR EQU >79 GET PROGRAM CHARACTER [0069] 007A SYM EQU >7A Find Symbol entry [0070] 007B SMB EQU >7B Find Symbol table entry [0071] 007D SCHSYM EQU >7D Search symbol table [0072] 007E SPEED EQU >7E SPEED UP XML [0073] 007F CRUNCH EQU >7F Crunch an input line [0074] 0081 CONTIN EQU >81 Continue after a break [0075] 0083 SCROLL EQU >83 SCROLL THE SCREEN [0076] 0084 IO EQU >84 IO utility (KW table search) [0077] 0085 GREAD EQU >85 READ DATA FROM ERAM [0078] 0086 GWRITE EQU >86 WRITE DATA TO ERAM [0079] 0087 DELREP EQU >87 REMOVE CONTENT FROM VDP/ERAM [0080] 0088 MVDN EQU >88 MOVE DATA IN VDP/ERAM [0081] 0089 MVUP EQU >89 MOVE DATA IN VDP/ERAM [0082] 008A VGWITE EQU >8A MOVE DATA FROM VDP TO ERAM [0083] 008B GVWITE EQU >8B WRITE DATA FROM GRAM TO VRAM [0084] 008E GDTECT EQU >8E ERAM DETECT&ROM PAGE 1 ENABLE [0085] 008F SCNSMT EQU >8F SCAN STATEMENT FOR PRESCAN [0086] *********************************************************** COMPCT, SYM, SMB, SCHSYM and some others are all hard coded. (Sorry this is your problem.) Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 26, 2015 Share Posted June 26, 2015 Well, I was adding a feature to my xas99 cross-assembler to embed the generated code in an Extended BASIC program. (There are, of course, quite a few tools which do that already.) When compiling the code myself I can relocate it so that it fits the upper end of the XB token table, and everything works fine. But for arbitrary, existing images I cannot coax the XB loader into placing the tokens where I want them. And fudged header data is noticed by the loader and results in an I/O Error. If it were an actually useful feature I'd add some code to move the image from the token table to the final destination, but it's been more of a plaything anyway ... I don't know what you mean by the "XB token table" or "arbitrary, existing images" - can you clarify these terms? Anyway, let's start at the beginning. If I understand you correctly you are trying to get the cross assembler to embed an assembly language program into an XB program, presumably so you can easily load and run it via XB. As you noted there are several loaders that can do this but as far as I know they all require that you go to the TI and create the program using XB and then save it from XB. One example is HMLOADER which is part of The Missing Link package. This lets you embed up to 24K of assembly in an XB program. But it sounds like you want to create and save the XB program directly from the assembler, bypassing the need to load the assembly code with the s..l..o..w.. CALL LOAD assembly loader in XB. If you use relocatable code (no AORGs) and assuming xas99 can compute the addresses of the labels the same way CALL LOAD would, then this should not be too difficult. To create the file you'd have to figure a starting address for the A/L code so that it ends at >FFE7 and then add a 1 line XB program ahead of that to start up the code, then save the file to disk. Let me know if I understand you correctly and we can go from there - no point in taking a lot of time answering the wrong question. 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 26, 2015 Share Posted June 26, 2015 If I understand you correctly you are trying to get the cross assembler to embed an assembly language program into an XB program, presumably so you can easily load and run it via XB. Let me know if I understand you correctly and we can go from there - no point in taking a lot of time answering the wrong question. Yes, you're spot on, that's exactly what I'm doing. But I already integrated it into the xas99 assembler, pretty much in the way you outlined in your post, so there aren't really any open questions left. I was merely musing how convenient it would have been if the XB loader could have been made to place the code at arbitrary positions, because then you could have embedded AORG'ed code or precompiled code ("arbitrary, existing images") as well. Of course you can still do that if you embed an additional routine that will move the embedded code to its real position before executing it, but I haven't bothered to implement that. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 26, 2015 Share Posted June 26, 2015 Look like I get to take the weekend off! Glad that you could work it out. For what it's worth, I think the XB loader would work if you saved the entire high memory, but I don't think you could quite get to >A000 and you'd have to save all the way to >FFE7. Not very efficient if you only want to save 1k starting at >B000. 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 26, 2015 Share Posted June 26, 2015 Never mind ... I guess I found it. Some sleep seems to be a good way to solve problems ... when I lay in bed this morning I thought "oh no, that's a FILE, not a PROGRAM, so ..." 0A = length of record First record: ABCD, startLNT, endLNT, Checksum, Memtop (10 bytes) FF = last record in this sector; all following bytes are ignored (never read) Actually I was also thrown off track with INT/VAR (and INT/FIX), because my Extended BASIC sample programs 100 A$="ABCDEFGHIJKLMNOPQRSTUVWXYZ" 110 OPEN #1:"DSK1.INTVAR63",OUTPUT,INTERNAL,FIXED 63 120 PRINT #1:SEG$(A$,1,20) ... yielded tiger ~/xdt99 > xdm99.py w.dsk -S 0x2a 00: 14 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F .ABC DEFG HIJK LMNO 10: 50 51 52 53 54 00 00 00 00 00 00 00 00 00 00 00 PQRS T... .... .... 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... .... .... .... on disk. I was assuming that the first data byte indicates how long the record is, so for INT/VAR this would be 00: 15 14 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E ..AB CDEF GHIJ KLMN 10: 4F 50 51 52 53 54 0B 0A 42 43 44 45 46 47 48 49 OPQR ST.. BCDE FGHI 20: 4A 4B 15 14 43 44 45 46 47 48 49 4A 4B 4C 4D 4E JK.. CDEF GHIJ KLMN But obviously this must be an artifact of writing Extended BASIC strings in INT mode, not a general feature of INT records. Otherwise the start of long BASIC programs 000000: 0a ab cd c5 38 ca 2b f0 ed ff e7 ... wouldn't make sense ... I should probably read more documentation rather than try to reverse-engineer stuff ... Quote Link to comment Share on other sites More sharing options...
RXB Posted June 27, 2015 Share Posted June 27, 2015 Actually I was also thrown off track with INT/VAR (and INT/FIX), because my Extended BASIC sample programs 100 A$="ABCDEFGHIJKLMNOPQRSTUVWXYZ" 110 OPEN #1:"DSK1.INTVAR63",OUTPUT,INTERNAL,FIXED 63 120 PRINT #1:SEG$(A$,1,20) ... yielded tiger ~/xdt99 > xdm99.py w.dsk -S 0x2a 00: 14 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F .ABC DEFG HIJK LMNO 10: 50 51 52 53 54 00 00 00 00 00 00 00 00 00 00 00 PQRS T... .... .... 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... .... .... .... on disk. I was assuming that the first data byte indicates how long the record is, so for INT/VAR this would be 00: 15 14 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E ..AB CDEF GHIJ KLMN 10: 4F 50 51 52 53 54 0B 0A 42 43 44 45 46 47 48 49 OPQR ST.. BCDE FGHI 20: 4A 4B 15 14 43 44 45 46 47 48 49 4A 4B 4C 4D 4E JK.. CDEF GHIJ KLMN But obviously this must be an artifact of writing Extended BASIC strings in INT mode, not a general feature of INT records. Otherwise the start of long BASIC programs 000000: 0a ab cd c5 38 ca 2b f0 ed ff e7 ... wouldn't make sense ... I should probably read more documentation rather than try to reverse-engineer stuff ... If you could read GPL code RXB has the XB source code included. Any changes are noted with * RXB PATCH CODE then some note here on what it is ******** The Regular XB code is there but indented with * as the GPL Assembler ignores anything after * in Source Code INT/VAR 254 is in RXB TEXT lrxb4 (>8000->9FFF) in GROM This is the SAVE, SAVE INT/VAR 254 and MERGE souce code: *********************************************************** [2175] * SAVE STATEMENT [2176] * SAVE "NAME", MERGE : Save in crunched form in program [2177] * into a file one line at at time with the line number. [2178] * File opened with sequential accessed, variable-length [2179] * records (161 max), display type & output mode, move one [2180] * line number and one in text to the crunch buffer then [2181] * write to the file one line at a time. [2182] * A normal SAVE : When ERAM not exist or the size of the [2183] * program and line number table in ERAM can fit in VDP [2184] * (can be moved into VDP from ERAM once), then the save [2185] * statement saves a program image to an external device, [2186] * including all the information the system needs for [2187] * rebuilding the program image on a machine with a [2188] * different memory size, also included is a checksum for [2189] * rudimentary error checking and for PROTECTION VIOLATION [2190] * A sequential SAVE : Maximum-length records are performed [2191] * to write the file and each record is copied into the VDP [2192] * from ERAM before it is written. [2193] *********************************************************** [2194] 8DB8 DA,45,80 SAVE CLOG >80,@FLAG * PROTECTION VIOLATION [2195] 8DBB 57,DB BR ERRPV [2196] 8DBD 06,92,35 CALL GPNAME This will also close all file [2197] * Check SAVE "NAME", MERGE or SAVE "NAME", PROTECTED first [2198] 8DC0 86,A3,B9 CLR V@SAPROT Clear "PROTECTED" flag [2199] 8DC3 0F,79 XML PGMCHR [2200] 8DC5 8E,42 CZ @CHAT EOL? [2201] 8DC7 6E,2B BS SAZ1 Yes, no need to check any opt [2202] 8DC9 D6,42,B3 CEQ COMMAZ,@CHAT Has to be a comma here [2203] 8DCC 41,09 BR ERRSYN [2204] 8DCE D7,B0,2C DCEQ >C805,V*PGMPTR Unquoted string with length 5 8DD1 C8,05 [2205] * has to be MERGE at this time [2206] 8DD3 4D,F4 BR G8DF4 [2207] 8DD5 D7,E0,02 DCEQ >4D45,V@2(@PGMPTR) "ME" of MErge 8DD8 2C,4D,45 [2208] * RXB PATCH CODE OPTION ADDED IV254 FOR SAVE 2015 ********* [2209] * SAVE "DSK#.FILENAME",MERGE ! SAVE MERGE FORMAT [2210] * SAVE "DSK#.FILENAME",IV254 ! SAVE IV254 PROGRAM FORMAT [2211] * SAVE "DSK#.FILENAME" ! NORMAL PROGRAM FORMAT OR IV254 [2212] * BR ERRSYN If not : SYNTAX ERROR [2213] 8DDB 5F,7C BR CIV254 CHECK FOR IV254 OPTION [2214] 8DDD D7,E0,04 DCEQ >5247,V@4(@PGMPTR) "RG" of meRGe 8DE0 2C,52,47 [2215] 8DE3 41,09 BR ERRSYN If not : SYNTAX ERROR [2216] 8DE5 D6,E0,06 CEQ >45,V@6(@PGMPTR) "E" of mergE 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0039 FLMGR-359 8DE8 2C,45 [2217] 8DEA 41,09 BR ERRSYN If not : SYNTAX ERROR [2218] 8DEC 8E,E0,07 CZ V@7(@PGMPTR) Check for EOL 8DEF 2C [2219] 8DF0 41,09 BR ERRSYN Not EOL : SYNTAX ERROR [2220] 8DF2 4F,76 BR SAVMG Go to handle this option [2221] * Has to be PROTECTED option here, crunched as unquoted str [2222] 8DF4 D7,B0,2C G8DF4 DCEQ >C809,V*PGMPTR Unquoted string with length 9 8DF7 C8,09 [2223] * has to be PROTECTED [2224] 8DF9 41,09 BR ERRSYN [2225] 8DFB D7,E0,02 DCEQ >5052,V@2(@PGMPTR) "PR" of PRotected 8DFE 2C,50,52 [2226] 8E01 41,09 BR ERRSYN If not : SYNTAX ERROR [2227] 8E03 D7,E0,04 DCEQ >4F54,V@4(@PGMPTR) "OT" of prOTected 8E06 2C,4F,54 [2228] 8E09 41,09 BR ERRSYN If not : SYNTAX ERROR [2229] 8E0B D7,E0,06 DCEQ >4543,V@6(@PGMPTR) "EC" of protECted 8E0E 2C,45,43 [2230] 8E11 41,09 BR ERRSYN If not : SYNTAX ERROR [2231] 8E13 D7,E0,08 DCEQ >5445,V@8(@PGMPTR) "TE",of protecTEd 8E16 2C,54,45 [2232] 8E19 41,09 BR ERRSYN If not : SYNTAX ERROR [2233] 8E1B D6,E0,0A CEQ >44,V@10(@PGMPTR) "D" of protecteD 8E1E 2C,44 [2234] 8E20 41,09 BR ERRSYN If not : SYNTAX ERROR [2235] 8E22 8E,E0,0B CZ V@11(@PGMPTR) Check EOL 8E25 2C [2236] 8E26 41,09 BR ERRSYN [2237] 8E28 90,A3,B9 INC V@SAPROT [2238] *********************************************************** [2239] 8E2B 8E,80,84 SAZ1 CZ @RAMTOP If ERAM NOT present then [2240] 8E2E 4E,42 BR G8E42 [2241] ***** CLEAR THE BREAKPOINT IN VDP ALONE TO SPEED UP ******* [2242] 8E30 BD,52,30 DST @STLN,@FAC8 End of line # buffer [2243] 8E33 B2,B0,52 G8E33 AND >7F,V*FAC8 Clear the breakpoint 8E36 7F [2244] 8E37 A3,52,00 DADD 4,@FAC8 Move to the next one 8E3A 04 [2245] 8E3B C5,52,32 DCH @ENLN,@FAC8 Until done [2246] 8E3E 4E,33 BR G8E33 [2247] 8E40 4E,69 BR VSAVZ [2248] 8E42 06,A0,20 G8E42 CALL UBSUB Clear the breakpoint in ERAM [2249] 8E45 BD,02,80 DST @RAMTOP,@MNUM Top of memory in ERAM 8E48 84 [2250] 8E49 A5,02,30 DSUB @STLN,@MNUM [2251] 8E4C 91,02 DINC @MNUM # of bytes total in ERAM [2252] 8E4E BD,00,70 DST @HIVDP,@VAR0 Top of memory in VDP [2253] 8E51 A5,00,02 DSUB @MNUM,@VAR0 [2254] 8E54 91,00 DINC @VAR0 [2255] * Check is there enough memory in VDP to move the program [2256] * text and line number table from ERAM to VDP [2257] 8E56 0A GT Not enough memory in VDP for sur [2258] 8E57 4E,B7 BR GSAVE [2259] 8E59 BF,10,0A DST VRAMVS+64+256,@VAR5 * 64 bytes are for safety b 8E5C 98 [2260] [2261] * DSR routine give file error when loading a program which [2262] * VDP maximum size and was saved from VDP to be a program [2263] * on disk when ERAM not exist. In order to fix this proble [2264] * restrict the program memory to be 256 bytes less then th [2265] * real space in VDP when ERAM not exist. [2266] 8E5D C9,00,10 DCHE @VAR5,@VAR0 Not enough memory in VDP, do [2267] * sequential file save 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0040 FLMGR-359 [2268] 8E60 4E,B7 BR GSAVE [2269] 8E62 A7,10,00 DSUB 10,@VAR5 * 10 bytes for control informat 8E65 0A [2270] 8E66 06,8F,4A CALL GVMOV Enough memory in VDP, move it [2271] * over and do the normal save l [2272] **************** Without ERAM, or after GVMOV ************* [2273] **************** do the normal save ************* [2274] 8E69 BD,0A,40 VSAVZ DST @FREPTR,@STADDR Store additional control info [2275] 8E6C 93,0A DDEC @STADDR Back up some more for 2 byte [2276] 8E6E BD,B0,0A DST @>8370,V*STADDR First current top of memory 8E71 70 [2277] 8E72 97,0A DDECT @STADDR [2278] 8E74 BD,B0,0A DST @STLN,V*STADDR Then STLN 8E77 30 [2279] 8E78 97,0A DDECT @STADDR [2280] 8E7A BD,B0,0A DST @ENLN,V*STADDR Then ENLN 8E7D 32 [2281] 8E7E 97,0A DDECT @STADDR Then [2282] 8E80 BD,B0,0A DST @STLN,V*STADDR 8E83 30 [2283] 8E84 B9,B0,0A DXOR @ENLN,V*STADDR STLN XORed with ENLN 8E87 32 [2284] 8E88 D6,A3,B9 CEQ 1,V@SAPROT Check is there PROTECTED opti 8E8B 01 [2285] 8E8C 4E,91 BR G8E91 [2286] 8E8E 83,B0,0A DNEG V*STADDR Negate the CHECKSUM to indica [2287] * LIST/EDIT protection [2288] 8E91 BD,E0,06 G8E91 DST @STADDR,V@BUF(@PABPTR) Save start address in P 8E94 04,0A [2289] 8E96 93,0A DDEC @STADDR [2290] 8E98 BD,E0,0A DST @>8370,V@RNM(@PABPTR) Compute # of bytes used 8E9B 04,70 [2291] 8E9D A5,E0,0A DSUB @STADDR,V@RNM(@PABPTR) and store that in PAB 8EA0 04,0A [2292] 8EA2 8E,80,84 CZ @RAMTOP If ERAM exists then [2293] 8EA5 6E,AD BS G8EAD [2294] 8EA7 BD,30,0C DST @BBB1,@STLN Restore the original STLN, EN [2295] 8EAA BD,32,08 DST @CCC1,@ENLN which points to ERAM [2296] 8EAD 06,97,5E G8EAD CALL IOCALL Call Device Service Routine f [2297] 8EB0 06 BYTE CZSAVE * SAVE operation [2298] 8EB1 06,60,22 LRTOPL CALL KILSYM Release string space/symbol t [2299] 8EB4 05,60,12 B TOPL15 Go back to toplevel [2300] *********************************************************** [2301] * Open the sequential file, set the PAB [2302] * File type : sequential file [2303] * Mode of operation : output [2304] * Data type : internal [2305] * Record type : variable length records [2306] * Logical record length : 254 maximum [2307] 8EB7 31,00,09 GSAVE MOVE 9,G@PAB3,V@4(@PABPTR) Build the PAB 8EBA E0,04,04 8EBD 8D,24 [2308] 8EBF 96,E0,05 DECT V@FLG(@PABPTR) Put in the correct I/O mode : 8EC2 04 [2309] * Compute the data buffer address [2310] 8EC3 BD,4A,70 DST @>8370,@FAC [2311] 8EC6 A7,4A,00 DSUB 253,@FAC 8EC9 FD [2312] 8ECA BD,E0,06 DST @FAC,V@BUF(@PABPTR) 8ECD 04,4A [2313] 8ECF BD,58,4A DST @FAC,@EEE1 Save it for later use in GVWITE [2314] 8ED2 06,97,6B CALL CDSR Call device service routine to o [2315] 8ED5 57,94 BR ERRZ2B Return with ERROR indication in [2316] * Put 8 bytes control info at the 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0041 FLMGR-359 [2317] * beginning of the data buffer [2318] 8ED7 BF,B0,4A DST >ABCD,V*FAC >ABCD indentifies a program f 8EDA AB,CD [2319] 8EDC 95,4A DINCT @FAC when doing LOAD later [2320] 8EDE BD,B0,4A DST @STLN,V*FAC Save STLN in control info 8EE1 30 [2321] 8EE2 95,4A DINCT @FAC [2322] 8EE4 BD,B0,4A DST @ENLN,V*FAC ENLN too 8EE7 32 [2323] 8EE8 95,4A DINCT @FAC [2324] 8EEA BD,B0,4A DST @STLN,V*FAC 8EED 30 [2325] 8EEE B9,B0,4A DXOR @ENLN,V*FAC Save the checksum 8EF1 32 [2326] 8EF2 D6,A3,B9 CEQ 1,V@SAPROT Check is there PROTECTED opti 8EF5 01 [2327] 8EF6 4E,FB BR G8EFB [2328] 8EF8 83,B0,4A DNEG V*FAC Negate the CHECKSUM to indica [2329] * the LIST/EDIT protection [2330] 8EFB 95,4A G8EFB DINCT @FAC [2331] 8EFD BD,B0,4A DST @RAMTOP,V*FAC Save the top of memory info 8F00 80,84 [2332] 8F02 BE,E0,09 ST 10,V@CNT(@PABPTR) Set the caracter count in PAB 8F05 04,0A [2333] 8F07 06,97,5E CALL IOCALL Call device service routine [2334] 8F0A 03 BYTE CZWRIT * With I/O opcode : write, to s [2335] * the control info for the first reco [2336] * Now start to use maximum-length record to write the file [2337] * and each record is copied into the VDP from ERAM bofore i [2338] * is written [2339] 8F0B BD,54,30 DST @STLN,@DDD1 Starting address on ERAM [2340] * DST @>8370,@EEE1 @EEE1 has been set up before [2341] * DST 253,@EEE1 Starting address of the data [2342] * buffer on VDP [2343] 8F0E BD,08,80 DST @RAMTOP,@CCC1 8F11 84 [2344] 8F12 A5,08,30 DSUB @STLN,@CCC1 [2345] 8F15 91,08 DINC @CCC1 [2346] 8F17 BE,E0,09 ST 254,V@CNT(@PABPTR) Set the character count of P 8F1A 04,FE [2347] 8F1C BF,56,00 G8F1C DST 254,@FFF1 @FFF1 byte count 8F1F FE [2348] 8F20 0F,8B XML GVWITE Move data from ERAM to VDP [2349] 8F22 06,97,5E CALL IOCALL Call device service routine [2350] 8F25 03 BYTE CZWRIT [2351] 8F26 A3,54,00 DADD 254,@DDD1 Update the source addr on ERA 8F29 FE [2352] 8F2A A7,08,00 DSUB 254,@CCC1 # of bytes left to move 8F2D FE [2353] 8F2E 6F,44 BS GSAV1 No more bytes to save [2354] 8F30 CB,08,00 DCHE 254,@CCC1 Leave the last record alone 8F33 FE [2355] 8F34 6F,1C BS G8F1C [2356] * Move the last @CCC1 bytes from ERAM to VDP [2357] 8F36 BD,56,08 DST @CCC1,@FFF1 @FFF1 : Byte count [2358] 8F39 0F,8B XML GVWITE Write data from ERAM to VDP [2359] 8F3B BC,E0,09 ST @CCC1+1,V@CNT(@PABPTR) Update the character cou 8F3E 04,09 [2360] * in PAB [2361] 8F40 06,97,5E CALL IOCALL Call device service routine [2362] 8F43 03 BYTE CZWRIT [2363] 8F44 06,97,5E GSAV1 CALL IOCALL [2364] 8F47 01 BYTE CZCLOS * Close the file [2365] 8F48 4E,B1 BR LRTOPL Continue 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0042 FLMGR-359 [2366] *********************************************************** [2367] * Move the program text & line # table to VDP, and relocate [2368] 8F4A BD,0C,30 GVMOV DST @STLN,@BBB1 Save STLN, ENLN for later use [2369] 8F4D BD,08,32 DST @ENLN,@CCC1 [2370] 8F50 BD,54,30 DST @STLN,@DDD1 Source addr on ERAM [2371] 8F53 BD,58,10 DST @VAR5,@EEE1 Destination addr on VDP [2372] 8F56 BD,0A,58 DST @EEE1,@STADDR Use later for RELOCA [2373] 8F59 BD,56,80 DST @RAMTOP,@FFF1 8F5C 84 [2374] 8F5D A5,56,30 DSUB @STLN,@FFF1 # of bytes to move [2375] 8F60 91,56 DINC @FFF1 @FFF1 : byte count for GVWITE [2376] 8F62 0F,8B XML GVWITE Move from ERAM to VDP [2377] 8F64 BD,A3,BC DST @RAMTOP,V@OLDTOP Set up @RAMTOP for old top 8F67 80,84 [2378] * of memory [2379] 8F69 BD,A3,BE DST @>8370,V@NEWTOP Set up @>8370 for new top 8F6C 70 [2380] * of memory [2381] 8F6D 06,8D,36 CALL RELOCA Relocate the program [2382] 8F70 BD,40,30 DST @STLN,@FREPTR Set up @FREPTR [2383] 8F73 93,40 DDEC @FREPTR [2384] 8F75 00 RTN [2385] *********************************************************** [2386] * Save the crunched form of a program into a file. [2387] * Move the line number and text to the crunch buffer, then [2388] * write to the file one line at a time. [2389] *********************************************************** [2390] * Open the file with: [2391] * I/O opcode : OPEN [2392] * File type : SEQUENTIAL file [2393] * Mode of operation : OUTPUT [2394] * Data type : DISPLAY type data [2395] * Record type : VARIABLE LENGTH records [2396] * Data buffer address : Crunch buffer address [2397] * Logical record length : 163 (length of curnch buffer + 2 [2398] * bytes for line #) maximum [2399] 8F76 31,00,09 SAVMG MOVE 9,G@PAB1,V@4(@PABPTR) Build PAB 8F79 E0,04,04 8F7C 8F,F9 [2400] 8F7E 06,97,65 CALL IOCLZ1 Call the DSR routine to open fil [2401] 8F81 BD,50,32 DST @ENLN,@FAC6 Start from the first line # [2402] 8F84 A7,50,00 DSUB 3,@FAC6 @FAC6 now points to the 1st line 8F87 03 [2403] * Write to the file from crunch bu [2404] * one line at a time [2405] 8F88 86,00 G8F88 CLR @VAR0 Make it a two byte later [2406] 8F8A 8E,80,84 CZ @RAMTOP If ERAM exists then [2407] 8F8D 6F,B6 BS G8FB6 [2408] 8F8F BD,54,50 DST @FAC6,@DDD1 Write the 4 bytes (line # and [2409] * line pointer) from ERAM to [2410] * crunch buffer [2411] * @DDD1 : Source address on ERA [2412] 8F92 BF,58,08 DST CRNBUF,@EEE1 @EEE1 : Destination address 8F95 20 [2413] * on VDP [2414] 8F96 BF,56,00 DST 4,@FFF1 @FFF1 : byte count 8F99 04 [2415] 8F9A 0F,8B XML GVWITE Write data from ERAM to VDP [2416] 8F9C BD,54,A8 DST V@CRNBUF+2,@DDD1 Line pointer now points to 8F9F 22 [2417] * length byte [2418] 8FA0 93,54 DDEC @DDD1 Get the length of this line [2419] * @DDD1 : Source address on ERA [2420] 8FA2 91,56 DINC @FFF1 @FFF1 : Byte count, coming ba 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0043 FLMGR-359 [2421] * from GVWITE above, =0 [2422] 8FA4 0F,8C XML GREAD1 Read the length byte from ERA [2423] 8FA6 BC,01,58 ST @EEE1,@VAR0+1 @EEE1 : Destination addr on C [2424] 8FA9 BF,58,08 DST CRNBUF+2,@EEE1 Write the text from ERAM to 3 8FAC 22 [2425] * byte of crunch buffer [2426] * @EEE1 : Destination addr on V [2427] * @DDD1 : Source addr on ERAM [2428] 8FAD 91,54 DINC @DDD1 Back to point to the text [2429] 8FAF BD,56,00 DST @VAR0,@FFF1 @FFF1 : Byte count [2430] 8FB2 0F,8B XML GVWITE Write data from ERAM to VDP [2431] 8FB4 4F,CD BR G8FCD ERAM not exist : line # table [2432] * and text in VDP [2433] 8FB6 BD,A8,20 G8FB6 DST V*FAC6,V@CRNBUF PUT THE LINE # IN 8FB9 B0,50 [2434] 8FBB BD,4C,E0 DST V@2(@FAC6),@FAC2 Get the line pointer out 8FBE 02,50 [2435] 8FC0 93,4C DDEC @FAC2 Line pointer now points to th [2436] * length byte [2437] 8FC2 BC,01,B0 ST V*FAC2,@VAR0+1 Get the length out 8FC5 4C [2438] * Move the text into the crunch buffer [2439] 8FC6 34,00,A8 MOVE @VAR0,V@1(@FAC2),V@CRNBUF+2 8FC9 22,E0,01 8FCC 4C [2440] 8FCD B2,A8,20 G8FCD AND >7F,V@CRNBUF Reset possible breakpoint 8FD0 7F [2441] 8FD1 95,00 DINCT @VAR0 * Total length=text length+line # len [2442] 8FD3 BC,E0,09 ST @VAR0+1,V@CNT(@PABPTR) Store in the cahracter c 8FD6 04,01 [2443] 8FD8 06,97,5E CALL IOCALL Call the device service routi [2444] 8FDB 03 BYTE CZWRIT * Write [2445] 8FDC A7,50,00 DSUB 4,@FAC6 Go to the next line # 8FDF 04 [2446] 8FE0 C9,50,30 DCHE @STLN,@FAC6 Finish moving all [2447] 8FE3 6F,88 BS G8F88 [2448] 8FE5 BF,A8,20 DST >FFFF,V@CRNBUF Set up a EOF for the last rec 8FE8 FF,FF [2449] 8FEA BE,E0,09 ST 2,V@CNT(@PABPTR) Only write this 2 bytes 8FED 04,02 [2450] 8FEF 06,97,5E CALL IOCALL Call the device service routi [2451] 8FF2 03 BYTE CZWRIT * Write [2452] 8FF3 06,97,5E CALL IOCALL Call the device service routi [2453] 8FF6 01 BYTE CZCLOS * Close the file [2454] 8FF7 4E,B1 BR LRTOPL Go back to top level [2455] 8FF9 00,12,08 PAB1 BYTE >00,>12,>08,>20,>A3,>00,>00,>00,>60 8FFC 20,A3,00 8FFF 00,00,60 [2456] * >0820 = CRNBUF [2457] * >A3 = 163 [2458] * >60 = OFFSET [2459] *********************************************************** [2460] * MERGE ROUTINE [2461] * MERGE load a file which is in crunched program form into [2462] * the CRNBUF one record (one in) at a time then take the [2463] * line # out in FAC, text length into @CHAT, and edit it [2464] * into the program. Identify EOF by the last record which [2465] * is set up at SAVE time. [2466] *********************************************************** [2467] 9002 06,92,35 MERGE CALL GPNAME Close all file, set up PAB [2468] 9005 DA,45,80 CLOG >80,@FLAG Check PROTECTION VIOLATION [2469] 9008 57,DB BR ERRPV [2470] * To fix the bug #06 in MERGE [2471] 900A 0F,79 XML PGMCHR Check EOL 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0044 FLMGR-359 [2472] 900C 8E,42 CZ @CHAT [2473] 900E 41,09 BR ERRSYN Not EOL : SYNTAX ERROR [2474] * Open the file with [2475] * I/O opcode : OPEN [2476] * File type : SEQUENTIAL file [2477] * Mode of operation : INPUT [2478] * Data type : DISPLAY type data [2479] * Record type : VARIABLE LENGTH records [2480] * Data buffer address : crunch address [2481] * Logical record length : 163 maximum [2482] 9010 31,00,09 MOVE 9,G@PAB1,V@4(@PABPTR) Set up PAB 9013 E0,04,04 9016 8F,F9 [2483] 9018 94,E0,05 INCT V@FLG(@PABPTR) Put in correct I/O mode : >14 901B 04 [2484] 901C 06,97,65 CALL IOCLZ1 Call the device service routi [2485] * to open the file [2486] 901F 06,97,5E CALL IOCALL Call the device service routi [2487] 9022 02 BYTE CZREAD * to read [2488] 9023 D7,A8,20 DCEQ >FFFF,V@CRNBUF If 1st rec is EOF 9026 FF,FF [2489] 9028 77,94 BS ERRZ2B [2490] 902A 87,80,D6 G902A DCLR @>83D6 Read in one line and edit it [2491] * program [2492] 902D BC,42,E0 ST V@CNT(@PABPTR),@CHAT Length of this record 9030 09,04 [2493] 9032 96,42 DECT @CHAT Text length = total length-2 [2494] * (line # length) [2495] * Put it in @CHAT for EDITLN [2496] 9034 BD,4A,A8 DST V@CRNBUF,@FAC Put the line # in @FAC for ED 9037 20 [2497] 9038 86,56 CLR @FAC12 Make it a double byte [2498] 903A BC,57,42 ST @CHAT,@FAC13 [2499] * Move the text up 2 bytes [2500] 903D 34,56,A8 MOVE @FAC12,V@CRNBUF+2,V@CRNBUF 9040 20,A8,22 [2501] 9043 BD,A3,9E DST @PABPTR,V@MRGPAB SAVE PAB POINTER 9046 04 [2502] 9047 06,60,32 CALL EDITLN EDIT IT TO THE PROGRAM [2503] 904A 87,04 DCLR @PABPTR Clear temporary PAB pointer [2504] 904C C1,04,A3 DEX V@MRGPAB,@PABPTR Restore old PAB pointer 904F 9E [2505] 9050 06,97,5E CALL IOCALL CALL THE DEVICE SERVICE ROUTI [2506] 9053 02 BYTE CZREAD * read another record or anoth [2507] * line [2508] 9054 D7,A8,20 DCEQ >FFFF,V@CRNBUF End of EOF 9057 FF,FF [2509] 9059 50,2A BR G902A [2510] * Double check EOF record [2511] 905B D6,E0,09 MERGZ1 CEQ 2,V@CNT(@PABPTR) I/O ERROR 905E 04,02 [2512] 9060 57,94 BR ERRZ2B [2513] 9062 06,97,5E CALL IOCALL Call the device service routi [2514] 9065 01 BYTE CZCLOS * close the file [2515] 9066 4E,B1 BR LRTOPL Go back to top level [2516] *********************************************************** Quote Link to comment Share on other sites More sharing options...
HackMac Posted January 25, 2016 Share Posted January 25, 2016 (edited) I just ask me, how to create a Extended Basic "long format" (with standard tools/programs on a TI, like TI Extended Basic). Can some one help me out? Edited January 25, 2016 by HackMac Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 25, 2016 Author Share Posted January 25, 2016 TIImageTool, create new file, paste content into window, close and save, specify "Extended Basic" and "Long format". Quote Link to comment Share on other sites More sharing options...
HackMac Posted January 25, 2016 Share Posted January 25, 2016 Sorry, I edited my post a bit too late... I mean creating on a TI, with standard programs like TI Extended Basic. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 25, 2016 Author Share Posted January 25, 2016 Only when the program exceeds - don't know - something around 13K or so. Load a program, resequence it, save it again as merge, then you can build bigger programs pretty easily by merging to the current program in memory. Quote Link to comment Share on other sites More sharing options...
HackMac Posted January 25, 2016 Share Posted January 25, 2016 Okay, thanks for this info. I read that already anywhere, that only large programs are stored in the large format. But I don't know how large large is. I'll try your trick. I thought there is an other (undocumented) more easy way to force saving a program to that file type. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 25, 2016 Share Posted January 25, 2016 XB256 has a utility that forces a save in IV254 format. This is part of the Game Developer's Package that can be downloaded from the Development Resources at the top of the page. You would load and run XB256, then load the XB program. Then: CALL LINK(“SAVEIV”,”DSKn.FILENAME”)This will save an XB program in IV254 format. See page 26 for more information. Also, I think Rich Gilbertson did some work including this with RXB and it may be part of that package. 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.