Subject: 64K Cartridge orders, round two...

From: Jon Guidry <[email-masked]>
Date: Thu, 17 Dec 2009 20:33:23 -0600

Yep, you heard it right.

There will be a few changes this time.  So, please read on and send me e-mail if you are interested in doing the following:

I need several people to do particular jobs to get this done.  Whether or not you decide to do more than one is up do you. :)

1) Spreadsheet maintainer/counter.  I will create a form like last time, and give someone control of the form and resultant spreadsheet.  It will be your job to keep track of pre order numbers.    For this next order, we want either 100 or 250 - that's our goal.  If we take forever to get to 100, we'll order 100.  If not, we'll order 250 if we get to it.

2) Packager/mailer - You will be responsible for packing the boards (they will already be in ASD bags, assembled) in a box with peanuts to send out to people (after they have been paid for).  You will weigh them, and communicate with the invoicer, below, regarding weights so that the invoicer can determine postage costs.  After doing all that, you will mail the packages.  The invoicer can work with you to pay you back for postage/boxes/peanuts.

3) Invoicer - someone who will invoice each person via e-mail for their quantity of boards.  You will be responsible for sending out invoices to people.  Most boards will go out first class mail, and some will be Priority, etc.  You will need a Paypal account to make it easy, and will charge people for the board + shipping/handling.  The shipping/handling fee includes the mail cost + $1 for the box/peanuts (approx) + a small offset for the Paypal fees.

4) Interface to ACC Electronix - that's me :)

Now, on to the fun part.

ACC Electronix will professionally be making the boards this go-around.  The boards will be made by PCBExpress, be RoHS compliant, and be professionally assembled.  A test fixture will be made by PCBEXpress to electrically test the PCBs before ACC assembles them.

ACC is charging just about what we were charging before for assembled boards.

If we order 100 from them for this second batch, they will be $1,494, or $14.94/ea.  If we order 250 from them, they will be $2,475, or $9.90/ea.  That's *assembled*, folks.

If we go through this second batch and order a third batch, 100 will cost around $897, or $8.97/ea assembled.  250 would be $1957.50, or $7.83/ea.

ACC will charge me a $400 fee up front, and then the rest is due within 30 days.  So if we don't get this done within 30 days, some folks will have to help with financing.

Bob Carmany and I will still be offering our EPROM burning services.  If someone wants to volunteer excess cart cases for the group, we can build that into the cost.

Thoughts, everyone?  How's $9.90/ea assembled sound?   Get 250 orders and you'll get it! :)

Jon

---

From: mark wills <[email-masked]>
Date: Thu, 17 Dec 2009 23:20:35 -0800 (PST)

Recently there was some talk about the FIG forth cartridge. Our Bill very kindly sent it to me.

I played around with it a little bit today. It is difficult without the manual to know the meaning and stack signatures for each word, but it is useful to test the behaviour of my own Forth to see if it behaves the same on the words that I do know.

Today I did a little speed test:

: TEST 5000 BEGIN DUP 0> WHILE DUP . 1- REPEAT ;

This is a simple count down loop, displaying 5000 down to 1 on the screen.

The timings were as follows:(Both running in Classic99)

FIG Forth Cartridge: 1:54.1
My Forth: 0:39.0

If you disable screen scrolling on my forth with FALSE SCROLL ! (not possible on FIG) you get 0:11.3 :-)

Not bad.

I still don't have a name for my Forth project. At the moment, it's just cForth (Cartridge Forth) but it's not exactly snappy... If anyone has any suggestions? I'm thinking TurboForth if it has not already been taken by another TI Forth...

Mark

---

From: "kabldb" <[email-masked]>
Date: Fri, 18 Dec 2009 13:20:17 -0000

Bravo !

What happens on screen when you disable scrolling ?

What about myForth, tForth, eForth, iForth, iFought, utterForth, ForthNuts, u&iForth, backForth, back&Forth, britForth, ForthCS, Forth7, myLife2, iWon, iWonder, wanderForth, goForth ...

;-)

Karsten

http://sometimes.99er.net
http://www.atariage.com/forums/topic/154680-destroyer-rgpc

---

From: mark wills <[email-masked]>
Date: Fri, 18 Dec 2009 05:30:52 -0800 (PST)

It wraps around to the top ;-)

I like GoForth!

>
>From: kabldb <[email-masked]>
>To: [email-masked]
>Sent: Fri, 18 December, 2009 14:20:17
>Subject: [TI994A] Re: FORTH speed tests
>
> >
>
>
>
>
>  >
>>      
> 
>Bravo !
>
>http://sometimes. 99er.net
>http://www.atariage .com/forums/ topic/154680- destroyer- rgpc
>
>>--- In TI994A@yahoogroups. com, mark wills <markrobertwills@ ...> wrote:
>>>

---

From: fdos <[email-masked]>
Date: Fri, 18 Dec 2009 08:17:46 -0700

How about Quick4th, Speedy4th, 5th-1, or even BadAss4th! :-)

Bill S

