tp99 Challenge

[+mizapf]

Concerning the COUNT-P file, there is another issue: The EOF offset is wrong. It is set to 00, see above dump, offset 000c (MSB of word "0050"), but it must be B4.

 

This, in fact, brings the editor into trouble.

 

 

[wolhess]

Hi Michael,

 

Thank you for your analysis. I will check it tomorrow. Since a few day’s I used the new  tidir v7.1 tool to convert my TIFILES to the disk image and back. On the way back I convert the v9t9 files to TIFILES. 
I will also check if the conversions are correct or if Turbo Pascal is saving the files in a different manner.

[Tursi]

13 hours ago, wolhess said:

Your web site shows the same version but dhe wrote in post #13 there is a new version 0024.

Right now I downloaded the current version 399.024 but the same is happening.

The short demos are running. But for larger programs Turbo pascal blocks in classic99.

I got tired of updating the website script, with all the close updates. After all, I said I wasn't doing that anymore. The download is correct.

 

I'll take a look at the large amount of debug information, thank you, but the most important information when you have any issues in Classic99 with disk is the DEBUG LOG. What does the debug log say when it hangs up?

 

Edit: I have some details

[Tursi]

I first tested with the build process in post 11, since I don't know anything about TP99

 

Classic99 complains about COUNT-P - you probably wouldn't see this as it would scroll off the debug window. (Mizapf details this above).

 

Detected D:\classic99\dsks\turbopascal\DSK3\COUNT-P as a TIFILES file
Warning: Number Records doesn't match sector length on variable file.
Corrupt file - truncating read at record 14.
D:\classic99\dsks\turbopascal\DSK3\COUNT-P read 14 records

 

Otherwise it worked fine. So I moved on to the PDF. It looks like WI99DE-P was a good candidate, so I tried that. This blew up during the load!

 

I restarted Classic99 and tried again so I could watch more closely, as I didn't expect THAT step to fail.

I found it odd to note that TP99 starts by reading a lot of the disk sectors directly... I guess there was some discussion of copy protection, eh?

 

Then it changes the top of VRAM pointer to >3BE3. This is okay, and the disk controller header is there.

Then I loaded DSK3.WI99DE-P. After 178 records the TI crashed. Classic99 said there were 340 records available.

 

I did a cold reset and loaded the file into Editor/Assembler to confirm it was okay on that side. This was fine and the file looked good.

 

I went back to TP99 and tried to load it again. This time I watched the heatmap to see where it was loading. Naturally, this time it loaded successfully. It looked like the data was being stored in VDP... there is definitely something there, but it's not the raw text, starting at 0x6e3. Maybe tokenized...? It's not in CPU RAM otherwise.

 

Since I could reproduce a problem just by loading, I simply tried again. On the third try it failed on record 11. It's not clear to me what it's doing though...

 

It seems to be just scrolling through memory looking for something, eventually it starts hitting the device memory space and crashes out.

 

The code doing this is called from the interrupt hook:

 

>  B5C8  02E0  lwpi >b014                 
   B5CC  8040  c    R0,R1                 (R0 = 001C, R1 = B01B)
   B5CE  131F  jeq  >b60e                 
   B5D0  0420  blwp @>ad14                (Vector: AAC2, AD1A, just wraps SCAN to read the keyboard) 
         AD14
         
   B5D4  9820  cb   @>8375,@>b035         (8375 contains the keypress, B035 contains >FF (no key))
         8375
         B035
   B5DA  1319  jeq  >b60e                 (no key pressed, so jump taken)
   
>  B60E  02E0  lwpi >83e0                 
   B612  04E0  clr  @>837c                
   B616  045B  b    *R11                  (back to interrupt hook)

 

That's fine. But at some point, we end up jumping into the middle of the instruction at >B5D4, executing this nonsense piece of code which reads memory continuously, eventually hitting the hardware devices and crashing the system. Sometimes it returns to B5D8.

 

   B5D6  8375  c    *R5+,R13               (at breakpoint, R5 is >5a66, already well out of range, it started in low RAM. R13 is D402)
