Fractals

[lucien2]

Here are fractals in GPL.

 

This is not the first fractal program for the TI. I have "Fractal Explorer" from Steve Langguth, I don't know where it comes from.

 

In the Lima user group disks, there is "mandelzoon" in 150B.DSK, "FLOGO" in 172A.DSK, "FRACT-NTSC" in 174A.DSK, and "FRACTALS" in 817.DSK. (I didn't try any of those).

 

What is annoying with the Weiand's GPL assembler is that it doesn't compile floating point constants. Another problem is that there is no "integer to float" conversion routine (CIF) in the ROM. So I had to use floats for my counters. I started to convert the CIF function from the E/A cartridge to GPL, but it was to long.

 

The next step is to implement the zooming function and save/load the result to a file.

 

2 ways to run it:

FRACTALS/FRACTALT - EA5 program with Weiand's GPL simulator included (no hardware needed, slower)

FRACTALS@O - Compressed object file to load at GRAM >C000 with GPL@LOADER (runs fine with classic99, check "Options/GRAM/>C000")

 

I wanted to generate a GROM cartridge file: How do I convert a GPL object file to that?

 

 

GROM >C000

DATA >AA00,>0100,>0000

DATA MENU

DATA >0000,>0000,>0000,>0000

MENU DATA >0000

DATA START

STRI 'FRACTALS'

 

OXS TEXT '-2.15'

BYTE 0

OYS TEXT '-1.05'

BYTE 0

ZS TEXT '0.045'

BYTE 0

 

ONE DATA >4001,>0000,>0000,>0000

TWO DATA >4002,>0000,>0000,>0000

FOUR DATA >4004,>0000,>0000,>0000

SIXTYFOUR DATA >4040,>0000,>0000,>0000

FOURTYEIGHT DATA >4030,>0000,>0000,>0000

FOURTEEN DATA >400D,>0000,>0000,>0000

FMAX DATA >4028,>0000,>0000,>0000

COLORS BYTE 6,8,9,11,10,3,2,12,7,5,4,13,15,1

 

FLAGS EQU >83FD

CCHA EQU >837D

 

B1 EQU >8300

B2 EQU >8301

W1 EQU >8302

W1H EQU >8302

W1L EQU >8303

W2 EQU >8304

B3 EQU >8306

B4 EQU >8307

 

RAM EQU >A000

T32 EQU RAM

OX EQU RAM+32

OY EQU RAM+40

Z EQU RAM+48

X0 EQU RAM+56

Y0 EQU RAM+64

X EQU RAM+72

Y EQU RAM+80

X2 EQU RAM+88

Y2 EQU RAM+96

X2SQU EQU RAM+104

Y2SQU EQU RAM+112

IT EQU RAM+120

MAX EQU RAM+122

X3 EQU RAM+124

FIT EQU RAM+132

COL EQU RAM+140

RAMEND EQU RAM+142

 

 

START

MOVE 6,G@OXS,V@>1000

DST >1000,@FAC+12

XML CSN

MOVE 8,@FAC,@OX

 

MOVE 6,G@OYS,V@>1000

DST >1000,@FAC+12

XML CSN

MOVE 8,@FAC,@OY

 

MOVE 6,G@ZS,V@>1000

DST >1000,@FAC+12

XML CSN

MOVE 8,@FAC,@Z

 

ST 40,@MAX

 

CALL MCCLEAR

CALL MCMODE

 

DCLR @X

DCLR @Y

 

PIXEL

MOVE 8,@X,@FAC

MOVE 8,@Z,@ARG

XML FMUL

MOVE 8,@OX,@ARG

XML FADD

MOVE 8,@FAC,@X0

 

MOVE 8,@Y,@FAC

MOVE 8,@Z,@ARG

XML FMUL

MOVE 8,@OY,@ARG

XML FADD

MOVE 8,@FAC,@Y0

 

DCLR @X2

DCLR @Y2

CLR @IT

DCLR @FIT

 

ITERATION

MOVE 8,@X2,@FAC

MOVE 8,@X2,@ARG

XML FMUL

MOVE 8,@FAC,@X2SQU

 

MOVE 8,@Y2,@FAC

MOVE 8,@Y2,@ARG

XML FMUL

MOVE 8,@FAC,@Y2SQU

MOVE 8,@X2SQU,@ARG

XML FADD

 

MOVE 8,G@FOUR,@ARG

XML FCOMP

GT

BR DRAW

 

CH @IT,@MAX

BR DRAW

 

MOVE 8,@X2SQU,@ARG

MOVE 8,@Y2SQU,@FAC

XML FSUB

MOVE 8,@X0,@ARG

XML FADD

MOVE 8,@FAC,@X3

 

MOVE 8,@X2,@FAC

MOVE 8,@Y2,@ARG

XML FMUL

MOVE 8,G@TWO,@ARG

XML FMUL

MOVE 8,@Y0,@ARG

XML FADD

MOVE 8,@FAC,@Y2

MOVE 8,@X3,@X2

 

MOVE 8,@FIT,@FAC

MOVE 8,G@ONE,@ARG

XML FADD

MOVE 8,@FAC,@FIT

INC @IT

 

B ITERATION

 

DRAW

MOVE 8,@X,@FAC

XML CFI

ST @FAC+1,@XPT

MOVE 8,@Y,@FAC

XML CFI

ST @FAC+1,@YPT

 

MOVE 8,@FIT,@ARG

MOVE 8,G@FMAX,@FAC

XML FDIV

MOVE 8,G@FOURTEEN,@ARG

XML FMUL

XML CFI

DST @FAC,@>8300

* ?? CRASH.

* MOVE 1,G@COLORS(@>8300),@CCHA

MOVE 1,G@COLORS(@>8300),@COL

ST @COL,@CCHA

 

MOVE 8,@X,@FAC

MOVE 8,G@ONE,@ARG

XML FADD

MOVE 8,@FAC,@X

 

MOVE 8,G@SIXTYFOUR,@ARG

XML FCOMP

GT

BS PIXEL

 

DCLR @X

 

MOVE 8,@Y,@FAC

MOVE 8,G@ONE,@ARG

XML FADD

MOVE 8,@FAC,@Y

 

MOVE 8,G@FOURTYEIGHT,@ARG

XML FCOMP

GT

BS PIXEL

 

 

END B END

 

 

MCMODE

******

ST >E8,@B1

MOVE 1,@B1,#1

ST 2,@FLAGS

 

CLR @B1

CLR @B3

DCLR @W2

 

MC1 DCLR @W1

MC3 ST @B1,@T32(@W1)

DINC @W1

INC @B1

DCHE >20,@W1

BR MC3

 

CLR @B2

MC2 MOVE >20,@T32,V*W2

DADD >20,@W2

INC @B2

CHE 4,@B2

BR MC2

 

INC @B3

CHE 6,@B3

BR MC1

 

RTN

 

 

MCCLEAR

*******

DST >800,@W1

MCC1 DCLR V*W1

DINCT @W1

DCHE >E00,@W1

BR MCC1

RTN

 

END

 

FRACTALS.zip

[Gazoo]

 

I wanted to generate a GROM cartridge file: How do I convert a GPL object file to that?

 

 

Use the CARTSAVE program. It's pretty intuitive. You shouldn't need any docs.

Looks like you've got a cart header properly set up, so it's just a matter of running

CARTSAVE after you've loaded your code and saving the proper Grom bank.

 

ftp://ftp.whtech.com/9640news/CAT24/CARTSAVE.ARK

 

 

Gazoo

[lucien2]

Use the CARTSAVE program.

 

Thanks. It worked to save a cartridge from GRAM >C000. But classic99 loads GROM cartridges at >6000 by default, so you must add a line in classic99.ini with "G|C000|1800".

 

The problem is if I put my program at GRAM>6000, I can't load CARTSAVE anymore.

[Gazoo]

Thanks. It worked to save a cartridge from GRAM >C000. But classic99 loads GROM cartridges at >6000 by default, so you must add a line in classic99.ini with "G|C000|1800".

 

The problem is if I put my program at GRAM>6000, I can't load CARTSAVE anymore.

 

Cartsave loads at c>A000. There should be no conflict.

Is it because you're using EA to load it? Use a relocated EA image.

 

Gazoo

[+Torrax]

Here's CSAVE -- an EA Opt5 program. There is plenty of user selectable options after the intial "filename to save" prompt.

CSAVE.zip

[+Torrax]

Oops... Just checked out CARTSAVE -- same program. My file has no docs or the L&R version.

Edited March 20, 2013 by Torrax

[lucien2]

Is it because you're using EA to load it? Use a relocated EA image.

 

Yes I'm using EA to load it, with classic99, so it's not possible to load it with TI-BASIC (No disk controller commands).

 

Maybe there is another emulator with GRAM. I tried to enable the HSGPL card in MESS 0.136, but then I only have a black screen when I start the emulator.

 

A relocated EA image? It seems to be a hard thing to find. How could that be named? EARELOC? EAC000?

[lucien2]

OK, I found how to do it.

 

1. Load CARTSAVE

2. Warm restart (Keep RAM)

3. Load Fractal object file to GRAM >6000

4. With the debugger, change the PC to >A4A6 to run CARTSAVE

 

Here is the cartridge file: Fractals-Cartridge.zip

[Tursi]

Nice!

 

It might (MIGHT) also be helpful to know you can make a "ram" cartridge - basically to make Classic99 preload a file into RAM as part of startup. The type letter for RAM in Classic99.ini is 'R', and the rest is the same (load address, length, filename). This loads the file into memory like 'C' but doesn't mark it as ROM. You could create a custom cart that loads your CARTSAVE into RAM and your Fractal code into GROM.

 

You'd still be stuck with the debugger to get it to start at >A4A6, unless you made a custom ROM cart for CPU >6000, just a header with a name and a start address of >A4A6 would be enough.

 

If you had to do it many times in the course of debugging it might be helpful to set up. If you only need to do it once or twice your listed steps are probably enough.

[RXB]

You can use the RXB package.

Assemble the source with the GPL assembler be sure to use Compressed object code format.

Use the GPL@LOADER to load into >C000

Use CSAVE to save to to a GRAM format at >C000

 

Bingo you have a new cart file to load at >C000 or you could assemble it to any GROM address.

[lucien2]

Thanks, I tested both of your solutions.

 

@Rich: I didn't thought that REA was at GROM>E000, it works perfectly for my problem.

 

@Tursi: I didn't notice this "RAM Cartridge" feature. It works fine except that GPL@LOADER does not load the standard characters, but it does its job.

 

Here is the "GPL Utils" cartridge, with GPL@LOADER and CARTSAVE. Add these lines to classic99.ini:

 

[usercartXX]

name="GPL Utils"

rom0=C|6000|002E|mods\GPL Utils.C.bin

rom1=R|2000|0FFA|mods\GPL Loader.R.bin

rom2=R|A000|08FA|mods\CartSave.R.bin

GPL Utils.zip

[+mizapf]

Hello Lucien,

 

Maybe there is another emulator with GRAM. I tried to enable the HSGPL card in MESS 0.136, but then I only have a black screen when I start the emulator.

 

probably you have not set up the HSGPL properly.

 

http://www.ninerpedia.org/index.php/Setting_up_the_HSGPL_for_MESS

 

(however, this applies for versions 0.146 and higher, so you'd have to upgrade first.)

 

Michael

[lucien2]

...this applies for versions 0.146 and higher, so you'd have to upgrade first

 

It's nice to have a GRAM card fully emulated!

 

How do you load a GPL Tagged object file to the GRAM?

 

Here's is what I did:

1. Load the E/A module to GRAM bank 16

2. Return to TI-BASIC

3. CALL TIBASIC

4. CALL GRAM

5. Reset and select bank 0 (16)

6. Run E/A

7. Run GPL@LOADER

8. Load compressed object -> Error: No GRAM found at >C000

 

Another question: CALL HSGPL or EA5/HSGPLE40 bring me directly to the loader sub-menu. How do I go to the main menu?

[+mizapf]

Er ... do I still have a telephone joker? Sorry, I cannot give you more information about how to work with the HSGPL. I just did some elementary tests to make sure the emulation is good. Of course, if things don't work as in real, please tell me.

 

Michael

[jacquesg]

It's nice to have a GRAM card fully emulated!

 

How do you load a GPL Tagged object file to the GRAM?

 

Here's is what I did:

1. Load the E/A module to GRAM bank 16

2. Return to TI-BASIC

3. CALL TIBASIC

4. CALL GRAM

5. Reset and select bank 0 (16)

6. Run E/A

7. Run GPL@LOADER

8. Load compressed object -> Error: No GRAM found at >C000

 

Another question: CALL HSGPL or EA5/HSGPLE40 bring me directly to the loader sub-menu. How do I go to the main menu?

 

Lucien,

 

Here are the steps that I used to load your FRACTALS program into a bank of my HSGPL card.

 

1 - Ran the GPL source file through the Weiand GPL Assembler to create a compressed GPL object file.

2 - On my HSGPL card I had previously loaded file TK40G0 into all the banks from bank 0 to bank F. This makes TI BASIC accessible from any bank when you return to the title screen. There is also a file from Winfried Winkler which will also load into GROM 0 to 2. I prefer TK40G0.

3 - Prepared the HSGPL card to receive the object file. On my HSGPL card BANK 7 had GROM 6 and 7 empty. GROM 6 will receive a file loading at >C000. Enter from TI Basic CALL BANK(7) followed by CALL GWRON (turns gram write on) and return to title screen.

4 - Now run GPL*LOADER and it should indicate that the object file has been loaded at >C000.

5 - I cannot do a CALL HSGPL because it comes up as an 80 column program so I run EA5/HSGPLE40. Bank 7 will not show FRACTALS at GROM 6 but BANK(10)(16) will be a copy of BANK(7) and includes FRACTALS at GROM 6 being >C0000.

6 - You can copy the FRACTALS program from BANK(10) to any other BANK you want. To SAVE the file toggle off all the astericks except the one opposite GROM 6. Then press F to enter a file name and press S to save the file. Select a BANK where you want to load your file and press L to load the file.

 

When I first got my HSGPL card it took a lot of trial and error to understand what the various HSGPL CALLs did. I still have to reason it through but their use is now more easily understood. I assume that the MESS version works in a similar manner. I have never used MESS.

 

Jacques

[lucien2]

Thanks Jacques!

 

Your method works fine with MESS too.

 

The only step that was missing in my method was "CALL GWRON" to allow GRAM write...

[sometimes99er]

Fractals, or sort of, in Extended Basic.

 

100 CALL CLEAR::CALL SCREEN(2)::FOR I=1 TO 10::READ CO
110 CALL COLOR(I,CO,2)::CALL CHAR(25+I*8,"78FCFCFCFC78")::NEXT I
120 DATA 14,6,5,13,4,12,7,10,15,16
130 A=20::FOR B=0 TO 31::FOR C=0 TO 23:=B/15-1.5::E=C/11-1::F=D::G=E::H=0
140 I=F*F::J=G*G::IF I+J>4 OR H>=A THEN 150 ELSE G=2*F*G+E::F=I-J+D::H=H+1::GOTO 140
150 IF H>=10 THEN 160 ELSE CALL HCHAR(C+1,B+1,25+H*
160 NEXT C::NEXT B
170 GOTO 170

 

[RXB]

Here are fractals in GPL.

 

This is not the first fractal program for the TI. I have "Fractal Explorer" from Steve Langguth, I don't know where it comes from.

 

In the Lima user group disks, there is "mandelzoon" in 150B.DSK, "FLOGO" in 172A.DSK, "FRACT-NTSC" in 174A.DSK, and "FRACTALS" in 817.DSK. (I didn't try any of those).

 

What is annoying with the Weiand's GPL assembler is that it doesn't compile floating point constants. Another problem is that there is no "integer to float" conversion routine (CIF) in the ROM. So I had to use floats for my counters. I started to convert the CIF function from the E/A cartridge to GPL, but it was to long.

 

The next step is to implement the zooming function and save/load the result to a file.

 

2 ways to run it:

FRACTALS/FRACTALT - EA5 program with Weiand's GPL simulator included (no hardware needed, slower)

FRACTALS@O - Compressed object file to load at GRAM >C000 with GPL@LOADER (runs fine with classic99, check "Options/GRAM/>C000")

 

I wanted to generate a GROM cartridge file: How do I convert a GPL object file to that?

 

 

GROM >C000

DATA >AA00,>0100,>0000

DATA MENU

DATA >0000,>0000,>0000,>0000

MENU DATA >0000

DATA START

STRI 'FRACTALS'

 

OXS TEXT '-2.15'

BYTE 0

OYS TEXT '-1.05'

BYTE 0

ZS TEXT '0.045'

BYTE 0

 

ONE DATA >4001,>0000,>0000,>0000

TWO DATA >4002,>0000,>0000,>0000

FOUR DATA >4004,>0000,>0000,>0000

SIXTYFOUR DATA >4040,>0000,>0000,>0000

FOURTYEIGHT DATA >4030,>0000,>0000,>0000

FOURTEEN DATA >400D,>0000,>0000,>0000

FMAX DATA >4028,>0000,>0000,>0000

COLORS BYTE 6,8,9,11,10,3,2,12,7,5,4,13,15,1

 

FLAGS EQU >83FD

CCHA EQU >837D

 

B1 EQU >8300

B2 EQU >8301

W1 EQU >8302

W1H EQU >8302

W1L EQU >8303

W2 EQU >8304

B3 EQU >8306

B4 EQU >8307

 

RAM EQU >A000

T32 EQU RAM

OX EQU RAM+32

OY EQU RAM+40

Z EQU RAM+48

X0 EQU RAM+56

Y0 EQU RAM+64

X EQU RAM+72

Y EQU RAM+80

X2 EQU RAM+88

Y2 EQU RAM+96

X2SQU EQU RAM+104

Y2SQU EQU RAM+112

IT EQU RAM+120

MAX EQU RAM+122

X3 EQU RAM+124

FIT EQU RAM+132

COL EQU RAM+140

RAMEND EQU RAM+142

 

 

START

MOVE 6,G@OXS,V@>1000

DST >1000,@FAC+12

XML CSN

MOVE 8,@FAC,@OX

 

MOVE 6,G@OYS,V@>1000

DST >1000,@FAC+12

XML CSN

MOVE 8,@FAC,@OY

 

MOVE 6,G@ZS,V@>1000

DST >1000,@FAC+12

XML CSN

MOVE 8,@FAC,@Z

 

ST 40,@MAX

 

CALL MCCLEAR

CALL MCMODE

 

DCLR @X

DCLR @Y

 

PIXEL

MOVE 8,@X,@FAC

MOVE 8,@Z,@ARG

XML FMUL

MOVE 8,@OX,@ARG

XML FADD

MOVE 8,@FAC,@X0

 

MOVE 8,@Y,@FAC

MOVE 8,@Z,@ARG

XML FMUL

MOVE 8,@OY,@ARG

XML FADD

MOVE 8,@FAC,@Y0

 

DCLR @X2

DCLR @Y2

CLR @IT

DCLR @FIT

 

ITERATION

MOVE 8,@X2,@FAC

MOVE 8,@X2,@ARG

XML FMUL

MOVE 8,@FAC,@X2SQU

 

MOVE 8,@Y2,@FAC

MOVE 8,@Y2,@ARG

XML FMUL

MOVE 8,@FAC,@Y2SQU

MOVE 8,@X2SQU,@ARG

XML FADD

 

MOVE 8,G@FOUR,@ARG

XML FCOMP

GT

BR DRAW

 

CH @IT,@MAX

BR DRAW

 

MOVE 8,@X2SQU,@ARG

MOVE 8,@Y2SQU,@FAC

XML FSUB

MOVE 8,@X0,@ARG

XML FADD

MOVE 8,@FAC,@X3

 

MOVE 8,@X2,@FAC

MOVE 8,@Y2,@ARG

XML FMUL

MOVE 8,G@TWO,@ARG

XML FMUL

MOVE 8,@Y0,@ARG

XML FADD

MOVE 8,@FAC,@Y2

MOVE 8,@X3,@X2

 

MOVE 8,@FIT,@FAC

MOVE 8,G@ONE,@ARG

XML FADD

MOVE 8,@FAC,@FIT

INC @IT

 

B ITERATION

 

DRAW

MOVE 8,@X,@FAC

XML CFI

ST @FAC+1,@XPT

MOVE 8,@Y,@FAC

XML CFI

ST @FAC+1,@YPT

 

MOVE 8,@FIT,@ARG

MOVE 8,G@FMAX,@FAC

XML FDIV

MOVE 8,G@FOURTEEN,@ARG

XML FMUL

XML CFI

DST @FAC,@>8300

* ?? CRASH.

* MOVE 1,G@COLORS(@>8300),@CCHA

MOVE 1,G@COLORS(@>8300),@COL

ST @COL,@CCHA

 

MOVE 8,@X,@FAC

MOVE 8,G@ONE,@ARG

XML FADD

MOVE 8,@FAC,@X

 

MOVE 8,G@SIXTYFOUR,@ARG

XML FCOMP

GT

BS PIXEL

 

DCLR @X

 

MOVE 8,@Y,@FAC

MOVE 8,G@ONE,@ARG

XML FADD

MOVE 8,@FAC,@Y

 

MOVE 8,G@FOURTYEIGHT,@ARG

XML FCOMP

GT

BS PIXEL

 

 

END B END

 

 

MCMODE

******

ST >E8,@B1

MOVE 1,@B1,#1

ST 2,@FLAGS

 

CLR @B1

CLR @B3

DCLR @W2

 

MC1 DCLR @W1

MC3 ST @B1,@T32(@W1)

DINC @W1

INC @B1

DCHE >20,@W1

BR MC3

 

CLR @B2

MC2 MOVE >20,@T32,V*W2

DADD >20,@W2

INC @B2

CHE 4,@B2

BR MC2

 

INC @B3

CHE 6,@B3

BR MC1

 

RTN

 

 

MCCLEAR

*******

DST >800,@W1

MCC1 DCLR V*W1

DINCT @W1

DCHE >E00,@W1

BR MCC1

RTN

 

END

 

 

 

I wonder if the XB versions of CSN, FMUL, FCOMP, CFI and FDIV are faster then the TI Basic versions.

From some examples the ones in the XB ROMs seem to be much faster then the ones in the Console.

The reason is they are more compact and I wondered if a marked speed difference is there.

 

Other wise why would TI have written them so much different then the Console versions for XB.

If there was no speed increase then why not use the Console versions?

 

The answer obviously would be that they are slower so the XB ROMs were created to speed up the Floating Point functions.

 

Rich

[lucien2]

Now the TI-BASIC version with GPL subprograms for multicolor mode.

 

I tried to put the subprograms at GROM>E000 to use them with XB and RXB2012. The subprograms seem to work in command mode (without parameters), but they are not found in program mode...

 

I used Nouspikel's doc. He wrote that XML >13 takes the address of basic variables names at >832C.

I think >832C must contain the address of the first character of the variable name +1 and that >8342 (the last processed token) must contain the first character of the name.

 

100 CALL MCMODE
110 DIM COLS(14)
120 FOR I=1 TO 14
130 READ COLS(I)
140 NEXT I
150 DATA 6,8,9,11,10,3,2,12,7,5,4,13,15,1
160 OX=-2.15
170 OY=-1.05
180 MAX=40
190 Z=0.045
200 FOR Y=0 TO 47
210 FOR X=0 TO 63
220 X0=X*Z+OX
230 Y0=Y*Z+OY
240 X2=0
250 Y2=0
260 IT=0
270 X2SQU=X2*X2
280 Y2SQU=Y2*Y2
290 IF(X2SQU+Y2SQU>4)+(IT>MAX)THEN 350
300 X3=X2SQU-Y2SQU+X0
310 Y2=X2*Y2*2+Y0
320 X2=X3
330 IT=IT+1
340 GOTO 270
350 COL=COLS(IT/MAX*13+1)
360 CALL MCPOINT(X,Y,COL)
370 NEXT X
380 NEXT Y
390 CALL KEY(0,K,S)
400 IF S=0 THEN 390
410 CALL GMODE

 

 

GROM >6000

DATA >AA00,>0000,>0000,>0000

DATA >0000,SUBS,>0000,>0000

SUBS DATA SUB2

DATA MCMODE

STRI 'MCMODE'

SUB2 DATA SUB3

DATA GMODE

STRI 'GMODE'

SUB3 DATA SUB4

DATA MCCLEAR

STRI 'MCCLEAR'

SUB4 DATA >0000

DATA MCPOINT

STRI 'MCPOINT'

 

 

B1 EQU >8300

B2 EQU >8301

W1 EQU >8302

W1H EQU >8302

W1L EQU >8303

W2 EQU >8304

W2H EQU >8304

W2L EQU >8305

B3 EQU >8306

B4 EQU >8307

W3 EQU >8308

W3H EQU >8308

W3L EQU >8309

 

X EQU >830A

Y EQU >830B

COL EQU >830C

 

RAM EQU >A000

T32 EQU RAM

RAMEND EQU RAM+32

 

 

MCMODE

******

CALL FIRSTTOKEN

CALL CLEAR

 

ST >E8,@B1

MOVE 1,@B1,#1

ST >02,@B1

MOVE 1,@B1,#4

 

CLR @B1

CLR @B3

DCLR @W2

 

MC1 DCLR @W1

MC3 ST @B1,@T32(@W1)

DINC @W1

INC @B1

DCHE >20,@W1

BR MC3

 

CLR @B2

MC2 MOVE >20,@T32,V*W2

DADD >20,@W2

INC @B2

CHE 4,@B2

BR MC2

 

INC @B3

CHE 6,@B3

BR MC1

 

CALL >0012

 

MCCLEAR

*******

CALL FIRSTTOKEN

CALL CLEAR

CALL >0012

 

GMODE

*****

CALL FIRSTTOKEN

ST >E0,@B1

MOVE 1,@B1,#1

CLR @B1

MOVE 1,@B1,#3

CALL >0012

 

MCPOINT

*******

CALL FIRSTTOKEN

CALL READINTVAR

ST @FAC+1,@X

CALL READINTVAR

ST @FAC+1,@Y

CALL READINTVAR

ST @FAC+1,@COL

XML >1B

 

ST @X,@W1L

CLR @W1H

DSRL 1,@W1

DSLL 4,@W1

ST @X,@W2L

DAND >0001,@W2

DADD @W1,@W2

 

ST @Y,@W1L

CLR @W1H

DSRL 3,@W1

DSLL 9,@W1

ST @Y,@W3L

DAND >0007,@W3

DSLL 1,@W3

DADD @W1,@W3

DADD @W2,@W3

 

DST @W3,@W2

DSRL 1,@W3

ST V@>1000(@W3),@B1

DCLOG >0001,@W2

BS MCP1

AND >F0,@B1

OR @B1,@COL

B MCP2

MCP1 AND >0F,@B1

SLL 4,@COL

OR @B1,@COL

MCP2 ST @COL,V@>1000(@W3)

 

CALL >0012

 

FIRSTTOKEN

**********

CLR @W1H

ST V*>832C,@W1L

DINC @>832C

DADD @W1,@>832C

XML >1B

RTN

 

CLEAR

*****

DST >1000,@W1

MCC1 DCLR V*W1

DINCT @W1

DCHE >1600,@W1

BR MCC1

RTN

 

READINTVAR

**********

XML >1B

XML >13

XML >14

MOVE 8,V*>834E,@FAC

XML CFI

RTN

 

END

 

 

 

Here's the cartridge with the subprograms: Multicolor subprograms.zip

Edited March 24, 2013 by lucien2

[+Lee Stewart]

...

I used Nouspikel's doc. He wrote that XML >13 takes the address of basic variables names at >832C.

I think >832C must contain the address of the first character of the variable name +1 and that >8342 (the last processed token) must contain the first character of the name.

...

 

That is basically correct unless, of course, the variable name is just one character. In any event, >832C is simply the next byte (token) to be processed. As you imply, before the call to XML >13, you would have just read the first character of the name to see whether it is a valid starting character for a variable name. The call to XML >13 expects the first character to be in >8342, as you say. XML >13 will continue to process tokens as part of the variable name until it finds one with the high bit set (any byte greater than >7F). When the call returns, the byte (token) just past the variable name will have already been processed and will be available in >8342.

 

...lee

[+Lee Stewart]

I wonder if the XB versions of CSN, FMUL, FCOMP, CFI and FDIV are faster then the TI Basic versions.

From some examples the ones in the XB ROMs seem to be much faster then the ones in the Console.

The reason is they are more compact and I wondered if a marked speed difference is there.

 

Other wise why would TI have written them so much different then the Console versions for XB.

If there was no speed increase then why not use the Console versions?

 

The answer obviously would be that they are slower so the XB ROMs were created to speed up the Floating Point functions.

 

Rich

 

As near as I can tell, XB uses the same console routines as TI Basic. It appears that XB calls the routines directly, whereas TI Basic calls them indirectly through the XML tables. This added level of indirection may well account for the slower speed for TI Basic execution of the same routines.

 

...lee

[lucien2]

That is basically correct unless, of course, the variable name is just one character.

 

I didn't say that >832C must contain the address of the second character of the variable name, I said it must contain the address of the first character + 1. So what is incorrect ?

 

Anyway, thanks for the explanation, I was a little confused about that. I spent a lot of time moving all those "XML >1B" before digging into the ROM with the debugger.

[+Lee Stewart]

I didn't say that >832C must contain the address of the second character of the variable name, I said it must contain the address of the first character + 1. So what is incorrect ?

 

Touché!

 

Anyway, thanks for the explanation, I was a little confused about that. I spent a lot of time moving all those "XML >1B" before digging into the ROM with the debugger.

 

No prob. An indispensable resource for digging into the console ROM and GROMs is Heiner Martin's TI 99/4A Intern, which is available in the sticky thread at the top of this forum (TI-99/4A development resources). I use it all the time!

 

...lee

[RXB]

As near as I can tell, XB uses the same console routines as TI Basic. It appears that XB calls the routines directly, whereas TI Basic calls them indirectly through the XML tables. This added level of indirection may well account for the slower speed for TI Basic execution of the same routines.

 

...lee

 

I was going to make a video but the speed difference was so small as to be not noticeable. Very disappointed in results.

 

Most of the XML routines in XB are for String handling and using RAM for programs instead of everything in VDP.

Also the rest of the XML routines are for manipulation of tokens that is far faster then Basic that uses only GPL and no Assembly.

For example XML SPEED uses Assembly to find tokens in a Assembly in ROMs rather then use GPL like BASIC.

Edited March 24, 2013 by RXB

[+Lee Stewart]

I was going to make a video but the speed difference was so small as to be not noticeable. Very disappointed in results.

 

Most of the XML routines in XB are for String handling and using RAM for programs instead of everything in VDP.

Also the rest of the XML routines are for manipulation of tokens that is far faster then Basic that uses only GPL and no Assembly.

For example XML SPEED uses Assembly to find tokens in a Assembly in ROMs rather then use GPL like BASIC.

 

I don't know the reason many of the XML routines might have been rewritten for XB unless the console XML routines replaced use the CPU RAM PAD or other memory differently from XB and/or return to different locations; but, TI Basic does, in fact, use Assembly in the console ROM for token processing (and many other functions, as well) via XML calls from GPL to ROM. I would expect a speed difference with the use of expansion RAM by XB, but I wonder if that is true when VDP RAM is used for both TI Basic and XB.

 

...lee