mark wills wrote:
>     *From:* kabldb <[email-masked]>
>     *To:* [email-masked]
>     *Sent:* Fri, 18 December, 2009 14:20:17
>     *Subject:* [TI994A] Re: FORTH speed tests
> 
>      
> 
>     Bravo !
> 
>     What about myForth, tForth, eForth, iForth, iFought, utterForth,
>     ForthNuts, u&iForth, backForth, back&Forth, britForth, ForthCS,
>     Forth7, myLife2, iWon, iWonder, wanderForth, goForth ...
> 
>     ;-)
> 
>     Karsten
> 
>     http://sometimes. 99er.net <http://sometimes.99er.net>
>     <http://www.atariage.com/forums/topic/154680-destroyer-rgpc>
> 
>     --- In TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com>,
>     mark wills <markrobertwills@ ...> wrote:
>      >
>      > I played around with it a little bit today. It is difficult
>     without the manual to know the meaning and stack signatures for each
>     word, but it is useful to test the behaviour of my own Forth to see
>     if it behaves the same on the words that I do know.
>      >
>      > I still don't have a name for my Forth project. At the moment,
>     it's just cForth (Cartridge Forth) but it's not exactly snappy... If
>     anyone has any suggestions? I'm thinking TurboForth if it has not
>     already been taken by another TI Forth...
>      >
>      > Mark
>      >
> 
>

---

From: fdos <[email-masked]>
Date: Fri, 18 Dec 2009 09:15:57 -0700

Or KickAss4th, Instant4th, IxI4th (module instant & fast instant or I 
squared), IQ4th (Incredibly Quick), Flash4th (maybe in FLASH?) & 
GOcart4th ;-)

Bill S

fdos wrote:
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
>

---

From: Brian Tristam Williams <[email-masked]>
Date: Fri, 18 Dec 2009 18:46:40 +0200

FIFTH

2009/12/18 fdos <[email-masked]>

> >> *From:* kabldb <[email-masked] <kabldb%40yahoo.dk>>
> >> *To:* [email-masked] <TI994A%40yahoogroups.com>
> >> --- In TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com<TI994A%2540yahoogroups.com>
> >,

-- 
Brian Tristam Williams

"One man can make a difference."

---

From: tursi <[email-masked]>
Date: Fri, 18 Dec 2009 09:22:42 -0800 (PST)

>>>     (not possible on FIG) you get 0:11.3 :-)

Let's speed up your scroll routine... >:)

---

From: fdos <[email-masked]>
Date: Fri, 18 Dec 2009 10:40:57 -0700

Great idea!  Please include an 80 column text (TEXT2) screen scroll also 
for those of us with V9938/V9958 VDP powered TI systems and/or that use 
the MESS TI (or future Classic99) emulator.

Bill S

---

From: fdos <[email-masked]>
Date: Fri, 18 Dec 2009 10:52:41 -0700

Mark,

I keep hoping that someone will eventually put the figForth cart 
documentation up on WHTECH, but no indications yet.  Maybe Santa will 
put it up on Christmas Eve (All I want for Christmas is ....).

Bill S

mark wills wrote:
> I played around with it a little bit today. It is difficult without the 
> manual to know the meaning and stack signatures for each word, but it is 
> useful to test the behaviour of my own Forth to see if it behaves the 
> same on the words that I do know.
> 
> The timings were as follows: (Both running in Classic99)
> 
> I still don't have a name for my Forth project. At the moment, it's just 
> cForth (Cartridge Forth) but it's not exactly snappy... If anyone has 
> any suggestions? I'm thinking TurboForth if it has not already been 
> taken by another TI Forth...
> 
> Mark
>

---

From: "Ksarul" <[email-masked]>
Date: Fri, 18 Dec 2009 18:20:08 -0500

I think I have it--in German.  I'll look over the holidays. . .

Jim Fetzner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
fdos
Sent: Friday, December 18, 2009 12:53 PM
To: [email-masked]
Subject: Re: [TI994A] FORTH speed tests

Mark,

Bill S

Yahoo! Groups Links

---

From: mark wills <[email-masked]>
Date: Fri, 18 Dec 2009 20:03:32 -0800 (PST)

That's already built in - in so far as the system has a proper 'cursor' XY system (via EMIT) and the screen scrolling is already adapted to cater for 32,40 or 80 columns.

I haven't tested 80 column mode yet due to the lack of support in the emulators. As far as I know, only TI994W has it. I have an email from the author with the register settings for 80 column. I need to spend some time getting the binary image working in TI994W. The editor will also adapt automagically between 40 (windowing, FWEB style) and 80 columns.

I'm getting short of memory though - yesterday I added FORGET and ( to allow comments in the source.
962 bytes left, still got to finish the editor.

I also wrote a nice decompiler: SEE which can decompile Forth code from RAM. It's not finished yet but already decompiles most things. It's not included in the cartridge though. It will be a utility to load from disk, since you don't need it much.

Would anyone be interested in a companion website to go with the Forth system? I'll also happily host other site for systems such as X4th. I'm thinking about having the manual for the cartridge available as a hyperlinked HTML file on the web.

----- Original Message ----
> From: fdos <[email-masked]>
> Sent: Fri, 18 December, 2009 18:40:57
> Subject: Re: [TI994A] Re: FORTH speed tests
>

---

From: mark wills <[email-masked]>
Date: Fri, 18 Dec 2009 20:06:03 -0800 (PST)

Yes. The cartridge is a little on the slow side, but it is done very well. I think its only slower because more words are written in Forth, whereas mine is mostly assembler. On the other hand, mine isn't FIG (or anything else) compatible. It's 'Marks' Forth, basically a mish-mish of 79 (FIG) and 83 with some other stuff thrown in. Documentation will be essential.