>  B5D8  B035  ab   *R5+,R0                (at breakpoint, R0 is >001C)
   B5DA  1319  jeq  >b60e                  (jump is taken - data at R5 is 0 and MSB of R0 is 0, so result is 0)
   
>  B60E  02E0  lwpi >83e0                 
   B612  04E0  clr  @>837c                
   B616  045B  b    *R11                     (R11 is >0AB8 - return from user interrupt hook)

   
In repeating the test, I got a different kind of crash. This time there was no memory increment and the system just appeared to hang in a tight loop. It's apparently trying to read the DSR header but got lost.

 

   AC2C  C0A0  mov  @>83d2,R2              
   AC30  1D00  sbo  >0000                  (R12 is >1100 - disk controller ROM enable)
   AC32  C092  mov  *R2,R2                 (R2 is meaningless in this context - >0012 in one test)
   AC34  13E6  jeq  >ac02                  
   AC36  C802  mov  R2,@>83d2              
   AC3A  05C2  inct R2                     
   AC3C  C272  mov  *R2+,R9                
>  AC3E  D160  movb @>8355,R5             
   AC42  1309  jeq  >ac56                 
   AC44  9C85  cb   R5,*R2+               
   AC46  16F2  jne  >ac2c                 
   AC48  0985  srl  R5,8                  
   AC4A  0206  li   R6,>ab77              
   AC4E  9CB6  cb   *R6+,*R2+             
   AC50  16ED  jne  >ac2c            

   
As a final test, I copied the file onto a disk image and tested with the TI DSR. This also crashed on repeated loads in a similar manner (after three tries). So I don't think it's a DSR-related issue.

 

The one thing in common with the lockups seems to be a bad return address for a RTWP, suggesting that a register was altered unexpectedly. Ultimately, since the interrupt routine is involved, since it works "sometimes", and since even the crash is different sometimes, I suspect a race condition with the interrupt routine. Alternately, it's possible there's an interaction with the DSR ROM I don't understand. It could take some deep digging to understand it...
 

