Jump to content
IGNORED

Foxit - in progress


GDMike

Recommended Posts

Ok. I've started another little coding project, it's based on the old FoxPro for DOS, if you remember that one.

It had a command box that allowed the user to use predefined words to build a database file, add records and eventually even create the screen using commands as easy as TI basic.

An example of one of those commands  was, CALL SAY @ 2,3 "hello"

if I remember correctly...gees, don't make me go look it up now.. but of course I will double check that later on..

anyway, this little project is in assembly, and I've already created the command box with a couple words added to it's library. Yay.

it's strictly for the F18A/SAMs/TIPI

I'll drop a wip video on what I've got done -soon., those are always fun to see.

I've placed my user help screen data into a bank of  SAMs ram so that I can keep more of my programming code intact between >A000->F000 and reserve the rest of SAMS for user data space.

it's always fun to start a new project and I hope to have a completion date by end of year.

by then, I should have a DB creator with user defined screens for entering data, and the ability for real time/date processing via TIPi.

 

I'm currently developing the "CREA" or "CREATE" command, which places a DBF skeleton file on the TIPi drive.  that is,  a user can create an empty, no fields defined file.

And later the command, MODI STRU, or modify structure can be used on that file to add tables, indexes etc.

And eventually, a "CREA SCREEN" command to wrap it up, which allows user design of the screen and data input.

Screens can be saved and loaded by using commands such as "SET DEFAULT TO" and "DO SCREEN" for loading/saving screens and DBF files...

Well that's the plan... well see!! Wish me luck.

Ok, I had a tough time talking myself out of doing the whole thing in forth, but eventually decided on assembly but it wasn't easy. I didn't need the speed of assembly so that wasn't a factor. And by the time I had already finished the command box in assembly and still trying to decide, I figured I've already gotten this far so I might as well continue.

But....I could still Change my mind here.

Something is pulling at my pants leg and saying, do it! do it! in FORTH!! Lol 

And I think it's because of how I could use the power of forth for easy table manipulation and storage.

Well see.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Edited by GDMike
Typo
  • Like 5
Link to comment
Share on other sites

5 hours ago, GDMike said:

Ok. I've started another little coding project, it's based on the old FoxPro for DOS, if you remember that one.

It had a command box that allowed the user to use predefined words to build a database file, add records and eventually even create the screen using commands as easy as TI basic.

An example of one of those commands  was, CALL SAY @ 2,3 "hello"

if I remember correctly...gees, don't make me go look it up now.. but of course I will double check that later on..

anyway, this little project is in assembly, and I've already created the command box with a couple words added to it's library. Yay.

it's strictly for the F18A/SAMs/TIPI

I'll drop a wip video on what I've got done -soon., those are always fun to see.

I've placed my user help screen data into a bank of  SAMs ram so that I can keep more of my programming code intact between >A000->F000 and reserve the rest of SAMS for user data space.

it's always fun to start a new project and I hope to have a completion date by end of year.

by then, I should have a DB creator with user defined screens for entering data, and the ability for real time/date processing via TIPi.

 

I'm currently developing the "CREA" or "CREATE" command, which places a DBF skeleton file on the TIPi drive.  that is,  a user can create an empty, no fields defined file.

And later the command, MODI STRU, or modify structure can be used on that file to add tables, indexes etc.

And eventually, a "CREA SCREEN" command to wrap it up, which allows user design of the screen and data input.

Screens can be saved and loaded by using commands such as "SET DEFAULT TO" and "DO SCREEN" for loading/saving screens and DBF files...

Well that's the plan... well see!! Wish me luck.

Ok, I had a tough time talking myself out of doing the whole thing in forth, but eventually decided on assembly but it wasn't easy. I didn't need the speed of assembly so that wasn't a factor. And by the time I had already finished the command box in assembly and still trying to decide, I figured I've already gotten this far so I might as well continue.

But....I could still Change my mind here.

Something is pulling at my pants leg and saying, do it! do it! in FORTH!! Lol 

And I think it's because of how I could use the power of forth for easy table manipulation and storage.

Well see.

That is a massive project... You're basically trying to recreate a programming language for database management. Personally I would consider Forth instead of assembly as you get nearly the same access to computer resources but in a more programmer-friendly format, particularly during the testing and debugging process.