Mark

----- Original Message ----
> Sent: Fri, 18 December, 2009 18:52:41

---

From: mark wills <[email-masked]>
Date: Fri, 18 Dec 2009 23:34:20 -0800 (PST)

Sure, knock yourself out ;-)

Here's how it works...

It's very simple, it uses VMBR and VMBR (my own versions) to read a LINE from VDP into a LINE buffer (there is no screen buffer). It then writes that line one line above. So, it reads line 1, writes it to line 0. Reads line 2, writes it to line 1... Then it blanks the last line.

I'll stick my neck out and say there's isn't much you can do with it ;-)

Mark

; Scroll screen up by one line. Used by EMIT and CR to scroll the screen up if
; necessary (subroutine, not a FORTH word).
scrlup    mov @noscrl,r8    ; test NOSCROLL
        jeq scrlno        ; scrolling is supressed
        dec @scrY        ; clip y coordinate to 23
        li r8,scnbuf    ; store address of screen buffer in r8
        li r6,23        ; 23 lines to shift
        clr r0            ; screen address
sclup_    a @xmax,r0        ; move down one line
        mov r8,r1        ; address of buffer to store in
        mov @xmax,r2    ; number of bytes to store in the screen line buffer
        bl @vmbr        ; read screen data into buffer
        neg @xmax        ; set x negative
        a @xmax,r0        ; move up one line
        neg @xmax        ; restore x to positive
        mov @xmax,r2    ; number of bytes to write
        mov r8,r1        ; address of screen buffer
        bl @vmbw        ; write buffer to screen
        a @xmax,r0        ; move down a line
        dec r6            ; decrement the number of lines left to shift
        jne sclup_        ; repeat if not finished
        li r2,scnbuf    ; were done - now erase the bottom line: screen buffer
                        ; address in r2
        mov @xmax,r6    ; screen width
        li r1,>2020        ; two space characters
blnkln    mov r1,*r2+        ; write two spaces to the buffer
        dect r6            ; decrement character count
        jne blnkln        ; loop if not finished
        li r1,scnbuf    ; get ready for vmbw: buffer address in r1
        mov @xmax,r2    ; number of bytes to write in r2
        bl @vmbw        ; write blank line
        b *r9            ; return
scrlno    clr @scrY        ; scrolling is supressed, so zero Y
        clr @scrX        ; and x
        b *r9            ; and return

>
>From: tursi <[email-masked]>
>Sent: Fri, 18 December, 2009 18:22:42

---

From: mark wills <[email-masked]>
Date: Fri, 18 Dec 2009 23:37:30 -0800 (PST)

I hate how yahoo screws up the formatting.
But I like how we can add attachments!
See attached for formatted source code.

M

>
>From: mark wills <[email-masked]>
>Sent: Sat, 19 December, 2009 8:34:20
>>>From: tursi <yahoogroup@harmless lion.com>
>>>To: TI994A@yahoogroups. com

---

From: "Tursi" <[email-masked]>
Date: Sat, 19 Dec 2009 04:44:41 -0500

> I'll stick my neck out and say there's isn't much you can do with it ;-)

Ooh, a /challenge/, eh? Well, it's only 4:45am....

Your attachment didn't seem to work, but as long as no code is missing 
that's fine ;)

---

From: "kabldb" <[email-masked]>
Date: Sat, 19 Dec 2009 10:07:27 -0000

Hmm ... Attachment works fine here.

---

From: mark wills <[email-masked]>
Date: Sat, 19 Dec 2009 02:29:34 -0800 (PST)

That there code, that's poetry that is ;-)

>Sent: Sat, 19 December, 2009 11:07:27
>>--- In TI994A@yahoogroups. com, "Tursi" <yahoogroup@ ...> wrote:
>>>

---

From: "Tursi" <[email-masked]>
Date: Sat, 19 Dec 2009 06:16:21 -0500

> Here's how it works...
> It's very simple, it uses VMBR and VMBR (my own versions) to read a LINE 
> from VDP into a LINE buffer (there is no screen buffer). It then writes 
> that line one line above. So, it reads line 1, writes it to line 0. Reads 
> line 2, writes it to line 1... Then it blanks the last line.

Hehe.. well, that's not fair - the most critical code is in VMBR and VMBW, 
and you didn't include that.

I will say, you hit @xmax too often in your outer loop there:

Put it in a register. You'll save 6 words and the corresponding 48 cycles of 
memory access time (72 if it's in 8-bit RAM). Not a ton, admittedly, but 
over the whole loop that's 1104 cycles (or 1656). I'd go farther and say 
that you're better off using immediate values than a static memory location, 
but for that you'd need a different scroll routine for every width.

This costs, too, you could just use:
        s @xmax,r0

That would save 40 cycles (or 48 if xmax is in 8-bit RAM) per line, or 920 
cycles total (1104).

Ideally, if you do all the VDP access inline, you'll save a fair bit. Not so 
much in the main scroll (the bl@ only costs 20 cycles), but definitely in 
blnkln where you write data to a temporary buffer, then write that same data 
to the VDP (ie: two copy loops where one would do).

I notice you have scrX and scrY. Would it be sensible to use a single 
address instead, or do you need them separate too often? Depending on which 
way they are used more often would decide which makes more sense.

Overall, I'd suggest something like this (but again - not fair without 
access to the inner loop, so I've removed the BL's ;) )

