fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/05/2024]

[Tursi]

I thought I did have the FDR in there... oh well, I have saved your report off and will take a look at that. Serves me right for not testing against real hardware. I assume you mean from disk images? (I spent a lot more time on disk folders since I don't like images ).

 

I looked up the code for you on Thierry's site, and sure enough the TI disk controller does a hard-coded DECT on the total size of the disk. heh.

 

A59D4  AI   5,>00FF           disk info: point to data buffer area in ctrl block
       BL   @A4658            call subroutine
       DATA A4D4E             read sector 0
       BL   @A4B70            get 2 bytes from FDR into R0
       DATA >010A             # of sectors on disk
       MOV  0,6               duplicate it
       DECT 6                 minus directory itself (sect 0 + 1)

I just watched the FBForth demo on the Chicago demo - nice work!

[+Lee Stewart]

...

 

Thank you, Sir!—for both the info and the compliment.

 

...lee

[+Lee Stewart]

Nearly done with Chapter 14 “The Stack-based String Library”. I need to run it by @Willsy first. Not much longer for the next manual revision.

 

...lee

[+Lee Stewart]

I will be posting the latest revision to the fbForth 2.0 manual in the next day or two after one more proofing pass through it.

 

...lee

[+Lee Stewart]

Sorry about the delay in posting the updated manual for fbForth 2.0. I had a slight change of plans. I think I am going to add the words @Willsy needed to define for the String Library he ported to fbForth ( 2DUP NIP CELLS -ROT PICK WITHIN <> $. EXIT ) to the FBLOCKS menu and to the manual because most of them are very useful. I think I will also add three additional words to the same block for balance. They are 2DROP , TUCK and ROLL . Later today I will post their definitions and explain what they do.

 

...lee

[+Lee Stewart]

OK—here are explanations of the words mentioned in my last post as well as their definitions:

2DUP  ( a b -- a b a b )   Duplicate the top two numbers on the stack.
    : 2DUP   OVER OVER ;  
2DROP  ( a b -- )   Drop the top two numbers from the stack.
    : 2DROP   DROP DROP ;  
NIP  ( a b -- b )   Remove from the stack the number that is under the top number.
    : NIP   SWAP DROP ;
TUCK  ( a b -- b a b )   Put a copy of the top number under the top two numbers on the stack.
    : TUCK   SWAP OVER ;  
CELLS  ( n -- 2n )   Replace n (a number of cells) with 2n (the number of bytes in n cells).
    : CELLS   2 * ;
-ROT ( a b c -- c a b )   Rotate right the top three numbers on the stack, resulting in the top number on the bottom.
    : -ROT   ROT ROT ;
PICK  ( n -- [n])   Copy to the top of the stack the nth number down.  (The 0th number is the top number.)
    0 PICK is the same as DUP.
    1 PICK is the same as OVER.
        : PICK   1+ CELLS SP@ + @ ;
The source for ROLL was Marshall Linker via George Smyth’s Forth Forum.
ROLL  ( [n]..[0] n -- [n-1]..[0][n] )   Rotate left the top n+1 numbers on the stack, resulting in the nth number down on top.
    0 ROLL is a null operation.
    1 ROLL is the same as SWAP.
    2 ROLL is the same as ROT.
        : ROLL
            -DUP
            IF  
                1-  SWAP  >R  MYSELF  R>  SWAP  
            THEN  ; 
WITHIN ( n low high -- true|false )   Leave true (1) if low ≤ n < high and false (0) otherwise.
    : WITHIN   OVER - >R - R> U< ;
<>  ( a b -- 1|0 )   Leave true (1) if a ≠ b and false (0) otherwise.
    : <>   = 0= ;   
$.  ( n -- )   Display the top number on the stack as an unsigned hexadecimal number.
    : $. BASE->R HEX U. R->BASE ;
EXIT  ( -- )   EXIT is a synonym for ;S .  End the current word’s execution and return to the calling procedure or stop interpretation of a Forth block.
    : EXIT   [COMPILE] ;S ;   IMMEDIATE

...lee

Edited November 24, 2014 by Lee Stewart

[Gary from OPA]

Wow, got alot of reading to do, thanks for pointing out this topic to me from the other poll thread!

[+Lee Stewart]

While looking for a particular one of George Smyth’s “Forth Forum” columns, I rediscovered this edition of Dave Ramsey’s column, “Under the Hood,” from the November, 1984 issue of MANNERS Newsletter:

 

UnderTheHood198411.pdf

 

It discusses what Dave calls a “bug” in the CRU words of TI Forth (and by extension, fbForth). He doesn’t like the fact that the TI Forth authors used the term “CRU address” to mean the actual CRU bit number rather than double that number, which the Editor/Assembler Manual calls the CRU address and shows in the table in Chapter 24. I personally think the instructions for the CRU words in the TI Forth and fbForth manuals are clear enough; but, I certainly understand Dave’s frustration with trying to juggle two different ways of dealing with the same CRU operation. I bring all this up because I wonder if I should change the fbForth CRU words in line with Dave’s comments.

 

The above reminded me of conversations I had with Dave back in late 1983 and early 1984 at DC TIUG meetings regarding his similar reaction to the TI-Forth-TMS9900-Assembler way of representing ALC instructions. No matter that the source and destination addresses were in the same order—having the instruction follow them in the traditional RPN Forth way just stuck in his craw. I remember his excitement over discovering the TI Forth TMS9900 Assembler with its structured programming potential and just as suddenly swearing off of that Assembler because it meant changing the way he was used to writing ALC. I didn’t know much TMS9900 Assembler back then, so I did not have any very convincing arguments in my effort to cajole him to change his mind. I don‘t remember whether he continued with TI Forth very long after that. I‘ll need to reread my copies of his “Under the Hood” columns to jog my memory. I do know that I was very much in love with TI Forth and that it was the reason I‘ve stayed with the TI-99/4A all this time. I viewed Dave’s continued enthusiasm for TI Forth quite selfishly because I wanted a friend with his knowledge of TMS9900 ALC to help with my understanding of the ALC source for TI Forth. He had already started making noises about enhancing TI Forth, as I recall. I wish we had stayed in touch. I might have produced fbForth much sooner—but I digress...

 

...lee

Edited November 26, 2014 by Lee Stewart

[+Ksarul]

You've been doing a great job of it even without his help, Lee! I suspect it might be better to leave the CRU words alone--changing them would break any TI Forth program that used them. . .

[+Lee Stewart]

You've been doing a great job of it even without his help, Lee! I suspect it might be better to leave the CRU words alone--changing them would break any TI Forth program that used them. . .

 

Thank you, Sir!

 

Yeah—I think I might just beef up the discussion of those words to point out the differences.

 

...lee

[+Lee Stewart]

OK—here’s what I have so far for §11.3 “CRU Words” in the fbForth 2.0 Manual:

 

fbForth_2.0_Manual_11.3CRUWords.pdf

 

Please, let me know what you think needs changing.

 

...lee

[+Lee Stewart]

I have just posted the latest revision of the fbForth 2.0 Manual to post #1. It includes all of the additions to FBLOCKS made this month. I will post the newest FBLOCKS within the hour.

 

...lee

[+Lee Stewart]

The latest FBLOCKS is now posted to post #1.

 

...lee

[+Lee Stewart]

I have updated the title of this thread to show the date of the last update to fbForth downloads in post #1.

 

...lee

[+Lee Stewart]

I fixed a couple of bugs in fbForth 2.0:1 and posted the Classic99 and MESS ZIP files for fbForth 2.0:2 to post #1. The bugs fixed were

• Fixed a bug in the 40/80-Column Editor’s character-copy function that caused fbForth 2.0 to crash if the line-insertion and line-deletion functions were used on the last line of a block. The problem was not testing for a copy-count of 0 before copying the first character, causing the count to pass 0 before the test if the function was passed a count of 0, which it is on the last line.
• Fixed a bug in SGN that resulted in +1 for -32768 (8000h), the largest single-precision (16-bit) negative number possible on the TI-99/4A.

The BIN file in the Classic99 ZIP file can be used to update the EPROM on the cartridge you purchased from me at the Faire. If you cannot update the EPROM yourself, we can work something out.

 

...lee

[RXB]

While looking for a particular one of George Smyth’s “Forth Forum” columns, I rediscovered this edition of Dave Ramsey’s column, “Under the Hood,” from the November, 1984 issue of MANNERS Newsletter:

 

UnderTheHood198411.pdf

 

It discusses what Dave calls a “bug” in the CRU words of TI Forth (and by extension, fbForth). He doesn’t like the fact that the TI Forth authors used the term “CRU address” to mean the actual CRU bit number rather than double that number, which the Editor/Assembler Manual calls the CRU address and shows in the table in Chapter 24. I personally think the instructions for the CRU words in the TI Forth and fbForth manuals are clear enough; but, I certainly understand Dave’s frustration with trying to juggle two different ways of dealing with the same CRU operation. I bring all this up because I wonder if I should change the fbForth CRU words in line with Dave’s comments.

 

The above reminded me of conversations I had with Dave back in late 1983 and early 1984 at DC TIUG meetings regarding his similar reaction to the TI-Forth-TMS9900-Assembler way of representing ALC instructions. No matter that the source and destination addresses were in the same order—having the instruction follow them in the traditional RPN Forth way just stuck in his craw. I remember his excitement over discovering the TI Forth TMS9900 Assembler with its structured programming potential and just as suddenly swearing off of that Assembler because it meant changing the way he was used to writing ALC. I didn’t know much TMS9900 Assembler back then, so I did not have any very convincing arguments in my effort to cajole him to change his mind. I don‘t remember whether he continued with TI Forth very long after that. I‘ll need to reread my copies of his “Under the Hood” columns to jog my memory. I do know that I was very much in love with TI Forth and that it was the reason I‘ve stayed with the TI-99/4A all this time. I viewed Dave’s continued enthusiasm for TI Forth quite selfishly because I wanted a friend with his knowledge of TMS9900 ALC to help with my understanding of the ALC source for TI Forth. He had already started making noises about enhancing TI Forth, as I recall. I wish we had stayed in touch. I might have produced fbForth much sooner—but I digress...

 

...lee

I know the frustration you are talking about.

 

In the RXB manual I made I have this:

 

INPUT/OUTPUT ACCESS:

----------------------------------------------------------------

CALL IO controls the 9901 CRU chip. Sound lists can be played

independently of current status. (i.e. type in a program while

playing music from VDP/GROM.) Control Register Unit can turn

on/off single bits of CRU address bus. (i.e. cards/chips)

Cassette direct bus control. (i.e. no menu input/output, verify)

----------------------------------------------------------------

And the manual pages on IO:

IO subprogram PAGE I3

-------------------------------------------------------------

Format CALL IO(type,address[,...])

CALL IO(type,bits,cru-base,variable,variable

[,...])

CALL IO(type,length,vdp-address[,...])

Description

The IO subprogram allows access to and control of any chip in

the console or peripheral cards. The type refers to different

access methods like playing sound from GROM or VDP memory

automatically. The type can also specify reading or writing

directly to a Control Register Unit (CRU) address. Thereby

allowing direct chip control, or direct chip bypass if the

user wishes. The IO subprogram is a Graphics Programming

Language (GPL) command. So the function is exactly like GPL

despite being run from the XB environment. As most of XB is

written in GPL the user gains greater GPL like control.

After all the Operating System is written in GPL for a

good reason.*Note these docs are from GPL Manuals.

type address specifications

~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~

0 ---------- GROM sound list address.

1 ---------- VDP sound list address.

2 ---------- CRU input.

3 ---------- CRU output.

4 ---------- VDP address of Cassette write list.

5 ---------- VDP address of Cassette read list.

6 ---------- VDP address of Cassette verify list.

The length specifies the number of bytes. The length can be

from -32768 to 32767 depending on the amount of VDP memory

that is available. Of course a value of -32768 is HEX >8000

and 32767 is HEX >7FFF and VDP normally in a TI is only 16384

or HEX >4000 of VDP. So be careful or lock-up will result.

The cru-base is the CRU address divided by 2 in decimal form

as the command automatically doubles the value input. The CRU

-base ranges from 0 to 8191 or HEX >0000 to >1FFF with a EVEN

address for 8 bits or more being scanned. That means that a

value of 8191 will lock-up the system as it is looking for a

bit in 8192 that does not exist.

The variable can input or output values ranging from 0 to 255

as that is equivalent to a single byte value. As there are

two variables 16 bits can be represented in the two 8 bit

variables. If CRU input reads less than 8 bits, the unused

bits in the byte are reset to zero. If CRU input reads less

then 16 but more than 8 bits, the unused bits in the word

will be reset to zero. The bits range from 1 to 16 for input

or output.

IO PAGE I4

-------------------------------------------------------------

AUTO-SOUND INSTRUCTION GROM/GRAM/VDP

Format CALL IO(type,address[,...])

Control of the Sound Generator Chip (SGC) in the system

console is through a pre-defined table in GROM/GRAM or VDP

memory. Sound output is controlled by the table and the VDP

Interrupt Service Routine (ISR). A control byte at the end of

the table can cause control to loop back up in the table to

continue, or end sound output. The format of the table is the

same regardless of where it resides. The table consists of a

series of blocks, each of which contains a series of bytes

which are directly output to the SGC.

Since the VDP generates 60 interrupts per second, the

interrupt count is expressed in units of one-sixtieth of a

second.

When the IO command is called, upon the next occurring

VDP interrupt, the first block of bytes is output to the SGC.

The interpreter (Operating System) waits the requested number

of interrupts (for example, if interrupt counts are 1, every

interrupt causes the next block to be output). Remember that

interpretation of XB continues normally while the SGC control

is enabled.

The sound control can be terminated by using an interrupt

count of 0 in the last block of the table. Alternatively, a

primitive looping control is provided by using a block whose

first byte is 0, and the next 2 bytes indicate an address in

the same memory space of the next sound block to use. (That

means one block points to another block only in the same type

of memory).

If the first byte is hex FF or decimal 255, the next two

bytes indicate an address in the other memory space. (That

means one block points to another block but in another type

of memory.) These allow switching sound lists from GROM/GRAM

to VDP or VDP to GRAM/GROM. By making this the beginning of

the entire table, the sound sequence can be made to repeat

indefinitely.

The type 0 indicates sound lists in GROM or GRAM and type 1

indicates sound lists in VDP.

Executing a sound list while table-driven sound control is

already in progress (from a previous sound list) causes the

old sound control to be totally supplanted by the new sound

instruction. (That means any sound chip command will over-

ride old sound chip commands).

The SGC has 3 tone (square wave) generators - 0, 1, and 2

all of which can be working simultaneously or in combination.

The frequency (pitch) and attenuation (volume) of each

generator can be independently controlled. In addition, there

is a noise generator which can output white or periodic

noise. For more information on controlling the SGC, see the

TSM9919 SGC specification.

IO PAGE I5

-------------------------------------------------------------

ATTENUATION CONTROL (for generators 0, 1, 2 or 3)

One byte must be transmitted to the SGC:

Binary 1-REG#-1-Attenuation

REG# = register number (0,1,2,3)

Attenuation = Attenuation/2

(e.g. A=0000 0 db = highest volume;

A=1000 16 db = medium volume;

A=1111 30 db = off. )

EXAMPLE: 1 10 1 0000 : turn on gen. #2 highest volume.

1 01 1 0100 : turn on gen. #1 medium high volume.

1 11 1 1111 | turn off gen. #3 (noise generator).

FREQUENCY CONTROL (for generators 0, 1, 2)

-----------------

Two bytes must be transmitted to the SGC for a given register

and to compute the number of counts from the frequency F

use: N = 111860 / F

Binary 1-REG#-N(1s 4 bits)-00-N(ms 6 bits)

Note that N must be split up into its least

significant 4 bits and most significant 6

bits (10 bits total).

The lowest frequency possible is 110 Hz and the highest is

55938 Hz.

NOISE CONTROL |

------------- |

One byte must be transmitted to the SGC:

Binary 1-1-1-0-0-T-S

T = 0 for white noise, 1 for periodic noise;

S = Shift rate (0,1,2,3) = frequency center of noise.

S=3=frequency dependent on the frequency of tone

generator #3.

IO PAGE I6

-------------------------------------------------------------

Programs

Line 100 clears screen. | >100 CALL CLEAR ! Chimes

Line 110 to ... | >110 DATA 5,159,191,223,255,2

| 27,1,9,142,1,164,2,197,1,144

| ,182,211,6,3,145,183,212,5,3

| ,146,184,213,4

| >120 DATA 5,167,4,147,176,214

| ,5,3,148,177,215,6,3,149,178

| ,216,7

| >130 DATA 5,202,2,150,179,208

| ,6,3,151,180,209,5,3,152,181

| ,210,4

| >140 DATA 5,133,3,144,182,211

| ,5,3,145,183,212,6,3,146,184

| ,213,7

| >150 DATA 5,164,2,147,176,214

| ,6,3,148,177,215,5,3,149,178

| ,216,4

Line 160 ends sound list. | >160 DATA 5,197,1,150,179,208

| ,5,3,151,180,209,6,3,152,181

| ,210,7,3,159,191,223,0

Line 170 reads list into B and| >170 A=A+1 :: READ B :: CALL

A is counter | POKEV(A,B)

Line 180 checks end of list? | >180 IF B=0 THEN 190 ELSE 170

Line 190 shows how to access. | >190 PRINT "TYPE:": :"CALL IO(

| 1,8192)"

