Jump to content
IGNORED

Foxit - in progress


GDMike

Recommended Posts

4 hours ago, Lee Stewart said:

 

Why such an old revision? Classic99 is now at v399.052.

 

...lee

I just googled classic 99 downloads and was presented a massive listing, of course they all had update version numbers but no solid dates. 

 

Yell at google. Bwhahaha...im joking of course.

I wanted the version with no mayo, but it wasn't a "have it my way- day".

Well, thanks for the bright light in version numbers...I'll go look for another.. 

 

 

 

Link to comment
Share on other sites

16 minutes ago, GDMike said:

I just googled classic 99 downloads and was presented a massive listing, of course they all had update version numbers but no solid dates. 

 

Yell at google. Bwhahaha...im joking of course.

I wanted the version with no mayo, but it wasn't a "have it my way- day".

Well, thanks for the bright light in version numbers...I'll go look for another.. 

 

HarmlessLion Software

 

...lee

  • Like 1
Link to comment
Share on other sites

5 hours ago, GDMike said:

I just googled classic 99 downloads and was presented a massive listing, of course they all had update version numbers but no solid dates. 

Yell at google. Bwhahaha...im joking of course.

I wanted the version with no mayo, but it wasn't a "have it my way- day".

Well, thanks for the bright light in version numbers...I'll go look for another.. 

No site besides harmlesslion.com is authorized to distribute Classic99 -- please don't download from other sites. I can't control whether the software is infected or not, and there are too many evil people out there. 

 

