Jump to content
GDMike

Foxit - in progress

Recommended Posts

Posted (edited)

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

Share this post


Link to post
Share on other sites
1 hour ago, GDMike said:

FoxPro for DOS, if you remember that one.

dckr05d-3c194efe-1a40-44e1-acd1-7ec53fe7324b.thumb.gif.3d0efb9bc0f7906d95cf449516de8a89.gif

  • Haha 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 4

Share this post


Link to post
Share on other sites

I used to do a LOT of programming in foxbase. I found TI Base by Dennis F to be a really competent adaptation of dbase. Maybe you could find him, get him to release the source code and enhance from there?

  • Like 3

Share this post


Link to post
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 3

Share this post


Link to post
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 3

Share this post


Link to post
Share on other sites
Posted (edited)

Ok.  Testing for file name

 

Edited by GDMike

Share this post


Link to post
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.

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...