| >200 CALL IO(1,8192)

|

Line 310 continues AD loop. | >310 NEXT AD

Line 320 executes sound list. | >320 CALL IO(1,4096)

Line 330 prints out suggestion| >330 PRINT "CRASH": :"TYPE:":

on how to test IO. | "CALL IO(1,4096)"

IO PAGE I7

-------------------------------------------------------------

Programs

Line 100 clears the screen. | >100 CALL CLEAR ! CRASH

Line 110 to ... | >110 DATA 2,228,242,5

| >120 DATA 2,228,240,18

| >130 DATA 2,228,241,16

| >140 DATA 2,228,242,14

| >150 DATA 2,228,243,12

| >160 DATA 2,228,244,10

| >170 DATA 2,229,245,9

| >180 DATA 2,229,246,8

| >190 DATA 2,229,247,7

| >200 DATA 2,229,248,6

| >210 DATA 2,229,249,5

| >220 DATA 2,230,250,4

| >230 DATA 2,230,251,3

| >240 DATA 2,230,252,2

| >250 DATA 2,230,253,1

| >260 DATA 2,230,254,1

Line 270 ends sound list. | >270 DATA 1,255,0,0

Line 280 AD is VDP address to | >280 FOR AD=4096 TO 4160 STE

start with and ends with. | P 4