I've assumed the following:
-on entry, scrY is off the bottom. I don't assume the screen is 24 lines 
high (so left that code alone)
-scrnbuf is an equ pointing to the line buffer in CPU, which is at least 
xmax bytes
-I can only use the registers r0,r1,r2,r6,r8,r11 (because these are the only 
ones you overwrite)
-VDPWA, VDPWD and VDPRD are EQU'd somewhere correctly
-MYWP is an equate for the current workspace
-Interrupts are disabled

; Scroll screen up by one line. Used by EMIT and CR to scroll the screen up 
if
; necessary (subroutine, not a FORTH word).
VDPBIT DATA >4000

scrlup    mov @noscrl,r8    ; test NOSCROLL
        jeq scrlno        ; scrolling is supressed
        dec @scrY        ; clip y coordinate to 23
        li r8,scnbuf    ; store address of screen buffer in r8
        mov @xmax,r11  ; save width of screen (note: any other register is 
preferable, but I know R11 is free)
        li r6,23        ; 23 lines to shift (but if you copied scrY, it 
could be any height!)
        clr r0            ; screen address

sclup_    a r11,r0        ; move down one line
        SZCB @VDPBIT,R0    ; unfortunate to need to clear this
        mov r8,r1        ; address of buffer to store in
        mov r11,r2    ; number of bytes to store in the screen line buffer
        movb @MYWP+1,@VDPWA    ; low byte of R0
        movb R0,@VDPWA             ; high byte of R0
mbrlp
        movb @VDPRD,*R1+
        movb @VDPRD,*R1+
        dect r2
        jgt mbrlp          ; just in case someone passed in an odd value
        s r11,r0            ; move up one line
        mov r11,r2    ; number of bytes to write
        mov r8,r1        ; address of screen buffer
        SOCB @VDPBIT,R0  ; set 'write' flag for VDP (would be nice to put 
VDPBIT's data in a register, save 24 cycles)
        movb @MYWP+1,@VDPWA    ; low byte of R0
        movb R0,@VDPWA             ; high byte of R0
mbwlp
        movb *R1+,@VDPWD
        movb *R1+,@VDPWD
        dect r2
        jgt mbwlp        ; just in case someone passed in an odd value
        a r11,r0        ; move down a line
        dec r6            ; decrement the number of lines left to shift
        jne sclup_        ; repeat if not finished

        li r1,>2000        ; space character - we need to erase the bottom 
line, R0 is still set for write
        movb @MYWP+1,@VDPWA    ; low byte of R0
        movb R0,@VDPWA             ; high byte of R0
        mov r11,r2
erlp
        movb r1,@VDPWD
        movb r1,@VDPWD
        dect r2
        jgt erlp                            ; in case an odd width was 
passed
        b *r9            ; return

In addition to what I noted above, I also did a slight unroll of the read 
and write loops. I've checked the timings and on the fastest action (the two 
reads in a row) there's 3uS of slack over the worst case scenario (should be 
11uS between hits, VDP at most needs 8uS). Based on the assumptions I've 
made about your system - variables in 8-bit RAM, registers in Scratchpad, 
code in cartridge, this should be able to scroll a 32x24-character screen in 
about 166,974 cycles (including the scroll test at the top and the return).. 
so that would be 56mS or just shy of 18fps if you did nothing but loop.

Oi.. mustn't do these so late at night. :) hehe.. hope there's something 
useful ;)

---

From: mark wills <[email-masked]>
Date: Sat, 19 Dec 2009 03:39:25 -0800 (PST)

Wow! Nice one, I'll take a look at that!

Here's my VDP routines:

;[ vdp multiple byte read
; inputs: r0=vdp source address, r1=cpu ram destination address
; r2=number of bytes to read
; side effects: r1 & r2 changed
vmbr    swpb r0
        movb r0,@vdpa
        swpb r0
        movb r0,@vdpa
        nop
vmbr1    movb @vdpr,*r1+
        dec r2
        jne vmbr1
        rt

;[ vdp multiple byte write
; r0=destination in vdp, r1=source address in cpu ram, r2=number of bytes
; side effects: r1 & r2 changed
vmbw    ori r0,>4000
        swpb r0
        movb r0,@vdpa
        swpb r0
        movb r0,@vdpa
        nop
vmbw1    movb *r1+,@vdpw
        dec r2
        jne vmbw1
        xor @bit1,r0    ; reset bit 1
        rt

Note the NOPs - old code! Written ages ago.

The XOR annoys me. It's not required on Win994A, but is on Classic99 - we discussed this privately around a year or so ago. The conclusion was it wouldn't work on a real TI without it.

Mark

>
>From: Tursi <[email-masked]>
>Sent: Sat, 19 December, 2009 12:16:21
>>-I can only use the registers r0,r1,r2,r6, r8,r11 (because these are the only 
>>ones you overwrite)

---

From: "kabldb" <[email-masked]>
Date: Sat, 19 Dec 2009 12:09:51 -0000

<snip>
</snip>

As far as I recall we haven't _proven_ that it's safe to leave out the NOPs. TI recommended it. And luckily it's outside the loop.

<snip>
The XOR annoys me.
</snip>

I don't use it, but then r0 has a side effect (changed).

:-)

--- In [email-masked], mark wills <markrobertwills@...> wrote:
> >From: Tursi <yahoogroup@...>

---

From: "kabldb" <[email-masked]>
Date: Sat, 19 Dec 2009 12:20:49 -0000

Wow ! Good feedback. No news as such but never the less a good and thoroughly rundown. Round of applause.

:-)