Mizapf - if you boot in MAME and just keep reloading the file WI99DE-P, does it always load? (The REDO key works to recall the command, and if you hit 5 loads in a row I'd be satisfied )

 

[wolhess]

Hi, again thank you for your effort!

 

mizapf provided some clean files that I could test today, but the tests are as yesterday. The COUNT file works mostly and the other two files works only sometimes or never.
 

I loaded the three files again in the EA editor, deleted lines after the last END. statement if necassary and saved it to the NAME-A.

But saving or compiling shows the same problems.

 

I think I give up with this Turbo Pasc99 V2.0 version.

 

I found a disk image with Turbo Pasc99 V3.0 from 1989. I will now make some tests with this version. If it runs on classic99. I will post it in this forum.

[+mizapf]

I could not find a problem when loading WI99DE-P, also after 10 times; I even tried different disk controllers. Wolfgang reported that the file WI99DE-P as modified by me did not load in his TP99, while it loaded in E/A's editor. Maximum of confusion ... ?

 

I'll attach the image and the files in the ZIP.

tp99test1.dsk tp99test1.zip

[wolhess]

If I tried the files with my real TI I have no problems. All is working fine with the Turbo Pasc99 programs on my real floppy drive and the source files on my tipi folder.

When Turbo Pasc99 is starting the floppy is massive working on it, but after the Editor/Compiler is loaded then it works good.

[Tursi]

1 hour ago, wolhess said:

When Turbo Pasc99 is starting the floppy is massive working on it, but after the Editor/Compiler is loaded then it works good.

Yeah, when TP99 starts the Classic99 debug log shows that it uses direct sector access to read nearly half the disk - it's not clear why it's doing that. Libraries, maybe?

 

 

Sector read: TICC drive 1, sector 2, VDP >1000
Sector read: TICC drive 1, sector 3, VDP >1000
Sector read: TICC drive 1, sector 4, VDP >1000
Sector read: TICC drive 1, sector 5, VDP >1000
Sector read: TICC drive 1, sector 6, VDP >1000
Sector read: TICC drive 1, sector 7, VDP >1000
Sector read: TICC drive 1, sector 8, VDP >1000
Sector read: TICC drive 1, sector 9, VDP >1000
Sector read: TICC drive 1, sector 10, VDP >1000
Sector read: TICC drive 1, sector 11, VDP >1000
Sector read: TICC drive 1, sector 12, VDP >1000
Sector read: TICC drive 1, sector 13, VDP >1000
Sector read: TICC drive 1, sector 14, VDP >1000
Sector read: TICC drive 1, sector 15, VDP >1000
Sector read: TICC drive 1, sector 16, VDP >1000
Sector read: TICC drive 1, sector 17, VDP >1000
Sector read: TICC drive 1, sector 18, VDP >1000
Sector read: TICC drive 1, sector 19, VDP >1000
Sector read: TICC drive 1, sector 20, VDP >1000
Sector read: TICC drive 1, sector 21, VDP >1000
Sector read: TICC drive 1, sector 22, VDP >1000
Sector read: TICC drive 1, sector 23, VDP >1000
Sector read: TICC drive 1, sector 24, VDP >1000
Sector read: TICC drive 1, sector 216, VDP >1000
Sector read: TICC drive 1, sector 217, VDP >1100
Sector read: TICC drive 1, sector 218, VDP >1200
Sector read: TICC drive 1, sector 219, VDP >1300
Sector read: TICC drive 1, sector 220, VDP >1400
Sector read: TICC drive 1, sector 221, VDP >1500
Sector read: TICC drive 1, sector 222, VDP >1600
Sector read: TICC drive 1, sector 223, VDP >1700
Sector read: TICC drive 1, sector 224, VDP >1800
Sector read: TICC drive 1, sector 225, VDP >1900
Sector read: TICC drive 1, sector 226, VDP >1A00
Sector read: TICC drive 1, sector 227, VDP >1B00
Sector read: TICC drive 1, sector 228, VDP >1000
Sector read: TICC drive 1, sector 229, VDP >1100
Sector read: TICC drive 1, sector 230, VDP >1200
Sector read: TICC drive 1, sector 231, VDP >1300
Sector read: TICC drive 1, sector 232, VDP >1400
Sector read: TICC drive 1, sector 233, VDP >1500
Sector read: TICC drive 1, sector 234, VDP >1600
Sector read: TICC drive 1, sector 235, VDP >1700
Sector read: TICC drive 1, sector 236, VDP >1800
Sector read: TICC drive 1, sector 237, VDP >1900
Sector read: TICC drive 1, sector 238, VDP >1A00
Sector read: TICC drive 1, sector 239, VDP >1B00
Sector read: TICC drive 1, sector 240, VDP >1C00
Sector read: TICC drive 1, sector 241, VDP >1D00
Sector read: TICC drive 1, sector 242, VDP >1E00
Sector read: TICC drive 1, sector 243, VDP >1F00
Sector read: TICC drive 1, sector 244, VDP >2000
Sector read: TICC drive 1, sector 245, VDP >2100
Sector read: TICC drive 1, sector 246, VDP >2200
Sector read: TICC drive 1, sector 247, VDP >2300
Sector read: TICC drive 1, sector 248, VDP >2400
Sector read: TICC drive 1, sector 249, VDP >2500
Sector read: TICC drive 1, sector 250, VDP >2600
Sector read: TICC drive 1, sector 251, VDP >2700
Sector read: TICC drive 1, sector 252, VDP >2800
Sector read: TICC drive 1, sector 253, VDP >2900
Sector read: TICC drive 1, sector 254, VDP >2A00
Sector read: TICC drive 1, sector 255, VDP >2B00
Sector read: TICC drive 1, sector 256, VDP >2C00
Sector read: TICC drive 1, sector 257, VDP >2D00
Sector read: TICC drive 1, sector 258, VDP >2E00
Sector read: TICC drive 1, sector 259, VDP >2F00
Sector read: TICC drive 1, sector 260, VDP >1000
Sector read: TICC drive 1, sector 261, VDP >1100
Sector read: TICC drive 1, sector 262, VDP >1200
Sector read: TICC drive 1, sector 263, VDP >1300
Sector read: TICC drive 1, sector 264, VDP >1400
Sector read: TICC drive 1, sector 265, VDP >1500
Sector read: TICC drive 1, sector 266, VDP >1600
Sector read: TICC drive 1, sector 267, VDP >1700
Sector read: TICC drive 1, sector 268, VDP >1800
Sector read: TICC drive 1, sector 269, VDP >1900
Sector read: TICC drive 1, sector 270, VDP >1A00
Sector read: TICC drive 1, sector 271, VDP >1B00
Sector read: TICC drive 1, sector 272, VDP >1C00
Sector read: TICC drive 1, sector 273, VDP >1D00
Sector read: TICC drive 1, sector 274, VDP >1E00
Sector read: TICC drive 1, sector 275, VDP >1F00
Sector read: TICC drive 1, sector 276, VDP >2000
Sector read: TICC drive 1, sector 277, VDP >2100
Sector read: TICC drive 1, sector 278, VDP >2200
Sector read: TICC drive 1, sector 279, VDP >2300
Sector read: TICC drive 1, sector 280, VDP >2400
Sector read: TICC drive 1, sector 281, VDP >2500
Sector read: TICC drive 1, sector 282, VDP >2600
Sector read: TICC drive 1, sector 283, VDP >2700
Sector read: TICC drive 1, sector 284, VDP >2800
Sector read: TICC drive 1, sector 285, VDP >2900
Sector read: TICC drive 1, sector 286, VDP >2A00
Sector read: TICC drive 1, sector 287, VDP >2B00
Sector read: TICC drive 1, sector 288, VDP >2C00
Sector read: TICC drive 1, sector 289, VDP >2D00
Sector read: TICC drive 1, sector 290, VDP >2E00
Sector read: TICC drive 1, sector 291, VDP >2F00
Sector read: TICC drive 1, sector 292, VDP >1000
Sector read: TICC drive 1, sector 293, VDP >1100
Sector read: TICC drive 1, sector 294, VDP >1200
Sector read: TICC drive 1, sector 295, VDP >1300
Sector read: TICC drive 1, sector 296, VDP >1400
Sector read: TICC drive 1, sector 297, VDP >1500
Sector read: TICC drive 1, sector 298, VDP >1600
Sector read: TICC drive 1, sector 299, VDP >1700
Sector read: TICC drive 1, sector 300, VDP >1800
Sector read: TICC drive 1, sector 301, VDP >1900
Sector read: TICC drive 1, sector 302, VDP >1A00
Sector read: TICC drive 1, sector 303, VDP >1B00
Sector read: TICC drive 1, sector 304, VDP >1C00
Sector read: TICC drive 1, sector 305, VDP >1D00
Sector read: TICC drive 1, sector 306, VDP >1E00
Sector read: TICC drive 1, sector 307, VDP >1F00
Sector read: TICC drive 1, sector 308, VDP >2000
Sector read: TICC drive 1, sector 309, VDP >2100
Sector read: TICC drive 1, sector 310, VDP >2200
Sector read: TICC drive 1, sector 311, VDP >2300
Sector read: TICC drive 1, sector 312, VDP >2400
Sector read: TICC drive 1, sector 313, VDP >2500
Sector read: TICC drive 1, sector 314, VDP >2600
Sector read: TICC drive 1, sector 315, VDP >2700
Sector read: TICC drive 1, sector 316, VDP >2800
Sector read: TICC drive 1, sector 317, VDP >2900
Sector read: TICC drive 1, sector 318, VDP >2A00
Sector read: TICC drive 1, sector 319, VDP >2B00
Sector read: TICC drive 1, sector 320, VDP >2C00
Sector read: TICC drive 1, sector 321, VDP >2D00
Sector read: TICC drive 1, sector 322, VDP >2E00
Sector read: TICC drive 1, sector 323, VDP >2F00

 

 

Thanks for the test there, Mizapf. So it seems that the issue does not exist in MAME - although there's still some weirdness?

 

I attempted to prove the race condition theory.. and I have some support of it. TP99 spends most of its time with interrupts enabled, and it runs KSCAN from the interrupt handler, which can be a very slow operation. It can only get keypresses from the interrupt handler.

 

I made some minor changes so that the interrupt handler could not run during file loads - I changed the program default to interrupts off, and injected a little hook into the main loop to do the traditional LIMI 2/LIMI 0 sequence. With this I could load the file as many times as I wanted with no error, so at least in Classic99 the issue is related to the interrupt hook running during the load sequence. Since it happens with both the Classic99 DSR and the TI DSR, it's not racing the DSR code itself (the TI DSR takes real time to execute and the Classic99 DSR takes 1 instruction to execute, from the 9900's point of view), but something in the code that processes records. It's difficult to pin down where exactly it goes off the rails though so I can't determine if it's a software bug that got lucky or a Classic99 bug that gets triggered in this precise sequence. Or both.

 

