Foxit - in progress

[GDMike]

ok, next Ill push a MANUAL filename and Length and see if it works here.

[+9640News]

Yeah, definitely something going on with the filename length byte not being handled properly.

[GDMike]

12 minutes ago, 9640News said:

Yeah, definitely something going on with the filename length byte not being handled properly.

but the length and name are put in manually and I lock up. BUT it works on classic99. With placing A REAL NAME onto the directory.

Ill see if Lee will look at my code when he gets a chance.

 

THIS PROJECT ON HOLD

Edited October 7, 2021 by GDMike

[+9640News]

There is one difference between your earlier code, and your FOXIT code.  That is the filename itself.

 

Let me make a debugging suggestion.  Go to where the length byte is in VDP and read that byte.  Then, with that number of bytes, read the next "x" bytes and display on the screen.   This should be done right before you do an actual file save. This will help you confirm the filename you are intending to write is what you want to write.  After you write those "x" bytes, incrementing the character position each time, write another character (anything, but something where the character pattern is already defined) to confirm you do not have some undisplayable characters you are not seeing as part of the filename.  I hope that makes sense.

 

Should the filename be only "DSK4.TESTDB" or was there going to be something like an underscore key and a couple more letters?  I thought I remember reading a post somewhere there was going to be something appended to the filename itself.  I'm assuming the character was a legal character to be used on the PI itself for filenames.  I would think an asterix might be a problem.  Not sure how many other characters could be a problem.

 

Beery

 

 

 

[GDMike]

1 minute ago, 9640News said:

There is one difference between your earlier code, and your FOXIT code.  That is the filename itself.

 

Let me make a debugging suggestion.  Go to where the length byte is in VDP and read that byte.  Then, with that number of bytes, read the next "x" bytes and display on the screen.   This should be done right before you do an actual file save. This will help you confirm the filename you are intending to write is what you want to write.  After you write those "x" bytes, incrementing the character position each time, write another character (anything, but something where the character pattern is already defined) to confirm you do not have some undisplayable characters you are not seeing as part of the filename.  I hope that makes sense.

 

Should the filename be only "DSK4.TESTDB" or was there going to be something like an underscore key and a couple more letters?  I thought I remember reading a post somewhere there was going to be something appended to the filename itself.  I'm assuming the character was a legal character to be used on the PI itself for filenames.  I would think an asterix might be a problem.  Not sure how many other characters could be a problem.

 

Beery

 

 

 

yeap. i already did that too. I posted about how I decemented 1 byte at a time and it proved my file was indeed the right length.  but it was a good idea i thought

[GDMike]

actually I went back looking for that post and couldnt find it...but I did that test

[GDMike]

1 hour ago, 9640News said:

There is one difference between your earlier code, and your FOXIT code.  That is the filename itself.

 

Let me make a debugging suggestion.  Go to where the length byte is in VDP and read that byte.  Then, with that number of bytes, read the next "x" bytes and display on the screen.   This should be done right before you do an actual file save. This will help you confirm the filename you are intending to write is what you want to write.  After you write those "x" bytes, incrementing the character position each time, write another character (anything, but something where the character pattern is already defined) to confirm you do not have some undisplayable characters you are not seeing as part of the filename.  I hope that makes sense.

 

Should the filename be only "DSK4.TESTDB" or was there going to be something like an underscore key and a couple more letters?  I thought I remember reading a post somewhere there was going to be something appended to the filename itself.  I'm assuming the character was a legal character to be used on the PI itself for filenames.  I would think an asterix might be a problem.  Not sure how many other characters could be a problem.

 

Beery

 

 

 

Ahh. Yes, see the end characters. They are indeed "DB". The user enters a Filename, I've strictly enforced the length to like 6 I believe, and I add the DB which is seen in the classic 99 example after the file is saved and when I do a view of the folder contents.

Other than the normal slop that Lee finds in my code review and once he gets past that, I can't wait to see what he finds as far as the filing problem. I can deal with the slop, he usually finds stuff like my,