---

From: ti99_forever <[email-masked]>
Date: Sat, 19 Dec 2009 04:42:22 -0800 (PST)

I got greedy with my screen scroll routines and did it an entire screen at a time...

--- On Sat, 12/19/09, mark wills <[email-masked]> wrote:

> Date: Saturday, December 19, 2009, 2:34 AM
> It's very simple, it uses VMBR and VMBR (my own versions)
> to read a LINE from VDP into a LINE buffer (there is no
> screen buffer). It then writes that line one line above. So,
> it reads line 1, writes it to line 0. Reads line 2, writes
> it to line 1... Then it blanks the last line.
> 
>         clr r0     
>       ; screen address
>         mov @xmax,r2    ;
> number of bytes to store in the screen line buffer
>         bl @vmbr     
>         dec r6     
>       ; decrement the number of lines left to
> shift
>         jne sclup_     
>   ; repeat if not finished
>         li r2,scnbuf    ;
> were done - now erase the bottom line: screen buffer
>                
>         ; address in r2
>         mov @xmax,r6    ;
> screen width
>         li r1,>2020   
>     ; two space characters
> blnkln    mov r1,*r2+       
>         b *r9     
>       ; return
>         clr @scrX     
>   ; and x
>         b *r9     
>       ; and return
> >  >
> >>>>     > My Forth:
> 0:39.0
> >>>>>     > If you
> disable screen scrolling on my forth with FALSE SCROLL !
> >>>>>     (not possible
> on FIG) you get 0:11.3 :-)
> >
>     [email-masked]
> 
> 
>

---

From: "kabldb" <[email-masked]>
Date: Sat, 19 Dec 2009 13:23:39 -0000

I once had 24 lines in memory and a pointer to the line which was to be at the top. When I had to scroll up (or down) I changed the pointer and did 2 "blits" (moving chunks or CPU memory to VDP). One blit from pointer to end of memory and one from top of memory to pointer (filling vdp screen from the top).

:-)

--- In [email-masked], ti99_forever <ti99_forever@...> wrote:
> --- On Sat, 12/19/09, mark wills <markrobertwills@...> wrote:
> 
> > From: mark wills <markrobertwills@...>
> > number of bytes to write
> > number of bytes to write in r2
> >         bl @vmbw     
> >   ; write blank line
> >         b *r9     
> >       ; return
> > scrlno    clr @scrY        ;
> > >From: tursi <yahoogroup@...>

---

From: ti99_forever <[email-masked]>
Date: Sat, 19 Dec 2009 05:33:46 -0800 (PST)

To get even sillier with my silly ideas... I once had the idea of "refreshing" the VDP emulator style...

That is, maintain a "VDP" in CPU memory and update it ever so often. Once every so many VDP interrupts, or "rolling updates" where you update only a portion during one interrupt...

Yeah, add it to my other 1,000 silly ideas...

--- On Sat, 12/19/09, kabldb <[email-masked]> wrote:

> Date: Saturday, December 19, 2009, 8:23 AM
> I once had 24 lines in memory and a
> pointer to the line which was to be at the top. When I had
> to scroll up (or down) I changed the pointer and did 2
> "blits" (moving chunks or CPU memory to VDP). One blit from
> pointer to end of memory and one from top of memory to
> pointer (filling vdp screen from the top).
> 
> :-)
> 
> 
> > > I'll stick my neck out and say there's isn't much
> you can
> > > do with it ;-)
> > > 
> > > Mark
> > > 
> > > ; Scroll screen up by one line. Used by EMIT and
> CR to
> > > scroll the screen up if
> > > >>Let's speed up your scroll routine...
> >:)
> > > >
> > > >
> > > > 
> > > 
> > >

---

From: "kabldb" <[email-masked]>
Date: Sat, 19 Dec 2009 15:10:14 -0000

It's not at all silly. Okay, TI-99/4A computing is considered pretty silly these days, but I might learn something useful, or so I tell my family. I've been working on and off on 2 bitmap demos. One has a lot of pixels acting like a 3D surface, the other does some 3D vector animation. Well, in both cases I generate one frame in CPU RAM Expansion Memory, while the VDP displays another/the last frame, then I copy 12K from CPU RAM to VDP, clears the CPU RAM and finally starts generating the next frame in CPU RAM. I did much the same thing in my Turn It Down demo (copy one screen from CPU to VDP when it's done).

:-)

--- In [email-masked], ti99_forever <ti99_forever@...> wrote:
> --- On Sat, 12/19/09, kabldb <kabldb@...> wrote:
> 
> > From: kabldb <kabldb@...>
> > --- In [email-masked],
> > ti99_forever <ti99_forever@> wrote:
> > >
> > > --- On Sat, 12/19/09, mark wills
> > <markrobertwills@> wrote:
> > > 
> > > > From: mark wills <markrobertwills@>
> > > > >From: tursi <yahoogroup@>

---

From: fdos <[email-masked]>
Date: Sat, 19 Dec 2009 08:30:40 -0700

Thanks, it will be helpful.

Bill S