(Edit: and github.com/tursilion, I guess, since I've been moving software there)

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

Since I'm stuck in this and can't get it outta my head, I went and loaded the debugger  and if you see anything that stands out let me know.

Of course, everything runs on classic 99 well.

I don't expect an error in the debugger here, as the real issue seems to be on my TI computer. But whats funny is that the Same code was taken from SNP which, as of 5 mins ago ran fine on my TI.

There's gotta be something different...I'm pulling my hair now...lol yup...I got too much anyway..

 

Edited by GDMike
Link to comment
Share on other sites

So, first thing that's weird in there is there are a lot of writes to invalid VDP registers - you might want to track those down. ;)

 

No warnings on the SAVE opcode, so that's good. That means we can rule out a lot of common errors! Thanks for checking that!

 

 

 

  • Like 1
Link to comment
Share on other sites

58 minutes ago, Tursi said:

So, first thing that's weird in there is there are a lot of writes to invalid VDP registers - you might want to track those down. ;)

 

No warnings on the SAVE opcode, so that's good. That means we can rule out a lot of common errors! Thanks for checking that!

 

 

 

Thank you for taking a peak.

The vdp errors are associated with the F18A im using.. I know that doesn't sound informational... but I'll look.

My TI locks up within the DSRLNK.

Update. Someone once said I need to init my F18A with registers 8-E before initializing the other registers. I either misunderstood...or just misunderstood.. anyway, I was able to remove them and saw zero effects on my program, but those errors are gone. Yay. 

 

------

 

 

 

Edited by GDMike
Link to comment
Share on other sites

4 hours ago, GDMike said:

Thank you for taking a peak.

The vdp errors are associated with the F18A im using.. I know that doesn't sound informational... but I'll look.

My TI locks up within the DSRLNK.

Update. Someone once said I need to init my F18A with registers 8-E before initializing the other registers. I either misunderstood...or just misunderstood.. anyway, I was able to remove them and saw zero effects on my program, but those errors are gone. Yay. 

Yeah, those errors mean you were writing to the F18A registers, but you had not unlocked the F18A, so it was still acting like a standard 9918A. While Classic99 doesn't support (most of) the advanced graphics of the F18A, it does support the registers, the GPU, and some of the functions.

 

Since it locks up in DSRLNK, the next trick is to set up a TI disk controller on just one of the Classic99 drives, open the debugger, save to it, and when it locks up, hit F1 to breakpoint and look at the disassembly to see if you recognize the address it has locked up at. (Or, whether it does NOT lock up on the TI controller. If that is true, then you know it's something TIPI specific.)

 

(Edit as well) Regarding initializing registers 8-E, that might have been for 9938 compatibility, rather than for F18A compatibility. In that case, it's deliberate so it's fine to ignore the warning - Classic99 is just saying "Hey, did you mean to do this?" ;)

 

 

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

I threw a TI controller into my peb and changed my program to point to DSK1 and received the same scenario.. just fyi

 

F18A, I Know nothing! Schultz just placed the code for me. I only wanted 80 column text for this until I can get back to forth where I'm hoping will do the thinking on handling F18A for me.... probably not the case... but we'll handle it from there.

I forgot that there is a TIpi process log too.

I just need to figure out where it is. Lol

Ahh...it's thar..var/log/daemon.log

 

 

This is an excerpt from the Tipi Log...It shows Starting foxit, and trying to write a test file,

 

---------------

 

2021-10-05 12:48:50,543 tinames.tinames: INFO     DSK4.FOX -> /home/tipi/tipi_disk/WORK/FOX
2021-10-05 12:48:50,544 ti_files.FixedRecordFile: INFO     reading currentRecord: 250
2021-10-05 12:48:50,557 TipiService : INFO     Request completed.
2021-10-05 12:48:50,564 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Input, dataType: Display, recordType: Fixed, recordLength: 80, recordNumber: 0
2021-10-05 12:48:50,565 tinames.tinames: INFO     DSK4.FOX -> /home/tipi/tipi_disk/WORK/FOX
2021-10-05 12:48:50,566 TipiService : INFO     Request completed.

 


2021-10-05 12:49:23,555 TipiDisk    : INFO     Opcode 6 Save - DSK4.MYTESTDB  


2021-10-05 12:49:23,556 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 8192  (<<-- Correct byte count)
2021-10-05 12:49:23,557 TipiService : ERROR    Unhandled exception in main

                                                                                 ^

And then this.....                                                         ^  So what happened?

 


Traceback (most recent call last):
  File "./TipiService.py", line 83, in <module>
    tipiDisk.handle(pab, filename)
  File "/home/tipi/tipi/services/TipiDisk.py", line 51, in handle
    handler(pab, filename)
  File "/home/tipi/tipi/services/TipiDisk.py", line 331, in handleSave
    unix_name = tinames.devnameToLocal(devname)
  File "/home/tipi/tipi/services/tinames/tinames.py", line 77, in devnameToLocal
    path += "/" + findpath(path, part)
  File "/home/tipi/tipi/services/tinames/tinames.py", line 118, in findpath
    if os.path.exists(os.path.join(path, part)):
  File "/home/tipi/tipi/services/ENV/lib/python3.7/genericpath.py", line 19, in exists
    os.stat(path)
ValueError: embedded null byte
2021-10-05 12:49:24,094 TipiService : INFO     physical mode enabled
2021-10-05 12:49:24,102 TipiService : INFO     TIPI Ready

 

 

 

 

 

 

 

Edited by GDMike
Link to comment
Share on other sites

Going to make a suggestion here to see if you learn any thing from your log file.  If I understand this correctly, you are saving an 8,192 byte PROGRAM image file to the TIPI.  Correct?

 

I don't know about this line:

 

021-10-05 12:49:23,556 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 8192  (<<-- Correct byte count)

 

What I would suggest is going into the editor assembler module, and either create a BSS 8192 byte block with a SFIRST/SLAST/SLOAD statement, and then save the "dummy file/program" out creating a 32 sector, 8192 byte long (actually it may be two files, one 8192 bytes, and the next file containing the last few bytes because PSAVE added a header (6 bytes/file?).

 

See if the log files for the SAVE command show similar information.  I'm just not sure that the tag "dataType: Display" and "recordType: Fixed" are set correctly for a Program Image file.  If you were trying to write records, then you would need to do the open/write/close.

 

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, 9640News said:

Going to make a suggestion here to see if you learn any thing from your log file.  If I understand this correctly, you are saving an 8,192 byte PROGRAM image file to the TIPI.  Correct?

 

I don't know about this line:

 

021-10-05 12:49:23,556 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 8192  (<<-- Correct byte count)

 

 

 

 

I'm not sure about the space following the word, Pab in the log. That's concerning along with the message, "embedded null code"

 

This routine is what I'm using for SNP to save 8192 bytes as a program type file. Works in classic 99 AND real hardware as SNP pushes it. I'm stumped why the same routine doesn't work on real hw in foxit.

BUT....Since it doesn't work on TIpi, I'm going back to foxit code and will rewrite it by leaving the SNP(filem) source file alone and without modifying anything about the data I'll see if it saves a raw program image type file by itself. 

I'll discontinue the SAMS coding at the same time to reduce interference.

I've got another question though, should I just use a rewritten DSRLNK routine and stop using the built in utility in the editor assembler?

 

Edited by GDMike
Link to comment
Share on other sites

You are sending a file name with the length set incorrectly... your filename buffer in VDP is probably padded with zeros, and you didn't calculate the actual file name length...  Is that a thing? ???   Does the TI support that kind of abuse?  I couldn't tell in the other thread if you were saying it DID or DID NOT work in classic99.

  • Like 1
Link to comment
Share on other sites

The length of name is definitely calculated and set and vdp ram data was initialized to >2020 with some meaningful text, like about 40 bytes worth that I move from sam's ram prior to calling DSRLNK.

Yes, this program runs as expected in classic 99 with the exact data sent that I set.

 

I had thought about the Filename and the length so I made a test to verify that during one of my tests yesterday, I ended up cutting the name one character at a time to verify the correct length. My intention then wasn't for DSRLNK write or read, but just to verify my calcs.

Also, foxit cannot read a file that was created on Cl99 and moved over to my TIpi drive.

So it's not only a write issue but both a read and write.

 

Note, I have a very similar program using the same type Pab and buffer settings and addressing that does operate on my real hardware and also runs on Classic99.

It's just this particular program only runs on Classic99.

I haven't looked at the logs captured for a READ file attempt yet. Hmm slacker

 

 

 

 

 

Edited by GDMike
Link to comment
Share on other sites

Matt. Sorry for not answering immediately.

I love your troubleshooting logs in TIpi.

Ok. I thought about what you said about the, well everything. Lol

I started with filenames... I didn't get anywhere...

I went on to changing up some addressing..notta, no Change from what I saw

Then, and I made it a point earlier in all my programs to always catch the length of every filename I use, everywhere. So, that's where my first comment came from to you in an earlier post.

BUT...I went ahead and just plugged in a number, higher than what the actual byte length is in the Filename.

And behold... it worked.. sorta, kinda...iffy

Here's a video..

I dropped the length to a solid 15.

But, yeah...I gotta go look for where the ball is dropping..

Edited by GDMike
Link to comment
Share on other sites

"Also, if you are going to try to migrate FIADs from classic99 to TIPI, make sure you had it set to write in TIFILES format".

 

as far as the mention above. I use my SNP program in both TIpi and classic 99 with no issues between moving files.. just fyi and I'm using the same similar code here in foxit. But I didn't expect these kinda errors I'm seeing here.

But it's looking like I'm getting closer to resolving the issue. By how this filename might be growing for some reason or the name is getting changed? Luckily for me that name is loadable after it's being read.

thank you for taking time...I'll keep Hammering at this..I had already threatened this with a complete file redo altogether, but I wanted to try to look at those things you mentioned before blowing it up...oops, a better word might be, to just put phasers on kill.

 

 

Edited by GDMike
Link to comment
Share on other sites

Hmm. I had posted a remark yesterday but it's not there today..so I'll repeat..

I can read and write a file now, all the data I set up is passed successful.

But the Filename is scrambled, but still loads fine if I use the name I gave it. 

Still working on it.

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Oops.. referring to the previous post I made, all I did here was change the Filename length to a number larger than actual filename length. This is NOT how it successfully works on classic 99 AND SNP.

 

And what Im seeing as a result of my filename length Change is the exact same data I see in Classic 99, except that the Filename being saved has the correct 1st character but all the rest are sporadic.

I am Trying to find out where and how the FN is being trashed. But it's definitely working, meaning, I push data to upper Sam's, create a PAB, write the file. Read the file with the name I assigned originally,(don't use the one listed in the TIpi drive), and my data is successfully read.

Logs show success.

At least I got to use the logs and the Classic99 debugger, such a nice set of tools.

Again, though. I'm not seeing anything wrong with my PAB, buffer addresses, everything leading up to DSRLNK, but something is definitely astray and it's just a matter of putting my thumb on it. I thought of using explorer, but I don't think it can walk through DSRLNK. But maybe it'll show me something up to the point. I'll see if I can start it up.

Oh the fun..

 

 

 

  • Like 3
Link to comment
Share on other sites

I think I've found my issue. I'm using an EQU for storing my Filename and then I do math on it.

But I see I'm supposed to be doing an BSS instead..my EQU is pointing at a High address around >E000 and I thought I could work with it being there. 

I just thought about this and I need to confirm it.

Edited by GDMike
Link to comment
Share on other sites

1 hour ago, GDMike said:

I think I've found my issue. I'm using an EQU for storing my Filename and then I do math on it.

But I see I'm supposed to be doing an BSS instead..my EQU is pointing at a High address around >E000 and I thought I could work with it being there. 

I just thought about this and I need to confirm it.

You could use the EQU to reference the string address  but you need a BSS  with a label somewhere with the string in it. :)

And for a string you can also use  I think.

TEXT 'DSK1.1234567890'   

 

  • Like 1
Link to comment
Share on other sites

49 minutes ago, TheBF said:

You could use the EQU to reference the string address  but you need a BSS  with a label somewhere with the string in it. :)

And for a string you can also use  I think.


TEXT 'DSK1.1234567890'   

 

Ty for chiming in..

Yeah. I did everything I could to prove my code wrong and I lost again. My original EQU and then changing to a BSS 40, to make sure I had plenty of path naming, did nothing different at the end.

In both cases I received exactly what was typed in my command window, ie; DSK4.TEST with a length of 9.

Nothing more nothing less and of course my program ran without error in classic 99. But also runs in  Foxit but screws up the Filename on TIpi drive 4, or whatever drive# set.

I'm Going to next blow away my complete code that handles my file name input + the code that works in converting my inverted text to proper ASCII.

 Uh, that's the code we see when I place the Filename on the screen that BTW has been working.. but I've got to rule it out.

 

Note: this all seems like I never did testing along the way, but actually I'm not near my TI on the weekends when I'm doing most of my coding, so I test on Classic99 and my laptop.

And then every Tuesday I pull the code and run it on the TI. And this is just the latest testing results.

Edited by GDMike
Link to comment
Share on other sites

I threw a TI controller into my peb and changed my program to point to DSK1 and received the same scenario.. just fyi

 

I haven't got any info. I'm just telling you how to debug it. You got the same scenario - great! Now you have the tools to find out why. :)

 