It smells like an interrupt bug on my side, though it's a weird one. Tougher to find since ints are (almost) always on.

 

 

These are the patches I made. I did it live in the debugger so there's no updated binary. If the status register was already set when I made the changes I manually cleared it (which requires new Classic99 as the debugger omitted the ability to change the status register ) 

At 3F00, insert new code bytes: 0300 0002 0460 B57C
This is just LIMI 2, B @>b57c, and provides the interrupt enable in the main loop. For a real patch this would be inside the loaded code, but this space was unused and easy to monitor.

At B57A, change to 3F00
This just changes the target of a BLWP vector to the new code, it was B57C. The first instruction at B57C is LIMI 0.

At B3FE, change to 0000
This is an LIMI 2 called at startup and after DSR operations, this changes it to 0 and so sets the default.

These patches were enough to make loading reliable. Saving wasn't, so there's probably another patch needed. At any rate, it was to prove a point, not to patch TP99.
 

 

 

Edit: Classic99 has no issues with the modified files, Mizapf... although when I load WI99DE-P from the disk image, it reliably hangs at record 234. I can't see anything interesting about that record, but the predictability is a clue. I was able to load the TIFILES version without issue (more so than usual). (Nope, even the hang isn't 100% reliable, just loaded for me fine from the image too.)

