Opry99er Posted November 28, 2010 Author Share Posted November 28, 2010 (edited) Okay... if you look at my screen pictures from earlier, I have to display a 12x26 block onscreen. Here's my thoughts: VSBW EQU >2020 VMBW EQU >2024 DEF DRAW DEF MAP DEF DRW DRAW LI R0,291 LI R1,MAP LI R2,26 LI R3,12 DRW BLWP @VMBW AI R0,32 DEC R3 JNE DRW This will do 12 VMBWs of 26 bytes at a time, giving me 12x26. Look okay? Edited November 28, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 28, 2010 Share Posted November 28, 2010 Can't remember if R2 get decremented when using BLWP @VMBW. A fix would then be VMBW EQU >2024 DEF DRAW DRAW LI R0,291 LI R1,MAP LI R3,12 DRW LI R2,26 BLWP @VMBW AI R0,32 DEC R3 JNE DRW ... bla bla bla ... Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 28, 2010 Author Share Posted November 28, 2010 ahhh... i would have figured that out the hard way. =) thanks Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 28, 2010 Author Share Posted November 28, 2010 (edited) So... need to write this program to offset the DATA output. Here's the BASIC output from Magellan: MAP DATA 140,141,143,137,137,137,137,137,137,137,137,136,136,103,102,103 DATA 103,103,103,103,114,114,112,112,114,112,139,138,142,137,137,137 DATA 137,136,136,136,136,136,136,102,103,103,103,102,103,102,136,136 DATA 114,112,112,114,132,130,131,137,137,136,136,136,136,136,136,136 DATA 136,103,103,102,103,103,103,103,136,136,137,112,114,112,103,102 DATA 103,102,103,103,136,136,136,136,136,136,136,103,103,103,103,103 DATA 103,102,136,136,137,137,112,114,137,137,137,136,136,102,136,136 DATA 136,136,136,136,136,136,136,136,103,136,136,136,136,136,136,137 DATA 137,114,137,137,137,136,136,103,136,136,136,136,136,136,136,136 DATA 136,136,103,136,136,136,136,136,136,136,137,114,137,137,136,136 DATA 136,103,103,102,103,103,103,103,136,136,136,136,102,136,136,136 DATA 136,136,136,136,137,114,137,136,136,136,136,136,136,136,136,136 DATA 136,102,103,102,136,136,103,136,136,136,136,136,136,136,137,137 DATA 136,136,136,136,136,136,136,136,136,136,136,103,102,103,103,103 DATA 102,136,136,136,136,136,136,136,137,137,136,136,136,136,136,136 DATA 136,136,136,136,136,102,136,136,136,136,136,136,136,136,136,136 DATA 136,136,137,137,136,136,136,136,136,136,136,136,136,136,136,103 DATA 136,136,136,136,136,136,136,136,136,136,136,136,137,137,136,136 DATA 136,136,136,136,136,136,136,136,136,102,136,136,136,136,136,136 and here's the assembler output: MD4 DATA >8C8D,>8F89,>8989,>8989 ; DATA >8989,>8988,>8867,>6667 ; DATA >6767,>6767,>7272,>7070 ; * -- Map Row 1 -- DATA >8B8A,>8E89,>8989,>8988 ; DATA >8888,>8888,>8866,>6767 ; DATA >6766,>6766,>8888,>7270 ; * -- Map Row 2 -- DATA >8482,>8389,>8988,>8888 ; DATA >8888,>8888,>8867,>6766 ; DATA >6767,>6767,>8888,>8970 ; * -- Map Row 3 -- DATA >6766,>6766,>6767,>8888 ; DATA >8888,>8888,>8867,>6767 ; DATA >6767,>6766,>8888,>8989 ; * -- Map Row 4 -- DATA >8989,>8988,>8866,>8888 ; DATA >8888,>8888,>8888,>8888 ; DATA >6788,>8888,>8888,>8889 ; * -- Map Row 5 -- DATA >8989,>8988,>8867,>8888 ; DATA >8888,>8888,>8888,>8888 ; DATA >6788,>8888,>8888,>8888 ; * -- Map Row 6 -- DATA >8989,>8888,>8867,>6766 ; DATA >6767,>6767,>8888,>8888 ; DATA >6688,>8888,>8888,>8888 ; * -- Map Row 7 -- DATA >8988,>8888,>8888,>8888 ; DATA >8888,>8866,>6766,>8888 ; DATA >6788,>8888,>8888,>8888 ; * -- Map Row 8 -- DATA >8888,>8888,>8888,>8888 ; DATA >8888,>8867,>6667,>6767 ; DATA >6688,>8888,>8888,>8888 ; * -- Map Row 9 -- DATA >8888,>8888,>8888,>8888 ; DATA >8888,>8866,>8888,>8888 ; DATA >8888,>8888,>8888,>8888 ; * -- Map Row 10 -- DATA >8888,>8888,>8888,>8888 ; DATA >8888,>8867,>8888,>8888 ; DATA >8888,>8888,>8888,>8888 ; * -- Map Row 11 -- DATA >8888,>8888,>8888,>8888 ; DATA >8888,>8866,>8888,>8888 ; DATA >8888,>8888,>8888,>8888 ; Any ideas? =) I suppose I could load a byte into a register and then add 96 to it before actually writing it... but I would have to do 12x26 single byte writes as opposed to 12 multiple byte writes. That would be sloooooow though... I would actually prefer to convert all these values before assembly... I would hate to eat up so many cycles with unnecessary calculations Edited November 28, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 28, 2010 Author Share Posted November 28, 2010 (edited) So neither of these sets of DATA is useful without being converted? With the BASIC DATA, that gives me straight XB ASCII data... I assume the assembler output is giving me the offset values?? I'm a bit dense on this one. I suppose I could write an XB program that converts the DATA statements into strings and use SEG$ to pull out each entry individually and modify it, then save it back... Seems like a bunch of unnecessary work though. I think perhaps I'll listen here and see what is available from those who've tried all this before. =) I don't think I'm thinking about this the proper way anyway.... Edited November 28, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 This works... not too efficient, but I'm working with formatting right now. REM CREATE FILES ON DISK 100 OPEN #1:"DSK1.TEST",OUTPUT,DISPLAY REM SCREEN PARAMETERS REM READ DATA TO DSK 115 RESTORE 910 120 FOR I=1 TO 304 :: READ CHA :: A=CHA+96 130 PRINT #1:A :: NEXT I :: CLOSE #1 REM END SEQUENCE 910 DATA 140,141,143,137,137,137,137,137,137,137,137,136,136,103,102,103 920 DATA 103,103,103,103,114,114,112,112,114,112,139,138,142,137,137,137 930 DATA 137,136,136,136,136,136,136,102,103,103,103,102,103,102,136,136 940 DATA 114,112,112,114,132,130,131,137,137,136,136,136,136,136,136,136 950 DATA 136,103,103,102,103,103,103,103,136,136,137,112,114,112,103,102 960 DATA 103,102,103,103,136,136,136,136,136,136,136,103,103,103,103,103 970 DATA 103,102,136,136,137,137,112,114,137,137,137,136,136,102,136,136 980 DATA 136,136,136,136,136,136,136,136,103,136,136,136,136,136,136,137 990 DATA 137,114,137,137,137,136,136,103,136,136,136,136,136,136,136,136 . . . . . Basically I'm just doing this... 1) Opening DSK1, creating a file called "TEST" 2) READing DATA from subsequent lines of the program 3) adding the offset of 96 to the number 4) PRINTing the values into "TEST" That's it. =) Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 (edited) So, once I get the format how I want it, I'll just be able to use TI-99Dir to copy and paste the contents of the file named "TEST" into my Assembly code (preceded by "BYTE" as opposed to "DATA") and it'll be square... Edited November 29, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 29, 2010 Share Posted November 29, 2010 Yep, you're on a right track there. Nice. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 Thanks sometimes.... I wasn't sure whether I was doing the proper steps or not. I'll have some progress to show soon... stay tuned today. =) Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 29, 2010 Share Posted November 29, 2010 Writing the tools to support your main program can take more time than the main code itself. Your code looks fine to me. If it outputs what you want, then it is good. Your tools only have to work once, or *good enough* to get the job done. As for your main code, you must explain to me why you keep going back to VSBW / VMBW (you knew it was coming)? For something this small and specific, just roll your own (see example code early on in the thread.) Also, any time you are running assembly language that was called from BASIC (or XB), and you are dealing with the VDP, you really need to use LIMI 0 / LIMI 2 around your code. Matthew Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 29, 2010 Share Posted November 29, 2010 Proper or not. Getting the data right and displaying them from XB. I think I can help you with that if you get stuck. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 Thanks Matthew. =) I'm just trying to hack this thing as quick and ugly as I can, just to see if I can make it work. Right now I'm working on a way to create records on disk that look like: 255,230,222,230,230,230,230,230 201,200,201,201,201,203,203,231 222......... . . . Instead of: 255 230 222 230 230 . . I'm pretty close now... re-reading the PRINT options in XB. As to why the *VMBW EQU >2024* question, I'm using an example Marc Hull gave me a year ago... it contains that EQUate and works nicely, so if I can make it work quick and dirty, I'll refine the source code and make it much more elegant and efficient.... using your conventions. =) I'm glad you chimed in, Matthew. =) What would an assembly thread be without some good ol' fashioned VDP routine bashing!!! =) <jk> I hope I can get this working today... I'm pretty tired of trying to make XB and assembly talk to each other... It's fun at first, but DAMN did they make it difficult!!!! Maybe "difficult" is in the eye of the beholder though... I'm sure there are many people who are super fast at this kind of work with conversion tools in their back pocket and such... maybe me at some point as well. =) Anyway, once this project is done, I'll do a write-up of the trials and tribulations and post it to my blog. I haven't made a blog entry since the Beryl Reichardt development went to hell. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 Looks like I'll need to create an "IMAGE" and use "PRINT USING" to get the records to be in the order I'm looking for. This is going to take just a bit of study.... I'll do some reading and testing and get back to the thread when I have something worthwhile to show. =) Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 29, 2010 Share Posted November 29, 2010 Also, any time you are running assembly language that was called from BASIC (or XB), and you are dealing with the VDP, you really need to use LIMI 0 / LIMI 2 around your code. Marc didn't do it, and so I didn't either. I checked the following DEF TEST TEST JMP TEST END Classic99 Debugger has the Status Register Interrupt Mask set to >0. Same thing from both XB and Basic with EA. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 29, 2010 Share Posted November 29, 2010 Well, that code does not return. However, it *will* be interrupted by the ISR, and if you had just set up an address in the VDP, and the ISR needed to do something like service a sound list that was playing from VRAM, when the ISR is done your address will be destroyed. There are a lot of factors, it depends on what your code is doing and what else is going on in XB at the time. Turn on some auto-sprite movement and try it... The ISR can and does access the VDP, so if your assembly code does too, you should wrap your code in LIMI 0 / LIMI 2. It is cheap insurance that can prevent a lot of headaches trying to track down a strange random bug. Matthew Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 (edited) Apparently I can use something like this: 100 CALL CLEAR 110 RESTORE 270 120 GOSUB 290 130 A=CHA 140 GOSUB 290 150 B=CHA 160 GOSUB 290 170 C=CHA 180 GOSUB 290 190 D=CHA 200 GOSUB 290 210 E=CHA 220 GOSUB 290 230 F=CHA 240 GOSUB 290 250 G=CHA 260 PRINT USING 310:A,B,C,D,E,F,G 270 DATA 255,260,210,132,245,199,205 280 GOTO 280 290 READ CHA 300 RETURN 310 IMAGE "###,###,###,###,###,###,###" This was just a test to see if I could print it in the proper format. Now I just need to add the disk funtions and I'm rollin'! Edited November 29, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 29, 2010 Share Posted November 29, 2010 However, it *will* be interrupted by the ISR, ... Nope, don't think so. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 From what I understand, (and it's not much) the LIMI 2/LIMI 0 wrap on this small draw subroutine could only serve to help... Assuming I'm using your sound player in conjunction with this small subroutine, enabling/disabling interrupts on this routine won't affect the sound being played, correct? Sorry if that's an elementary question... I'm just covering my bases. Thanks! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 Hey sometimes.... On the print using, let's say I wanted the output data to look like lines of DATA... Could I simply do: 100 PRINT #1 USING 300:A,B,C,D,E,F,G 300 IMAGE "DATA ###,###,###,###,###,###,###" Would that work, you think? Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 29, 2010 Share Posted November 29, 2010 However, it *will* be interrupted by the ISR, ... Nope, don't think so. I stand corrected. It seems that when CALL LINK is executed, the interrupt flag is already set to zero. So Owen, don't worry about LIMI 0 / LIMI 2, it seems the assembly code called from XB is already running with interrupts disabled. Matthew Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 29, 2010 Share Posted November 29, 2010 (edited) Hey sometimes.... On the print using, let's say I wanted the output data to look like lines of DATA... Could I simply do: 100 PRINT #1 USING 300:A,B,C,D,E,F,G 300 IMAGE "DATA ###,###,###,###,###,###,###" Would that work, you think? Oops, you better ask someone else. Haven't done much in that department. Edit: Wouldn't it be BYTE instead if DATA ? Edited November 29, 2010 by sometimes99er Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 Nice catch. . I was thinking XB Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 SUCCESS!!!! This was a bit*h to get done, but the code for my converter is below. [code100 OPEN #1:"DSK1.MYTEST"110 CALL CLEAR120 RESTORE 340130 GOSUB 300140 A=CHA150 GOSUB 300160 B=CHA170 GOSUB 300180 C=CHA190 GOSUB 300200 D=CHA210 GOSUB 300220 E=CHA230 GOSUB 300240 F=CHA250 GOSUB 300260 G=CHA270 A=A+96 :: B=B+96 :: C=C+96 :: D=D+96 :: E=E+96 :: F=F+96 :: G=G+96280 PRINT #1,USING "BYTE ###,###,###,###,###,###,###":A,B,C,D,E,F,G290 GOTO 130300 READ CHA310 ON ERROR 330320 RETURN330 CALL CLEAR :: PRINT "DONE" :: END340 DATA 140,141,143,137,137,137,137,137,137,137,137,136,136,103,102,103350 DATA 103,103,103,103,114,114,112,112,114,112,139,138,142,137,137,137360 DATA 137,136,136,136,136,136,136,102,103,103,103,102,103,102,136,136370 DATA 114,112,112,114,132,130,131,137,137,136,136,136,136,136,136,136380 DATA 136,103,103,102,103,103,103,103,136,136,137,112,114,112,103,102390 DATA 103,102,103,103,136,136,136,136,136,136,136,103,103,103,103,103400 DATA 103,102,136,136,137,137,112,114,137,137,137,136,136,102,136,136410 DATA 136,136,136,136,136,136,136,136,103,136,136,136,136,136,136,137420 DATA 137,114,137,137,137,136,136,103,136,136,136,136,136,136,136,136430 DATA 136,136,103,136,136,136,136,136,136,136,137,114,137,137,136,136440 DATA 136,103,103,102,103,103,103,103,136,136,136,136,102,136,136,136450 DATA 136,136,136,136,137,114,137,136,136,136,136,136,136,136,136,136460 DATA 136,102,103,102,136,136,103,136,136,136,136,136,136,136,137,137470 DATA 136,136,136,136,136,136,136,136,136,136,136,103,102,103,103,103480 DATA 102,136,136,136,136,136,136,136,137,137,136,136,136,136,136,136490 DATA 136,136,136,136,136,102,136,136,136,136,136,136,136,136,136,136500 DATA 136,136,137,137,136,136,136,136,136,136,136,136,136,136,136,103510 DATA 136,136,136,136,136,136,136,136,136,136,136,136,137,137,136,136520 DATA 136,136,136,136,136,136,136,136,136,102,136,136,136,136,136,136[/code][/spoiler]The key part of this program are these two lines: 270 A=A+96 :: B=B+96 :: C=C+96 :: D=D+96 :: E=E+96 :: F=F+96 :: G=G+96 280 PRINT #1,USING "BYTE ###,###,###,###,###,###,###":A,B,C,D,E,F,G After the Magellan output is READ into these 7 variables, it is added to "96" and then printed to the file on disk... Then, the loop goes back to read the next DATA statements in the line, re-using the same 7 variables. =) And here's what the disk information looks like in TI-99Dir BYTE 236,237,239,233,233,233,233 BYTE 233,233,233,233,232,232,199 BYTE 198,199,199,199,199,199,210 BYTE 210,208,208,210,208,235,234 BYTE 238,233,233,233,233,232,232 . . . This was alot of fun. =) Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 29, 2010 Share Posted November 29, 2010 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 29, 2010 Author Share Posted November 29, 2010 (edited) Heh.... Don't think I deserve the GOLD medal.... Maybe bronze. I will need to adjust the number of bytes I am converting at a time though.... With the ON ERROR I am using, it simply ends the program if the number of bytes is not a multiple of 7. This is a problem when you reach the end of the DATA list and you have just a few remaining bytes to write. I will change the number of bytes per line to 6 and use the variables A-F.... Since my maps are 12x26, that should give me 52 lines of 6 bytes per line. Should work, yes? Edited November 29, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.