Line 290 reads list. | >290 READ V1,V2,V3,V4

Line 300 moves them into VDP. | >300 CALL POKEV(AD,V1,V2,V3,V

| 4)

Line 310 continues AD loop. | >310 NEXT AD

Line 320 executes sound list. | >320 CALL IO(1,4096)

Line 330 prints out suggestion| >330 PRINT "CRASH": :"TYPE:":

on how to test IO. | "CALL IO(1,4096)"

All data values must converted to Binary in order to see

what is going on. You now have all the data that I have as

to this phase of IO types 0 and 1. See Editor Assembler

Manual also for more data on sound lists and sound chip.

IO PAGE I8

-------------------------------------------------------------

Sound table creator for conversion of sound data.

100 CALL CLEAR

110 PRINT "*SOUND DATA TABLE CREATOR*"

120 Q$="0123456789ABCDEF"

130 INPUT "GENERATOR # ?":GN

140 INPUT "DURATION ?":DUR

150 INPUT "FREQUENCY ?":FREQ

160 INPUT "VOLUME ?":VOL :: PRINT : : :

170 IF DUR>17 THEN 190

180 DUR=17

190 REM DURATION

200 DUR=INT((DUR*255)/4250) :: CONV=DUR

210 GOSUB 430

220 DUR$=SEG$(HX$,3,2) :: IF FREQ>-1 THEN 310