I would ultimately ask, why??? But I already know the answer: because you can ? Looking forward to seeing how this develops...

Edited by Vorticon
  • Like 5
Link to comment
Share on other sites

Interesting project @GDMIKE.  The other obvious reason to use Forth is the virtual memory system with the BLOCK function.

And of course you can still write lots of Assembly language code to support the program if you feel the need.

Happy to support your efforts should you choose to go that way.

 

Old man story: (Ignore at your leisure)

 

Long long ago in a place far far away I build an election management system for our local TV station. It was all Forth and the data was maintained as fields in disk blocks.

 

To create the database records there was a small language that looked something like this:

 

DATABASE      ( switches to database lexicon)

 

RIDING MONTREAL WEST

LIBERAL  TRUDEAU ENCUMBENT

CONSERVATIVE SMITH

NDP JOHNSON

COMMUNIST  SARKOV  

 

(i had pre-defined the parties)

 

I gave an example like this the newsroom admin and said "Can you type up a file like this for all the national election ridings?" She said "Is that all I have to do?"

 

I took her text file and fed it to the system and I had a database. She "programmed" it perfectly. 

That was a good day. :) 

  • Like 4
Link to comment
Share on other sites

1 hour ago, TheBF said:

Interesting project @GDMIKE.  The other obvious reason to use Forth is the virtual memory system with the BLOCK function.

And of course you can still write lots of Assembly language code to support the program if you feel the need.

Happy to support your efforts should you choose to go that way.

 

Old man story: (Ignore at your leisure)

 

Long long ago in a place far far away I build an election management system for our local TV station. It was all Forth and the data was maintained as fields in disk blocks.

 

To create the database records there was a small language that looked something like this:

 

DATABASE      ( switches to database lexicon)

 

RIDING MONTREAL WEST

LIBERAL  TRUDEAU ENCUMBENT

CONSERVATIVE SMITH

NDP JOHNSON

COMMUNIST  SARKOV  

 

(i had pre-defined the parties)

 

I gave an example like this the newsroom admin and said "Can you type up a file like this for all the national election ridings?" She said "Is that all I have to do?"

 

I took her text file and fed it to the system and I had a database. She "programmed" it perfectly. 

That was a good day. :) 

Hahaha....I love it when things like that happen. 

 I know I probably should do this in FORTH, as I've said before, and it would aid tremendously for my wanting to know more about FORTH, and I still may as I continue.

I'll go forward with what I have for now and we'll see how things go. If I get into trouble or don't like how things are progressing, I'll shut it down and start over.

Yes, I understand the blocks function in forth and that's really the way to go if I choose. Mark made this ideal in TF, also the use of .S" DSK#.NAME" (<---maybe spelled wrong),  for swapping out files is an ideal operation too.

So many things, but I have code already drummed up for my filing in assembly, and ok ..Im probably not going to convince anyone on which way to go with this, I'll just continue with what I have.. thx for offering to help, maybe things will swing later.

 

 

 

  • Like 4
Link to comment
Share on other sites

  • 3 weeks later...
  • 5 weeks later...

Ok. I'm back on this again, after delay. I've been trying to get my filename straightened out lately, see, my issue was the user enters the command, "CREA DSK#.FILE" this is set on a white screen using blue characters which are set exactly 123 characters into the character set. If I need to invert these typed in characters then I'll need to convert each character by adding -123 to the byte which turns the character to a white character on blue background and is easier for my program to work with actual characters for filling with.

But I've gotten into a pickle because I chop off the last character during my read if the string is odd in count but all works out if the string is on even count.

My plan to take care of this is to do a search for last character and set the character manually because I already have a method in place that adds "DB" to the end of the string, so in this case I'll just confirm that"DB" remains which should fix my cutoff last char problem.

I'm hoping to finish that tonight.

 

Link to comment
Share on other sites

Success! I now have completed the filter for filename process for the command, "CREA" this is a critical step going forward that has to be correct before a file can actually be made and activated.

What took me so long was having to wade through my inverted charset and getting the length for filename set + correct charset active behind the scenes as the user works in inverted char mode all the time, but error reporting is always in proper charset no matter what screen/char color comes up.

It's not a Hassel really, but one of my problems was reading the stream and ending on an odd byte in which time the program never knew as it was just reading the string, incorrectly though.

