Jump to content

InsaneMultitasker

+AtariAge Subscriber
  • Posts

    4,749
  • Joined

  • Days Won

    2

InsaneMultitasker last won the day on March 2

InsaneMultitasker had the most liked content!

About InsaneMultitasker

Profile Information

  • Gender
    Male
  • Interests
    TI-99/4A, Geneve, terminal emulation and BBSs, Anime ;)

    Employee of Cecure Electronics (1990s) where I repaired and upgraded Myarc & TI hardware.

    Geneve program librarian for Milwaukee Area TI User Group

    Author of S&T BBS, which is still in use by The Hidden Reef and HeatWave BBS, both operating on real hardware. See signature for current Telnet address.

    Author of various other TI-99/4A and Geneve programs.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

InsaneMultitasker's Achievements

Quadrunner

Quadrunner (9/9)

6k

Reputation

  1. Ok, the CYA utility successfully updated my PFM+ chips. Whew. @9640News I sent you CYA 7.50 for review. I want to finish source file cleanup for CRCOS, PFM, and CYA. I'll send you a PM with some more information tomorrow, including test results and any observations related to the MDOS 7.44 release packet you sent me.
  2. I was in the "checkers and baggers know what they are doing" lane today; it was a welcome experience. Last week I had the misfortune of entering the, "I will keep trying the same card and PIN for 10 minutes and hope it magically works" lane; alas, that was of course after the person in front of her asked to buy a personal item that required the checker to saunter 5 lanes over to locate said item, return 5 minutes later to inform the customer there are none in stock, at which time the customer asked for a different brand that was either out of stock or not available at the location.
  3. PFMSYS and CYA have been updated with the faster CRC routine. The table-driven CRC finishes in just under 3s for the current OS; the old byte-wise routine finishes in about 10s. I also took the opportunity to re-enable the PFM device options, so that CYA can now load and save directly from/to the PFM+ and PFM512. The load routine works properly but I think I'll double-check the chip programming loop later today - before I enable the save routine, lest I make a mistake and "brick" my system.
  4. Today I separated the table-driven CRC routine from the CRCOS program so that I could use it within other programs, including the PFM and CYA utilities. In the process of testing the programs, I observed two unexpected results: 1. Protecting a file does not inhibit BWRITE (direct file write) from writing to the blocks within the file. I was surprised when instead of an error, my program successfully wrote new CRC values to a protected OS file! I haven't confirmed whether the file can be overwritten though I suspect it is possible. I need to test the same operation on a floppy. Does anyone know how the /4a DSRs behave? 2.Writing to a file with BWRITE does not update the file's last modified date. I have this vague memory that long, long ago the timestamp update was disabled in the interest of speed. I'm not sure of the best approach nor the right approach. I suppose this explains why sector-editing a file doesn't change the timestamp, though I never had cause to notice, until now.
  5. I liked playing with what to me are some of the fun features, such as the ability to use the cart for serial "com" port applications. Some day I'll get to play with more as there is a lot to explore.
  6. All done! I added conditional assembly directives to where I incorporated the debug output. The code all assembles and links, and I have confirmed that the error trap is working as expected. I'll get the files to you in the near future. Last but not least, here is an image of the disk I saved hoping that one day the root cause would be found.
  7. SAVE doesn't report an error. There is yet another place where the error byte is cleared improperly. MDOS now captures the original error condition and I confirmed the trap works for both SAVE (>06) and BWRITE (>0B). Both Advanced BASIC (MDOS mode) and Extended BASIC (/4a mode) report IO Error 66. @9640News I had trouble with ABASIC crashing the system until I removed some of the debug statements. I am fairly certain at least one DSR section is near the 8k page boundary or close to stomping on an AORG'd/DORG'd area.
  8. I changed the FDR (file descriptor record) of SYSTEM/SYS from a program image file to a DF255 file. I then wrote a small ABASIC program to read the last 30 records of the file. When the program tried to read the first bad record (bad sector), the DSR reported the error as >C0 and returned to ABASIC, which reported an error 26. I then attempted to write to the file; the first bad record generated an error >C0 and ABASIC error 36. So I'm pretty confident record IO is ok. Later today, I will manipulate a small program file's cluster nybbles to point to the bad sectors. With luck, the save opcode will generate an error but I won't bet on it.
  9. I think some of that comes into play. The flags are set in different ways leading to confusion. And VIBCHG is byte value, so sometimes VIBID comes along for the ride. To put another way, there are actually three flags at play: CLOSEF, VIBCHG, and VIBID. From my tests in GPL and MDOS and ABASIC, I think the BWRITE issue is resolved. I confirmed some of the operations via debug output. I'm mostly satisfied with the fix and the code, though I still want to try to test the SAVE and record IO with the bad sectors. I included some of my very raw notes at the end. 1. CLOSEF=>FFFF, VIBCGH=>02, VIBID=>01 (disk number). This is the VIB flush that occurs when a FCB is written via BWRITE. This is good. 2. This is the end of the failed copy operation. TRAP4 shows error code 0xC000. CLOSEF and VIBCHG are cleared, VIBID is 01. MDOS reports the error. 3. DF80 fixed record IO. The log shows that we opened the file (opcode >00), write 5 records (opcode >03) and closed (opcode >01). The VIB is flushed upon open (to preserve the file attributes and update bitmap) and upon closure. VIBCHG looks random but its value depends on the called routines. 4. SAVE operation under ABASIC CLOSEF and VIBCHG are set, so a flush occurs to DSK9. the opcode is >06. 5. /4a mode GPL routine >15, direct output. The >FF in the PAB indicates VDP memory, as expected. CLOSEF is >FFFF and VIBCHG is >02. This flushes the VIB during creation of the file on DSK1. Notes related to the flags, where they are set/cleared, and general observations: CLOSEF - when set, flushes VIB sector 0. Set for delete, close, and a few other opcodes. (CLOSE, DELETE, SAVFCb for >15, OPENUPdate, VIBCHG - used to also flag VIB alter. This may incorrectly override the forced update via CLOSEF. See OPEN&LS2: COPVIB . Rename. GETVIB. GETSEC. I think that the SYSRTN should be skipping the VIB test if the flag is set. VIBCHG/VIBID: GETAUS: calls getvib then getsec. This is where VIB flush is set, in spite of the CLOSEF flag. So in theory, all direct output will flush VIB? GETSEC: changes VIBCHG MSByte to the bitmap mask via GS$J2 GETVIB: changes VIBCHG to the VIBID (drive?) 16-bit value| clears if error DELETE-P: changes VIBCHG MSByte to >01xx OPEN&LS2: RENDR9 to indicate change; BSECW1 binart secwrite, sets to H0001. (save) COPVIB, sets to HFF SYSRTN: BUDOP4 clears both vib and close flag SYSR11, clears both CLOSFL, tests the VIBCHGH MSByte only! So sometimes, MSByte is >00xx CLOSEF is set at CLORESSTS:CLOSE (for closure), DELETE:DENTRY (forced update) + vibchg, FILEOP!:SAVFCB forced update for GPL>15 and BWRITE creation FILEOP!:OPENUP forced update for Open,save, maybe others. HDR2-P2: OPOK, clears flag before entry into the device table call SYSRTN: SYSRTN, tests flag, then looks at ID/FDR/open file/etc. if set, skip test for open file check VIBCHG byte, if 0, skip flush; if <>0, flush. SYSRTN: BUDOFF, clear flag During bwrite, CLOSEF >FFFF and VIBCHG might come from GETSEC. but save/write set vibchg to >0001, so there is no flush. FILEOP: OPENFI, creates fcb Note: this is a byte value. See l8.layout VIBCHG BYTE 0 FLAG 0=VIB NOT ALTERED, 0<>VIB ALTERED VIBID BYTE 0 DRIVE NUMBER OF VIB IN VIB BUFFER FDRVID BYTE 0 drive for the file, tested in SYSRTN
  10. @9640News if you have a moment, please inspect L8.SYSRTN and the SYSRTN routine at the start of the file. CLOSEF, when set, is intended to flush the VIB. However, the later VIBCHG flag test can override CLOSEF. It seems to me if CLOSEF is set, then the VIBCHG test should be skipped so the flush occurs. Another potential problem is that when the CLOSEF is not set and there is an open file, the routine jumps to SYSRT1 and bypasses the VIBCHG test. The two flags are used in different routines and for different purposes. Do you recall the reason for implementing VIBCHG.
  11. I'm not sure about confident SAVE jumps into code for close/restore, and I see similar routines used to update the FCB. However, it looks as if the original error from the trap is preserved unless there is a media error, in which case the latter is reported. This leads me to wonder why the MDOS bwrite exits the DSR via a different path and if that is indeed the problem for the >0B opcode. I've almost run out of time for today.
  12. Initial tests show that trapping the first error code works; MDOS now reports an error when the bad sector is encountered. I loaded DSKU and tried to copy to the same file. DSKU halted with an error, suggesting the /4a-mode DSR routine is immune to the bug. I suppose this makes sense since the above routine is only modifying the MDOS error code. But it also means I must walk through the MDOS level 3 record IO routine as it could incorporate the same bug. To test, I'll create a fake file and FDR, with clusters that overlap the SYSTEM/SYS bad sectors. I can then open the file as relative/fixed and see what happens during a write operation. (I suppose the same test is required for SAVE opcode >06). At first glance, I don't see a similar bug in the corresponding hard drive BWRITE routine but I have no (easy) way to test it without a known, bad file on hard drive media.
  13. I tracked down the problem. This bug is very old and very naughty. During the "save program" and "binary write" operation, the DSR is told to write a certain number of sectors. The DSR writes sectors until the buffer is exhausted or until an error is encountered. When the DSR encounters a write error due to bad sector, open drive door, etc. the write loop exits with an error code. The OS then tries to update the FCB (FDR) for the file. Unfortunately, the OS does not save the previous error condition. When the FCB is written, the previous error byte is overwritten. To the caller, the write operation is typically reported as successful. This can happen multiple times per file. Where is the bug? The low-level floppy controller routine sets the error condition. If the FCB/FDR write is successful, the error is cleared; if it fails, an error is reported but it might not match the earlier error. PABERR is the universal reporting byte for the DSR. R9 is cleared and in most cases, the write succeeds, so the earlier error vanishes. (L8.SECT3 IO and L8.FORMAT return) GODRT BADRT BL @RESPA1 RESTORE PAD CLR R9 ZERO DSR LINK ERROR CODE MOVB R10,@MYPAD+>50 STORE ERROR CODE IF ANY JEQ NE BRANCH IF NO ERROR LI R9,>C000 BAD OP 6 CB @HB34,R10 WRITE PROTECT? JNE NE LI R9,>2000 NE MOVB R9,@PABERR for 9640 mode format error code The "simple solution" is to give the first error priority over the FCB write condition. I also need to check the record write routines for a similar problem. We now have an explanation for some (many?) of the incomplete files over the years. File managers, terminal emulators, Archiver, BASIC/XB, COPY command, and programs that use SAVE opcode 0x06 or direct output/bwrite opcodes are susceptible to this bug.
  14. Yep, I have the disk - it is in the last case that I have been working through. I will be down to 10 or fewer disks soon. To be honest, I am always amazed at the disks’ longevity; some of them are squeaking as they turn but overall, even the disks from the late 80s are reading just fine. And for some files I've tested, like Infocom and MDOS, there has been no bit rot. I've steered clear of disk drive head cleaners these past 30+ years, which makes me wonder if those were all a ruse to sell to the masses or if I just got lucky with the various drives. But I digress.
  15. I recall an article that I believe was written by Jerry Coffey, that described how to make the jump boot disk. This was not a MP article but some other format, either in a newsletter or a DV80 article. Anyway, it involved a few different steps to ensure the correct, fastest format. I doubt that I still have the printed article in my archives but I will check anyway.
×
×
  • Create New...