230 REM NOISE FREQUENCY

240 FR=ABS(FREQ)-1 :: FR$="E"&STR$(FR)

250 REM NOISE VOLUME

260 VOL=INT(VOL/2) :: CONV=VOL

270 GOSUB 430 :: VOL$="F"&SEG$(HX$,4,1)

280 PRINT "DATA>02";FR$;",>";VOL$;DUR$: : :

290 GOTO 390

300 REM TONE FREQUENCY

310 FR=INT((111860.8/FREQ)+.5)

320 CONV=FR :: GOSUB 430

330 FR$=SEG$(Q$,GN*2+7,1)&SEG$(HX$,4,1)&SEG$(HX$,2,2)

340 REM TONE VOLUME

350 VOL=INT(VOL/2) :: CONV=VOL

360 GOSUB 430

370 VOL$=SEG$(Q$,GN*2+8,1)&SEG$(HX$,4,1)

380 PRINT "DATA>03";SEG$(FR$,1,1)&SEG$(FR$,2,1);",>";

SEG$(FR$,3,2);VOL$;",>";DUR$;"00": : :

390 PRINT: :"ANOTHER SOUND (Y/N)?"

400 CALL ONKEY("YN",3,K,S) GOTO 100,420

410 GOTO 400

420 CALL CLEAR :: END