Ksarul wrote:
> From: [email-masked] <mailto:TI994A%40yahoogroups.com> 
> [mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>] On 
> Behalf Of
> fdos
> To: [email-masked] <mailto:TI994A%40yahoogroups.com>

---

From: fdos <[email-masked]>
Date: Sat, 19 Dec 2009 08:51:47 -0700

No, MESS has 80 column support for the TI, just like it does for the TI. 
  One only has to choose the EVPC version of the MESS TI emulator.  The 
V9938 version has been available since early 2003, and it works very 
well, but there is a random exit error (back to the title screen) that 
requires a manual reset.  Raphael never got it fixed, and apparently the 
"bug" report got lost during the transition.

FYI I also have the "SEE" decompiler in a binary code library of MDOS 
Forth+.  Currently it's in my 8K (SuperCart) support tools along with 
the expanded TI assembler and 80 column editor, but all will migrate to 
binary code libraries eventually.

Bill S

mark wills wrote:
>  
> 
> That's already built in - in so far as the system has a proper 'cursor' 
> XY system (via EMIT) and the screen scrolling is already adapted to 
> cater for 32,40 or 80 columns.
> 
> I haven't tested 80 column mode yet due to the lack of support in the 
> emulators. As far as I know, only TI994W has it. I have an email from 
> the author with the register settings for 80 column. I need to spend 
> some time getting the binary image working in TI994W. The editor will 
> also adapt automagically between 40 (windowing, FWEB style) and 80 columns.
> 
> I also wrote a nice decompiler: SEE which can decompile Forth code from 
> RAM. It's not finished yet but already decompiles most things. It's not 
> included in the cartridge though. It will be a utility to load from 
> disk, since you don't need it much.
> 
> Would anyone be interested in a companion website to go with the Forth 
> system? I'll also happily host other site for systems such as X4th. I'm 
> thinking about having the manual for the cartridge available as a 
> hyperlinked HTML file on the web.
> 
>  > From: fdos <[email-masked] <mailto:fdosbrs%40frontiernet.net>>

---

From: fdos <[email-masked]>
Date: Sat, 19 Dec 2009 09:16:04 -0700

X4th99 (and Forth+ for that matter) is TI (fig) Forth for all matching 
words, but words not in the TI FORTH glossary are also a mish-mash of 79 
and 83, but Forth+ has, as will X4th99, an F83 compatibility binary code 
library intended only so users can "RUN" existing F83 code in 
Forth+/X4th99, and should not be used to develop applications (as the 
F83 binary code library has to be mapped in almost always, therefore, 
other Forth+/X4th99 libraries would be very difficult to use).  Besides 
the F83 Vocabulary stack and associated operations are not implemented. 
  I did attempt to do it in Forth+, but this required any common words 
that were in binary code libraries to be controlled by the stack 
operations also.  It just became too complicated for my very simple 
mind.  The "hooks" and source are still there, but commented out of the 
assembly and compile operations.

So goes the development compromise process.  For Forth+ 2.00 I 
considered updating to ANS Forth, but it is highly based on Forth 83, so 
that didn't get far at all.

Bill S

mark wills wrote:
>  
> 
> Yes. The cartridge is a little on the slow side, but it is done very 
> well. I think its only slower because more words are written in Forth, 
> whereas mine is mostly assembler. On the other hand, mine isn't FIG (or 
> anything else) compatible. It's 'Marks' Forth, basically a mish-mish of 
> 79 (FIG) and 83 with some other stuff thrown in. Documentation will be 
> essential.
> 
> Mark
>

---

From: "Tursi" <[email-masked]>
Date: Sat, 19 Dec 2009 15:47:37 -0500

>The XOR annoys me. It's not required on Win994A, but is on Classic99 - we 
>discussed this privately around a year or so ago. The >conclusion was it 
>wouldn't work on a real TI without it.

Only if you are continuing to use R0 for reads after the write (which you 
are).

Remember what that "write mode" bit in the address does - it's the prefetch 
inhibit, and it affects what address your next data operation affects.

-If the bit is SET, the VDP does NOT prefetch a byte of data, and the 
address counter remains where you set it,
-If the bit is CLEAR, the VDP DOES prefetch a byte of data, and the address 
counter is incremented.

/Unrelated/ to the above:

-When you READ DATA, the VDP returns the value currently in the prefetch 
buffer, fetches the byte pointed to by the address counter into the prefetch 
buffer, then increments the address counter
-When you WRITE DATA, the VDP stores your byte in the prefetch buffer, 
copies it to memory at the address pointed to by the address counter, then 
increments the address counter

Thus: if you use the bit exactly as its intended, everything works just like 
you'd expect. If you mix the modes you'll get weird results.

Remember I tried to give you the opposite trick as a speedup, too, using the 
faster DEC and INC to avoid needing to set the inhibit bit (decrement the 
desired address, load to the VDP - which will prefetch and increment, start 
writing, increment the address on return if needed) - this works on a real 
TI and Classic99 too, but failed on Win994A, so you didn't want to use it 
(so I didn't use it in this morning's code ;) ).

I got very familiar with the operation of the VDP memory access while fixing 
it in Classic99. Win994A suffers from the exact same problems I had before I 
implemented it properly. You can see the errors most easily running Popeye 
(right edge of playfield corrupted, bottles don't get erased as they cross 
the screen) or the Diagnostics cartridge Checkerboard memory test. The way 
that the E/A describes VDP access really glosses over a lot of it - on a 
casual inspection, it looks like a simplified approach should work fine. But 
in practice, there are a few gotchas when coders do things slightly 
differently.

