Bones-69

January 23, 2013

What a tease!

Any hints? Perhaps disk file access?

If this compiler came out at the peak of the 99/4a popularity it would have changed the world. I think it is an amazing concept and have been playing with it daily since the release. In due course I think some fantastic stuff will be born as a result. Personally, Assembler has always been out of my league, but I am now estatic about the possibility of have assembler performance with a language that I can understand. Finally the only real limit for the XB programmer now is imagination . That's a great spot to be in. :applaud

January 21, 2013

Woops... Somthing got lost there in the copy/paste to the forum. Hope you get the idea anyway...

January 21, 2013

OK... Thought my program would be ready for release by now and my silly request would be understood, but the final stages are taking longer than expected so I should explain.

I am writing an XB program that will grab any screen displayed, then package the screen into the smallest format possible (that I have been able to develop in XB anyway), then have my program export a second program that reproduces the exact screen it grabbed including colours & char definitions. This exported program, which is specifically compatible with the XB Compiler, can then be merged/pasted into any program destined to be XB compiled (or be copy pasted to and from text editors without loosing characters 0-31 and characters 127-159). My main motivation for writing this was to get Magellan designed screens straight into the XB Compiler but it will work on any 24x32 screen it is given (including the prompt).

Now, when merging my program with an XB Magellan exported program I have access to all the data which the screen was designed with, but if I want my program to be able to build any screen (without knowing in advance what the colours were set to, or where to find this information), then I needed a way to "back door" the colour and screen values. Especially if my program is going to be used with the RUN command directly from another program.

Anyway... All should be clear in a few days when it is finished (hopefully). The good news it is working and it is only the additional features that are holding things up. Here is the current output (still a few glitches to sort), that my program exported after it was merged into a Magellan exported program. It will also write a true XB version (without the X-B compiler "DISPLY" or the relevant RXB CALL statement which escapes me at the moment).

PROGRAM #1																																		
Use in XB programs which are going to be compiled.																								
																																				
*Program #1 requires DSK1.C-XTRAS to be loaded if testing in XB environment. Refer XB Compiler documentation or use Program #2.					
																																				