430 REM DECIMAL TO HEX

440 AY=INT(CONV)/16 :: BY=INT(AY)/16

450 CY=INT(BY)/16 :: DY=INT(CY)/16

460 AP=(AY-INT(AY))*16 :: BP=(BY-INT(BY))*16

470 CP=(CY-INT(CY))*16 :: DP=(DY-INT(DY))*16

480 HX$=SEG$(Q$,DP+1,1)&SEG$(Q$,CP+1,1)&

SEG$(Q$,BP+1,1)&SEG$(Q$,AP+1,1)

490 RETURN

Use this program to create Hex strings that can use

CALL MOVES to move strings into VDP to be played from

a CALL IO(1,VDP-address)

IO PAGE I9

-------------------------------------------------------------

CRU ACCESS INSTRUCTION

Format CALL IO(type,bits,cru-base,variable,variable

[,...])

The IO types 2 and 3 can be used to control a variety of

input-output devices including Speech, or CRU. IO always must

be the CRU address divided by 2 as any value above 8192 will

be out of range. The cru-base must be divided by 2 as the

9901 chip ignores the least significant bits of the base

register it uses. See Editor Assembler Manual page 61.

The CRU data to be written should be right justified in the

byte or word. The least significant bit will output to or

input from the CRU address specified by the CRU base address.