[Tursi]

Found it, and it was a tricky one. At least my instincts were right.

 

After a context switch (BLWP and XOP, for instance, as well as actual physical interrupts), interrupts are disabled for one instruction. This is to prevent another interrupt from stealing your context information before you have a chance to do something about it.

 

TP99 has a keyboard scan wrapper which is called from the console interrupt routine using BLWP. It also has a subroutine used to scan a DSR header (part of its DSRLNK) which is used to get address information, also called with BLWP and using the same workspace. And, TP99 runs with interrupts turned on most of the time.

 

The very first instruction of the DSRLNK address function is LIMI 0, which was meant to turn off interrupts and prevent this conflict. However, the code I put into Classic99 to block the first instruction after a context switch was not working correctly. So, if the BLWP instruction was called and then the console interrupt executed BEFORE the LIMI 0 did, the KSCAN wrapper would overwrite the context information from the FIRST BLWP (because they shared a workspace) and corrupt a number of pointers. The race window was one instruction wide. This is why it could be hit hundreds or even thousands of times before it tripped.

 

Ultimately, the Classic99 bug was an off-by-one. I can now load the file till the cows come home. I'm just going to run through the full build sequence and then I'll push a new build. As a bonus, got a few new debugging tools in there.

 

[Tursi]

Ran through the full compile sequence a couple of times with no additional issues, calling it.

 

Sorry for the inconvenience and thanks for the help!

 

[wolhess]

That‘s great, you are a real professional and a TI magician.

 

Thank you

 

 

[+mizapf]

Good job! Those issues are extremely difficult to trace. And really, every single detail of operation has some effect at some time.

[wolhess]

Hi,

 