F18A, I Know nothing! Schultz just placed the code for me. I only wanted 80 column text for this

 

Ahh, in that case, yes, the extra register sets were for 9938 compatibility. You should put them back. :)

 

Link to comment
Share on other sites

8 hours ago, Tursi said:

Ahh, in that case, yes, the extra register sets were for 9938 compatibility. You should put them back. :)

Ahh. Good to know for dbl sure. I think my original source was solid, as most code I use had always been verified before I used it, that is, as long as there aren't typos. Haha..

Like I said, I don't know what each of the regs do, I do have the spreadsheet for those but I still don't know.. anyway,

I'll run SNP and see what that TIpi Pab looks like compared since that works with TIpi correctly.

 

 

Link to comment
Share on other sites

Tipi logs comparing SNP and Foxit Data saves. (Both do the same thing, But only SNP works.

 

SNP first

Program Load boot

2021-10-07 11:32:00,964 TipiService : INFO     Request completed.
2021-10-07 11:32:01,342 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Input, dataType: Display, recordType: Fixed, recordLength: 80, recordNumber: 0
2021-10-07 11:32:01,343 tinames.tinames: INFO     DSK2.SNP -> /home/tipi/tipi_disk/PROGRAMS/SNP
2021-10-07 11:32:01,343 TipiDisk    : ERROR    responding with error: 0
NoneType: None
2021-10-07 11:32:01,344 TipiService : INFO     Request completed.

SNP
Program DATA Save

2021-10-07 11:34:17,102 TipiDisk    : INFO     Opcode 6 Save - DSK4.SNPTEST00           
2021-10-07 11:34:17,103 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 8192
2021-10-07 11:34:17,104 tinames.tinames: INFO     DSK4.SNPTEST00            -> /home/tipi/tipi_disk/WORK/SNPTEST00
2021-10-07 11:34:18,346 TipiService : INFO     Request completed.
2021-10-07 11:34:20,917 TipiService : INFO     physical mode enabled
2021-10-07 11:34:20,925 TipiService : INFO     TIPI Ready

-----
Foxit Test
Program Load boot

2021-10-07 11:35:20,148 TipiService : INFO     Request completed.
2021-10-07 11:35:26,881 TipiDisk    : INFO     Opcode 0 Open - DSK4.FOXIT
2021-10-07 11:35:26,882 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Input, dataType: Display, recordType: Fixed, recordLength: 80, recordNumber: 0
2021-10-07 11:35:26,883 tinames.tinames: INFO     DSK4.FOXIT -> /home/tipi/tipi_disk/WORK/FOXIT
2021-10-07 11:35:26,883 TipiDisk    : INFO     (2) Passing to other controllers
2021-10-07 11:35:26,884 TipiDisk    : ERROR    responding with error: 0
 


Foxit Test
Program DATA Save

2021-10-07 11:45:20,650 TipiDisk    : INFO     Opcode 6 Save - DSK4.TESTDB  ??¯0ÈƤ{
2021-10-07 11:45:20,650 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 8192
2021-10-07 11:45:20,651 tinames.tinames: INFO     DSK4.TESTDB  ??¯0ÈƤ{ -> /home/tipi/tipi_disk/WORK/TESTDB  ??¯0ÈƤ{
2021-10-07 11:45:21,852 TipiService : INFO     Request completed.
2021-10-07 11:45:25,304 TipiService : INFO     physical mode enabled
2021-10-07 11:45:25,312 TipiService : INFO     TIPI Ready

 

----looks like crashing filename to me...

 

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