Subsequent bits will come from or go to sequentially higher

CRU addresses. If the CRU input reads less than 8 bits, the

unused bits in the byte are reset to zero. If the CRU input

reads less than 16 bits but more than 8 bits, the unused bits

in the full two 8 bit bytes will be reset to zero.

Programs

Line 100 display what it does | >100 DISPLAY AT(1,1)ERASE ALL

for you. | :"THIS PROGRAM CHECKS FOR

| UNUSUAL KEYS BEING PRESSED

| , EVEN IF MORE THEN FOUR KEY

| ARE BEING PRESSED AT ONCE"

Line 110 scans CRU at >0006 | >110 CALL IO(2,16,3,A,B):: IF

and reports keys pressed. | A=18 AND B=255 THEN 110 ELS

| E CALL HPUT(24,3,RPT$(" ",30

| ),24,24,STR$(A)&" "&STR$(B))

Line 120 more reports. | >120 IF A=146 THEN CALL HPUT(

| 24,3,"FUNCTION KEY")ELSE IF

| B=191 THEN CALL HPUT(24,3,"C

| ONTROL KEY")ELSE IF B=223 TH

| EN CALL HPUT(24,3,"SHIFT KEY

| ")

Line 130 still more reports. | >130 IF B=251 THEN CALL HPUT(

| 24,3,"ENTER KEY")ELSE IF B=2

| 53 THEN CALL HPUT(24,3,"SPAC

| E BAR")ELSE IF B=254 THEN CA

| LL HPUT(24,3,"PLUS/EQUAL KEY

| ")

Line start over scan of keys. | >140 GOTO 110

|

The above program scans CRU input/output lines for keys.

Please note that EMULATION of the TI99/4A is never complete,

so many CRU address in a Emulator are not fully functional.

IO PAGE I10

-------------------------------------------------------------

Programs

Line 100 clears screen. | >100 CALL CLEAR

Line 110 explains program. | >110 CALL HPUT(4,7,"This is a

| demo of the",6,7,"CALL IO(3

| ,8,2176,B)",8,7,"3 = TYPE(CR

| U output)",10,7,"8 = NUMBER

| OF BITS",12,7,"2176=address/

| 2")

Line 120 turn off card, show | >120 CALL IO(3,8,2176,0):: FO

the present byte value being | R B=0 TO 255 :: CALL HPUT(14

sent. | ,7,"B=byte (value "&STR$(B)&

| ")")

Line 130 display block to get | >130 CALL HPUT(18,5,"********

attention. | ******************",19,5,"WA

| TCH THE DRIVE LIGHTS",20,5,"

| **************************")

Line 140 send byte to card and| >140 CALL IO(3,8,2176,B):: NE

when done with loop, clear for| XT B :: CALL HCHAR(14,24,32,

starting over program. | 7):: GOTO 110

|

The above program will only work on a REAL TI not EMULATORS.

Line 100 explains program. | >100 ! TURNS OFF/ON/OFF EACH

| CARD FROM >1000 TO >1F00 BUT

| WILL LOCKUP WITH CERTAIN

| CARDS.

Line 110 cru address from | >110 FOR CRU=2048 TO 3968 STE

>1000 to >1F00 | P 128

Line 120 turn off card, turn | >120 CALL IO(3,8,CRU,0,3,8,CR

on card, delay for 2 seconds, | U,255)::FOR A=1 TO 200::NEXT

turn off card. | A::CALL IO(3,8,CRU,0)

Line 140 loop till done. | >140 NEXT CRU

Options

Some CRU address are used by the Operating System or XB and

any attempt to redefine them will create problems. Also some

of the address areas will return incorrect values as they

have changed since IO has accessed them. These problems will

never become completely apparent at first, so take care.

Additionally some cards have the same problem, if the card

has a program that has a interrupt or CRU links turned on as

you access it, a complete lock up will result as a fight for

control ensues. So with that happy thought, a alternate way

is to use EXECUTE or LINK instead.

IO PAGE I11

-------------------------------------------------------------

CASSETTE INPUT/OUTPUT/VERIFY INSTUCTION

Format CALL IO(type,length,vdp-address[,...])

The three different cassette I/O instuctions use the same

format. The write and read instructions physically perform

Input/Output to the cassette. The verify instruction will

read a tape and compare it, byte by byte, against what is in

the specified vdp area. All will report an I/O error if one

is detected.

No prompts are present with these three formats. These three

types control the cassette directly so no prompt will tell

the user to turn on or off the cassette record/play buttons.

The programmer must inform the user with his own prompt.

Programs

Presently I have no cassette to write programs with.

AUDIO GATE

----------

CRU bit 24 is the audio gate which allows data being read to

be heard. If the bit is set to 1, the data being read is

heard, and if the bit is set to 0, the data is not heard.

Setting the bit to a 0 or 1 is done with an IO instruction, or

a Assembly instruction.

MOTOR CONTROL

-------------

There are two CRU bits (22 and 23) used to control cassettes

1 and 2, respectively. When there is no Cassette IO being

done, both motors remain on. When Cassette IO is specified,

the DSR (Device Service Routine) will control the data being

read. If there are two motor units connected, the data will be

read simultaneously, or you may have the option of reading

data from one motor unit and playing the recorded voice from

another motor unit through the TV (Monitor) speaker.

*NOTE:

Compatibility with or without 32K or other devices is not a

concern as IO needs no RAM to work with. Therefore from just

a console all IO commands will work fine. If you only have a

Cassette and RXB you can quickly load/save/verify without

menus, or just make up your own.

Even with all the examples and even on disk ones I get Assembly Programmers that ask why it does not work as you need to double the address.

Short of publishing a CRU map in the next RXB documents I do not see how to explain it better.

[+Lee Stewart]

 

I know the frustration you are talking about.

...

Even with all the examples and even on disk ones I get Assembly Programmers that ask why it does not work as you need to double the address.

Short of publishing a CRU map in the next RXB documents I do not see how to explain it better.

 

 

I feel your pain, Rich.

 

...lee

[+Lee Stewart]

I just noticed that the new binary (fbForth 2.0:2) broke the BSAVEd options of FBLOCKS. It’s going to happen every time a new binary is produced because labels stored with the BSAVEd binary move around. It’s really no problem to produce a new FBLOCKS file with each new cartridge binary revision; but, I wonder whether I should just remove those from future FBLOCKS files in favor of just giving instructions (and caveats) on how users might produce them themselves. Thoughts?

 

...lee

[+InsaneMultitasker]

While looking for a particular one of George Smyth’s “Forth Forum” columns, I rediscovered this edition of Dave Ramsey’s column, “Under the Hood,” from the November, 1984 issue of MANNERS Newsletter:

 

UnderTheHood198411.pdf

 

It discusses what Dave calls a “bug” in the CRU words of TI Forth (and by extension, fbForth). He doesn’t like the fact that the TI Forth authors used the term “CRU address” to mean the actual CRU bit number rather than double that number, which the Editor/Assembler Manual calls the CRU address and shows in the table in Chapter 24. I personally think the instructions for the CRU words in the TI Forth and fbForth manuals are clear enough; but, I certainly understand Dave’s frustration with trying to juggle two different ways of dealing with the same CRU operation. I bring all this up because I wonder if I should change the fbForth CRU words in line with Dave’s comments.

 

 

 

...lee

 

Years ago Bill Sullivan and I exchanged some notes on this same challenge.

 

As you know, in assembly the CRU bit value used with TB/SBO/SBZ must be doubled before it is loaded into R12 or operated by LDCR/STCR operations. Documentation that references the CRU bit value for the TB/SBO/SBZ instructions as an address can do a disservice to the reader -unless- the author provides an explanation. Since the R12 CRU value's least significant bit is ignored at the hardware level, a CRU bit value must be doubled (shifted left one position) to convert it to an addressable offset usable with R12. A lot of documentation fails to properly explain what's going on, leaving the programmer stymied when things don't work.

 

Personally, I think the programming languages should follow the same convention where possible, so that programmers know CRU base 0x1100 means 0x1100 and that testing an offset bit 1 at base 0x1100 means you are testing 0x1102.

[+Lee Stewart]

I just posted a new (20141204) FBLOCKS ZIP file in post #1. It is identical to the previous one (20141129) but for updated binary images for the last three menu options (see 2 posts back for the problem fixed).

 

...lee

[+Lee Stewart]

This from the Bitmap Mode thread suggesting a solution to my getting cramped on space when trying to add functionality to the fbForth 2.0 cartridge:

 

You could always try to divide things up so you could use another bank or two, Lee. . .

 

I certainly can divide things up to provide extra space to add another word to the cartridge except for one problem. I am running very short on space in the word-header bank. I am almost to the point of needing to rethink how I have organized that bank. Each new word requires about 16 bytes of header information in bank 2, depending on the length of the word's name. I only have 149 bytes left in bank 3. H-m-m-m...I guess I could do that for a couple more words. I will work on coding DATA soon!

 

...lee

[+Lee Stewart]

Looking at TurboForth's DATA , I am not sure how to proceed. My immediate goal is to compile numbers to an array. I am not particularly interested in the behavior of TF's DATA . Perhaps I should code my word to be used by a future implementation of DATA (if I have enough room!). Now, however, I need suggestions for a good Forthy name for my word:

 

<compile-numbers-word> ( count --- )

This word will compile count numbers from the input stream using , (comma).

 

...lee

[+Ksarul]

DCOUNT or something similar?

[Willsy]

How about INTS:

 

To whit:

 

5 INTS: 1 2 3 4 5

[+Lee Stewart]

I think it should, at the very least, end with a ‘,’ to indicate a Forth compile—something like NUMS, or INTS, or DCOUNT, or all of the TMS9900 Assembler words. H-m-m-m...maybe ,, to indicate a multi-number compile. Keep ’em comin’, Folks!

 

...lee