TurboForth

[+TheBF]

Just imagine how much faster you could find that in Forth. 

[+Lee Stewart]

1 hour ago, GDMike said:

I'm so glad you asked for that Char file..and saw that typo...

and there she is...while were here, Lee do you see anything weird on my sound byte code..i think its called "CDATA" 

from what i remember it was playing correctly on its first hit, but on its second round it bacame off frequency.

ok kids, what did Lee teach us? quite a bit, its never a loss when He gets ahold of something!! 

 

Ha!  ?

 

Re sound processing, there are a few things wrong:

1. You are moving 12 bytes to VRAM when there are 13 to move.
2. You should be checking >83CE in its own loop. As it is, you are resetting the sound table each time through the loop before the first instance of the sound has had a chance to finish.
3. Also, unless you want to repeat the sound indefinitely, you do not want to include the first part of your LOOP code in the loop.

Here is code that should work:

BP     LI   R0,BUFFER         You do not need to CLR R0,R1,R2
       LI   R1,CDATA          ...before loading them.
       LI   R2,13
       LIMI 0                 Disable interrupts while we mess with VRAM and sound setup.
       BLWP @VMBW
       LI   R10,BUFFER
       MOV  R10,@>83CC
       SOCB @H01,@>83FD
       MOVB @H01,@>83CE
       LIMI 2                 Enable interrupts so sound table will be processed.
LOOP   MOVB @>83CE,@>83CE     Wait until sound table 
       JNE  LOOP              ...has finished.
       LIMI 0
       MOVB R0,@STATUS
       RT

 

...lee

[GDMike]

thanks Lee very much. im def not good in sound in assy, TF and FB Forth make this easy. As for my count of 12 bytes, i think i was actually in the middle of a "What If" scenario in my troubleshooting. I Don't mind assembly, but last year I got about this much code completed then my PC seemed to get lost, as i used a lot of BL subs versus a straight down approach to my writing style. I always ended with a RT but found R11 was losing its mind sometimes and for someone always in a rush, i spent more time truoubleshooting rather than getting something done. TF was simple as basic and quickly took care of me, but im not seeing to many examples of things in TF covering RS232 serial tx/rx. Ill take this assy prgm to its max as long as I can reach my result the way I like it to be. So far im getting there.

[+Lee Stewart]

Though your CLR routine certainly gets the job done for clearing the screen:

CLR    CLR  R0
       LI   R1,>2000
CLRR   BLWP @VSBW
       INC  R0
       CI   R0,960
       JLT  CLRR
       RT

Here is a VRAM FILL routine adapted from fbForth via TI Forth that does it faster because it does not set the VRAM address for every byte:

       REF  VDPWA,VDPWD

*== VDP fill routine. =================================================
*
*     R0: VRAM address
*     R1: character to fill VRAM
*     R2: character count
*
VFILL  CLR  R0             Address to start VRAM fill
       LI   R1,>2000       Fill character in left byte
       LI   R2,960         Fill count
       ORI  R0,>4000       Set bit for VDP write
       SWPB R0
       MOVB R0,@VDPWA      LS byte first
       SWPB R0
       MOVB R0,@VDPWA      Then MS byte
       NOP                 Kill time
VFLOOP MOVB R1,@VDPWD      Write a byte & auto-increment VRAM address
       DEC  R2
       JNE  VFLOOP         Not done, fill another
       RT
*======================================================================

 

...lee

Edited June 26, 2019 by Lee Stewart
Cleaned up ALC

[+TheBF]

And just for the sake of discussion, after reviewing some of the high speed game code I found here on Atariage here is VFILL with VDPWD loaded into R3.

When I timed it versus the normal version Lee showed it seems to go about 12.9% faster. Not bad for a small code change.

Just a thought.

 

Here is the code in my Forth Cross-Assembler dialect but it's not too different from TI Forth Assembler.

 

Weird stuff:

• TOS is just an alias for R4 which is a "cache" for top of stack item.
• I use a sub-routine called WMODE to setup the VDPWA, to save space
• POP, is a Forth macro for:

: POP,          ( dst -- )  *SP+      SWAP  MOV, ;    \ 22 cycles

 