So I needed a pad at the end of my string, so I used "*" marks since that character can't be passed as part of a filename and can get caught by my error handling too. I've set strict filename parameters, So it works nicely.

 

 

Edited by GDMike
  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

"CREAte" database file routine finished last night at like, 2am.

When entering the command in the command window, a DB skeleton file is made containing the word DATABASE: followed by the name the user gave it followed by TABLE:0 which tells the program how many fields are associated.

This is just another step done in the process.. sorry it's taking so long, I've been really busy lately on other personal projects...

 

 

Edited by GDMike
  • Like 4
Link to comment
Share on other sites

Well, I'm going to rewrite the way "USE" will be implemented..

For those that don't know the way its supposed to work is this:

if a user load's up a database file it's "remembered" until another database is used or created. And also,

Creating a dbf automatically makes that particular file active.

But if the command  word "USE" is called then whatever dbf that was in memory- is dropped and usually no message follows.

"USE" can also be used to set an already existing dbf file active IF coupled with a dbf as in calling the command word, "USE DBF" Without quotes. The status message area displays the name of the database.

Of course, in SQL we just use the SQL word "SELECT" to do The same thing.

But in my case, in Foxit, I'd like to use the same command to do the work of both actions, the USE by itself and the USE+File AND display a message, "No DBF in use" if USE is called alone AND The file in use if a DBF is applied.

Really it's not a tough thing but I figured it's best to let the program filter out the two calls but I'll just clear that RAM space out where that info is held after each call to USE then I'll throw out a message, "no dbf in use"  which is shorter than placing a message+ filename. This way both messages can occur with the actual USE filename conquers if it's ever called.

This way I don't waste programming space by running two separate types of messages and routines.

It's a bit of rework for me, but not a terrible thing. Well, after I saw the length of the 2 messages, then it hit me that I could and should change the way it's acting.

Update...it's already done. But I'm trying to figure out why my cursor comes back with a flashing "U" character in the command window, lol... is anyone missing one? I got an extra here..

..I'll figure it out..

 

 

 

 

 

 

 

 

 

Edited by GDMike
  • Like 2
Link to comment
Share on other sites

I am wondering...

 

Sounds like you are going to get a considerable sized interpreter by the time you are finished with record and field creation.

 

Wondering how you implemented the interpreter?

You probably know where I am going.    

Should you make a command that lets you make a new command? 

 

I have seen that somewhere else... where was that? :)

 

 

Link to comment
Share on other sites

5 hours ago, TheBF said:

I am wondering...

 

Sounds like you are going to get a considerable sized interpreter by the time you are finished with record and field creation.

 

Wondering how you implemented the interpreter?

I have seen that somewhere else... where was that? 

Before I took this up.. and one of the reasons I took it up was exactly the amount of commands that needed to be written out.

Thankfully it's less than 10 commands besides the obvious that need defined, "Call Ver, Call Clear,

Quit.."

those types are simple, but necessary.

The actual database words themselves are simple to install and add in at any time as there just in a list. The interpreter looks at the first command, decides if it's even close as an entry and either continues in its word search or just bails out.  I don't want to spend time searching a serial list for a bottom listed definition when it's obviously in the list, so early in my search routine I need to make my decision.

So that is fundamental to my definition find.

 

Ahh. My search is not the one that was smartly written by Lee in my SNP program that ended up not being added in because I ran low of program space to add it.

That's completely my fault. Yes, it's under 60 bytes I believe, but I was sweating when time came to wrap up SNP. But I do have ideas on how to get it added in with some restructuring of other code. Such as removing on line-built in help. That's all it takes to free up 900 bytes right there..

but...it's a give and take at the moment and I'm ok without the Lee Search routine, for me.. as I'm the only one who uses SNP for my daily docs, Hehe...it's just a text editor with bells.

 

Now, with Foxit, well, I thought about it, and what I just mentioned about running low on ram, so I decided firstly that I wouldn't make that mistake again by placing my help routine in main ram space.

So I smartly devised early at program boot to set address >3000 - >3FFF as a space for my help.

This includes the help menu, the key presses and checks, everything as a complete subprogram to be AORG'd to>3000.

Then I secondly build my SAMs mapper and I push all of local>3000 ->3FFF into my last SAMs page. Freeing up my local >3000->3FFF for continued program space. So when help is called, I merely set SAMs last page and BL @>3000. Since I have a return in my last SAMs page I then remap back to local>3000.

