Assembly->XB link project

Opry99er · November 28, 2010

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

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

Opry99er · November 28, 2010

ahhh... i would have figured that out the hard way. =) thanks

Opry99er · November 28, 2010

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

Opry99er · November 28, 2010

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

Opry99er · 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. =)

Opry99er · November 29, 2010

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

sometimes99er · November 29, 2010

Yep, you're on a right track there. Nice.

Opry99er · 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. =)

matthew180 · 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

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

Opry99er · 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:

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.

Opry99er · 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. =)

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

matthew180 · 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

Opry99er · November 29, 2010

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

sometimes99er · November 29, 2010

However, it *will* be interrupted by the ISR, ...

Nope, don't think so. :cool:

Opry99er · 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!

Opry99er · 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?

matthew180 · 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

sometimes99er · 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?

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

Opry99er · November 29, 2010

Nice catch. . I was thinking XB

Opry99er · November 29, 2010

SUCCESS!!!! This was a bit*h to get done, but the code for my converter is below.

[code

100 OPEN #1:"DSK1.MYTEST"
110 CALL CLEAR
120 RESTORE 340
130 GOSUB 300
140 A=CHA
150 GOSUB 300
160 B=CHA
170 GOSUB 300
180 C=CHA
190 GOSUB 300
200 D=CHA
210 GOSUB 300
220 E=CHA
230 GOSUB 300
240 F=CHA
250 GOSUB 300
260 G=CHA
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
290 GOTO 130
300 READ CHA
310 ON ERROR 330
320 RETURN
330 CALL CLEAR :: PRINT "DONE" :: END
340 DATA 140,141,143,137,137,137,137,137,137,137,137,136,136,103,102,103
350 DATA 103,103,103,103,114,114,112,112,114,112,139,138,142,137,137,137
360 DATA 137,136,136,136,136,136,136,102,103,103,103,102,103,102,136,136
370 DATA 114,112,112,114,132,130,131,137,137,136,136,136,136,136,136,136
380 DATA 136,103,103,102,103,103,103,103,136,136,137,112,114,112,103,102
390 DATA 103,102,103,103,136,136,136,136,136,136,136,103,103,103,103,103
400 DATA 103,102,136,136,137,137,112,114,137,137,137,136,136,102,136,136
410 DATA 136,136,136,136,136,136,136,136,103,136,136,136,136,136,136,137
420 DATA 137,114,137,137,137,136,136,103,136,136,136,136,136,136,136,136
430 DATA 136,136,103,136,136,136,136,136,136,136,137,114,137,137,136,136
440 DATA 136,103,103,102,103,103,103,103,136,136,136,136,102,136,136,136
450 DATA 136,136,136,136,137,114,137,136,136,136,136,136,136,136,136,136
460 DATA 136,102,103,102,136,136,103,136,136,136,136,136,136,136,137,137
470 DATA 136,136,136,136,136,136,136,136,136,136,136,103,102,103,103,103
480 DATA 102,136,136,136,136,136,136,136,137,137,136,136,136,136,136,136
490 DATA 136,136,136,136,136,102,136,136,136,136,136,136,136,136,136,136
500 DATA 136,136,137,137,136,136,136,136,136,136,136,136,136,136,136,103
510 DATA 136,136,136,136,136,136,136,136,136,136,136,136,137,137,136,136
520 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. =)

sometimes99er · November 29, 2010

Opry99er · November 29, 2010

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

Assembly->XB link project

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members