CODE: VFILL   ( VDP-addr count char-- )
              TOS SWPB,            \ fix the TMS9900 byte order
              R2 POP,              \ R2=count
              R0 POP,              \ VDP-addr popped into R0
              WMODE @@ BL,         \ setup VDP write address IN R0
              R3 VDPWD LI,         \ vdp addr. in a reg. makes this 12.9% faster
              BEGIN,
                TOS *R3 MOVB,      \ write byte to vdp ram
                R2 DEC,            \ dec the byte counter
              EQ UNTIL,            \ jump back if not done
              TOS POP,
              NEXT,
              END-CODE

 

[+TheBF]

9 hours ago, GDMike said:

im not seeing to many examples of things in TF covering RS232 serial tx/rx. Ill take this assy prgm to its max as long as I can reach my result the way I like it to be. So far im getting there.

I know Willsy got kind of excited when he saw that I was working on a driver for RS232 for my Forth system.

 

I know it's a pain to translate Forth Assembler to TI Assembler. ( I have done my share the other way)

But this code actually works to provide an OPEN, SEND and RCV routine. So here it is. Happy to answer any questions.

(It shows the signs of my trial and error in the comments.) ?

 

This code is in my home-made cross-compiled Forth dialect but it could be adapted to Turbo Forth or FB Forth pretty simply I think.

Here are some preliminary docs to explain it:

