+mizapf Posted April 26, 2020 Share Posted April 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 26, 2020 Share Posted April 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 26, 2020 Share Posted April 26, 2020 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 27, 2020 Share Posted April 27, 2020 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 ) Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 27, 2020 Share Posted April 27, 2020 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 27, 2020 Share Posted April 27, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 27, 2020 Share Posted April 27, 2020 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 27, 2020 Share Posted April 27, 2020 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.) 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 27, 2020 Share Posted April 27, 2020 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. 2 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 27, 2020 Share Posted April 27, 2020 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! 3 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 27, 2020 Share Posted April 27, 2020 That‘s great, you are a real professional and a TI magician. Thank you 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 27, 2020 Share Posted April 27, 2020 Good job! Those issues are extremely difficult to trace. And really, every single detail of operation has some effect at some time. 4 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 28, 2020 Share Posted April 28, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 28, 2020 Share Posted April 28, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 28, 2020 Share Posted April 28, 2020 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 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 28, 2020 Share Posted April 28, 2020 Looks like we crossed paths. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 28, 2020 Share Posted April 28, 2020 Ah yes, I checked the thread before I set off, but then did not have another look... ? 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted April 28, 2020 Share Posted April 28, 2020 2 hours ago, Tursi said: Looks like we crossed paths. Two emulator gladiators, passing through the night? Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 28, 2020 Share Posted April 28, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 28, 2020 Share Posted April 28, 2020 Mizapfs correction works in my tests too. I like to use his version. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 28, 2020 Share Posted April 28, 2020 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? Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 28, 2020 Author Share Posted April 28, 2020 >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! Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 29, 2020 Share Posted April 29, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 29, 2020 Share Posted April 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 29, 2020 Author Share Posted April 29, 2020 fwiw - I've seen that same error, or one very similar in fortrans99+Classics99. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.