---

From: "Tursi" <[email-masked]>
Date: Sat, 19 Dec 2009 15:53:53 -0500

> As far as I recall we haven't _proven_ that it's safe to leave out the 
> NOPs. TI recommended it. And luckily it's outside the loop.

We proved it "on paper", so to speak. I had the logic analyzer on the bus 
and measured everything we threw at it. There was some attempt to start 
proving it in code, but I don't know if that was completed. I believe the 
basics were confirmed.

The only way to beat it on a stock system is with code in scratchpad, doing 
a move FROM the VDP using register indirect mode for both arguments (or the 
change workspace and use LI trick).

The datasheet tells us that the worst case scenario is 8uS between accesses. 
We can't even come close to that with writes because of the combination of 
the multiplexer and the read-before-write of the 9900. And we can only hit 
it with reads as documented above.

---

From: "Tursi" <[email-masked]>
Date: Sat, 19 Dec 2009 15:58:45 -0500

> I once had 24 lines in memory and a pointer to the line which was to be at 
> the top. When I had to scroll up (or down) I changed the pointer and did 2 
> "blits" (moving chunks or CPU memory to VDP). One blit from pointer to end 
> of memory and one from top of memory to pointer (filling vdp screen from 
> the top).
>

That's your fastest way - work on CPU memory and just copy it when needed --  
and that gives you a nice ring buffer so there's no unneeded shifting. :) Of 
course, you have to be able to spare that much CPU RAM.

I did the same thing with my sprite table for flicker purposes. ;)

---

From: mark wills <[email-masked]>
Date: Sun, 20 Dec 2009 20:56:34 -0800 (PST)

Yeah, I'd like to have done it like that but I wanted to leave some memory free in low-mem (where all the system stuff lives). In my forth, it is possible to use both high and low memory for your programs/data - the user have 27K of RAM to play with.

FFAILM @ HERE ! 

The above line of code gets the [F]irst [F]ree [A]ddress [I]n [L]ow [M]emory, and writes it to HERE. HERE tracks the current location that data is compiled to.

So you can do something like:

FFAILM @ HERE ! ( work in low memory )
: TEST 100 0 DO I . LOOP ; ( count to 100 )
FFAIHM @ HERE ! ( work in low memory )
: TEST2 BEGIN ." FORTH ROCKS " AGAIN ;

Seperate memory pointers track the available memory in high and low banks. Want to know how much memory you have free, just type FREE ;-)

See attached screenshot ;-)

Mark

>Sent: Sat, 19 December, 2009 14:23:39
>>--- In TI994A@yahoogroups. com, ti99_forever <ti99_forever@ ...> wrote:
>>>
>>> --- On Sat, 12/19/09, mark wills <markrobertwills@ ...> wrote:
>>> 
>>> > From: mark wills <markrobertwills@ ...>
>>> > >From: tursi <yahoogroup@ ...>
>>> > >>>>     > My Forth:
>>> > >>>>>     > If you
>>> > ------------ --------- --------- ------
>>> > 
>>> > Yahoo! Groups Links
>>> > 
>>> > 
>>> >     TI994A-fullfeatured @yahoogroups. com
>>> > 
>>> > 
>>> >
>>>
>
>
>

---

From: mark wills <[email-masked]>
Date: Sun, 20 Dec 2009 20:58:36 -0800 (PST)

That's not silly - that's basically buffering. Double buffering is a technique often used in game development. Two copies of the screen are kept in memory. One is updated while the other is on screen. This technique is useful for games using software sprites. Software sprites without double buffering tend to flicker, depending on coding technique of course.

Mark

>
>From: ti99_forever <[email-masked]>
>Sent: Sat, 19 December, 2009 14:33:46
>>--- On Sat, 12/19/09, kabldb <kabldb@yahoo. dk> wrote:
>
>>> From: kabldb <kabldb@yahoo. dk>
>>> <markrobertwills@ ...> wrote:
>>> >

---

From: mark wills <[email-masked]>
Date: Sun, 20 Dec 2009 21:07:33 -0800 (PST)

Hi Bill,

That's useful information, and a good reason to install MESS, which I un-installed some time ago as I don't like the MESS gui at all (although the TI emulator is excellent!)

That means I can test 80 column support in both MESS and TI994W which is good news.

Regarding SEE, it's quite an interesting program to write, and quite challenging (to a Forth Newbie like me).

There are number of special cases that must be taken into account, such as LIT, BRANCH, 0BRANCH etc, because the de-compiler needs to read-ahead and get the parameter and simply display it, NOT decompile it. 