Turbo Pascal 99 now runs smoothly in classic99 (version 399.025).

Many thanks to Tursi for analyzing the problem and providing the new version of classic99.

Today I have loaded, saved and compiled all the programs from the posts before without any error!

 

These are the program disk images for using Turbo Pascal 99 v2.0

 

TP99V2.dsk                             In classic99 this disk must be mapped as a disk image to DSK1.

 

TP99-DEMO.dsk                       The example programs from this disc can be mapped as a disk image
                                                    DSK2 or DSKx.  Or you can copy the TIFILES in a classic99 FIAD directory and map it as DSK2 or DSKx.

 

To run Turbo Pascal 99 please use the E/A option 3 LOAD AND RUN and enter the FILE NAME? DSK1.TP99

 

To run the Turbo Pascal 99 linker please use the E/A option 5 RUN PROGRAM FILE and enter the FILE NAME? DSK1.LK99

 

For more information please read the file COMMANDS on TP99V2.dsk
 

turbo_pasc_99_manual.pdf      This is the manual for Turbo Pascal 99 in German

TurboPasc99_manual_english.pdf   This is the manual in English, I have added a table of content with page numbers and the last page with the information to version 2.0

 

If you want to run the compiled and linked program image files, you can use the TP99 linker.

After a restart of classic99 or after a Cold Reset in classic99 you cannot run directly a compiled program image file.

Please run first the linker LK99 or run the little BASIC program PREPTP (from the TP99V2.dsk) and make a Warm Reset.
Then you can run the TP99 programs from E/A option 5.

[Tursi]

Ahhh, yes, zero bytes in RAM. I'm torn on whether to do something about that one. I'm inclined to say we should fix the startup code to do the test correctly, since it's not JUST Classic99 that it doesn't work on cold, right? Anything with SRAM? It shouldn't be too hard to fix...?

 

(edit) So I tried.

 

This is the code that fails... this is mostly already covered...

 

   FF56  8820  c    @>2000,@>311e          (50)
   FF5C  1339  jeq  >ffd0                  (14)

 

Interesting, loading Editor/Assembler zeros out >2000 (and apparently ONLY >2000) at startup. We can probably honor the spirit of the original test by checking whether >2000 matches another word in the runtime. The bytes at >2000 (B66B) do not match in the RUNTIME file, but interestingly, they DO match the beginning of the startup code at FD44. So if we just patch those two bytes to compare from 311E to FD44 (safe, since that's the code that's checking!), then we should be good in all cases. Or at least as good as a single word test can be!

 

I first looked at LK99, assuming it'd be in there. I found the startup code, but now I'm not sure if it's not just using it for itself. the code existed multiple times on the disk (and I checked a full 16 bytes to minimize false positives.) As a for instance, in LK99 at offset >1336 you'll find this string of bytes, representing the above code:

 

88 20 20 00 31 1E

 

Change the bytes at 133A from 31 1E to FD 44, and save. In searching the entire disk for that string, I found it 7 times. That would make sense if the tools themselves were written in TP99. On the attached disk, I patched them all.

 

My testing isn't comprehensive since I meant to go to bed 90 minutes ago, but I did run through a full load/edit/compile/launch sequence and it seemed to do the right thing each time. So, for your consideration:

 

TP99V2_BootPatch.zip
 

And I'll stop derailing your training thread. For what it's worth, I think this is pretty cool and I wish I had it back when I was doing Pascal in school.

 

[+mizapf]

I don't know of any other program that relies on special values in memory on startup, except for programs built by TP99. Probably not worth the hassle.

 