future subs will be made this way with, maybe reserving 100 SAMs pages for just BL subs. Anyway, I haven't reserved that type of space for Foxit because I feel I won't need to since database commands won't require the extra space..so far that's my story and I've got quite a bit of program space available to me so I'm happy with everything and my search for command strings, as primative as it may be, searching character by character and exiting if no match seems to be the quick and dirty solution for the few commands that will exist. 

like I mentioned earlier, this is easily accomplished and rightfully better if done in forth, I'm not changing my mind about that, BUT for me, I'm not versed enough yet to push it to forth. Some of it, yes. Maybe half I could do, but the filing routine, I feel I'm more comfortable with in assy. That's hopefully going to change next year after I start diving back into forth. Plus, I'm not sure, is it me or is it how turbo forth handles SAMs. I see in TF when a word is created it becomes available wether it's in sam's or not, which is nice, but I sure ate up a lot of SAMs pages quickly when writing words in SAMs pages. I dunno.. maybe I was just on a roll and things were just adding up quickly, but before I knew it, I was already left with 10 pages of SAMs left when was messing around last year with TF..I had sound tables, I had graphics and the assembler loaded all in my local ram, but only had room in SAMs for my practical application...so I dunno.. something that kinda worries me, unless I think of ways of chaining my crap together. But here, in assembly, I seem to have everything I'll need in this application without chaining, which, btw, is smooth and carefree in a tipi environment. But I degress.

 

 

 

 

Edited by GDMike
  • Like 2
Link to comment
Share on other sites

Sounds like you have a clear vision of where you are going and 10 or so keywords is certainly not too many to hard code them all.

 

I have never tried TF's SAMS words but there is a bit of extra cruft needed to remember the page no. and how to return.  I will have to take a look again at how Mark did that.

However all that being so, we all know how very easy it is to code away and consume more resources.

As Murphy's law of computing states:

 

                       "All systems grow to fill the known universe"  :) 

Forth can bite you because of the dictionary header and the name of the word being in the code. They say write lots of small words which helps the programmer but it eats up bytes too.

Assembler on the 9900 is very efficient at inline code but nesting sub-routines can add a lot of fat that catches me by surprise in this machine Forth compiler I am trying to master.

 

Utopia is hard to find.

 

Keep on keepin' on with Foxit. It will be fun to see it come to life. 

 

 

 

  • Like 2
Link to comment
Share on other sites

I've solved my sudden appearance of a "u" that appeared. It was doing exactly what it was told. Hmmm. Lol, and this was because I wasn't doing a vsbr prior to leaving my routine, instead, I had a vsbw. 

From what I know on TF, after running the SAMs routine that Mark setup, I just issue a new page number and "USE".

Once that happens a page of ram is added and words created at this time become available along with preexisting words. No worry about switching banks.

Now, this is from my memory with working with TF a couple years back.

So excuse me if that's not right, but that's what I remember.

I'm not sure how FB does it, i didn't get that far with it, :(

Foxit Forward...

 

 

 

 

 

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, GDMike said:

 

From what I know on TF, after running the SAMs routine that Mark setup, I just issue a new page number and "USE".

Once that happens a page of ram is added and words created at this time become available along with preexisting words. No worry about switching banks.

I just took another look at Mark's code. When I first saw it my system was not stable enough to dream about it but it all looks pretty much like I thought it should now.

He uses the word SETBANK.  USE I believe selects the BLOCK file.

 

I will take a run at translating this to Camel99 Forth.  I have some ideas about the bank stack implementation that could make it a bit smaller.

Thanks again for the reminder about this.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Just now, TheBF said:

I just took another look at Mark's code. When I first saw it my system was not stable enough to dream about it but it all looks pretty much like I thought it should now.

He uses the word SETBANK.  USE I believe selects the BLOCK file.

 

I will take a run at translating this to Camel99 Forth.  I have some ideas about the bank stack implementation that could make it a bit smaller.

Thanks again for the reminder about this.

Yeah. It's coming back... 1 setbank works just like that. Sorry. "USE" is used in lots of places. You're so correct on setting a file with that word. Man...I'm glad I don't rely on memory...I really suck at remembering words, but forth doesn't.

  • Like 2
Link to comment
Share on other sites

1 hour ago, GDMike said:

I'm not sure how FB does it, i didn't get that far with it,

 

SAMS in fbForth 2.0 works pretty much the same as in TurboForth. The biggest difference is that low expansion RAM is mostly unavailable in fbForth—certainly, not enough for a 4-KiB page. It must use upper RAM for paging SAMS 4-KiB banks and how it does it is up to the user.

 

I have not implemented TurboForth’s “SAMS Programming Library” in fbForth 2.0. It should be possible and I have thought about doing it. The one thing that has kept me back is that there is still a significant use of CPU RAM for the SAMS-defined words—it is not all in SAMS and the headers (as I recall) are larger to accommodate SAMS paging. I just don’t remember how much of each word is in CPU RAM—I should look at that again before I prove I don’t know what I’m talking about. |:)

 

