+TheBF Posted June 25, 2019 Share Posted June 25, 2019 Just imagine how much faster you could find that in Forth. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 25, 2019 Share Posted June 25, 2019 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: You are moving 12 bytes to VRAM when there are 13 to move. 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. 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 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 25, 2019 Author Share Posted June 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 25, 2019 Share Posted June 25, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 26, 2019 Share Posted June 26, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 26, 2019 Share Posted June 26, 2019 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] 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 26, 2019 Share Posted June 26, 2019 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! 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 26, 2019 Share Posted June 26, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 26, 2019 Author Share Posted June 26, 2019 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... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 26, 2019 Share Posted June 26, 2019 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 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 10, 2019 Author Share Posted July 10, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 31, 2019 Author Share Posted July 31, 2019 "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. VID_20190731_153351517.mp4 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 1, 2019 Author Share Posted October 1, 2019 (edited) 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" VID_20190930_191910582.mp4 Edited October 1, 2019 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 1, 2019 Author Share Posted October 1, 2019 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 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 1, 2019 Share Posted October 1, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 1, 2019 Share Posted October 1, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 1, 2019 Author Share Posted October 1, 2019 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. Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 1, 2019 Author Share Posted October 1, 2019 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.. 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 2, 2019 Author Share Posted October 2, 2019 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 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 4, 2019 Share Posted October 4, 2019 (edited) 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 ; REPEATKEY.mp4 Edited October 4, 2019 by TheBF 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 4, 2019 Author Share Posted October 4, 2019 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. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 4, 2019 Share Posted October 4, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 4, 2019 Author Share Posted October 4, 2019 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). 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 6, 2019 Author Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 6, 2019 Share Posted October 6, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.