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

[LASooner]

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.

 

 

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

 

 

[LASooner]

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

[Tursi]

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 August 30, 2017 by Tursi

[LASooner]

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.

 

 

 

 

 

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 August 30, 2017 by LASooner

[Tursi]

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.

[Tursi]

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.

[Tursi]

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.

[+InsaneMultitasker]

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.

[+InsaneMultitasker]

>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 August 31, 2017 by InsaneMultitasker

[Tursi]

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

[+InsaneMultitasker]

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

 

 

 

 

 

*  CALL FILES(n) equivalent  HRD bug/Myarc version, AVPC compatible
*------------------------------------------------------------------
*  Call as  BL   @CFILE#
*           DATA >0n00       ; n>=1, no range checks
*  DSRES+2, real VTOP could be done in lead-in code if room

DBFTOP EQU  >3DEA
NOFILS EQU  >3FFF->3DE9->206  Allow for extra buffer size
NOFILT EQU  >3FFF->3DE9       Without extra
FILSIZ EQU  >206
DSRES  BYTE >00,>AA,>3F,>FF,>11,>03
       EVEN

CFILE# EQU  $
       MOV  @MAXMEM,R0        Fetch MAXMEM pointer
CF#10  AI   R0,FILSIZ         Add a disk buffer size
       CI   R0,DBFTOP         Above the area for 0 files
       JL   CF#10             Not yet

       AI   R0,NOFILS         Fixed area - 0 files
       MOV  R0,@DSRES+2       Write to header (may be below >3FFF)
       AI   R0,-NOFILT        Restore value

       MOV  *R11+,R1          Fetch new # of files
       MOVB R1,@DSRES+5       Write into header
       SRL  R1,8              Make word index
CF#20  AI   R0,->206          Back off
       DEC  R1                Count down
       JGT  CF#20             Not yet done

       MOV  R0,@MAXMEM        As much as the Myarc ever does
       MOV  R0,@CF#30         Write in as pointer data
       AI   R0,6              Point to Vbyte after VMBW done
       BLWP @VMBW             Write header to VDP
CF#30  DATA 0,DSRES,6         Leaves VDPWA set at next Vbyte
CF#40  MOVB R1,@VDPWD         Start writing nulls to VDP
       INC  R0                Match the autoincrement
       C    R0,@DSRES+2       Top of Disk DSR share of VDP ?
       JL   CF#40             Not yet

       RT                     RETURN to caller