CLR R3

LI R3,0000

Or similar

Hahaha.. sorry

 

Edited October 7, 2021 by GDMike

[+9640News]

Only other suggestion I have, and I don't use the Classic 99 or the debugger, is can you view the contents of VDP ram in the debugger?

 

Can you watch the PAB in VDP and confirm length byte?  It sounds like your earlier test should have done the trick, but it would not be the first time I have an INCrement instruction too early or late in some code and moved too little or too much data. 

 

I don't know if you can single step in the Classic 99 debugger or not following a breakpoint, but you might also make sure >20's follow the filename as I saw one earlier post something sorta seemed to work when you added a space character.  If you can edit VDP while in the debugger, if that is possible, that may help determine what may or may not work.

 

Beery

 

 

[GDMike]

I don't remember what can be done in the debugger. After lunch I'll take a peek. I know that you can set break points and it does show all the registers, ram,cpu and instructions too.

I tried single step I think once, but didn't figure out if it worked, I didn't pay too much attention with the debugger... because it was working in classic 99. But I'll play with it later anyway. As Lee has my program scattered all over his living room and stretching out all his windows by now..

.ok maybe not. Lol

Edited October 7, 2021 by GDMike

[GDMike]

Ahh. Yes F1 and F2 in the debugger pause and step the code running.

I see I'm getting a corrupted or illegal Pab buffer  header error too which I didn't see before.

It says, and it should of copied the error message, but something about address >3xxx

So does DSRLNK do something in that address range. I've got my SAMs coding paging that area. Hmm. Maybe I should always copy >3000->3FFF and restore it prior to page change.

 

Edited October 7, 2021 by GDMike

[+Lee Stewart]

1 hour ago, GDMike said:

It says, and it should of copied the error message, but something about address >3xxx

So does DSRLNK do something in that address range.

 

Not DSRLNK (unless you tell it to), but the DSR it calls uses the >3xxx area in VRAM (not your SAMS window in CRAM) above the address contained in >8370—the TI Disk Controller definitely uses this area of VRAM.

 

...lee

[GDMike]

1 hour ago, Lee Stewart said:

 

Not DSRLNK (unless you tell it to), but the DSR it calls uses the >3xxx area in VRAM (not your SAMS window in CRAM) above the address contained in >8370—the TI Disk Controller definitely uses this area of VRAM.

 

...lee

Oops, I meant. I should of copied the error message.

 

Oh. Ok that's Clear

 

Edited October 8, 2021 by GDMike

[GDMike]

This past weekend I was able to add the command, "MODI STRU".

If you type that into the command window without a, "USE DSK#.FILEDB" first, then an error, "no database is open" is displayed.

So a, "USE DSK#.FILEDB" will display the name of the current Database file underneath the command window.

Issuing a, "MODI STRU" here now will display how many fields are associated with this open database file.

9 fields can be added. 

Adding a field has not been created yet. But the modify structure command is started.

An example of a field being added will look like,

 

MODI STRU First Name,T,13

 

Available data types will be.

Field name (actual field label) comma(separator) followed by

TEXT (T) or VALUE(V) or DD (Date only) or

DT(date and time) or TT(Time) followed by comma, and the length of the field in decimal number format.

Filing is still being hammered out.

 

In the actual old version of fox from like version 2.2 and so on, mathematics is allowed in the command window. This had commands such as "?" And "SUM", "TOTAL" and others..

Example: ? 4+8 12 and also,

TOTAL ON field1 638

But, unless I could find a way to build a calculator with XMLNK, I think it is, but I'm not sure on that.. but yeah I'll think on it after the basics are In place.

Ideal for Forth though

 

 

 

 

 

 

Edited October 12, 2021 by GDMike

[GDMike]

The latest Foxit video and additions.. while the filing gets a makeover.

 

[GDMike]

Actually modi stru doesn't open a file..my bad..too many things going on lately.. sorry for confusing.. and the command"USE" Will be changed to the word "SELE" another flabizaster on my part.