User defined preferences;																															
>Program line number start:100																													
>Program line number Increment:10																												
>Data line number start:1000																														
>Character 31 has been replaced by character 32 to create less data and draw screen faster.														
>Magellan data was used to identify correct screen colour.																						
>Hex Data and character definition routine has been included.																					
*Standard XB hex char data has been selected. (Hex data has not been optimised to reduce programming space.										
>Characters 0-31, character 33 & characters 127-159 are drawn to screen during a second pass using CALL HCHAR. The number of characters requiring
a second pass is 41. (Support option for Magellan which skips BLANK characters rather than writing 0000000000000000.)							
-Characters found with hex code 3C5ADBFF18244281 have been reset to 0000000000000000.															
																																				
* A second file has been created, refer "DSK1.SS-S". This file has additional information and formatting styles which may be useful.				
																																				
PROGRAM #1 START (Copy/Paste the following program into Classic99. Program is ready to be compiled or included elsewhere.)							
110 CALL CLEAR::RESTORE 1000																														
120 READ A::CALL SCREEN(A)::FOR I=0 TO 14::READ A,B,C::CALL COLOR(A,B,C)::NEXT I																	
130 FOR I=1 TO 28::READ A,A$::CALL CHAR(A,A$)::NEXT I																								
140 FOR I=1 TO 24 STEP 4::READ A$::CALL LINK("DISPLY",I,1,A$)::NEXT I																				
150 READ A$::FOR I=1 TO LEN(A$)STEP 3::A=ASC(SEG$(A$,I,1))::IF A=42 THEN 170																		
160 CALL HCHAR(A-77,ASC(SEG$(A$,I+1,1))-77,ASC(SEG$(A$,I+2,1))+33)::NEXT I::GOTO 150																
170 CALL KEY(0,A,B)::IF B=0 THEN 170																												
180 END																																			
1000 DATA 2																																		
1010 DATA 0,2,1,1,5,2,2,7,2,3,12,2,4,12,2,5,12,2,6,12,2,7,12,2																						
1020 DATA 8,12,2,9,8,2,10,8,5,11,15,5,12,12,5,13,12,5,14,16,13																						
1030 DATA 32,"0000000000000000800000000000000000000000000000000000000000000000",36,"FFFFFFFFFFFFFFFF007E7E7E7E7E7E0014143E143E1414003844040810207C00"
1040 DATA 40,"0000001F1F181818000000F8F8181818000000FFFF0000001818181818181818",44,"1818181F1F000000181818F8F8000000181818F8F81818181818181F1F181818"
1050 DATA 48,"00708888888888700010301010101038003844040810207C0038440418044438",52,"00081828487C0808007C4078040444380018204078444438007C040810202020"
1060 DATA 56,"0038444438444438003844443C04083000FF0000000000000020505020544834",60,"0002040810204000000000000018081000201008102000000038440408100010"
1070 DATA 64,"0000000000003030003844447C44444400782424382424780038444040404438",68,"0078242424242478007C40407840407C007C404078404040003C40405C444438"
1080 DATA 72,"004444447C444444003810101010103800040404040444380044485060504844",76,"004040404040407C00446C545444444400446464544C4C44007C44444444447C"
1090 DATA 80,"0078444478404040003844444454483400784444785048440038444038044438",84,"007C101010101010004444444444443800444444282810100044444454545428"
1100 DATA 88,"00444428102844440044442810101010007C04081020407C0028287C287C2828",92,"0000090D0B09090000007456555474000000B8A1B0A1B8000000A050A050A000"
1110 DATA 96,"00000000000000FF8080808080808080FF000000000000000101010101010101",100,"007E7E7E7E7E7E00000000000000000000000000000000000000000000000000"
1120 DATA 104,"030E1D2D767BCDB6B6CD7B762D3D0E03C070BCB46EDEB36D6DB3DE6EB4B870C0",108,"0000000000000000000000000000000000000000000000000000000000000000"
1130 DATA 112,"0000000000000000000000000000000000000000000000000000000000000000",116,"0000000000000000000000000000000000000000000000000000000000000000"
1140 DATA 120,"0103060C15252D36250D14262C3720200080C060504868D8486050C868D80808",124,"3F61446637121009091110120B08070000C060201030E0800080C0601010E000"
1150 DATA 128,"00003F21EDADA1A8AFE02E3B0E000000082008000C0CFF01F98539EF38000000",132,"005824020F3975FBDEDF240408102000001C2242F09CAEDF7BFB242010080400"
1160 DATA 136,"0103070F1F3F793F3939BFF195F591FF0080D8F8F8FC9EFC9F9FFFFF09FF09FF",140,"FF0000000000000000EE44444E0000000000000000000000FF00EAACAAEA0000"
1170 DATA " ````````````````	 MENU c%%%%%%%%%%%%%%%%a	 :::: c%%%%%%%%%%%%%%%%a 1@SELECT CHARc%%%%%%%%%%%%%%%%a 2@FILL;ERASE "		
1180 DATA "c%%%%%%%%%%%%%%%%a 3@INVERT;MOVEc%%%%%%%%%%%%%%%%a 4@SWAP;COPY c%%%%%%%%%%%%%%%%a 5@HEX CODES c%%%%%%%%%%%%%%%%a 6@COLOUR	 "		
1190 DATA "c%%%%%%%%%%%%%%%%a 7@MEDIA SETUPc%%%%%%%%%%%%%%%%a 8@HELP	 c%%%%%%%%%%%%%%%%a			 c%%%%%%%%%%%%%%%%a ```` MEDIA "		
1200 DATA "c%%%%%%%%%%%%%%%%ac a::::: c%%%%%%%%%%%%%%%%ac a>PLAYINGc%%%%%%%%%%%%%%%%ac a[4	 c%%%%%%%%%%%%%%%%ac a	 "		
1210 DATA "c%%%%%%%%%%%%%%%%ac a>SHOWING bbbbbbbbbbbbbbbb c a[5=[6=[7 BG [1(*&'*)[3 [4 c a;[8 PLUS(*****.$$$$/*****)c aB<GROUND"		
1220 DATA "+xz |~+$hj$+	 + bbbb		 +y{ } +$ik$+	 + F@LOAD<SAVE ,*****.$$$$/*****- E@EXIT			 ,\]^_-			 V1@0"		
1230 DATA "ZamZbmZcmZdl[am[bg[ci[dm\am\bh\cj\dm]am]bm]cm]dm^ak^bk^ck^dn_am_bg_ci_dm`am`bh`cj`dmaamabmacmadmbZ_b[ab]cb^ecS^cZ`c[bc]dc^f***"

When you dismiss all the char & colour data statements (which are required regardless), plus the 6 lines which make up the drawing routine, you are basically left with a reasonably small amount of data responsible for displaying 768 characters - so grabbing complex screens is made fast and not occupy too much XB & XB Compiler programming space.

1170 DATA " ````````````````	 MENU c%%%%%%%%%%%%%%%%a	 :::: c%%%%%%%%%%%%%%%%a 1@SELECT CHARc%%%%%%%%%%%%%%%%a 2@FILL;ERASE "		
1180 DATA "c%%%%%%%%%%%%%%%%a 3@INVERT;MOVEc%%%%%%%%%%%%%%%%a 4@SWAP;COPY c%%%%%%%%%%%%%%%%a 5@HEX CODES c%%%%%%%%%%%%%%%%a 6@COLOUR	 "		
1190 DATA "c%%%%%%%%%%%%%%%%a 7@MEDIA SETUPc%%%%%%%%%%%%%%%%a 8@HELP	 c%%%%%%%%%%%%%%%%a			 c%%%%%%%%%%%%%%%%a ```` MEDIA "		
1200 DATA "c%%%%%%%%%%%%%%%%ac a::::: c%%%%%%%%%%%%%%%%ac a>PLAYINGc%%%%%%%%%%%%%%%%ac a[4	 c%%%%%%%%%%%%%%%%ac a	 "		
1210 DATA "c%%%%%%%%%%%%%%%%ac a>SHOWING bbbbbbbbbbbbbbbb c a[5=[6=[7 BG [1(*&'*)[3 [4 c a;[8 PLUS(*****.$$$$/*****)c aB<GROUND"		
1220 DATA "+xz |~+$hj$+	 + bbbb		 +y{ } +$ik$+	 + F@LOAD<SAVE ,*****.$$$$/*****- E@EXIT			 ,\]^_-			 V1@0"		
1230 DATA "ZamZbmZcmZdl[am[bg[ci[dm\am\bh\cj\dm]am]bm]cm]dm^ak^bk^ck^dn_am_bg_ci_dm`am`bh`cj`dmaamabmacmadmbZ_b[ab]cb^ecS^cZ`c[bc]dc^f***"

Because the above data contains no characters that get lost when pasting between text editors ie- chars <32 & >126 , nothing gets lost when using text editors. I needed a solution for this problem during a time the XB Compiller does not support disc file functions.

Sorry to rave. This info really belongs in its own thread when I finsh the program.

January 15, 2013

OK.. So after testing and getting good answers, I put it into my program and the numbers are now coming out strange with -9's and stuff like that. So at this stage, I don't have a fix. Ahhh... The highs and then the lows.

January 15, 2013

Thanks for the feedback guys. Greatly appreciated.

An assembly language program can be used to read the bytes from VDP into CPU memory where they can be PEEKed. The following is one way to do it:

START LWPI WKSP

LI R0,>080F character set 0 starts at this vdp address

LI R1,10000 read to this address

LI R2,17 17 bytes

BLWP @>202C vdp multiple byte read

LWPI >83E0

B @>006A back to basic

WKSP BSS 32

The following XB program will load this A/L program into memory and run it, then return to XB.

10 CALL LOAD(9460,2,224,37,16,2,0,8,15,2,1,39,16,2,2,0,17,4,32,32,44,2,224,131,224,4,96,0,106)

20 CALL LOAD(8192,36,244)::CALL LINK("X")::CALL LOAD(8192,32,90)

After the program runs 17 bytes of the color table are copied into CPU RAM starting at 10000. Now you can PEEK the bytes and determine the color of any character set. To find out the color of character set 3:

CALL PEEK(10003,X)::FG=1+INT(X/16)::BG=FG*16-X-15

Unfortunately the screen color is set by writing to a VDP register and I don't think there is any way that you can read from the register.

This seems like this should fit my requirements really well, I can *just* get by with not knowing the screen colour.

I have NEVER stepped outside of XB. Everything to do with Assembler makes me want to take up the fetal position in a dark room.... Everything is, unknown, kinda scary and I suspect out of my league so please excuse me asking some (probably) dumb questions

To test the above I copied pasted the following into EA;

START LWPI WKSP
LI R0,>080F
LI R1,10000
LI R2,17
BLWP @>202C
LWPI >83E0
B @>006A
WKSP BSS 32

I then attempted to assemble this file. I got the following message.

END ASSUMED - 0009

0001 ERRORS

Is END ASSUMED the 0001 error or is END ASSUMED just a passing comment?

I tried it anyway in XB after the above error and was surprised to see the FG was always reported correctly, however BG value is incorrect - but still fairly usable with a little work (awesome!).

COL / BG VALUE

1 / 1

2 / 0

3 / 1

4 / 2

5 / 3

6 / 4

7 / 5

8 / 6

9 / 7

10 / 8

11 / 9

12 / 10

13 / 11

14 / 12

15 / 13

16 / 14

Regarding the incorrect BG answer liseted above, is this the result of the Assembling 0001 ERROR, or a calc error with FG/BG or is there a reasonable chance I have just stuffed it all up?

But.... at the end of the day I think this really nailed things for me so thanks heaps.

January 14, 2013

Linput.....LINPUT!

I spent all yesterday going through the Users Reference Guide (I always use this because I find the file functions are very well described here), without even thinking about XB commands. Linput, for whatever reason, is one of those commands I either forgot about or just never discovered. After your post I pulled out the XB manual and started reading and yep - Linput was the magic bullet for my problem. Everything is now working exactly as I had hoped. THANKS WILLSY!

Re the fixed length files, at this stage I do need to access the files randomly so not too concerned about this option at the moment. Once all the testing etc is over I may look closer at fine tuning areas like this. Right now I just want to get my program completed and confirm my idea works OK.

January 14, 2013

I have come up with a real issue that has me stumped. If I can't find a solution, I think I can still make things work - but I will be forced to avoid some features I wanted to implement in what could otherwise be a pretty handy little application (aimed at the XB enthusiast who is using the XB compiler).

Here is an example which illustrates my issue;

100 CALL CLEAR
110 OPEN #1:"DSK1.FTEST",RELATIVE,DISPLAY ,UPDATE,FIXED 255
120 A$="Hello,World"
130 PRINT ">A$ IS;" :: PRINT " "&A$ :: PRINT
140 A$="1000 DATA "&CHR$(34)&A$&CHR$(34):: PRINT ">A$ CHANGED TO; ":" "&A$ :: PRINT
150 PRINT ">SAVING A$ TO "&CHR$(34)&"DSK1.FTEST"&CHR$(34)&" AT RECORD 1" :: PRINT #1,REC 1:A$ :: PRINT
160 PRINT ">READING RECORD 1 BACK FROM DISC AND ASSIGNING VALUE TO B$."
170 INPUT #1,REC 1:B$ :: PRINT
180 PRINT ">LENGTH OF A$="&STR$(LEN(A$));". A$ IS;" :: PRINT " "&A$ :: PRINT
190 PRINT ">LENGTH OF B$="&STR$(LEN(B$))&". B$ IS;" :: PRINT " "&B$ :: PRINT
200 END

I can get the correct answer by changing line 110 to;

110 OPEN #1:"DSK1.FTEST",RELATIVE,INTERNAL ,UPDATE,FIXED 255

* If replacing line 110 with above, remember to first delete "DSK1.FTEST" or you will get an I/O error due to the change in file-type.

However, for my particular project I can not use INTERNAL as the file-type. I am 100% stuck on needing to use DISPLAY as the file-type.

The program I am creating will write a set of records which when viewed is in the form of a XB Line Numbered Program. The idea is that these records (program lines), can then be viewed with Ti99Dir and copied/pasted back into any XB program which is intended for XB Compiling or general XB use.

Using the DISPLAY file-type still allows this to be possible (thank goodness), as the written records remain in the correct format and can be properly copied/pasted into Classic99 as intended(1000 "DATA Hello,World"), but the program I am writing also needs to access and manipulate these same records before it completes - this is where commas are triggering some major problems when I try to read the information back within my own program. I was able to fool things somewhat by adding additional quotation marks but then this effects the format of the records I am writing which makes it impossible to then paste back to Classic99 (pasted line numbers are getting the old * UNMATCHED QUOTES error and of course the syntax is horrible anyway).

I have been over and over the file documentation and from what I can tell the TI is doing exactly what it is supposed to - the comma is splitting the file record when using the INPUT file command. The one thing I am very thankful for is that when viewing the record it is correct. In the above example Record 1 correctly lists 1000 DATA "Hello,World" - As this is the data I want to Copy/Paste (the whole intention of my program), then ultimately I can still make my program work.

The single fix I have is replacing line 170 with;

170 INPUT #1,REC 1:B$,C$ :: B$=B$&","&C$

-But this is not a suitable fix because although I now get the correct answer, I need to know about the comma before it is encountered and even if I could teach my program to learn about future commas (which would be easy enough), it would then throw my entire file structure and records into a nightmare - Especially if the string I need to work on resembles something like; 1000 DATA ",,,,,g,,,,,d,,,,#" (which is possible)

Any ideas? I need a way to write DISPLAY type files and not have the comma mess things up when I try to read the information back and manipulate the data, and at the same time I can't have quote marks in places they don't belong as it messes up the syntax and makes copying/pasting into Classic99 impossible.

I think I am asking the impossible with my problem but I am tired and have been hitting a brick wall all day with this issue. A simple solution I haven't thought about might be staring me in the face....?.

For what it is worth I am writing a Screen Capture/Optimised Char Writer program which will take Magellan output (or any displayed 24*32 screen) and turn everything into an optimised format that can then be copied/pasted into a XB program. Creating these files (which are actually little pastable programs), allows a work around for getting this "optimised screen format" back into a XB program which can not access disc files. i.e. - Programs intended for the XB Compiler. This concept may also be part of a larger application I have been toying with.

If I can overcome this current problem I am having I am then about 80% finished and should be able to release the program in a few days for testing.

January 11, 2013

I am writing an XB program at the moment and I would like to be able to determine the screen colour plus the foreground and background colour for each colour set, without knowing in advance what the values were set at. I can't help but think this question came up once before....

Does anybody know if this information can be retrieved with the right CALL PEEK's?

On the PEEK concept, if I wrote a small program to write every peek value from -32767 through to 32767 to disc, then made a single change of screen colour or colour set to the program, would I be able to drill down where this information is held by comparing a second scan of peek values and investigating the values which have changed? ie- Would changes in before/after PEEK values lead me to the information I need?

Thanks guys.

January 11, 2013

Well glad you found it considering the description I gave you. Checking myself I found the actual book was the "User's Reference Guide". At least I got the colour correct, except for all the white, yellow, blue and cyan..... Glad I am not testifying in a court of law.

January 11, 2013

The green BASIC book that comes with the TI has a comprehensive section or errors and covers the I/O erorrs really well. Don't have it with me at the moment, but from memory it is about 3/4 the way through.

December 28, 2012

You are running up against the line number bug that Rich G. discovered.

Thanks for your help. A res certainly solved the problem.

XB compiled then run with Classic CPU throttling is certainly going to make for some fun times.

December 28, 2012

Still playing with this to get some ideas of speed etc. I threw together a small routine which runs fine in XB and does what it is supposed to, and it also assembles without errors - but when running the XB compiled program the dots don't move. Also when I try to BREAK the program it locks up with a buzz. Any ideas what the issue is?

100 DIM X(28),XD(28),XS(28),Y(28),YD(28),YS(28)
110 CALL CLEAR :: CALL SCREEN(2):: CALL CHAR(128,"000001"):: CALL COLOR(13,14,2)
120 CALL CHAR(129,"00000000000000FF"):: CALL CHAR(130,"FF"):: CALL CHAR(131,"0101010101010101"):: CALL CHAR(132,"8080808080808080")
130 CALL HCHAR(5,5,129,23):: CALL HCHAR(20,5,130,23):: CALL VCHAR(6,4,131,14):: CALL VCHAR(6,28,132,14)
140 FOR I=1 TO 28
150 X(I)=95 :: Y(I)=117
160 XD(I)=INT(RND*2)+1 :: YD(I)=INT(RND*2)+1
170 XS(I)=INT(RND*4)+1 :: YS(I)=INT(RND*4)+1
180 CALL SPRITE(#I,128,(RND*13)+3,X(I),Y(I))
190 NEXT I
200 FOR I=1 TO 28
210 IF XD(I)=1 THEN 220 :: X(I)=X(I)-XS(I):: GOTO 230
220 X(I)=X(I)+XS(I)
230 IF YD(I)=1 THEN 240 :: Y(I)=Y(I)-YS(I):: GOTO 250
240 Y(I)=Y(I)+YS(I)
250 IF X(I)<40 THEN 260 :: GOTO 270
260 X(I)=41 :: XD(I)=1 :: GOTO 290
270 IF X(I)>150 THEN 280 :: GOTO 290
280 X(I)=149 :: XD(I)=2
290 IF Y(I)<26 THEN 300 :: GOTO 310
300 Y(I)=27 :: YD(I)=1 :: GOTO 330
310 IF Y(I)>208 THEN 320 :: GOTO 330
320 Y(I)=207 :: YD(I)=2
330 CALL LOCATE(#I,X(I),Y(I)):: CALL COLOR(#I,(RND*13)+3):: NEXT I :: GOTO 200

December 26, 2012

Nope - no disk access.

If this a future possibility?

Not a request and I have no idea of the challenge that implementing something like this would take, but wow - it would rock big time with file access.

BTW - I am loving really this compiler! Thanks for the effort.

December 22, 2012

I did the download and had a play with this today. Only being an XB programmer I can really see a lot of potential from this compiler and I was fascinated by the results. In short this is awesome!

July 11, 2012

For what it is worth... Attached is the document I was talking about. As I said, it's pretty unorganised and likely won't make much sense to anyone.

GA7.zip

July 11, 2012

What I have so far is more a collection of crap rather than a program. I have it all on an Excel spreadsheet - snippets of code, character defs, file & variable descriptions etc that nobody (including me for the most part), would make sense from. I have been going through it since the thread was bumped and I actually think time away has given me a fresh set of eyes on the whole idea. I have come up with some new ideas I don't remember having earlier. To be honest I think the little thread bump has re-excited me about this program.

My time management at the moment is just plain terrible so while I would be interested in playing any part in a "group project", and graphics would suit me probably quite well, I will just end up letting people down if I was to accept at this time.

July 2, 2012

I really got on a roll with this one. Had a few levels almost created and was finalising some of the little programming challenges. It was almost writing itself. Then life got in the way and I haven't returned. I am sure I will return but will now have to almost start from scratch because my whole thought process now is gone. Not sure when time will allow me to throw some time at this project.

January 31, 2012

Probably not.... This was just to burn a few hours - But I do like some of the effects so you never know.

It also never occured to me just how quick CALL PATTERN was in XB. I always knew it was quicker than CALL CHAR as a potential alternative but I never noticed until doing this little excercise just how quick it was.

January 29, 2012

Another little one to add....


100 CALL CLEAR :: CALL SCREEN(12):: CALL MAGNIFY(4)
110 FOR I=40 TO 88 STEP 4 :: READ A$ :: CALL CHAR(I,A$):: NEXT I
120 CALL SPRITE(#1,40,5,100,100)
130 CALL SPRITE(#2,48,2,100,100)
135 CALL SPRITE(#3,44,15,100,100)
140 FOR I=52 TO 88 STEP 4 :: CALL PATTERN(#2,I):: NEXT I :: GOTO 140
1000 ! TYRE AND CENTRE ANIM 1
1010 DATA 00071F386060C0C3C2C3C06060381F0700C0F0380C0C06868686060C0C38F0C0
1020 ! centre colour
1025 DATA 000000071F1F3F3C3D3C3F1F1F070000000000C0F0F0F8787878F8F0F0C00000
1030 ! SPOKES ANIM 2
1040 DATA 00000000000101310E010101020200000000008080000000E018000000000000
1050 ! SPOKES ANIM 3
1060 DATA 000000000000013906010102020200000000008080800000C038000000000000
1070 ! SPOKES ANIM 3
1080 DATA 000000000000003D020102020202000000000080808080008078000000000000
1090 ! SPOKES ANIM 4
1100 DATA 000000000000100D020102020400000000000000408080008060100000000000
1110 ! SPOKES ANIM 5
1120 DATA 0000000000100805020102040800000000000000204080008040201000000000
1130 ! SPOKES ANIM 6
1140 DATA 0000000010080403020304081000000000000000102040808080402010000000
1150 ! SPOKES ANIM 7
1160 DATA 0000000008080403020304180000000000000000003040808080402020000000
1170 ! SPOKES ANIM 8
1180 DATA 000000040404040302033C000000000000000000000078808080404040400000
1190 ! SPOKES ANIM 9
1200 DATA 000000020404040302231C000000000000000000000070888080404040800000
1210 ! SPOKES ANIM 10
1220 DATA 000000020204040302330C000000000000000000000060988080404080800000
1230 !SPOKES ANIM 11
1240 DATA 0000000202020203023F00000000000000000000000000F88080808080800000

January 29, 2012

I was so bored today after a week of rainy weather so I started fiddling... Ignore the crappy programing, was just playing to see what certain sprites/animations look wike when put together. Thought I might as well share them!

100 CALL CLEAR :: CALL SCREEN(12):: CALL MAGNIFY(3)
110 READ A$ :: CALL CHAR(96,A$)
120 READ A$ :: CALL CHAR(100,A$)
130 CALL SPRITE(#1,96,2,100,100)
140 CALL SPRITE(#3,100,8,100,100)
150 RESTORE 1020
160 FOR I=104 TO 116 STEP 4 :: READ A$ :: CALL CHAR(I,A$):: NEXT I
170 CALL SPRITE(#2,100,7,100,100)
171 READ A$ :: CALL CHAR(128,A$)
172 CALL SPRITE(#4,128,5,100,100)
180 FOR I=104 TO 116 STEP 4 :: CALL PATTERN(#2,I)
185 B=RND :: B=RND
190 NEXT I :: GOTO 180
999 ! OUTSIDE CIRCLE
1000 DATA 0718234C5090A0A0A0A090504C231807E018C4320A0905050505090A32C418E0
1009 ! INSIDE CIRCLE FILL
1010 DATA 00071C302060404040406020301C070000E0380C04060202020206040C38E000
1019 ! POSITION 1
1020 DATA 00071C302060404040406020301C07000000000000000000020206040C38E000
1029 ! POSITION 2
1030 DATA 00071C302060404040406020301C070000E0380C040602020000000000000000
1039 ! POSITION 3
1040 DATA 00071C3020604040000000000000000000E0380C04060202020206040C38E000
1049 ! POSITION 4
1050 DATA 000000000000000040406020301C070000E0380C04060202020206040C38E000
1059 ! INSIDE CIRCLE
1060 DATA 000000030F0F1F1F1F1F0F0F03000000000000C0F0F0F8F8F8F8F0F0C0000000

100 CALL CLEAR :: CALL SCREEN(5):: CALL MAGNIFY(3)
110 FOR I=96 TO 120 STEP 4 :: READ A$ :: CALL CHAR(I,A$):: NEXT I
120 CALL SPRITE(#20,96,2,100,100)
130 CALL SPRITE(#21,100,7,100,100)
140 CALL SPRITE(#22,104,13,100,100)
150 CALL SPRITE(#1,108,11,100,100)
160 FOR I=108 TO 120 STEP 4 :: CALL PATTERN(#1,I)
170 B=RND
180 NEXT I :: GOTO 160
1000 ! CIRCLE OUTLINE
1010 DATA 0000030C13142828282814130C0300000000C030C8281414141428C830C00000
1020 ! CIRCLE INSIDE FILL
1030 DATA 000000030C0810101010080C03000000000000C03010080808081030C0000000
1040 ! CIRCLE CORE FILL
1050 DATA 000000000003070707070300000000000000000000C0E0E0E0E0C00000000000
1060 ! CIRCLE ROTATE 1
1070 DATA 000000030C0810101010080C03000000000000000000000008081030C0000000
1080 ! CIRCLE ROTATE 2
1090 DATA 000000030C0810101010080C03000000000000C0301008080000000000000000
1100 ! CIRCLE ROTATE 3
1110 DATA 000000030C0810100000000000000000000000C03010080808081030C0000000
1120 ! CIRCLE ROTATE 4
1130 DATA 00000000000000001010080C03000000000000C03010080808081030C0000000

1 ! HOURGLASS ANIMATION
100 CALL CLEAR :: CALL SCREEN(2):: CALL MAGNIFY(3)
110 FOR I=72 TO 140 STEP 4 :: READ A$ :: CALL CHAR(I,A$):: NEXT I
120 CALL SPRITE(#1,72,8,100,100)
130 CALL SPRITE(#2,76,5,100,100)
140 FOR I=76 TO 140 STEP 4 :: CALL PATTERN(#2,I)
150 A=RND
160 NEXT I
170 FOR I=1 TO 500 :: NEXT I :: GOTO 140
1000 ! HOURGLASS OUTLINE
1010 DATA 3F10080804040201010204080810103FFE0408081010204040201008080404FE
1020 ! FULL / START
1030 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808000000000000000
1040 ! ANIM 1
1050 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808080000000000000
1060 ! ANIM 2
1070 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808080800000000000
1080 ! ANIM 3
1090 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808080808000000000
1100 ! ANIM 4
1110 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808080808080000000
1120 ! ANIM 5
1130 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808080808080800000
1140 ! ANIM 6
1150 DATA 000F070703030100000000000000000000F8F0F0E0E0C0808080808080808000
1160 ! ANIM 7
1170 DATA 000F070703030100000000000000010000F8F0F0E0E0C080808080808080C000
1180 ! ANIM 8
1190 DATA 000007070303010000000000000103000000F0F0E0E0C0808080808080C0E000
1200 ! ANIM 9
1210 DATA 00000007030301000000000001030700000000F0E0E0C08080808080C0E0F000
1220 ! ANIM 10
1230 DATA 00000000030301000000000001030F0000000000E0E0C08080808080C0E0F800
1240 ! ANIM 11
1250 DATA 000000000003010000000000030F0F000000000000E0C08080808080E0F8F800
1260 ! ANIM 11
1270 DATA 000000000000010000000001070F0F00000000000000C080808080C0F0F8F800
1280 ! ANIM 12
1290 DATA 000000000000000000000003070F0F000000000000000080808080E0F0F8F800
1300 ! ANIM 13
1310 DATA 000000000000000000000007070F0F000000000000000000808080F0F0F8F800
1320 ! ANIM 14
1330 DATA 000000000000000000000307070F0F0000000000000000008080E0F0F0F8F800
1340 ! ANIM 15
1350 DATA 000000000000000000010307070F0F00000000000000000000C0E0F0F0F8F800

1 ! BEAKER
100 CALL CLEAR :: CALL SCREEN(2):: CALL MAGNIFY(3)
110 FOR I=36 TO 124 STEP 4 :: READ A$ :: CALL CHAR(I,A$):: NEXT I
120 CALL SPRITE(#1,36,8,100,100)
130 CALL SPRITE(#2,40,5,100,100)
140 FOR I=44 TO 124 STEP 4 :: CALL PATTERN(#2,I)
150 A=RND
160 NEXT I
170 GOTO 140
1000 ! BEAKER OUTLINE
1010 DATA 00000000000002020202040808080403000000000000404040402010101020C0
1020 ! FLUID START
1030 DATA 0000000000000000000000000000000000000000000000000000000000000000
1040 ! ANIM 1
1050 DATA 00000000000000000000000005070300000000000000000000000000E0E04000
1060 ! ANIM 2
1070 DATA 00000000000000000000000207070300000000000000000000000000E060C000
1080 ! ANIM 3
1090 DATA 00000000000000000000010007050300000000000000000000000000A0E0C000
1100 ! ANIM 4
1110 DATA 00000000000000000001000005070300000000000000000000000040E0E04000
1120 ! ANIM 4
1130 DATA 00000000000000000000000207070300000000000000000080004000E060C000
1140 ! ANIM 5
1150 DATA 0000000000000001000002000707020000000000000000000080000060E08000
1160 ! ANIM 6
1170 DATA 00000000000000000100010007050300000000000000800000000040E0A0C000
1180 ! ANIM 7
1190 DATA 00000000000000000001000005070300000000000080008000004000C0E04000
1200 ! ANIM 8
1210 DATA 00000000000001000100000207070100000000008000000000800020E060C000
1220 ! ANIM 9
1230 DATA 0000000000010001000002000705030000000040000000008000002060E0C000
1240 ! ANIM 10
1250 DATA 0000000002000001000100000507030000A040A00000800000004080E060C000
1260 ! ANIM 11
1270 DATA 0000020502000000010001040707030000000000400080000080000060E0C000
1280 ! ANIM 12
1290 DATA 00000000000000010001020007070300000000200080000080000080E0E0C000
1300 ! ANIM 13
1310 DATA 00000000000001000101000007070300001028108000008000004000E0E0C000
1320 ! ANIM 14
1330 DATA 00000001000200000100000007070300000080408040008000000000E0E0C000
1340 ! ANIM 15
1350 DATA 000000040A0400010000000007070300000000205020800000000000E0E0C000
1360 !ANIM 16
1370 DATA 00000000000001000000000007070300000000000080000000000000E0E0C000
1380 !ANIM 17
1390 DATA 00000000000100000000000007070300000000004000000000000000E0E0C000
1400 !ANIM 18
1410 DATA 00000000020000000000000007070300000000200000000000000000E0E0C000
1420 !ANIM 20
1430 DATA 00020502000000000000000007070300000010000000000000000000E0E0C000
1440 ! ANIM 21
1450 DATA 00000000000000000000000007070300040A04000000000000000000E0E0C000

1 ! ROTATE CIRCLES
100 CALL CLEAR :: CALL SCREEN(2):: CALL MAGNIFY(4)
110 FOR I=96 TO 132 STEP 4 :: READ A$ :: CALL CHAR(I,A$):: NEXT I
120 CALL SPRITE(#1,96,8,100,100)
130 CALL SPRITE(#2,104,5,100,100)
135 CALL SPRITE(#3,100,7,100,100)
140 FOR I=104 TO 132 STEP 4 :: CALL PATTERN(#2,I)
150 A=RND
160 NEXT I
170 GOTO 140
1000 ! CIRCLE
1010 DATA 01324A493000609090600030494A3201804C52920C0006090906000C92524C80
1020 ! CIRCLE FILL
1030 DATA 0001313000000060600000003031010000808C0C00000006060000000C8C8000
1040 ! ANIM 1
1050 DATA 0001010000000000000000000000000000808000000000000000000000000000
1060 ! ANIM 2
1070 DATA 0000000000000000000000000000000000000C0C000000000000000000000000
1080 ! ANIM 3
1090 DATA 0000000000000000000000000000000000000000000000060600000000000000
1100 ! ANIM 4
1110 DATA 000000000000000000000000000000000000000000000000000000000C0C0000
1120 ! ANIM 5
1130 DATA 0000000000000000000000000001010000000000000000000000000000808000
1140 ! ANIM 6
1150 DATA 0000000000000000000000003030000000000000000000000000000000000000
1160 ! ANIM 7
1170 DATA 0000000000000060600000000000000000000000000000000000000000000000
1180 ! ANIM 8
1190 DATA 0000303000000000000000000000000000000000000000000000000000000000

December 15, 2011

I would like to see the Classic99 screen bordered by the image of old TV set.... But s'pose that's just being silly.

December 4, 2011

I can't check it on an emulator or original equipment at this time so just going from memory, but try putting a space between beep & size.

June 30, 2011

Quick update here as I have been missing in action lately.

Grotto Escape is still very much on the go. I have lately been spending a lot of time working out the best method to control and keep track of enemies.

My intention was once a screen has scrolled to a new location, enemies will "spawn" into existence. The trigger for controlling this information with so many maps is becoming a fine balance.

There are 26 enemy variables for each level which contain an enemy. My original intention was to load these variables either from disk or from program data upon initialization to keep the game play as smooth as possible (of the 26 variables only a couple will be required for the game save feature with the rest being fixed values). To load these during initialization I need something that resembles DIM (56,26) but this does put a huge drain on the little TI's memory. The alternative is to load 26 variables into a single one dimension array and read the new values each time the player scrolls to a new level. The preferred method is to fetch these values from disk so I am not needlessly chewing up Program Stack space but my testing shows this process will take around 4 seconds each time a new level is scrolled into play (even with CPU throttling).

At this moment I am leaning towards the pre-game initialization method (with values read from disk) but with the variables I have so far determined I need during the game this only leaves me around 2K to play with. If there is something I hadn't yet thought about this 2K with get chewed through real quickly. If I could get it down to a 4K buffer I am almost at the point now where I can start putting all the pieces together with confidence that the end product won't result in memory issues.

More homework needed.

April 5, 2011

So, with your permission, I'd like to take your game and port it. Is that ok?

Mark, this would be fine, not only do I not have any objections to such a suggestion - I am excited that it might be possible.

Will get my head down and ass up and try and get it finished before the RDGC contest closes.

April 4, 2011

Please make this into a Rainy Day Game Contest (RDGC) entry - deadline 1st of July (IIRC).

Will see how I go. Don't have a lot of time these days so can only slowly chip away at it...

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by Bones-69