TheBF
-
Posts
4,470 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by TheBF
-
-
Mine went in a while back. I am getting very tired of compiling from floppy disk.
-
Yes that is what I would need to do to make a Forth inner interpreter. I would only be the first 5 lines in my case.
From what I understand the way it is done in byte code Forth is to have a table of primitives written in Assembler or C.
The size of that table can be anything from a minimum of 35 or so Forth primitives all the way up to 256 if you wanted more speed.
Then another table is created for "secondary" definitions that are written in Forth calling the primitives in the 1st table.
Open-Firmware has something called the Active-Package which from what I can see is a selector for the secondary table.
So each Active-package would be limited to 256 routines. More than enough for a pretty complex program.
-
4 hours ago, apersson850 said:
I was referring to Forth on the TI. I've not seen any byte-coded Forth there. Does it exist in some version?
Got it.
You are correct. There is not one... yet.
It's on my todo list of variants to create with the cross-compiler.
I think I can make good use of the indexed addressing mode to look up the primitives.
-
"This is similar to Forth’s approach, where programs consist of a long line of addresses. But they are words, so each instruction there requires twice as much memory as for the p-code."
For full disclosure Forth doesn't actually specify how you should do this. It is commonly addresses but their are byte-coded Forths too.
The most famous byte-code Forth is Open-firmware which booted Sun Workstations, Apple Power PC machines and I think one of the Linux distros.
<We now return to our regularly scheduled program>
-
1
-
-
On 4/25/2020 at 4:17 PM, TheBF said:
Has anyone ever used this chip in a Supercart?
I has an 8 byte clock and calendar built in. I used it in an industrial product in the 90s.
I can confirm that this line of 8K battery RAMs is a drop-in chip for the Super Cart board from Arcade Shopper.
I didn't install the battery holder since the chip has a built in battery. Of course I didn't install the switches either and the open positions work with the MK48T18,
I might change R2 to reduce the brightness of the LED should I choose to install a LED.
But it is so neat to have an extra 8K RAM in the old machine.
Thank you Arcade Shopper.
-
3
-
-
26 minutes ago, GDMike said:
Ahh. Yes, well there are characters NOT on the keyboard that a user might need to place, one such character is, I found, the cent mark opposed to the dollar mark, another would be the celcius and farenheit, IF I defined those, or how about cell characters, left,top,sides etc, to make a cell or divider.
I'm sure there are other characters as I haven't reviewed what should be included. So this allows the user to call up a character, a help key could be presented to show the current ASCII chart of what is defined.
OR I could just allow the user to create their own char and have it placedvon the screen.
I think this is just fine for now. Plus I've gotta move on to file access... but I needed to get this outta my way.
Ahh. That's cool. It's like the SYMBOL table in Microsoft word but you select with a text command. Nice idea.
-
1
-
-
I am happy that the code does what you want but I am not clear on what the feature is for.
On the surface it looks like you are writing an ascii value to the screen which displays the appropriate letter.
How does the Super Notes user use this?
Maybe this is just a test bed for future work. (?)
-
1
-
-
I know that editors are like underwear and quite personal but I started playing around with ATOM again after a long time away. I found a package that supports ANS Forth and it is quite nice to use.
It even is smart enough to memorize the names of variables, constants and word definitions in the file and serve up auto-completion suggestions.
It also supports GitHub so you can keep your repositories current, something I will be doing over the next week. (I hope)
Something to consider for development with Classic99 and Forth. (Looks like it is for 64 bit Windows only)
Interestingly it is not as cool in some ways as FPC (DOS) and Win32Forth from the 1990s in which the editor hyper indexed all the code so you could explore right down to the real code "atoms". By double clicking on any word in the file(comments excluded) you would see the definition of that word in source code. Click on any word in that definition and another file would open and so on.
Tom Zimmer the author of both of those systems was brilliant
-
1
-
-
Too many shortcuts
Awhile back I was struggling with making a reliable repeating KEY. I used a known algorithm and even re-wrote it in Assembler to no avail. I essentially gave up on it and moved on.
While perusing the Playground documentation I came across this piece of code.
LWPI >83E0 MOV R11,@>836E store the return address BL @>000E (keyscan uses both intws and gplws) MOV @>836E,R11 restore the return address LWPI WKSP
I remembered reading about saving GPL workspace R11 and restoring it when using the KSCAN code but in my efforts to find superfluous bytes in the kernel I removed this and didn't see any difference.
In my efforts to make the repeating KEY routine reliable, I had made every effort to protect the KEY? routine (KSCAN) code with Interrupts disabled and correctly reading the GPL status byte. It all worked great... except when I used it in a repeating key routine.
So I thought what the h*ll. Let's see if it makes a different. It does. The new code is below in XFC99 cross-compiler Assembler.
Since the system runs in RAM I just use a memory location before the code to save GPL's R11. I also discovered that it only is 100% reliable if I don't re-enable interrupts in this routine but rely on my VDP routines to do that job later. So there is more to this than I understand. Not ideal, but I will take it for now.
l: GPLR11 0 DATA, CODE: KEY? ( -- ?) \ *WARNING* it takes 1,128uS for KEY? scan to run TOS PUSH, TOS CLR, \ TOS will be our true/false flag 0 LIMI, TOS 837C @@ MOVB, \ clear GPL flags 83E0 LWPI, \ switch to GPL workspace R11 GPLR11 @@ MOV, 000E @@ BL, \ call ROM keyboard scanning routine GPLR11 @@ R11 MOV, WRKSP0 LWPI, \ return to Forth's workspace 837C @@ R1 MOVB, \ read GPL status byte (=2000 if key pressed) R1 3 SLA, \ check the key bit OC IF, \ if carry flag set 8374 @@ TOS MOV, \ read the key ENDIF, NEXT, \ return END-CODEWith this working reliably I loaded up a version of ED99, my VDP editor and it looks like I might have an editor that I can use on real iron. Testing on the TI-99 to follow.
What an ordeal this has been because I saved 8 bytes. :)
-
6 hours ago, FarmerPotato said:
It is fascinating. My only idea was that a list of tokens referred to dictionary addresses in VDP. Like your idea.
I look forward to your working out how to use the tiny memory
Surely there has been a teeny tiny FORTH in all its history?
Just kidding, you are under no obligation to solve such an interesting exercise!
If it walks like a gauntlet and it talks like a gauntlet
I must confess that I was thinking about it. My cross-assembler post might show how it could be created by a program running on TI-99.
Now look what you did. I am thinking about it again.
-
On 6/10/2020 at 4:58 PM, FarmerPotato said:
The Sandbox is mind-blowing. Imagine if people had known how to exploit this back in the day - commerical "BASIC" cassette programs that get around the bottlenecks in TI BASIC!
99'er magazine reviewers would be stumped at how a program got that performance!
Imagine a FORTH environment that targets the Sandbox loader. FORTH might be a good way to leverage the tiny page size! A word would have to be limited in its compiled size to very tiny. The stacks would be similarly limited. Perhaps static analysis could determine in advance what the required depths would be. (or at least run-time tests.) In the end, a FORTH program that executes from a bare console in BASIC, with mind boggling performance nearly as fast as assembly, certainly faster than GPL or BASIC!
This would be pretty a good trick.
Typically you would need 16 levels for each stack so there goes 64 bytes!
You could limit that in the way you write programs. Might be able to use registers as a short data stack. (?)
It begs the question of what threading mechanism you would use. The smallest code to run is native code because the CPU does all the interpretation. So you could just pass addresses from VDP of code snippets that load to scratchpad, run and reload the VDP reader.
You might be able to use byte code that feeds native code snippets to the scratchpad for each byte code and then reloads the byte code interpreter... my head starts swimming.
-
3
-
-
your example is dividing HEX 42 ( DECIMAL 66) by HEX 0A ( DECIMAL 10)
So that gives the result 6 with 6 as the remainder.
I am not sure what you want to do exactly. Convert a binary number into ascii digits?
-
1
-
-
For what it's worth...
This is the kind of thing where a Forth style assembler and Classic99 can be really handy to explore how instructions work without compiling the entire program and writing special test code to display results or memory locations. Then you can take what you've learned and confidently code it into your application.
With the MARKER directive you can purge your little routine from the system without removing all the tools (Assembler etc..) and just re-assemble the little routine over and over until it works!
I am using my Forth here but all the others can do the same thing. Not bad for 1970's technology.
Spoiler\ You can play with Assembler in tiny pieces in Forth to learn \ then convert back to TI assembler for the actual program \ Paste this into Classic99 with Camel Forth running \ Mitzaph's example \ LI R3,0 \ LI R4,101 \ LI R2,4 \ DIV R2,R3 \ conditionally pull in the Assembler and some tools NEEDS MOV, FROM DSK1.ASM9900 \ load the assembler NEEDS MARKER FROM DSK1.MARKER NEEDS .S FROM DSK1.TOOLS \ translate to Camel Forth for interactive testing MARKER REMOVE \ REMOVE forgets our code but keeps the assembler & tools DECIMAL CODE DIVTEST ( -- n tos ) \ tos is R4 in Camel99 Forth TOS PUSH, \ SAVE R4 (called TOS). gives us free use of R4 \ Mitzaph's example in Forth Assembler R3 0 LI, R4 101 LI, R2 4 LI, R2 R3 DIV, \ R4, the TOS register should be 1 R3 PUSH, \ Push R3 onto Forth stack so we can see it easily NEXT, \ return to Forth ENDCODE-
1
-
-
Old floppy drive head cables never die. They just get tangled on stuff.
My 35 year old floppy drive works again.
Took a while to figure out why the head assembly slid perfectly except in the middle of the travel.
The head cables hidden at the back of the drive had slowly moved to a place where they were rubbing on a projection in the chassis and at the middle of travel the rubber insulation snagged on it.
A bit of "forming" and it's back in business. (clean it a little anyway)
My day has improved greatly.
-
1
-
-
I didn't realize you did the search order switch with DATA[ .
That's pretty fancy.
Here is the only reference I know of to a PolyForth Manual.
http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf
I did a little homework on the concept before but never wrote any code. From what I can gather a hash value is calculated from the contents of the name and a 3 bit code is embedded in the header that determines which search list the word is attached to. This way the longest search is word-count/8. So a significant speed up. In the original PolyForth they also only recorded the first 3 characters of the name and hashed the remaining characters for even faster lookups.
Camel Forth is rather liberal in the header giving up an entire byte for the precedence bit so I have lots of space to hide the extra bits. I suppose that you could use 2 bits for a 4 way hash and still get a good improvement if header space is an issue.
B
-
2
-
-
2 minutes ago, GDMike said:
I just traded an ea cart for my spare half ht fd. And I'm using a gotek for fdsk1.
My only half ht FD I have left is my drive 2. And I'm temporarily using a borrowed ramdisk. I can't wait now for my tipi.
I think tipi will be the best thing for file management!
How do you do EA cart stuff without the cart. I have not looked at any of the options.
-
1
-
-
The bad news: My 2nd old 1/2 height floppy drive is not seeking reliably. I hope that a thorough cleaning will improve it.
The good news: I have successfully compiled code into different pages of SAMS memory. It's just a beginning but it works.
This implementation creates something like "vocabularies" for each 4K PAGE. It's not ideal in that it is not a big contiguous code space. It's not a particularly elegant solution either but it was for exploration.
It's good because the compiler and the code runs at full speed after the mapping operation. The CMAP operation is Forth but it's still pretty fast. I can improve that later.
So here is Concept 1 to compile code into Sams from Camel Forth. Happy to answer any questions but this is just a means to an end.
In Concept 2, I will have to organize a group of pages into a linked list that can searched sequentially. This would allow a simulated 64K code segment to be used with the caveat that you won't be able to compile code across 4K pages, but the compiler will be able to search the entire list.
This then begs the question of lookup time which might require a re-write of the kernel to use 8-way hashing of the dictionary as was done in poly-Forth. Even a linear Assembler search will bog down with a 2000 word dictionary.
Spoiler\ SAMS Memory Forth compiler CONCEPT 1: Jun 8 2020 B Fox \ Compile to a discrete, named 4K page and link back to Kernel dictionary \ Each code page holds a 2 CELL header with DP and LATEST for that page the end of block \ Each code page in this model is like a small vocabulary that links back to Forth NEEDS DUMP FROM DSK1.TOOLS \ debug only HEX E000 CONSTANT CSEG \ CODE SEG. The page in CPU for extended code F000 2 CELLS - CONSTANT PLINKS \ dictionary pointers at end of page block \ compute CSEG SAMS register at compile time :) CSEG 0B RSHIFT 4000 + CONSTANT CREG DECIMAL 24 USER 'R12 \ address of R12 in any Forth workspace HEX \ *set the CRU address in 'R12 before using these words* CODE 0SBO ( -- ) 1D00 , NEXT, ENDCODE CODE 0SBZ ( -- ) 1E00 , NEXT, ENDCODE : SAMSCARD ( -- ) 1E00 'R12 ! ; \ select sams card : CMAP ( bank# -- ) \ CODE MAP >< \ swap bytes, bank# must be in left byte SAMSCARD 0SBO \ turn on the card ( bank#) CREG ! \ store bank# in SAMS register 0SBZ ; \ turn off card CREATE HOME 0 , 0 , \ 2 cell variable : DICTIONARY ( -- n n) DP @ LATEST @ ; \ get dictionary pointers : RELINK ( dp latest -- ) LATEST ! DP ! ; \ set dictionary pointers : REMEMBER ( -- ) DICTIONARY HOME 2! ; : INITPAGE ( bank# -- ) CMAP \ map extended memory CSEG LATEST @ PLINKS 2! ; \ CSEG as DP & current dictionary : FORTH ( -- ) HOME 2@ RELINK ; \ Restore the Forth dictionary to a HOME : ENDDEFS ( -- ) DICTIONARY PLINKS 2! ; : CODEPAGE: ( page# -- ) \ page# can be 0..$FF (0..255) CREATE DUP , \ compile page# INITPAGE \ set the pointers at end of page DOES> @ CMAP \ map in the memory page PLINKS 2@ RELINK ; \ set new dictionary pointers : PAGE-USE ( -- n ) PLINKS 2@ DROP CSEG - ; 30 CODEPAGE: MISC 31 CODEPAGE: XASM99 32 CODEPAGE: ASM9900 33 CODEPAGE: BLOCKS \ Remember the Forth dictionary to this point so we can get back from a SAMS dictionary REMEMBER \ TEST CODE DECIMAL FORTH MISC : STAR 42 EMIT ; : STARS 0 ?DO STAR LOOP ; : HI CR ." Hello world from SAMS memory!" ; INCLUDE DSK1.SOUND INCLUDE DSK1.COLORS INCLUDE DSK1.ELAPSE ENDDEFS PAGE-USE DECIMAL . FORTH XASM99 INCLUDE DSK1.XASM99 ENDDEFS PAGE-USE DECIMAL . FORTH ASM9900 INCLUDE DSK1.ASM9900 ENDDEFS PAGE-USE DECIMAL . FORTH BLOCKS INCLUDE DSK1.BLOCKS ENDDEFS PAGE-USE DECIMAL .-
1
-
-
Do you drive it with the TI-99?
Is there a "PCL" type language for 3d printing?
Edit: Yes
https://all3dp.com/g-code-tutorial-3d-printer-gcode-commands/
-
SAMS Variables in Forth
In VI99 I needed a way to keep the context of each of the 10 files that could be in memory. That meant space for 10 file names and 5 variables. Altogether that consumed 250 bytes of valuable dictionary memory. It made me wonder if I could save some memory and make the string variable and the integer variables in SAMS memory?
I decided I could use the first record of SAMS memory as local memory for the file. I will change the editor to put text starting at record 1.
That gives me 128 bytes at the top of the SAMS segment. Lots of space but would the speed penalty be too much to use SAMS for variables in the editor?
The SAMSVAR records an offset value. The offset is relative to the beginning of the 64K segment that is selected in the Camel99 SAMS management system.
The difference between a SAMSVAR and other variables is that when you invoke a SAMS variable it automagically pages in the memory page required from SAMS.
This means we can use our normal fetch and store words in Forth to work with SAMSVARs.
We make SAMSVARs with Forth's CREATE DOES> structure. In OOP vernacular, CREATE DOES> lets us make an object constructor that has only one method .
(Note: TI-FORTH and FbForth use the <BUILDS DOES> combination to do this)
This way of working can flummox newbies to Forth so I will take a run at explaining it. (This is going step by step so it's kind of long)
-------------------------------------------
To start let's understand the word CREATE in Forth. CREATE makes an entry in the Forth dictionary. It literally puts the text following CREATE into memory with a little extra stuff to connect it to the list of other words.
CREATE FOO ( puts the word FOO in the dictionary)
After "creating" FOO, if you type FOO into Forth all you get back is a memory address sitting on the top of the data stack. That's all.
The Forth comma ',' takes a number from the data stack and compiles it into the next available. So if we say:
CREATE FOO 7 ,
… we can reference the address of that the number seven using the name FOO. Typing FOO will return the address where '7' is stored and put that address onto the data stack.
---------------
If it helps imagine it's a little this in Assembly Language:
FOO DATA 7
--------------
Now we can type FOO "fetch" "print-number" as below and '7' will appear with ok from Forth. Wonderful. We're just getting started.
FOO @ . 7 ok
Now consider this code:
99 CREATE FOO ,
It works the same but we put 99 onto the data stack first. Comma doesn't care. It picked up 99 and stored in memory the same as it did with 7.
So let's define a new Forth word that does all of this for us:
: VAR: CREATE , ;
Now we can make variables that are initialized to anything we want. They will return the address where the numbers are stored so we can "fetch" them with @ or change them with !. (store)
0 VAR: NULL 99 VAR: FOO 7 VAR: BARThis is the first part of making a SAMSVAR. We don't need the CPU RAM address of a variable, we need the SAMS card address. So a SAMSVAR needs to be different in what it "does" compared to a regular variable. We can use the "Forth word DOES> to tell a SAMSVAR what to do. (See what I did there?)
: SAMSVAR: CREATE , ( like before ) DOES> @ ( fetch the number we gave it) PAGED ( convert to SAMS address, pull in the bank) ;So CREATE and comma are what happens when we invoke the word SAMSVAR: (this is when we compile a program)
DOES> changes what will happen, in other words what code will run, when we invoke the name of a word created with SAMSVAR:
Clear as mud?
So to use SAMSVARs we must give each one their memory address in a virtual memory space called a SEGMENT. Each SEGMENT is 64k.
PAGED is an assembler routine that computes where any address will appear in the CPU RAM page that we selected (>3000 is used in CAMEL99) and maps it into CPU RAM.
So my new code looks like this:
0 SAMSVAR: TOPLINE 2 SAMSVAR: LASTLINE 4 SAMSVAR: ECOL 6 SAMSVAR: EROW 8 SAMSVAR: UPDT \ true if file is changed in anyway 10 SAMSVAR: FILENAME \ ready for long file paths
All that to say the performance hit is about 38% slower than referencing variables in CPU ram. I think I can live with that.
To play with this code in Camel99 do:
INCLUDE DSK1.TOOLS ( to get DUMP and .S )
INCLUDE DSK1.SAMS
Then you can paste this code into Classic99 to explore.
-
1
-
1
-
-
1 hour ago, GDMike said:
I don't know why it wouldn't have attraction. It's super.. but I'm only using real hw so I'm not going to see good stuff like 80 col. But oh well. (My choice).
I'm not giving up just because of that, well, unless I can't get it to text mode on real hw. I doubt that.
I booted this version on real hardware today. It boots in Text mode.
If you want 32 column like BASIC, do INCLUDE DSK1.GRAFIX
To see /study a simple graphics mode program INCLUDE DSK3.SMPTE ( color bars from the society of motion picture and television engineers)
If you don't want to use the editor INCLUDE DSK1.MORE .
Then use MORE DSK1.anyfile to see it. Spacebar will pause the display. BREAK will stop it.
-
1
-
-
Well I am just happy that somebody else boots the darn thing.
Don't hesitate to ask a question or 2.
Have fun
B
-
1
-
-
CAMEL99 Forth V2.61
Here what's new:
- ']' is now not an immediate word in compliance with standard Forth
- DSK1.CAML99SC is Forth compiled to load at >6000 and so works with a SUPER cart and Classic99. This gives 8K more CPU RAM for your programs
- DSK1.SAMSDUMP adds the word SDUMP to the system so you can dump SAMS memory. This works with the SAMS SEGMENT system, dividing SAMS memory into 15 by 64K segments.
- DSK1.INPUT changes the #INPUT word to use the new NUMBER? conversion word. #INPUT works like TI-BASIC's input command looping with an error until a valid number is entered.
- CROSS99 builds a simple cross compiler using DSK1.XASM99 to make standalone binary programs. Forth is not part of the finished program.
- DSK1.XASM99 is a cross assembler that assembles programs into a target memory location.
- Demo program DSK3.HELLOSRC is the source code for a cross-assembled Hello World program. DSK3.HELLO is the binary program file that loads with E/A 5
- DSK1.SAMSFAST has been removed and replaced with DSK1.SAMS, the fastest access to SAMS memory in CAMEL99
-
DSK1.SAMSFTH does the same as DSK1.SAMS but is written mostly in Forth. It's slower but would worker better for MULTI-tasking because it defines R12 as a user variable making R12 unique in each task.
For all those users out there please report any bugs.
-
2
-
1
-
Three Cheers for Formal Testing
(which I didn't do)
I was working today on a faster way to delete/insert a line in a file in SAMS memory. It's an interesting challenge due to the block nature of the memory.
In the course of playing with some methods I wanted to calculate the value of some constants and compile them as a literal value.
In other words do something that those fancy compilers like GCC do for you.
In Forth it would look like this.
HEX 99 CONSTANT X 4A CONSTANT Y : MYROUTINE ( -- n) [ X Y + ] LITERAL ;MYROUTINE switches the compiler off with '[' and so the interpreter is active. X & Y are added together and the sum is left on the DATA stack.
']' turns the compiler back on and LITERAL compiles the number on the stack as a "literal" number, pre-calculated.
I was doing a bunch of this and so I wanted a more expressive way to do this so I wrote:
: ]EVAL ] POSTPONE LITERAL ; IMMEDIATE ( Now it looks better) : MYROUTINE ( -- n) [ X Y + ]EVAL ;
It didn't work!
I tried it in FbForth. (using the older word [COMPILE] instead of POSTPONE) It worked.
I checked my source code and OOPS! I made ']' IMMEDIATE. It's been that way probably since I began this journey. I don't use it much so it never was noticed.
My apologies. I only partially tested the system with the HAYES Test Suite for standard Forth because it had a lot of extras that Camel99 doesn't have. Modifying the big test suite was a pain.
Lesson learned.
I will publish a new version shortly with the correction that also has a couple of small additions to the library as well.
-
1
-
-
So it turns out that an "ok" fix to the VI99 escapes sequence interpreter was 2-fold:
- Use the faster assembler coded version of the SAMS mapper so screen writes move along quicker.
- If the interpreter can't figure out what the sequence is then wait until their are no more keys coming in.
Here is the simple solution to the interpreter. CLRKEYS just reads keys with the timed key routine TKEY until TKEY returns 0.
Make CLRKEYS the default alternative in the case statement and everything gets stable. Still can't autorepeat these keys but at least it is reliable.
: CLRKEYS ( -- ) BEGIN D0 TKEY 0= UNTIL ; : CURSCTRLS ( $ -- ) CASE " [1~" $OF TOSTART ( Home) ENDOF " [A" $OF MOVEUP ( up arrow) ENDOF " [B" $OF MOVEDN ( dn arrow) ENDOF " [D" $OF LEFT ( Left arrow) ENDOF " [C" $OF RIGHT ( right arrow) ENDOF " [4~" $OF TOEND ( End) ENDOF " [5~" $OF PGUP ENDOF " [6~" $OF PGDN ENDOF " [23~" $OF -1 +FILE ( F11) ENDOF " [24~" $OF 1 +FILE ( F12) ENDOF CLRKEYS ENDCASE-
1
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Supernotes
in TI-99/4A Development
Posted
Aside from upholding sacred TI-99 protocols (
) does the word CALL do anything in the Supernotes interpreter?