I'll fix it all Saturday night and present another video.. dang...wth....I feel like Im Coding in my sleep lately...

Can anything fix stupid, I Know it wasn't possible in 1985.

 

[GDMike]

Modi STRUcture is back on the drawing board..

Here's the latest fixes, changes..

This is great going into the weekend.

 

I'll be calculating modi STRUcture, which is a two step process,

 

 First we define fields and place that list into the database.

 

Then we proceed with placement of those fields  onto a screen. 

This actually becomes Record 1.,2.,..etc as we page up/down.

 

We're allowed a max of 9 fields per screen (record).

 

Fields can be a date, a date+time, a time, a value of 1-9 numbers and text field of 30 characters max.

 

 

Edited October 16, 2021 by GDMike

[+9640News]

13 hours ago, GDMike said:

 

Fields can be a date, a date+time, a time, a value of 1-9 numbers and text field of 30 characters max

I would give some serious thought to making a text field larger than 30 characters.  If someone is going to use your program and wants to have a "Comments" field, then 30 characters would not be enough.  I would really consider something around 255 characters. 

 

Another thing, if someone wants to have it be a filepath, then I would go at least 80 characters.

 

That is my 2 cents on text field length.

 

 

 

 

[GDMike]

Right on. As a memo Field isn't added in yet.

I'm thinking I'll have a around1300 bytes but we won't know until later after I get the basics in. 

 

[GDMike]

2 hours ago, 9640News said:

That is my 2 cents on text field length.

Thanks so much for reminding me of that last field..I had considered it, but with so much going on lately it did get pushed out. But thanks for the reminder to NOT forget it. 

[GDMike]

Well get more done over the weekend here .

 

 

[GDMike]

Very little got done over the weekend. The building I was working out of had AC problems and no way I was going to do any coding in that HOtasSpLacE. So I did some paperwork and more planning on my MODI STRU command instead. 

Did I mention that we're dropping the "SAVE" file type to  a record based write file method instead? Each screen could end up being a record I suppose, but I haven't done any math on that yet.

Lee suggested to me a couple weeks ago and it sounds better. Plus the fact that I couldn't find the problem with the TIpi save issue I was having., Ahem..

.  AND it's just a better approach in this case.

 

 

 

[GDMike]

"DISP STRU" has been created and it works nicely.

Giving an error message IF a DB file isn't in the open state. And giving the total number of fields that exist for the current DB file. 

But now the focus is  MODI STRU now, as it will entail creating each Field and it's properties and how that will be set as an open record to be saved. 

I think we're thinking to save a bundle of fields, with the beginning of each record having information about which bank # it belongs to in SAMs, (it's direct address) + field properties type + screen col/row for each Field location+field length and allowance for 1 memo() field to follow at a bank# address for an xxx amount of bytes.

A simple search routine to follow later. 

 

This will give me a direction on how I can make it expandable by leaving room for a possible relational approach if we have programming space that would allow it, because right now I'm not  including the option to open multiple records and having a search routine that can tie other fields together. I just want a stable, simple and of course useable DB.

What's the point if while doing a search takes 20 minutes to achieve. Because I think that's where that might head to with any storage Device.

 

 

 

 

 

 

Edited October 21, 2021 by GDMike

[GDMike]

Weekend Update....

The form for the "FIELD" modify/create is in progress and I'm about a quarter of the way into it.

There's a ton of, "what,ifs,buts and where's," going on at this point of the program, so it's taking awhile to knaw through.

I ended up dividing my "HELPS" data SAMs bank into 2 sections. Half for actual help menu and the other half for variables dealing with making a screen form. This way I don't waste program space.

I'll do a video as soon as I get a break.

 

 

 

 

 

[HOME AUTOMATION]

1 hour ago, GDMike said:

Weekend Update.... I'll do a video as soon as I get a break.

Will this include, The Not Ready for Primetime Players?

 

[+dhe]

Any chance of uploading the code to a github repo so we could all watch as things develop?