• CONSTANT:  is just a CONSTANT
• VARIABLE:   is just a VARIABLE
• T! is just !  (means "target" store" ie: for the TI progam image)
• EQU is like EQU but backwards syntax to TI ASM
• l:  means create a "label" . It's like CREATE in Turbo Forth and kind of like  "0 VARIABLE" in FB Forth (I think)
  
  Stuff you won't need:
• [CC] (CROSS-COMPILING) lets me use the interpreter to do simple calculations or change the RADIX interpretatively
• [TC] switches back to the [TARGET-COMPILING] mode to make TI programs
• RPUSH is macro. Below are the macros for both stacks.
   

  \ PUSH & POP on both stacks
  : PUSH,         ( src -- )  SP DECT,  *SP   MOV, ;    \ 10+18 = 28  cycles
  : POP,          ( dst -- )  *SP+      SWAP  MOV, ;    \ 22 cycles
  
  : RPUSH,        ( src -- ) RP DECT,  *RP   MOV,  ;
  : RPOP,         ( dst -- ) *RP+      SWAP  MOV,  ;
  

  There is some code below "housekeeping on USER VARIABLES..."   It just increments your variables to keep track of the video column and OUT which counts characters since the last carriage return.
  
  /explanations

• Spoiler

  
  \ xfcc99 cross-compiler tms9902 rs232/1 DIRECT cru DRIVER 9Feb2019 bjf
  \ CODE words are used to save kernel space by not needing the CRU library
  
  \ These routines push the value in R12 onto the return stack
  \ then restore it when returning to Forth.
  \ This supports accessing other I/O devices while using the serial port.
  
  [CC] HEX [TC]
                     1300 CONSTANT: RS232/1     \ card address
  [CC] RS232/1 40 +  [TC] CONSTANT: /TTY1       \ 40= uart#1,
  \ [CC] RS232/1 80 + [TC] CONSTANT: /TTY2      \ 80= uart#2
  
  \ 9902 control bits
  [CC] DECIMAL
         13 EQU LDIR           \ "load interval register"
  \ for reference...
  \      16 CONSTANT: RTSON    \ request to send
  \      18 CONSTANT: RIENB    \ rcv interrupt enable
  \      21 CONSTANT: RXRL     \ receive register loaded bit
  \      22 CONSTANT: TXRE     \ transmit register empty bit
  \      27 CONSTANT: -DSR     \ NOT data set ready
  \      28 CONSTANT: -CTS     \ NOT clear to send
         31 EQU RESET          \ 9902 reset bit
  
  [CC] HEX
  
  TARGET-COMPILING
  
  VARIABLE: BPS    \ 0034 BPS T!   \ 9600 baud
  VARIABLE: PROTO  \ 9300 PROTO T! \ 8 bits, no parity, 1 stops
  VARIABLE: PORT
  \ VARIABLE: CARD
  
  \ 9900 sub-routines. *NOT* Forth words.
  l: LEDON
           R12 RS232/1 LI,    \ select the card
           7 SBO,             \ turn LED on
           RT,
  l: LEDOFF
           R12 RS232/1 LI,    \ select the card
           7 SBZ,             \ turn LED off
           RT,
  
  \ * variables BPS and PROTO MUST BE SET CORRECTLY BEFORE USING OPEN-TTY *
  CODE: OPEN-TTY  ( port -- ) \ Usage: /TTY1 OPEN-TTY
           R12 RPUSH,
           LEDON @@ BL,
           TOS R12 MOV,       \ load 9902 port address
           RESET SBO,         \ reset card
           TOS PORT @@ MOV,   \ set the port variable to use
           PROTO @@ 8 LDCR,   \ set protocol
           LDIR SBZ,          \ disable 9902 timer
           BPS @@ 0C LDCR,    \ set baud rate
           TOS POP,           \ refill TOS
           LEDOFF @@ BL,
           R12 RPOP,          \ restore R12
           NEXT,
           END-CODE
  
  [CC] DECIMAL [TC]
  \ this word turns on the LED when sending
  CODE: CEMIT ( c -- )  \ 'com-emit"
           R12 RPUSH,
           LEDON @@ BL,
           PORT @@ R12 MOV,
           BEGIN,
             27 TB, EQ    \ test -DSR bit =0
           UNTIL,
           16 SBO,        \ set RTS
           BEGIN,
             22 TB, EQ    \ wait XBRE empty
           UNTIL,
           TOS SWPB,      \ put byte on the other side
           TOS 8 LDCR,    \ send 8 bits
           16 SBZ,        \ reset RTS
  \ housekeeping on USER VARIABLES...
           R1      STWP,  \ get current user area address
           30 (R1) INC,   \ inc  OUT
           34 (R1) INC,   \ inc  VCOL
           LEDOFF @@ BL,
           R12 RPOP,
           TOS POP,
           NEXT,
           END-CODE
  
  \ VARIABLE: KBUFF           \ holds the last char rcv'd
  
   [CC] DECIMAL [TC]
  CODE: CKEY? ( -- n )         \  "com-key"
           0 LIMI,
           R12 RPUSH,
           PORT @@ R12 MOV,    \ select >1340 CRU address
           TOS PUSH,
           TOS CLR,
           21 TB,               \ test if char ready
           EQ IF,
               TOS 8 STCR,      \ read the char
               18 SBZ,          \ reset 9902 rcv buffer
               TOS 8 SRL,       \ shift to other byte
    \            TOS KBUFF @@ MOV,
            ENDIF,
            R12 RPOP,
            2 LIMI,
            NEXT,
            END-CODE
  
  [CC] HEX [TC]
  

   

   

 

 

 

[+TheBF]

On 6/24/2019 at 8:05 PM, Lee Stewart said:

BP     LI   R0,BUFFER         You do not need to CLR R0,R1,R2
       LI   R1,CDATA          ...before loading them.
       LI   R2,13
       LIMI 0                 Disable interrupts while we mess with VRAM and sound setup.
       BLWP @VMBW
       LI   R10,BUFFER
       MOV  R10,@>83CC
       SOCB @H01,@>83FD
       MOVB @H01,@>83CE
       LIMI 2                 Enable interrupts so sound table will be processed.
LOOP   MOVB @>83CE,@>83CE     Wait until sound table 
       JNE  LOOP              ...has finished.
       LIMI 0
       MOVB R0,@STATUS
       RT

 

...lee

I am gonna steal this little gem Lee. 

I think much of it could be done in Forth with the addition of an LIMI word.

 

Merci!

[+Lee Stewart]

And—Here is “my” VFILL routine incorporating @TheBF’s suggestion for putting VDPWD (VDP Write Data address) into R3:

 

       REF  VDPWA,VDPWD

*== VDP fill routine. =================================================
*
*     R0: VRAM address
*     R1: character to fill VRAM
*     R2: character count
*     R3: VDPWD (VDP Write Data address)
*
VFILL  CLR  R0             Address to start VRAM fill
       LI   R1,>2000       Fill character in left byte
       LI   R2,960         Fill count
       LI   R3,VDPWD       VDP Write Data address
       ORI  R0,>4000       Set bit for VDP write
       SWPB R0
       MOVB R0,@VDPWA      LS byte first
       SWPB R0
       MOVB R0,@VDPWA      Then MS byte
       NOP                 Kill time
VFLOOP MOVB R1,*R3         Write a byte & auto-increment VRAM address
       DEC  R2
       JNE  VFLOOP         Not done, fill another
       RT
*======================================================================

 

...lee

[GDMike]

yes, ive been seeing this ORI >4000 Statement for quite awhile.  i have to dig deepeer into it's depth to figure what's going on, but its tremendously a faster approach..i have experimented a little, but because i didnt understand it, and ive seen various illustrations with it buried in loops 6 and 8 times deep..i dunno yet because i havent had that need for speed yet i guess. but when i do, i know its an option.  thx for that reminder...

[+Lee Stewart]

7 hours ago, GDMike said:

yes, ive been seeing this ORI >4000 Statement for quite awhile.  i have to dig deepeer into it's depth to figure what's going on, but its tremendously a faster approach..i have experimented a little, but because i didnt understand it, and ive seen various illustrations with it buried in loops 6 and 8 times deep..i dunno yet because i havent had that need for speed yet i guess. but when i do, i know its an option.  thx for that reminder...

 

Because I am not sure whether you do not understand “ORI  Rn,>4000” or why it is used to write to the VDP Write Address Register, I will try to explain both.

 

“ORI  R0,>4000” performs a bitwise OR of >4000 with the contents of R0. That is, it sets the bits in R0 (makes them each 1) that correspond to the 1 bits in ‘>4000’ (binary 0100000000000000). If R0 contains >7FFF (binary 0111111111111111) before “ORI  R0,>4000” executes, it will still contain >7FFF afterwards because all (only one in this case) bits set in >4000 are already set in R0. If R0 contains >2006 (binary 0010000000000110) before “ORI  R0,>4000” executes, it contains >6006 (binary 0110000000000110) afterwards.

 

As to why you would perform “ORI  R0,>4000” to write to the VDP Write Address Register, you use bit 1 (from the left) of the VRAM address to tell the VDP whether you are going to read from or write to that VRAM address. At first blush, this may make no sense since it would appear you are changing the VRAM address when you set bit 1. However, the VDP (TMS9918A in this case) addresses a maximum of 16 KiB, which means that the available address range for the VDP is  0 – >3FFF, which means that bits 0 and 1 do not affect the address value. This makes bits 0 and 1 available as flags that can be passed to the VDP at the same time as setting a VRAM address. The designers of the TMS9918A did just that to tell the VDP whether the passed address is the read address (bit 1 off) or the write address (bit 1 on). Once you have set the VRAM address, you can read from or write to it repeatedly for a VRAM block of data because the VDP read/write registers are auto-incrementing. By the way, bit 0 is used as a flag to signal writing to VDP registers VR00 – VR07

 

To go a step further, the VSBR, VMBR, VSBW, VMBW and VWTR utilities all use the memory-mapped, VDP access addresses (referred to above as “registers”), VDPWA (RAM = >8C02 [VDP Write Address]), VDPRD (RAM = >8800 [VDP Read Data]) and VDPWD (RAM = >8C00 [VDP Write Data]) to do their work. You may not save much time writing your own routines for VMBR, VMBW and VWTR, except for the BLWP/RTWP overhead, or even for VSBR and VSBW when you are truly only interested in a single VRAM byte. However, when you use VSBW to fill blocks of VRAM with the same byte, you waste a significant amount of time setting the VRAM address for each and every byte when you could write your own routine to take advantage of the VRAM-auto-incrementing feature of the VDP.

 

OK....That is probably TMI so I will stop now. ?

 

...lee

[GDMike]

Thanks Lee.  Naa, actually I studied up on that when Matt was explaining it, BUT I didn't know about bits 0,1 or I forgot and I didn't know which Refs SHOULDN'T be rewritten generally. Good to know. And I always need a refresher anyway..memory issues on a personal scale...good stuff

Edited July 10, 2019 by GDMike

[GDMike]

"Forth Essentials" does have a one word command to push it to graphics mode put-up the title splash screen and enable the sound frequencies.

[GDMike]

I've been"trying" to write code for my own flashing cursor which gets the char from the keypress to appear at location 0 then move the position of the cursor to the rt one space all while checking for repeating key press and keeping the cursor flashrate steady.

I'm really really close, my code is kinda not so bad, but it's doing the job. Sorta

Once I get it close I'll show the code, I know if I show it now Lee or someone would say, oh..do it like this and bam my feelings are hurt! Haha...I'm gonna give it my time then I'll let the pros show me where I went wrong..well, better for sure. Someone said read the source of the editor..but the source I only found was in assy, which made me think, if I just had a hint at the logic maybe it's enough and well it seems to be really close to working as it should. My logic I gathered was one step different..as I did this:

Setup graphics mode (for something else later)

Read the char at position 0

Create a delay with checking keyboard inside and leaving the loop if a key was pressed.

Upon keypress save the condition of the keyboard, if a key is down S1=1, 

Save whatever is in $8375 to variable

At this point I put (cursor (old char,del1, 0, del1,old char)) into a begin loop with a break? And my chk routine inside next to it.

Chk basically looks for a duplicate key

By delay then key? Check new key($8375) against old key (GK) if it's the same I put it through a delay before writing to the screen. It does work 

Results: I can type a sentence out and once hmmm in I guess 20 letters I'll get a mistype. I can hit 1,2 fast and They show fast, and my duplicate key press are penalized good with the delay.

BUT.......

It's not right. And the way I know is because I cannot press my hands all over the place and get quick response keys appearing... Im sooo very close with this, but....I know once I show it, it gets destroyed..lol funny

I did this in assy and it wasn't this hard.

Oh, not in forth assembly..sorry..I'm not good for that yet.

Can someone kinda walk the logic steps, remember I'm only using "key?" Turboforth command vs "Key"

 

 

 

 

 

 

Edited October 1, 2019 by GDMike

[GDMike]

After pondering why my key reaction isn't what it should be, I remembered that in the cursor code was 2 delays that Break the loop if a key is pressed, that works for the first instance but the second delay will still process. And I didn't take that into account. Because I've cleared the flag after the first delay break and so after the first loop Break all that happens is we enter the second delay earlier and NOT the complete cursor loop. 

I'll try manipulating that loop tommorow. If it's good, I'll share my code and get a cursor makeover.  Lol

 

[+Lee Stewart]

4 hours ago, GDMike said:

Once I get it close I'll show the code, I know if I show it now Lee or someone would say, oh..do it like this and bam my feelings are hurt! Haha...I'm gonna give it my time then I'll let the pros show me where I went wrong..well, better for sure.

 

Moi?    Seems like a challenge to me.

 

4 hours ago, GDMike said:

Someone said read the source of the editor..but the source I only found was in assy, ...

 

Look at TI Forth system disk blocks 34 – 38 (40-column editor) and blocks 22 – 29 (64-column editor). Key entry is done differently in the two editors. They are written in Forth. You can also check FBLOCKS blocks 6 – 13 for the 64-column editor.

 

For the fbForth 2.0 40/80-column editor, I basically converted the Forth code of RKEY from the 64-column editor to ALC.

 

...lee

[+TheBF]

Take a look here for some ideas as well. 

You could re-write the TMR@ word to decrement a variable and return the value each time you call it.

When it hits zero, it resets itself back to some number of your choosing. 

 

The key to good Forth is take your program apart and make simple little words for each part.   

Then use those words to make the program.

 

 

 

[GDMike]

I found that I could use a flag within the delay loop, (there are 2 back to back that chj for key press), if this flag is 1 then I could look at a variable that tells me where I am in a "word" compilation. Making defined words while the cursor is idling blinking... BUT I don't know how to get around floppy access which would kill my cursor loop....it's a thought in not actually doing it.

[GDMike]

I haven't looked at other sources yet as

Lee mentioned, I've still gotta find the location..but as promised here's my bees nest. Not too much code, and I'm sure there is some redundancy, but someone once said, make it work, then Clean up later...I'm not versed enough to do both at the same time..

 

[GDMike]

Ok the code is there, now I'm stumped for a bit. And I haven't found that editor source code yet either. But have at it if anyone wants to challenge my good looking code.lol Lee, tear it up if you have to cause I always learn something from you.  Well call this the "cursor engine makeover" challenge Haha

[+TheBF]

Who Knew?

 

I had no idea how tricky it would be to write a repeating key routine in Forth.

Because Forth is structured you just can't jump out in the middle of code normally.  I spent a couple of days playing with all kinds of different code ideas.

None of them made me happy. Finally I took a look a TI-99 tech pages to see how they did it in Assembler.

It seemed a bit simpler (at a glance) that the FbForth version Lee sent me.

 

I literally re-wrote the assembler code in Forth. It's not very Forthy. It uses variables to keep track of the delay time (state), counter and key buffers.

I can go over it and clean it up later.  But it works!

 

I still had the problem of how to jump out as you would in Assembler.

That was solved with the word EXIT and by separating the repeater code from the main KEY loop.

I think I am getting stupid in my old age and I am very thankful to have had some other code to study.

 

Edit: Got rid of 2 gratuitous variables by using DO/LOOP

 

Spoiler

\ RKEY, A repeating KEY word
\ algorithm from
\ http://www.unige.ch/medecine/nouspikel/ti99/keyboard.htm#auto-repeat

\ NEEDS DUMP FROM DSK1.TOOLS

DECIMAL
 70 CONSTANT LONG      \ Ticks before auto-repeat kicks in
  2 CONSTANT SHORT     \ Delay between repeats

\ Not very Forthy using all these variables
VARIABLE DLY           \ Current delay & "state" variable
VARIABLE NEWKEY        \ key buffer
VARIABLE OLDKEY        \ previous key buffer

HEX
: RKEY?  ( -- c) 83C8 ON  KEY? ;  \ repeating KSCAN

\ decrement a variable to 0, return true when expired
: EXP?  ( counter -- ?)  DUP @ IF  DUP 1-! THEN @ 0= ;

: (RKEY) ( -- )
    DLY @ LONG =        \ Are we repeating?
    IF   LONG DLY !     \ No, use long delay
    THEN
    DLY @ 0
    DO
        RKEY? DUP NEWKEY !
        OLDKEY @  <>    \ different than before?
        IF
          NEWKEY @  OLDKEY !  \ Memorize current key (will be >00 if no key)
          LONG DLY !    \ reload initial delay
          UNLOOP  EXIT  \ jump out of the routine (to the semi-colon )
        THEN
    LOOP
    SHORT DLY !         \ Done with waiting: load repeat delay
;

: RKEY   ( -- char)
         VPOS VC@ >R     \ store char under cursor
         BEGIN
           TMR@ 1FFF >   \ read 9901 timer. compare to >2000
           IF CURS @     \ true? fetch cursor char
           ELSE R@       \ false? fetch screen char
           THEN VPUT     \ multi-tasking friendly screen write
          (RKEY)
           NEWKEY @      \ get the newkey value
          ?DUP
         UNTIL
         R> VPUT ;       \ put the char back

\ =====[ END OF CODE ]=====

: TEST  ( -- )  BEGIN RKEY EMIT  ?TERMINAL UNTIL ;

 

 

Edited October 4, 2019 by TheBF

[GDMike]

Yes, my thoughts were if I could do most of it with the forth assembler that it'd probably be better, but unfortunately I'm not up to speed in that assembler. 

[+TheBF]

3 hours ago, GDMike said:

Yes, my thoughts were if I could do most of it with the forth assembler that it'd probably be better, but unfortunately I'm not up to speed in that assembler. 

Assembler would save you some space and being free to jump anywhere can be simpler to understand sometimes.

Traditional Forth Assemblers typically have the same limitation in that they use structured loops and IF/ELSE/ENDIF so you would still be fighting a bit OR you could modify the assembler which is fair ball in Forth. 

 

But this application doesn't need the speed since it spends most of its time spinning waiting for the human to push a button.

(In multi-tasking Forth you use that free loop time to do other things)

 

If yours works the way you want it to then you have it.

 

[GDMike]

It's getting close, I'd say I'm 90 perc. There, but I threw the real hard ware code onto classic 99 and it did not go well. I'll be back on real hw. Today I'm having dizzy spells, I really need to pull a fuel tank from an old car I'm working on, but didn't get far. I suppose I'll not get to this fun project either for a bit. I had an idea I wanted to implement at my repeat delay since that's my last area of concern but yes I'm pleased at how it's handling and my delay loop actually has room for a flag to allow other processes to occur depending on the time it's been idling cursing (blinking with no keypress).

 

 

[GDMike]

I love Classic 99, I run mine on a VMware, win7. It just works flawlessly for me. One day, if I ever get$$ I'd love to give sumpin.. but, I still have no job at the moment.. sorry Tursi.

[Tursi]

1 hour ago, GDMike said:

I love Classic 99, I run mine on a VMware, win7. It just works flawlessly for me. One day, if I ever get$$ I'd love to give sumpin.. but, I still have no job at the moment.. sorry Tursi.

It's fine. All I ask of people is that they vote daily on my 'next task' spreadsheet. Doesn't cost a dime.  http://harmlesslion.com/cgi-bin/walrusquery.cgi