Jump to content

Photo

Getting a crash in classic 99 QI396, using FWEB Assembler packed w/XB256


10 replies to this topic

#1 LASooner OFFLINE  

LASooner

    Chopper Commander

  • 133 posts

Posted Fri Aug 25, 2017 1:40 PM

I was compiling an XB program and when I got to the assembler , it crashes immediately in C99 upon pressing #2 from the Fweb menu, 100% repeatable 

 

I ran an older version of C99 I happen to have and it runs fine. No crash

 

Here's the error message. I don't know where the debug log gets saved, it wasn't in the root directory.

 

L5v7e3a.jpg

 

The version of F'WEB is 4.40 the one that comes with XB256 game developer package.

 

 



#2 LASooner OFFLINE  

LASooner

    Chopper Commander

  • Topic Starter
  • 133 posts

Posted Sat Aug 26, 2017 1:20 AM

The version that I used that works is QI391 if that helps



#3 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,745 posts
  • Location:BUR

Posted Wed Aug 30, 2017 1:39 AM

That's a warning I added that checks before disk access if the disk control blocks have been corrupted. If you were running that program on a TI disk controller instead of the Classic99 disk controller, the emulation believes that the code would crash. Rather than permit the crash, which tends to cost me hours of troubleshooting to confirm, it just checks and stops. It doesn't abort anything. If you think the emulator is lying, just press OK and let it continue (you might need to open the debugger and/or press F1 to release the breakpoint - you're the first one to get the message). ;)

The debug log isn't written to disk. You see it by opening the debugger screen from the menu.

If you want me to try to reproduce, please post a copy of the disk image/data you're using.

(edit: The XB256 package shipped with Classic99 doesn't include Funnelweb...)

Edited by Tursi, Wed Aug 30, 2017 1:43 AM.


#4 LASooner OFFLINE  

LASooner

    Chopper Commander

  • Topic Starter
  • 133 posts

Posted Wed Aug 30, 2017 4:44 AM

That's a warning I added that checks before disk access if the disk control blocks have been corrupted. If you were running that program on a TI disk controller instead of the Classic99 disk controller, the emulation believes that the code would crash. Rather than permit the crash, which tends to cost me hours of troubleshooting to confirm, it just checks and stops. It doesn't abort anything. If you think the emulator is lying, just press OK and let it continue (you might need to open the debugger and/or press F1 to release the breakpoint - you're the first one to get the message). ;)

The debug log isn't written to disk. You see it by opening the debugger screen from the menu.

If you want me to try to reproduce, please post a copy of the disk image/data you're using.

(edit: The XB256 package shipped with Classic99 doesn't include Funnelweb...)

 

I mistakenly typed XB256, I meant Compiler 256

 

Steps to reproduce

 

put ..\Contributors\Harry_Wilhelm\Compiler256D in DSK1, this came with C99

 

reset and select Extended Basic, it will auto load.

 

PKgC104.png

 

cjgpeeG.png

 

6aUtoYi.png

 

L5v7e3a.jpg

 

If I click OK, then press F1 to continue, nothing happens, and I need to reset it to get it working again.

 

As I stated previously, this disk works fine in an older version of Classic 99

 

Also of note in this version of Classic 99, sometimes I have to close it and restart it several times before I get video. This behavior is inconsistent but happens on both my laptop and desktop.


Edited by LASooner, Wed Aug 30, 2017 5:11 AM.


#5 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,745 posts
  • Location:BUR

Posted Wed Aug 30, 2017 12:44 PM

and I need to reset it to get it working again.


You will need to open the debugger for the hotkeys to work. F1 won't do anything until you do.

"Worked" has two definitions. In one, it works as intended. In the other, something goes wrong but it works anyway. Classic99 is warning about the latter case.

#6 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,745 posts
  • Location:BUR

Posted Wed Aug 30, 2017 1:26 PM

I can see what you are reporting. The debug log notes this:

Detected C:\classic99\Contributors\Harry_Wilhelm\Compiler256D\QD as a V9T9 file
loading 0xA3E bytes
VDP disk buffer header corrupted at PC >FD0E
DSR opcode >5 on PAB >0FEE, filename DSK1.AS
Invalid file buffer header at >37D7. Bytes >AA,>40,>07,>11,>03


So at the "top of ram" pointer, there needs to be a 6 byte header for the TI disk controller to function. Before a DSR call, Classic99 checks whether this header is at least somewhat sane:

1) the first byte must be >AA (although it's not clear that the disk controller checks this)
2) the next two bytes are the top of VRAM. It's expected to remain >3Fxx. You can see here it was changed to >4007
3) the fourth byte is the CRU of the controller in question, >11 is correct, Classic99 only supports >11
4) the final byte is the number of files, Classic99 just ensures it's 9 or less (ie: it doesn't check if all the file buffers would fit)