...lee

  • Like 3
Link to comment
Share on other sites

5 hours ago, Lee Stewart said:

 

The one thing that has kept me back is that there is still a significant use of CPU RAM for the SAMS-defined words—it is not all in SAMS and the headers (as I recall) are larger to accommodate SAMS paging. I just don’t remember how much of each word is in CPU RAM—I should look at that again before I prove I don’t know what I’m talking about. |:)

 

...lee

I think this can be done by storing all the extra stuff in the SAMS page that you pull in. That way you only need to remember the SAMS page# and all the data is available as soon as you MAP in the page.

I did this last year but it got confusing with wordlists and vocabularies.  I am looking at doing an ultra simple version because my projects are "growing to fill the know universe" :) 

 

I am also looking at just using the return stack for the page# value. I don't think we need a separate stack since there is a SAMS :  and a SAMS ;   They should save the page# and retrieve the page# when you enter and exit the words.

 

MAP can be really simplified because we always know that the code page maps into >3000.  Here it is in Forth. 

Computing stuff at compile time means this can be used in FbForth by changing CSEG to >E000 or where ever you need it. 

(SAMSCARD is just a constant for >1E00 )

: SAMSCARD  ( -- ) 1E00 'R12 ! ;   \ select sams card

 

\ SAMS memory management for code
HEX              3000 CONSTANT CSEG      \ CPU RAM window for SAMS code
4000 CSEG 0B RSHIFT + CONSTANT CREG      \ compute CSEG SAMS register
CSEG 4 RSHIFT         CONSTANT PASSTHRU  \ default SAMS page

\ "CMAP"  brings pages of code into the window called CSEG
\ *should be CODE for best speed
: CMAP ( bank# -- )    \ ** bank# must be in low byte**
      SAMSCARD 0SBO     \ turn on the card
      ( bank#) CREG !   \ store bank# in SAMS register
      0SBZ ;            \ turn off card

 

I also think overloading : and ; is  extra baggage that takes precious space. 

Using code to select the right operation at run time can be eliminated by just having a BANK selector  and  special colon/semi-colon pair like  FAR:   ;FAR

 

The ultimate thing for me will be modifying FIND so SAMS words can call SAMS words in other pages. ? 

 

 

 

 

  • Like 2
Link to comment
Share on other sites

We're you going to use a predefined address, like >3000? I'm not sure how Mark has his. I mean, TF seems to just bank and be done with no More user interaction required, not even unmapping. I do love it though, when I ran close to having no bytes left I just said, next bank please.. incrementing from the last, like 20 to 21 SETBANK. And wholla, I've got another 4K and I don't have to worry about which bank my new words are generated in, they all seem to all coexist. But, maybe if one wanted to use >3000 for something it might not be possible.. not sure..I'll have to cross that bridge later.

I'm forever thankful for Lee and you and others that enlightened me on how to use SAMs. It's a great piece of hardware that is indeed one of the best things to learn how to use for this hobby. I've still got to do some more learning regarding F18A, though Lee has me in a starting stage where I can init and set to 80 col text mode, I'm going to do the rest of my learning experience within TForth. 

Next summer probably.

Edited by GDMike
  • Like 2
Link to comment
Share on other sites

With code I posted you choose the page address by setting CSEG. Your choice. Mark's code uses >3000 by default.

By making the decision at compile time for the page to use,  MAP becomes over 2X faster and since MAP is happening every time the word runs it's important to keep it fast.

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...