Here is my SEE program so far, with the utility word CFA> (CFA> converts a cfa into a dictionary address, whereas >CFA converts a dictionary address into a CFA, as I'm sure you know!)

Note that a better way to write this code wouyld have been with CASE..OF - but I hadn't coded those words! I now have them however ;-)

Enjoy the Forthness!

Mark,

VARIABLE SpecialFlag

: CFA> LATEST @ BEGIN ?DUP WHILE 2DUP SWAP U< IF NIP EXIT THEN @ REPEAT DROP 
   0 ;

: NextWord ( addr -- addr+2 ) 2+ ;

: WRAP? ( addr len -- addr len ) DUP XY? DROP + 40 > IF CR THEN ;
  
: SetFlag? IF 1 SpecialFlag ! THEN ;
  
( special cases )
: IsLIT? ( addr -- addr ) DUP @ ['] LIT = SetFlag? ;
: IsBRANCH? ( addr -- addr ) DUP @ ['] BRANCH = SetFlag? ;
: Is0BRANCH? ( addr -- addr ) DUP @ ['] 0BRANCH = SetFlag? ;
: GetLITERAL ( addr -- addr ) DUP NextWord @ . NextWord ;

: DoSpecialCases ( addr -- addr )
  0 SpecialFlag !
  IsLIT?
  IsBRANCH?
  Is0BRANCH?
  DROP
  SpecialFlag @ IF GetLITERAL THEN
;

: ShowWord ( addr -- addr )
  DUP ( for DoSpecialCases below )
  DUP @ CFA> 2+ DUP @ SWAP 2+ SWAP WRAP? TYPE SPACE
  DoSpecialCases
;

: ForthWord? ( dict_addr -- addr t/f )
  ." ADDRESS: " DUP $.
  DUP 8000$ AND IF ." (IMMEDIATE) " THEN
  >CFA DUP @
  8320$ =
  IF
    ." FORTH" 
    CR 
    ." DOCOL "
    NextWord
    TRUE
  ELSE
    ." ASSEMBLY" CR
    FALSE
  THEN
;

: NotExit? ( addr -- addr t/f ) DUP @ 832E$ <> ;
(>832A is the CFA of DOCOL )

: GoSee ( dict_addr -- )
  ForthWord?
  IF
    BEGIN 
      NotExit?
    WHILE
      ShowWord
      NextWord
    REPEAT
    ." EXIT" CR
    DROP
  ELSE
    DROP
  THEN
;

: SEE 
  WORD FIND ?DUP 
  IF 
    CR GoSee
  ELSE
    ." not found" CR 
  THEN
;

----- Original Message ----
> Sent: Sat, 19 December, 2009 16:51:47
> >  > From: fdos >

---

From: mark wills <[email-masked]>
Date: Sun, 20 Dec 2009 21:11:18 -0800 (PST)

Well, it seems ANS forth has it's own issues, as is often hotly debated on comp.lang.forth

There is an oft occuring rant/debate about the word POSTPONE, which is a kind of replacement about the mess of words ['] ' , LITERAL 

My plan is to do a version of Forth for an ARM based system after this (embedded). I'll not be implementing any particular standard - it will be coded to do what I want, how I want ;-)

Mark

----- Original Message ----
> Sent: Sat, 19 December, 2009 17:16:04

---

From: mark wills <[email-masked]>
Date: Sun, 20 Dec 2009 21:15:46 -0800 (PST)

Thanks, nice post. I will cross post this to 99er.net forums in the hope that Cory eventually reads it.

Mark

>Sent: Sat, 19 December, 2009 21:47:37

---

From: fdos <[email-masked]>
Date: Mon, 21 Dec 2009 09:14:14 -0700

Mark,

I began with MESS due to MDOS Forth+ 2.00 development (obviously, not 
possible with PC99 or any other emulator at that time or now. 
Naturally, once I decided to do a TI-99/4A version of Forth+ I stayed 
with MESS because I could use all the floppy disk and hard disk images 
from Forth+ and MESS supported 80 columns and up to 1MB of AMS/SAMS 
(only a good PC keyboard implementation is missing--may require a 
TI-99/4P emulation), so almost ideal for my purposes.

I do agree that the MESS GUI leaves a lot to be desired, and more 
detailed explanation of how to setup and customize to suit the user.

The "SEE" I use is implemented with "CASE...OF...ENDOF... ENDCASE", and 
works in Forth+ and in TI FORTH, but needs some tweaks to fully support 
X4th99 (mostly due to more complex paging).  However, I will study your 
implementation for possible speed ups and efficiency, as time and 
priorities allow--Christmas and family at the moment.

What we really need, tool wise, is a Forth style disassembler.  I will 
eventually get around to it, but that is way down on my priority stack!

Keep on Forthing.

Bill S

mark wills wrote:
>  
> [Attachment(s) <#TopText> from mark wills included below]
> 
> Hi Bill,
> 
> That's useful information, and a good reason to install MESS, which I 
> un-installed some time ago as I don't like the MESS gui at all (although 
> the TI emulator is excellent!)
> 
> There are number of special cases that must be taken into account, such 
> as LIT, BRANCH, 0BRANCH etc, because the de-compiler needs to read-ahead 
> and get the parameter and simply display it, NOT decompile it.
> 
> Here is my SEE program so far, with the utility word CFA> (CFA> converts 
> a cfa into a dictionary address, whereas >CFA converts a dictionary 
> address into a CFA, as I'm sure you know!)
> 
> Note that a better way to write this code wouyld have been with CASE..OF 
> - but I hadn't coded those words! I now have them however ;-)
> 
> Enjoy the Forthness!
> 
> Mark,
> 
> VARIABLE SpecialFlag
> 
>  > > > > >>> > If you disable screen scrolling on my forth with FALSE 
> SCROLL !
>  > > > > >>> (not possible on FIG) you get 0:11.3 :-)
>  > > > >