Jump to content

InsaneMultitasker

+AtariAge Subscriber
  • Content Count

    3,217
  • Joined

  • Days Won

    1

InsaneMultitasker last won the day on August 18 2019

InsaneMultitasker had the most liked content!

Community Reputation

2,920 Excellent

About InsaneMultitasker

  • Rank
    River Patroller

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 librarian for Milwaukee Area TI User Group

    SysOp of HeatWave BBS, operating on real hardware at 38.4Kbps. See signature for current Telnet address.

    Author of S&T BBS Software and other TI/Geneve programs

Recent Profile Visitors

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

  1. This is in the 9640 FAQ that DHE put together long ago I recall the instructions to create jump boot disks were written down, maybe in a newsletter or Micropendium.
  2. If I recall correctly, it was Dr. Jerry Coffey who documented what was called the jumpboot process. There are some additional tricks to reduce the load speed even further, such as where and how you copy the file to the disk. I cannot for the life of me remember where I have read the article, it might be something I have saved in my folder of printed information. If I think of it tomorrow I'll go look in my binder. There is mention of the commercial disk in this thread:
  3. RFILE1-S is incorrect on my fixed disk (edit: even though the screenshots I took clearly show the file was fixed!) so I may have compounded the errors. I viewed every file before I saved the disk image and they all worked fine, but now some do not. I might have saved my work to a different folder without knowing it? I'll try to sort that out tonight. The question still remains as to why the EOF offset is wrong in the first place, and what program or DSR is causing this situation. Edit: I wonder if I had the disk image open with TI99Dir at the same time without realizing it, could that have caused the problem with my fixed image?
  4. Lot of good detail! For these steps, was step 6 completed with the RAMdisk? I cannot tell for sure because in step 5, you say you copied the files to TIPI.
  5. Yea, if that was one of my early ones (versus someone else) I was just learning back then. Not to say I'm an expert now by any means but it was before we were doing commercial hand-soldering. The wires were installed that way on purpose for a few reasons. There were only two of us that did Myarc work. And I cannot tell if my date/initials are for the update or for a repair. No repair records exist from those years.
  6. There are variants. The one in the ebay pic is a 256K variety, 2x 128K atmel 29c020.
  7. Sadly, the gate array is locked into specific pages in GPL mode for a maximum of 16k space. For kicks I wrote a simple loader that performed 8,192 unrolled MOVs to simulate bank switching in the 6000 space and patched the binary trampoline to execute my own bank switch. While the result was somewhat acceptable for programs that didn't switch banks too often, more trampolining meant more banking and performance degradation - certainly unacceptable for many games. From that idea I moved on to executing the binary from native OS mode by creating a small wrapper. It required the author to build an alternate binary using the Geneve video/sound port addresses and a Geneve keyboard routine (joysticks use the same cru). The ROM address-based trampoline was replaced with a bank mapper for the GEneve pages, which was determined by the wrapper at load time. (another caveat is that since the binary runs out of RAM, writing to what is normally ROM is a 'bad thing'.) A proof of concept was tested in 2019 for an unreleased game. This ROM wrapper handled up to 128K; a binary up to 256K could be loaded into a standard Geneve; 512k was possible with expanded memory. The wrapper program is around 1k in size. Here's a shot of where I left the code last year. I think there was a sound-related issue left unresolved but gameplay itself seemed stable. This is the snip of code that is used to switch banks. Note that I use the ROM caller's bank number and slightly manipulate to use the Geneve memory mapper. Probably simple to incorporate this sort of code into the binary using macros at assembly time?
  8. I have corrected all file FDRs -- every file had the same issue. Try copying these files to your ramdisk and assembling. If this results in successful assembly, we can assume level 2 copies were successful and move on to level 3 record IO as follows: load one of the two previously non-working source files from the ramdisk. Save the file from the editor to the two devices: TIPI and floppy. Attach the newly created TIPI file here. Also copy the file from floppy to TIPI then attach here. We can compare the resulting files. RFILE-fixed.dsk
  9. The EOF byte in the FDR (which exists both on physical disk and in a TIFILES header) is incorrect in the corrupted files. Its value is one greater than the actual end of the last record. This suggests to me that one of the DSRs is at times calculating the offset incorrectly. And, unless I am mistaken, the pointer is wrong in the working files as well. The most likely reason the COPY directive fails during assembly is that those files contain no END directive, so the assembler continues reading the file until the EOF is reached or in this case, an error is encountered. For example, here is RFILE1-S viewed in Disk Utilities. And after correcting the EOF byte in the FDR (also present in a TIFILES header) by -1, level 3 read finishes as expected. I inspected two other files and their EOF pointer is incorrect as well. The question here, as @F.G. Kaal points out in his post earlier, is determining where the problem is occurring. Is it the TI Disk Controller, TIPI, or TI99Dir. (we might have ruled out ROS by nature of the earlier tests.) Including @jedimatt42 for awareness.
  10. forgot to ask... where was the file created and how did it get copied to the disk image. One of the two bad files on the disk image seems to have an incorrect EOF marker in the File Descriptor Record, and is off by one byte. I did not have time to inspect the other or look any further.
  11. Strangely enough, if I mount the disk via Geneve emulation and copy from the disk to internal Geneve ramdisk, the file exhibits the same behavior on the ramdisk. So this isn't limited to the Horizon. I -can- view the file from the floppy without any issues. I have run out of time but my next suggest step would be to compare the good and bad FDRs for any clues.
  12. When I view the two protected files (from RDISK.DSK) using MENU/BOOT, there is problem with the file. I did not inspect the File Descriptor Record to determine the issue with the file but here is what I see as an example: I'm guessing somewhere in the creation or transfer of these files, the EOF marker or record count has been corrupted. Hard to tell which device may have caused it without further testing.
  13. Yes, please. I am curious to know if the 8-character limit is an issue with the old ROS. Be sure to use the ROSCCTI file not the ROSMYARC when you load ROS. I use DM2K to copy from TIPI to HRD w/3200 sectors, so that should be ok, but I have not yet tried v3.0 to confirm. There can be issues copying if you don't specify the CRU. Are you copying with device TIPI or device DSKx on the TIPI?
  14. @wolhess - would you mind formatting your RAMdisk with ROS 8.14F then trying the same test?
×
×
  • Create New...