Jump to content

9640News

+AtariAge Subscriber
  • Content Count

    2,353
  • Joined

  • Last visited

Community Reputation

2,144 Excellent

About 9640News

  • Rank
    River Patroller
  • Birthday 01/04/1964

Profile Information

  • Gender
    Male
  • Location
    Campbellsburg, KY
  • Interests
    Powered Paragliding and scuba diving.

Recent Profile Visitors

6,716 profile views
  1. Matt, Thanks for the update. I will test this evening to confirm this addresses the issue. I will be able to test on a non-GenMod system to confirm the results one way or the other. I'm going to toss this out for others on this forum to ask if there is anyone running a GenMOD system that would be booting their system from a TIPI rather than from another fast storage device? My suspicions are that if someone has a GenMod system with Memex, they likely have either a SCSI or HFDC already in their system and would not be using the TIPI as their main boot system. If there is someone that would be using a TIPI with a GenMod system, then I hope with positive test results on my end, they could test it on their end as well. Beery
  2. Hans, I got my F18 installed, and it is up and running. Many thanks! Beery
  3. As far as MDM V1.60, I got all the pieces from the one and only set of source files I knew. I am not sure if it was listed as 1.29 or 1.30. To differentiate that package, I numbered it 1.60. There was a post some 6 months or so ago where I described the details. I put all the source files together in a package along with all the necessary linking that built the program image files should someone ever want to advance the software. Unless someone wanted to format a HFDC, I am of the opinion nobody should be using MDM5 on the Geneve. The directory create routine on the HFDC eprom does not match what the documentation says it should be. Things are all hunky-dorrey on a TI-99/4A as it doesn't care, however the Geneve master DSR does things to the specifications. individuals will run into trouble if they use MDM5 to create a directory, and then use any MDOS program or CLI function to remove that directory. Fred's GDM2K or Clint Pulley's Directory Manager should really be the only programs to be used. Beery
  4. OK, once you are in Rompage mode, all MDOS REMAP commands disappear. You are now under the actual Eprom DSR's. If you are going to format a HFDC drive, then you need to setup MDM5 to run from DSK1. You can probably do this to a TIPI mapped DSK1 drive, but not 100% sure. Preferably, do this on HFDC DSK1 if that is your only floppy controller.
  5. I'm back in the house after mowing, and just tested the Myarc FDC option. The TIPI hangs and this is using the original V0.99 eprom. No issue booting with the modified V0.99 with the delay loop skipping the other devices and going straight to the TIPI.
  6. I'll pass the code to you along with a separate piece of code that Tim suggested I tried that seems to "fix" the booting issue. I modified the 0.99 eprom to go straight to the TIPI. First time, the software booted up from the TIPI without issue. Repeated attempts to reboot, no luck. HFDC was in the system. @InsaneMultitasker suggestion was to put in a delay loop after running the powerup routines on each device. So, I set a loop that I run through 20 times, counting down from >FFFF on each loop right before I start looking for a file but after all the powerup routine calls. Yeah, significant delay, but I did not want to be on the border of the issue. Now, it boots every time, with or without another controller card in the system. What I am thinking, is that depending upon what behind the scenes work the PI is doing, possibly the TIPI powerup routine has initiated some python calls on the PI that have not completed and the powerup routine is just proceeding without any tests???? Then, the TIPI gets the call to load LOAD-TIP, and somewhere, the PI side of things finishes up the powerup, messing up the process to then load SYSTEM-SYS. That's just a guess. Could also be there may need to be another powerup verification test that needs to be done that isn't being checked. I'll send the source code over to you shortly. Either way, there is now a way to boot from the TIPI in a TIPI only system with no other devices.
  7. For @jedimatt42 sake, my TIPICFG reports AUTOMAPPING is OFF. I read the WIKI for AUTOMAPPING, and I think loading LOAD-TIP (program image file) from DSK0 would have no effect, but just want to confirm.
  8. Chris, Your post gave me something to consider and lead me to some additional clues. Regarding your use with the HFDC. Not sure if you are testing with the DREM or not. When the power was off, I removed the SD card and had the floppy drive door open and it booted from the TIPI. I was still cabled up to the DREM for HFDC, but no cables for the floppy side of the DREM. It took maybe 15 seconds for it to continue from floppy door open, but it then started loading from the TIPI and booted. I then pulled the HFDC and rebooted. I saw it go to the TIPI with the TIPI light remaining on and doing nothing. At this point, my configuration had DSK1. mapped to a TIPI subfolder. I rebooted with HFDC, went into TIPICFG, and changed DSK1 to an empty entry. Actually, changed DSK2 to an empty entry as well, as DSK3 and DSK 4 were already empty. I then REBOOTED the PI. Not sure if this is critical or not. I then rebooted, with the HFDC removed. No floppy controller cards present. The TIPI immediately booted without anything else in the system. If I add back an entry to the DSK1 into TIPICFG, things hang. Unfortunately, if I then remove the DSK1. entry again in TIPICFG, it now will not boot from the TIPI. At first, I thought the search for DSK1.LOAD-MFM during the HFDC search was pulling from my original TIPI mapped DSK1 where I by chance had a LOAD-MFM and was causing the TIPI hang, but the TIPI logs do not show access to that file. The HFDC eprom looks at DSK1.LOAD-MFM first on the HFDC DSK1 directory, then rolls over to HFDC floppy DSK1.LOAD-MFM. My thinking was that it then may have rolled further to TIPI mapped DSK1.LOAD-MFM. Since it does not show up in the log file entry, that discounts that thought. In fact, the logs show it correctly accessing DSK0.LOAD-TIP as it should. It just did not hang on that first try. Why it hangs on a subsequent attempt, I do not know. I did do a TIPICFG Reboot each time those settings changed. I'm going to test a new eprom image that bypasses the IDE, SCS, HFDC, and goes straight to the TIPI at DSK0.LOAD-TIP and see what happens and report back. @jedimatt42 @InsaneMultitasker I have included Tim and Matt on this post to make sure they see it. Tim has my code for the eprom, and if you want to look it over as well Matt, I am happy to share it to see if anything looks obvious.
  9. Definitely a solution with copy/restore. He will need to realize that any keyboard, video, DSR, or other XOP calls will use that memory. I’m also not sure if some of that memory is used during a test for task switching needs. He will likely need to run disabling interrupts except when he makes an XOP call.
  10. The reference to the 27256 was for the TIPI Eprom Chris was having an issue.
  11. El Cheffe, I have a lot of information in my 9640News diskazine I distributed back in the 90's. Check out www.9640news.com and look for the 9640 News Magazine on the sidebar. Feel free to use the information however it fits best. I've got no restrictions on the use of my information in there. The other historical information of the time can be found in Micropendium magazines as a reference for dates and projects that were circulating back in the earlier years.
  12. Fred, It should be fixed now. There is a new LOAD-IDE, V2.7 over in the EPROM V0.99 discussion topic.
  13. The LOAD-IDE file for autotracking of AUTOEXEC from the IDE drive has been fixed with V2.7 of the eprom. I have updated the original zip file with the corrected file, and also providing the LOAD-IDE file here if you want just that file. LOAD-IDE
  14. You should be burning a 27256 eprom. The 27128 doesn't cut it. Found that out last night myself.
  15. I thought it should, but I had an issue I did not understand why it didn't work. If it comes to it, I will/can move the TIPI to the top of the device checks so it would be the first device tested rather than second to last. Beery
×
×
  • Create New...