TheBF
-
Posts
4,470 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by TheBF
-
-
This helps...
10 REM 20 CALL CLEAR 25 CALL SCREEN(2) 50 CALL MAGNIFY(2) 100 CALL SPRITE(#1,68,1,40,97,0,0) 120 CALL SPRITE(#2,73,1,40,113,0,0) 130 CALL SPRITE(#3,86,1,40,129,0,0) 140 CALL SPRITE(#4,69,1,40,145,0,0) 200 CALL SPRITE(#5,66,1,64,81,0,0,4,0) 201 GOSUB 9000 210 CALL SPRITE(#6,79,1,64,97,0,0,4,0) 211 GOSUB 9000 220 CALL SPRITE(#7,77,1,64,113,0,0,4,0) 221 GOSUB 9000 230 CALL SPRITE(#8,66,1,64,129,0,0,4,0) 231 GOSUB 9000 240 CALL SPRITE(#9,69,5,64,145,0,0,4,0) 241 GOSUB 9000 250 CALL SPRITE(#10,82,5,64,161,0,0,4,0) 1000 CALL COLOR(#1,5,#2,5,#3,5,#4,5) 1010 CALL COLOR(#5,5,#6,5,#7,5,#8,5) 1020 CALL COLOR(#9,5,#10,5) 1100 FOR I=1 TO 5000 :: NEXT I 1300 END 9000 FOR I=1 TO 100 9010 NEXT I 9020 RETURN
-
You can only display 4 sprites in a row horizontally.
It is a hardware limitation of the 9918 VDP chip.
-
1
-
-
10 minutes ago, mizapf said:
006A clears the GPL status (see TI Intern). You should also make sure that the GROM address counter did not change (no accesses to GROM while running the machine language program).
This works as well without clearing >837C first.
Thanks everyone.
-
2
-
-
11 minutes ago, HOME AUTOMATION said:
(maybe)...
E/A manual, 24.11.3 p.442Other returns
Clear the GPL STATUS byte,
load GPL Workspace Registers,
branch to @>0070.P.S. In another example(speech) they show >006A as the return addr(p.361).
P.P.S. I used to be more familiar with these.
Thanks!. I saw that but had no idea if I was supposed to go back to the GPL interpreter.
I will give it a try.
\ SIMPLE super cart binary program HEX CROSS-ASSEMBLING START. NEW. ABSOLUTE 6000 ORIGIN. \ super cart RAM >6000 TI-99.EA5 \ builds the file header in RAM \ =============================================== PROGRAM: GPLRTN 8300 LWPI, \ set workspace pointer located at >8300, fast ram \ wasting time loop R1 FFFF LI, BEGIN, E002 @@ INCT, E004 @@ DEC, R1 DEC, EQ UNTIL, \ * return to GPL with ROM routine R0 CLR, R0 837C @@ MOVB, 83E0 LWPI, 0070 @@ B, END. \ ============================================== \ save the binary image file FILENAME$ $SAVE-EA5. BYEAnd hey it works.
This code is pretty weird cuz it's written for my Forth cross-assembler but you get the idea.
-
3
-
-
New Undocumented feature in CAMEL99 Forth V2.59B
With the addition of the WARM command we can re-boot Forth back to a previous dictionary content point.
If you INCLUDE DSK1.MARKER as your first addition to the system you get the ANS Forth word MARKER
https://forth-standard.org/standard/core/MARKER
AND you get a Camel99 word called LOCK
After including DSK1.MARKER you can INCLUDE some utilities for example:
INCLUDE DSK1.TOOLS
INCLUDE DSK1.DIR
Then invoke the LOCK command.
LOCK records the dictionary pointers for the existing dictionary.
Now you can load a project, test it etc. as normal.
When you want to return to the bare system but keep the tools and dir utility in memory just invoke WARM and the system reverts to what it was when you used the LOCK command.
-
1
-
-
I think this question has been answered somewhere in Atariage but I can't find the right search terms to find it
Is it possible to run a program with E/A 5 and return to the E/A cartridge menu? (versus exiting to the main screen)
-
Here is a three disk package of the current version of Camel99 Forth. It includes a rebuild on my new computer (DSK1.CAML259B) along with the original DSK1.CAMEL99
It includes the SAMS editor ED99SAMS. I have not implemented repeating keys in this version because I am still seeing an occasional random key injected into the files.
That is way more problem than not repeating.
To that end I have included EDIT40 and EDIT80 on disk two, the editor disk, as well.
There is also a release notes document and brief instructions on how to play with the ED99 SAMS editor.
Should anybody be brave enough to play with this please send me all the bugs.
Happy Friday
-
5
-
-
In the topic below there is a discussion of Pascal using strings in a CASE statement.
This got me wondering what would it take to add this to Camel99 Forth.
Not bad for a "low level" language.
\ string case statement NEEDS DIM FROM DSK1.STRINGS NEEDS CASE FROM DSK1.CASE : $OF ( -- ) POSTPONE OVER POSTPONE =$ POSTPONE IF POSTPONE DROP ; IMMEDIATE : TEST ( $ -- ) CASE " APPLE" $OF CR ." Granny Smith" ENDOF " PEAR" $OF CR ." Barlett" ENDOF " GRAPE" $OF CR ." Concord" ENDOF CR ." Unknown fruit" ENDCASE ;
-
3
-
-
Sometimes you have know when it is time to surrender.
I spent way to much time trying to get the Nouspikel repeating key algorithm to work reliably. Even re-writing it in assembler, following the code on the web, gave the same result.
I finally relented and took the code from old TI-Forth.
Interesting to note the Forth Assembler version of Nouspikel used 242 bytes, partly because it uses a separate workspace.
The updated TI-Forth version uses 232 bytes!. Forth for the win.
I was able to make it a little simpler by factoring out the blinking cursor and using some special functions I use in the kernel
(1+@, increment variable and fetch value; OFF set variable to zero).
I changed some of the variable names to make more sense to me and voila! It works perfectly.
Note:
Sometime this week I will be releasing a 3 disk set that is a functional system with the SAMS multi-file editor and also copies of TI's EDIT V3.0 for 40 column and 80 columns.
DSK3 will have a number of demo programs to give examples of how to use the library files.
\ TI-forth repeating key modified for CAMEL99 DECIMAL 40 CONSTANT LD 5 CONSTANT SD VARIABLE OKEY VARIABLE KC VARIABLE DLY LD DLY ! HEX : BLINK ( char --) TMR@ 1FFF > IF DROP CURS @ THEN VPUT ; HEX : RKEY ( -- char|0) VPOS VC@ >R BEGIN R@ BLINK 83C8 ON ( force repeating KSCAN) KEY? ?DUP IF ( key is pressed ) KC 1+@ IF ( waiting to repeat ) DLY @ KC @ < IF ( long enough ) SD DLY ! 1 DUP KC ! ( force exit) ELSE OKEY @ OVER = IF ( need to wait more ) DROP FALSE ELSE ( force exit ) 1 DUP KC ! THEN THEN ELSE ( new key ) TRUE ( force loop exit ) THEN ELSE ( no key pressed) LD DLY ! KC OFF FALSE THEN UNTIL DUP OKEY ! R> VPUT ;-
2
-
-
12 hours ago, Tursi said:
um... no. SAMS is different hardware.
Understood. i was told in another topic that I can't page SAMS memory into cartridge space, but it works on Classic99.
I thought perhaps super-cart might have something to do with it... but no.
-
On 4/10/2020 at 1:48 AM, Tursi said:
8k super cart memory is available automatically when you load Editor/Assembler. More isn't supported. MAME has it.
Is this why I can use >6000 to page in SAMS memory with the E/A cartridge?
-
I have much more respect for the use of tidy little blocks in traditional Forth systems.
I got my 500 line editor onto the real iron. It takes about 4 seconds to save the 468 lines of source code for the SAMS editor on Classic99. Save the same file to a floppy disk on the TI-99 and it takes about 40 seconds.
Oh well. I am just a couple of little bugs away from having a functional multi-file editor that can live on real iron.
I have not timed the compile time but typically it is 2X slower than on Classic99 so that should be about 2 minutes.
-
1
-
-
I think my agony is over. I decided to do a complete re-write. I used an concept which I wrote for serial port sending to the real TI99 as a starting point. TIMEKEY waits for a period of time for a key. If a key is pressed it exits immediately. If not key is pressed it times out and returns zero. I got no errors when I used TIMEKEY with a single delay value. It made me wonder if it would work if I controlled the delay value with different states.
I had a feeling that something was not right using the trick of setting >83C8 to >FF to force KSCAN to repeat all the time, since the Assembler version showed the same problem. So here, I only switch that on when a "new" repeating key is detected otherwise it is not enabled.
In the test condition where I could make the random characters repeatably this version seems flawless.
Now I can get back debugging/designing the editor functions instead of this !@#$% problem.
\ New repeating key Apr 9 2020 B Fox HEX VARIABLE T 0100 T ! VARIABLE OLDKEY : KEEP ( c -- c) DUP OLDKEY ! ; : NEW? ( c -- c ? ) DUP OLDKEY @ <> ; : DELAY ( n -- ) T ! ; : TIMEDKEY ( wait-time -- 0 | c ) BEGIN 1- DUP \ decrement wait-time WHILE \ while wait-time<>0 KEY? ?DUP \ read key, dup if <> 0 IF \ if key was pressed NEW? \ test if new key IF KEEP \ it's new key remember it 100 DELAY \ set long delay time THEN NIP \ NIP wait-time EXIT \ exit & return the key ELSE \ no key was pressed 100 DELAY \ reset the delay THEN REPEAT NEW? \ timed-out, is it a new key? IF 83C8 ON \ yes, enable repeating THEN 5 DELAY \ then set the fast delay ; : BLINK ( char -- ) TMR@ 1FFF > \ wait for 9901 to 1/2 expire IF DROP CURS @ \ replace char with cursor THEN VPUT ; \ then write to screen : RKEY VPOS VC@ >R BEGIN PAUSE R@ BLINK T @ TIMEDKEY ?DUP UNTIL R> VPUT ; -
Einstein once said that insanity is doing the same thing over and over and expecting a different result.
I have been working getting the various features of this editor working they way I want but I was still getting these random characters inserted into the text when I used a repeating key routine. It never happen with a non-repeating key routine. I had first translated the code here: Repeating key into Forth almost literally. I tried a great number of things that I thought might cure it but no luck.
So in desperation I re-wrote it Forth Assembler, where everything happens in a separate workspace.
My original Forth translation must be pretty good because it does exactly the same thing! ?
Looks like I need to re-think my control key handler. (?) I will try things on real iron as well.
At least I now have some key-strokes to make the problem happen on demand.
\ http://www.unige.ch/medecine/nouspikel/ti99/keyboard.htm#quick%20scan \ *-------------------------------------------- \ * Keyboard scanning with auto-repeat. \ * Put even values in R0 and R1 either at assembly or at run time. \ * Put an odd value in R0 to disable auto-repeat. \ *-------------------------------------------- NEEDS MOV, FROM DSK1.ASM9900 NEEDS .S FROM DSK1.TOOLS NEEDS MARKER FROM DSK1.MARKER MARKER COLD HERE HEX CREATE WREGS1 0080 , \ R0: Time before auto-repeat kicks in 0020 , \ R1: Delay between repeats 0080 , \ R2: Current delay FF00 , \ R3: old Key buffer 0500 , \ R4: Keyboard argument 0000 , \ R5: scratch 0000 , \ R6: time counter 0000 , \ R7: scratch 0000 , 0000 , 0000 , 0000 , 0000 , 0000 , 0000 , 0000 , 0000 , HEX CREATE (RKEY) R2 R1 CMP, \ Are we repeating? NE IF, \ IF NOT R4 8374 @@ MOVB, \ Set keyboard argument R0 R2 MOV, \ use long delay ENDIF, R2 R6 MOV, \ Reload counter register BEGIN, 83C8 @@ SETO, \ Erase previous key's scan code 83C8 @@ 83CA @@ MOVB, \ Ditto for keyboard 5 83E0 LWPI, 000E @@ BL, \ Call scanning routine WREGS1 LWPI, 8375 @@ R11 MOVB, \ Get key's ascii code R11 R3 CMPB, \ Same as before? NE IF, \ No 8375 @@ R3 MOVB, \ Memorize current key (will be >FF if no key) R0 R2 MOV, \ Load initial delay R3 8 R13 () MOVB, \ Pass key to Forth's TOP of stack register RTWP, \ return to Forth ENDIF, R6 DECT, \ Yes: wait. Never zero if odd delay EQ UNTIL, \ Keep scanning (as key could change) \ Done with waiting R1 R2 MOV, \ load repeat delay R3 8 R13 () MOVB, \ Pass key to Forth's TOP of stack register RTWP, \ return to Forth \ vector to call MYSCAN with BLWP CREATE MYSCAN WREGS1 , (RKEY) , CODE RKEY? ( -- c|0) TOS PUSH, TOS CLR, MYSCAN @@ BLWP, TOS SWPB, TOS 00FF CI, EQ IF, TOS CLR, ENDIF, NEXT, ENDCODE -
Does Fortran default to floating point or integers?
-
: SC_S \ print index value of 100 times through loop PAGE \ clear screen 100 0 DO I . \ print loop index LOOP ;Same here.
I would think that this Fortran compiler is pretty naive, meaning it doesn't have a lot of room for optimizing options and simply converts the source code one way.
The TI99 doesn't give it much room to flex those kind of muscles.
It's remarkable that it does as much as it does.
It would be fun to see the table of emitted routines.
-
1
-
-
9 minutes ago, HOME AUTOMATION said:
Some late models had a B+ chassis. Ouch! While newer models may have an insulated chassis.
I'm not a fan of this discharge to GND idea! In fact, I like the screwdriver idea better, though also problematic. Some capacitors might not be connected directly to GND. This could result in excessive I and V to other sensitive components. This could also result in reverse voltages across other components, possibly charging other capacitors as well... not magic! Finally, this may not discharge some capacitors.The picture tube itself is often well insulated and can hold a formidable charge for long periods of time. Zap!
Always! Think First!
Thinking is the best practice for sure.
When we worked on studio monitors we always grounded the CRT anode for the very reason you stated.
If you want faster discharge you can adjust the resistor value down to control the amount "snap"
you want to cause.
On the broadcast transmitters I worked on inside every rack was a "shorting hook" which was tied directly to ground.
It was a 2 foot plastic rod with a brass hook on the end that you would hang on a high voltage point and leave it there while you worked.
This was on top of the shorting points installed on all the rack doors that shorted B+ when you opened the door.
Now sometimes in the wee hours of the morning you might forget to remove the hook, close the cabinet and hit the power.
That was called a power supply overload detector and circuit breaker test.
-
1
-
-
Best way is to use an insulated handle with an electrode that is connected to a ground wire that has a 100K resistor (1W would be best) in series with the path to ground.
Better than a screw driver would be a short piece of small plastic pipe with an electrode on the end. This would be better for playing with CRT circuits. Use a strong method to connect the lead to ground ie: a strong alligator clip or even screw it to the chassis if it makes you more confident.
After turning the unit off and removing AC cord, go around the circuit and touch the lethal sections with the special grounded tool.
Hold it on each HV point for a couple of seconds. Be aware that capacitors will self re-charge a little. This not a problem for 100V cap, but a 15,000V cap can still be dangerous when it self re-charges back to 1000V!! We used to call this "air charging" but the real mechanism is some magic physics I would think.
You will also understand why we always worked on HV gear with one hand in our pocket. No need to defib needlessly.
It definitely focuses the attention. When I was young I opened an old oscilloscope and reached over the chassis and contacted a 1.5Kv oil cap into my forearm.
I couldn't go near that thing for days.
-
2
-
-
50 minutes ago, Tursi said:
Actually, since that came up twice today, I think I'm just going to close all support for a while. The answer for the next couple of months is "use MAME". It's not fair that I invest hundreds of hours debugging problems for everyone - half the time they turn out to be issues in the original software and not the emulator. Send your questions to Mizapf for a while.
Tursi I think Classic99 is amazing. You have given this old guy endless hours of pure enjoyment.
Thank you
-
5
-
1
-
-
Do they work or are they just plastic blocks with terminals?
-
Here is a new scam that uses the "Forgot your password" feature of online banking.
Never talk to anybody who called you from your bank or financial service company.
Hang up and call your bank back at the number you normally use if you feel the need or ignore it.
https://robservatory.com/how-i-lost-control-of-our-bank-accounts-to-a-phone-scammer/
Evil bastards.
-
4 minutes ago, Lee Stewart said:
Oops! I screwed up the code. As noted in the corrections in my post above, I was in full Assembler mode at the time!
...lee
I got it to work ok. No worries.
You gave the disclaimer. "Not tested"
-
It's also starting to look like there is little point in testing for BANK# in memory.
Using my version and this 32Kword load routine, It 13.98 seconds with no comparison and 13.41 seconds with the bank# comparison.
: LOADSAMS FFFF 0 DO I I PAGED ! 2 +LOOP ;
So the inner interpreter swamps the differences. Probably better to go with less space and simplify.
-
I made your version as >PAGED to have a different name.
I measured them with the 9901 timer like this: (it tests the literal parameter passed to the routine of course but that's reality)
: TEST1 ( -- n) TMR@ D000 PAGED TMR@ NIP - ; : TEST2 ( -- n) TMR@ D000 >PAGED TMR@ NIP - ;
These both returned the value 13 the 1st time and 11 the 2nd time after the page is already in memory.
That converts to 276.9 uS and 234.3 uS
On modern processors this would probably be a win for your version but the 9900 sucks up a lot of cycles for even simple instructions.
It was worth a try.
Always! Think First!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
1 Meg Super AMS Discussion Thread
in TI-99/4A Computers
Posted
Very nice. I organized SAMS this way as well. I settled on putting the page at >3000 but it can be moved by changing one constant.
I have data working very well. The "speed" of the old 9900 starts to show when you start loading and erasing hundreds of Kbytes.
I am toying with the best way to compile Forth code into SAMS.
If you PLOAD programs in RXB2020 can you edit them just the same as normal?