The issue originates in LK99; (I'll just do it)

 

This should solve the problem. The check routine is implanted by LK99; so I patched it by replacing the JEQ at FF5C by a NOP. So every newly linked program should run. We should not throw away the old linker, though; I would suggest to explicitly refer to the patched linker as LK99A.

LK99A.zip lk99a.dsk

[Tursi]

Looks like we crossed paths.

 

[+mizapf]

Ah yes, I checked the thread before I set off, but then did not have another look... ?

[RickyDean]

2 hours ago, Tursi said:

Looks like we crossed paths.

 

Two emulator gladiators, passing through the night?

[Tursi]

To be fair, Mizapf's fix is the safer one. The TP99 startup code had a bug that made it always load the RUNTIME except in the one faulty case (which crashed it anyway)... now it /always/ loads.

 

My fix preserves what I think was the original intent by fixing what was ostensibly a bug, but the problem with fixing long standing bugs is they sometimes masked /other/ bugs. So if there is a case where a TP99 program can start with the runtime already loaded (like a chain or something?), then it should start 1 file faster. But if there's any new instability at all, we should just use Mizapf's version instead.  I don't mind reapplying the patch over the whole disk again.

[wolhess]

Mizapfs correction works in my tests too. I like to use his version.

 

 

[Tursi]

46 minutes ago, wolhess said:

Mizapfs correction works in my tests too. I like to use his version.

Did you want me to re-patch the disk with his fix so all the tools have it, or are you good?

 

[+dhe]

>Did you want me to re-patch the disk with his fix so all the tools have it, or are you good?

I appreciate it, if you do that thing!

[wolhess]

8 hours ago, Tursi said:

Did you want me to re-patch the disk with his fix so all the tools have it, or are you good?

I‘m fine thank you, I think I can do to patch the provided disks in this thread with Mizapfs patch and then link the demo programs so all should be working in the classic99 environment.

 

Then everybody can use it.

 

 

[wolhess]

Hi Tursi and Mizapf,

today I discovered another problem with TP99 SAVE to a disk image in classic99.

Maybe it is the one with the corrupt header Mizapf detected before.

 

TP99 produce a file with a corrupted header when I save it to a disk image or when I compile it to a disk image.

 

DSK1=TP99V2.dsk

TP99V2.dsk
DSK2=mapped to DSK2 FIAD folder in classic99 with the content of the TP99-DEMO.dsk

DSK2.zip
DSK3=TP99-DEMO.dsk

TP99-DEMO.dsk

 

I did the following:

1.       Run TP99                                      EA3 and DSK1.TP99

2.       LO DSK3.COUNT-P                         COUNT-P is loading

3.       SA DSK2.COUNT-P                         COUNT-P is saved to the DSK2 FIAD folder

4.       SA DSK3.COUNT-P                         COUNT-P is saved to the disk image

 

Now I used Ti99DIR 7.1a to show the content of the source files:

From the DSK2. FIAD Folder Ti99Dir shows it without a problem
From the DSK3 disk image Ti99Dir shows an error message and then the source file content.

 

 

 

Then I used the TIIMAGE tool and it shows me a header error.

 

 

Then I use the Ti99Dir tool to copy the COUNT-P from DSK2 FIAD folder to the disk image again and all is good.

 

 

 

This happens only If I save from the TP99 program and if I compile the source to the assembler image. In the last case, the assembler source file (after CO DSK3.COUNT-S) COUNT-S has the header problem too!

 

 

The editor from the EA can load the assembler source file, but after save this file it has the corrupt header again.

The assembler cannot use the source file with the corrupt header and produce an I/O error code 2.

 

I loaded the corrupt file in the EA editor and saved it to a new file COUNTB-S. to the DSK3 disk image

The new file has also the corrupt file header, but it can be assembled with a lot of errors.

 

For the next test I did the following:

1.       Run TP99

2.       LO DSK3.COUNT-P          load the file with the corrupt header from the image

3.       SA DSK2.COUNTC-P        save the file to the DSK2 FIAD folder

4.       CO DSK2.COUNTC-S       compile it to the assembler source

 

I have no problems to show the two new files COUNTC-P and COUNTC-S with TiDir.

So, the file saves to a FIAD folder and compiling it to a FIAD folder is working without corrupting the header or write a correct header even it was corrupt before.

 

5.       I assembled the COUNTC-S and linked it with LK99 and the program runs without an error.

 

 

 

 

 

 

[+dhe]

fwiw - I've seen that same error, or one very similar in fortrans99+Classics99.