So that leads to two questions:
-why did FW change the top of VRAM to an invalid value? and
-does anyone care? ;)

We can see the PC it changed at... breakpointing there shows a copy loop, which it looks like Funnelweb is using to copy PABs into VDP.. but what's very odd is that exact sequence above is deliberately copied overtop of the DSR header. So that's the 'why', as far as can be determined.

For the 'who cares', I did a search through the disk controller disassembly. This value does actually matter, it's used to locate structures inside the reserved space... one of the reasons for this check was the pCode card crashing in odd ways when it was incorrect (even on the Classic99 controller which doesn't technically need it).

So, I gave it a shot on the real TI controller, and it does in fact succeed despite the bad pointer. I guess it's never inspired to call the setup routine that has trouble with it.

Best I can do is make it an option. I put it in there to help with all the disk access issues that everyone (including me) keep running into, to help pinpoint where the issues occur. But since some people don't care, I guess I don't need to enforce it. ;)

#7 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,745 posts
  • Location:BUR

Posted Wed Aug 30, 2017 1:41 PM

I'm actually not sure what FW is trying to do... anyone with more insight into the original?

It seems to be in the QD module, but this is the block of code that comes up with that pointer:

   FA98  C020  mov  @>8370,R0              (38)
         8370
   FA9C  0220  ai   R0,>0206               (30)
         0206
   FAA0  0280  ci   R0,>3dea               (26)
         3DEA
>  FAA4  1AFB  jl   >fa9c                 
   FAA6  0220  ai   R0,>0018              
         0018
   FAAA  C800  mov  R0,@>fa94             
         FA94
>8370 contains >37d7, as per normal, but it's not clear to me what it's doing with the >0206 there, or the compare to >3DEA. It ends up going through >39DD,>3BE3,>3DE9 (almost!), and settling on >3FEF. Then it adds >0018 to get >4007 and stores that value to copy later.

Is the >3DEA compare an off-by-one bug? That makes it write >3E01 instead (which Classic99 still doesn't like ;) ). At any rate, I was hoping to fix it fast with a program patch, but I can't see what it's trying to do.

#8 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,690 posts

Posted Wed Aug 30, 2017 5:50 PM

This section of code conflicted with the CF7/nanoPEB devices long, long ago due to how they reserve an extra 8 bytes of VDP ram to track the mounted disks.  I patched a F'web disk image to work around this issue  - I wonder if that image was used here?

 

As I recall, this code adjusts @>8370 by first setting a new starting point then it "allocates" buffers one by one until R0 reaches the point where no more buffers can fit.  I forget why the McGoverns handled things this way; I think it was due to the some of the early Myarc and/or Horizon DSR VDP manipulations. 

 

I will locate my notes and this section of code later tonight.



#9 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,690 posts

Posted Wed Aug 30, 2017 6:12 PM

>8370 contains >37d7, as per normal, but it's not clear to me what it's doing with the >0206 there, or the compare to >3DEA. It ends up going through >39DD,>3BE3,>3DE9 (almost!), and settling on >3FEF. Then it adds >0018 to get >4007 and stores that value to copy later.

 

As I suspected in my earlier post, it seems the image uses some files from the cf7/nanopeb patches I conjured up prior to having any McGovern source code to pick apart. 

 

Egads, 2009? Time sure flies.  I recommend replacing FW/LOAD/UTIL1 with the stock variants, then try again.

----

To: ti99-4a@yahoogroups.com
Date: Sat, 18 Jul 2009 22:31:45 -0500
Subject: RE: [TI-99/4A] Re: CF7+ and Funnelweb - FIX

/snip/

1. Find "1afb 0220 0010" and replace with "1afb 0220 0018" ai r0,>10  ai r0,>18
2. Find "fa94 0220 fdea" and replace with "fa94 0220 fde2" ai r0,fdea ->ai r0,fde2 (-18)
3. Find "0580 8800 fa94" and replace with "0580 0280 3ff8" C R0,@FA94 ->CI R0,3ff8

All three changes should be located within the same sector.

 

 

Edit:  Might be simple to change the LOAD program to allow the user to select either the stock FW or the CF7 modified FW file.  Then the distribution would work for either system.  :)


Edited by InsaneMultitasker, Thu Aug 31, 2017 5:32 PM.


#10 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,745 posts
  • Location:BUR

Posted Thu Aug 31, 2017 12:21 PM

Thanks, Tim. I'll try and get that fixed in my distribution. :)

#11 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,690 posts

Posted Thu Aug 31, 2017 8:27 PM

Here is the Funnelweb source code for the routine in question.  Good but not foolproof ;)

 

 

Spoiler





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users