+9640News Posted April 11, 2021 Author Share Posted April 11, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted April 11, 2021 Share Posted April 11, 2021 I'm trying to be a beta tester. I can't find the 24V ac adapter to my UV eraser. I found 3 27C128's in my memory bin. One was bad (3 bits not blank, 16 programming errors) two have contents. I have gobs of 2764 and 27C256 but no more of these. Stuck. Considered making a 27C256 adaptor. 1 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted April 11, 2021 Share Posted April 11, 2021 51 minutes ago, 9640News said: You should be burning a 27256 eprom. The 27128 doesn't cut it. Found that out last night myself. Yup, 27C256 is what I used. I have a few 27C256 that would fail on verify if I selected 27C256, but burn fine if I select 27256. Not sure why.. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 11, 2021 Share Posted April 11, 2021 58 minutes ago, @9640News said: You should be burning a 27256 eprom. The 27128 doesn't cut it. Found that out last night myself. 6 minutes ago, Shift838 said: Yup, 27C256 is what I used. I have a few 27C256 that would fail on verify if I selected 27C256, but burn fine if I select 27256. Not sure why.. Hold on, why won't a 27128 work? My current 0.98 EPROM is a 27128 - same capacity as the EPROM binary. In order to rule out a PEBKAC error, this afternoon I programmed an Atmel 29C256 (32K) chip, taking care to duplicate the first 16K into the second 16K. I installed the EPROM then powered up the PEB. Geneve OS 7.30 booted properly from the TIPI and also picked up the Autoexec, once I created it in the root (i.e., TIP1.AUTOEXEC). My system contains HFDC, SCSI, ramdisk, and Myarc FDC devices - none of which had the requisite loaders or OS copied to them, and the EPROM appeared to scan them all prior to landing on the TIPI. I did encounter one issue - if the SYSTEM-SYS file is not found, the Geneve locks at the swan. The TIPI log confirms that loader attempted to find the OS and failed. Quote Link to comment Share on other sites More sharing options...
Shift838 Posted April 11, 2021 Share Posted April 11, 2021 3 minutes ago, InsaneMultitasker said: 58 minutes ago, @9640News said: You should be burning a 27256 eprom. The 27128 doesn't cut it. Found that out last night myself. Hold on, why won't a 27128 work? My current 0.98 EPROM is a 27128 - same capacity as the EPROM binary. In order to rule out a PEBKAC error, this afternoon I programmed an Atmel 29C256 (32K) chip, taking care to duplicate the first 16K into the second 16K. I installed the EPROM then powered up the PEB. Geneve OS 7.30 booted properly from the TIPI and also picked up the Autoexec, once I created it in the root (i.e., TIP1.AUTOEXEC). My system contains HFDC, SCSI, ramdisk, and Myarc FDC devices - none of which had the requisite loaders or OS copied to them, and the EPROM appeared to scan them all prior to landing on the TIPI. I did encounter one issue - if the SYSTEM-SYS file is not found, the Geneve locks at the swan. The TIPI log confirms that loader attempted to find the OS and failed. we are talking about the TIPI EPROM Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted April 11, 2021 Share Posted April 11, 2021 Where are the TIPI EPROMs located? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 11, 2021 Share Posted April 11, 2021 4 minutes ago, Shift838 said: we are talking about the TIPI EPROM Ah, I see that now. I didn't know the conversation jumped to a different EPROM mid-stream when I replied. Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 11, 2021 Author Share Posted April 11, 2021 35 minutes ago, InsaneMultitasker said: Hold on, why won't a 27128 work? My current 0.98 EPROM is a 27128 - same capacity as the EPROM binary. The reference to the 27256 was for the TIPI Eprom Chris was having an issue. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 11, 2021 Share Posted April 11, 2021 Here is bootup using load-tip and system-sys with the 0.99 eprom from post #1. The autoexec file (on tip1) contains the echo line shown below. 4 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted April 12, 2021 Share Posted April 12, 2021 thought I would post my TIPI log file entries as me and @InsaneMultitasker were discussing last night. The TIPI is running Pi Version 2.20 and DSR Build 2021-02-24 I do not have any drive or URI mappings, nor do I have WiFi enabled. It is hooked up via CAT5. Log file from cold boot or pressing CTRL+SHIFT+SHIFT of Geneve with HFDC (no drivers hooked up besides floppy) and TIPI @>1800 2021-04-12 06:34:47,023 TipiService : INFO physical mode enabled 2021-04-12 06:34:47,024 TipiService : INFO TIPI Ready Errors to 'CANNOT LOCATION SYSTEM SYS FILE ON HFDC PRESS ANY KEY TO RETRY' Log file after after pressing any key to retry. 2021-04-12 06:39:27,284 TipiService : INFO physical mode enabled 2021-04-12 06:39:27,285 TipiService : INFO TIPI Ready 2021-04-12 06:39:32,571 TipiDisk : INFO Opcode 5 LOAD - DSK0.LOAD-TIP 2021-04-12 06:39:32,572 Pab : INFO opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 12288 2021-04-12 06:39:32,572 tinames.tinames: INFO DSK0.LOAD-TIP -> /home/tipi/tipi_disk/LOAD-TIP 2021-04-12 06:39:32,574 TipiDisk : INFO LOAD image size 1024 2021-04-12 06:39:32,700 TipiService : INFO Request completed. 2021-04-12 06:39:32,732 LevelTwo : INFO set path request 2021-04-12 06:39:32,734 LevelTwo : INFO unit: 0, path: DSK0. 2021-04-12 06:39:32,734 tinames.tinames: INFO DSK0. -> /home/tipi/tipi_disk 2021-04-12 06:39:32,734 LevelTwo : INFO set unit 0 path to DSK0. 2021-04-12 06:39:32,736 LevelTwo : INFO direct input 2021-04-12 06:39:32,739 LevelTwo : INFO unit: 0, blocks: 0, filename: SYSTEM-SYS, startblock 0 2021-04-12 06:39:32,739 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:32,744 LevelTwo : INFO direct input 2021-04-12 06:39:32,747 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 0 2021-04-12 06:39:32,748 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:33,776 LevelTwo : INFO direct input 2021-04-12 06:39:33,779 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 32 2021-04-12 06:39:33,779 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:34,883 LevelTwo : INFO direct input 2021-04-12 06:39:34,885 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 64 2021-04-12 06:39:34,886 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:35,987 LevelTwo : INFO direct input 2021-04-12 06:39:35,990 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 96 2021-04-12 06:39:35,990 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:37,086 LevelTwo : INFO direct input 2021-04-12 06:39:37,089 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 128 2021-04-12 06:39:37,090 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:38,210 LevelTwo : INFO direct input 2021-04-12 06:39:38,213 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 160 2021-04-12 06:39:38,214 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:39,321 LevelTwo : INFO direct input 2021-04-12 06:39:39,324 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 192 2021-04-12 06:39:39,324 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:40,440 LevelTwo : INFO direct input 2021-04-12 06:39:40,443 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 224 2021-04-12 06:39:40,443 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:41,566 LevelTwo : INFO direct input 2021-04-12 06:39:41,569 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 256 2021-04-12 06:39:41,570 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:42,661 LevelTwo : INFO direct input 2021-04-12 06:39:42,664 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 288 2021-04-12 06:39:42,665 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:43,788 LevelTwo : INFO direct input 2021-04-12 06:39:43,791 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 320 2021-04-12 06:39:43,791 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:44,901 LevelTwo : INFO direct input 2021-04-12 06:39:44,904 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 352 2021-04-12 06:39:44,905 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:46,034 LevelTwo : INFO direct input 2021-04-12 06:39:46,037 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 384 2021-04-12 06:39:46,037 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:47,171 LevelTwo : INFO direct input 2021-04-12 06:39:47,174 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 416 2021-04-12 06:39:47,175 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:48,274 LevelTwo : INFO direct input 2021-04-12 06:39:48,277 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 448 2021-04-12 06:39:48,277 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:49,378 LevelTwo : INFO direct input 2021-04-12 06:39:49,381 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 480 2021-04-12 06:39:49,381 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:50,442 LevelTwo : INFO direct input 2021-04-12 06:39:50,445 LevelTwo : INFO unit: 0, blocks: 32, filename: SYSTEM-SYS, startblock 512 2021-04-12 06:39:50,445 tinames.tinames: INFO DSK0.SYSTEM-SYS -> /home/tipi/tipi_disk/SYSTEM-SYS 2021-04-12 06:39:52,571 TipiDisk : INFO Opcode 0 Open - TIPI.AUTOEXEC 2021-04-12 06:39:52,572 Pab : INFO opcode: Open, fileType: Sequential, mode: Input, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0 2021-04-12 06:39:52,572 tinames.tinames: INFO TIPI.AUTOEXEC -> /home/tipi/tipi_disk/AUTOEXEC 2021-04-12 06:39:52,574 TipiService : INFO Request completed. 2021-04-12 06:39:52,581 Pab : INFO opcode: Read, fileType: Sequential, mode: Input, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0 2021-04-12 06:39:52,582 tinames.tinames: INFO TIPI.AUTOEXEC -> /home/tipi/tipi_disk/AUTOEXEC 2021-04-12 06:39:52,584 TipiService : INFO Request completed. 2021-04-12 06:39:52,628 Pab : INFO opcode: Read, fileType: Sequential, mode: Input, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 1 2021-04-12 06:39:52,628 tinames.tinames: INFO TIPI.AUTOEXEC -> /home/tipi/tipi_disk/AUTOEXEC 2021-04-12 06:39:52,629 TipiDisk : ERROR responding with error: 5 NoneType: None 2021-04-12 06:39:52,630 TipiService : INFO Request completed. Pulled HFDC and installed Myarc FDC only Log file from cold boot of Geneve: 2021-04-12 06:53:50,830 TipiService : INFO physical mode enabled 2021-04-12 06:53:50,831 TipiService : INFO TIPI Ready The Geneve goes to the TIPI but the light only stays on the TIPI. It never reads or adds anything else to the logs besides what is shown above. Unhooking the floppy cable but leaving the FDC installed allows for a successful boot via TIPI from a cold start but only once. after that it produces the same results as above with the same type of log entries. I have tried both Myarc and TI FDC's. Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted April 12, 2021 Share Posted April 12, 2021 16 hours ago, atrax27407 said: Where are the TIPI EPROMs located? Hi, here is the homepage: https://www.jedimatt42.com/downloads.html Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 12, 2021 Author Share Posted April 12, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 12, 2021 Author Share Posted April 12, 2021 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. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 12, 2021 Share Posted April 12, 2021 FYI, I have push notifications off for everything in my life. I don't use the internet the way it is trending. ---- But, I do browse this sight regularly. ---- Looking at the log flows, in the failed boot attempts, the boot ROM doesn't appear to even be trying to make a request of the TIPI. The intermittent nature speaks to reading from un-initialized memory and consequently choosing a different code path. Are all the VDP bytes for the PAB cleared or explicitly set? Or anything else that influences a comparative jmp? I would be happy to review the boot ROM code and see if I can help. Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 12, 2021 Author Share Posted April 12, 2021 26 minutes ago, jedimatt42 said: FYI, I have push notifications off for everything in my life. I don't use the internet the way it is trending. ---- But, I do browse this sight regularly. ---- Looking at the log flows, in the failed boot attempts, the boot ROM doesn't appear to even be trying to make a request of the TIPI. The intermittent nature speaks to reading from un-initialized memory and consequently choosing a different code path. Are all the VDP bytes for the PAB cleared or explicitly set? Or anything else that influences a comparative jmp? I would be happy to review the boot ROM code and see if I can help. 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. 3 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 12, 2021 Share Posted April 12, 2021 The power-up routine triggers an interrupt that tells the TipiWatchDog service to shutdown the TipiService. The power-up code can be done before that interrupt has been processed on the PI. That kills the TipiService. The systemd linux service then takes a beat, and restarts the TipiService. Normally, if the TipiService is down, any attempt to make a request to it would just block. Until the service is back up, and able to respond. If your request is getting responded to by the previous instance of the TipiService, that then gets killed, I would expect hangs. The evidence would be in the log before the TIPI Ready log entry, as the latest TIPI Ready statement would come from the new instance. I'll still take a look. But seems like the Geneve might have been fast enough to get in there before that TipiWatchDog handles the reset. I can probably come up with a prescriptive delay, so it doesn't have to be arbitrarily long. I will look at the code you send (sent, cause that just happened ) 3 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted April 12, 2021 Share Posted April 12, 2021 update.... I put my HFDC back in and it boots every time and I know why! (homer moment coming...) Spoiler I had my gotek installed as DSK1 as usual. I created a disk image to get the new LOAD-MFM over on the HFDC and i left the image mounted! DOH! 1 4 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 12, 2021 Share Posted April 12, 2021 4 hours ago, 9640News said: @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. Most interesting. It will be helpful to have a definitive answer so that we can (also) address adding the proper TIPI powerup to the OS in the near future. Were you able to test the same scenario with a Myarc FDC in the system, to validate shift838's second example? Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 12, 2021 Author Share Posted April 12, 2021 10 minutes ago, InsaneMultitasker said: Most interesting. It will be helpful to have a definitive answer so that we can address adding the proper TIPI powerup to the OS in the near future. Were you able to test the same scenario with a Myarc FDC in the system, to validate shift838's second example? 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. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted April 12, 2021 Share Posted April 12, 2021 I've got another PEB coming in, not sure of condition yet,"works". I'll be able to put my ti-99/4A in it and the Geneve can have the known to work every time peb. Oops, will be needing a tipi for one of them.. and another raspberry pi 3.. and I'm (Waiting on the latest eprom)... should be here soon 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 13, 2021 Share Posted April 13, 2021 (edited) On 4/12/2021 at 11:27 AM, jedimatt42 said: The power-up routine triggers an interrupt that tells the TipiWatchDog service to shutdown the TipiService. The power-up code can be done before that interrupt has been processed on the PI. That kills the TipiService. The systemd linux service then takes a beat, and restarts the TipiService. Normally, if the TipiService is down, any attempt to make a request to it would just block. Until the service is back up, and able to respond. If your request is getting responded to by the previous instance of the TipiService, that then gets killed, I would expect hangs. The evidence would be in the log before the TIPI Ready log entry, as the latest TIPI Ready statement would come from the new instance. I'll still take a look. But seems like the Geneve might have been fast enough to get in there before that TipiWatchDog handles the reset. I can probably come up with a prescriptive delay, so it doesn't have to be arbitrarily long. I will look at the code you send (sent, cause that just happened ) After looking at the boot rom, and hearing the description of events, it seems like the TIPI ROM (not the boot rom) needs to be less async during powerup. I've applied this code, and it seems to allow my 4A TIPI to still function... low level logging seems to produce the sequence of events I want... then my gear all went to hell. The Flash chips I was using in the TIPI ROM socket seem to being failing after a couple flashes. My SAMS card is claiming to be active... when in TI BASIC... stupid stuff like that... The code change I made is here: https://github.com/jedimatt42/tipi/commit/fcae1d66e32637fee03c2f1e6dd838600c2f360f It asks the PI to dirty the RCIN port, then does the cru reset, then waits for the TipiService to zero the RCIN port again. ROM datecode will be today. The 12th. This doesn't cause any noticeable delay in 4A powerup time. The loop counters might need to be longer for the Geneve. Below is a portion of the listing... ROM address >42F0 is >0400, you might set that to >0800, and ROM address >4304 is also just >0400, and might want to be >0800... They were >0200, and I bumped them up... If you don't get a TIPI Ready in the tipi.log with every call to the powerup routine, then they need to be bigger. 0017 ; If the PI is alive, trigger it to dirty RCIN 0018 42E6 0201 20 LI R1,>F100 ; this is the brief reset echo for 42E8 F100 0019 ; synchronizing the ack counter 0020 42EA D801 38 MOVB R1,@TCOUT ; send that to the PI. 42EC 5FFD 0021 42EE 0202 20 LI R2,>0400 ; setup a limited loop 42F0 0400 0022 42F2 D060 34 ! MOVB @RCIN,R1 ; read the ack register from TIPI 42F4 5FF9 0023 42F6 0281 22 CI R1,>F100 ; 42F8 F100 0024 42FA 1302 14 JEQ crureset ; escape out of the limited retry loop 0025 42FC 0602 14 DEC R2 0026 42FE 16F9 14 JNE -! ; if we leave hear early, RCIN will be 0xF1 0027 ; and later we get to check that full reset 0028 ; happened by RCIN becoming 0x00 0029 0030 ; Trigger reset signal to RPi 0031 ; This kills the TipiService and restarts it asynchronously. 0032 crureset 0033 4300 1D01 20 SBO 1 ; turn on the second cru bit 0034 4302 0201 20 LI R1,>0400 4304 0400 0035 4306 0601 14 ! DEC R1 0036 4308 16FE 14 JNE -! 0037 0038 ; turn off the reset signal so RPi service can finish starting 0039 430A 1E01 20 SBZ 1 Note: I'm not in a position to test anything on a Geneve (or a 4A as of now either) Edited April 15, 2021 by jedimatt42 binary deleted to prevent spread of known bad software 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 13, 2021 Author Share Posted April 13, 2021 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 13, 2021 Share Posted April 13, 2021 I was using a SCSI that wouldn't boot due to timing issues. And an HRD to get around that with my Genmod Geneve. But those were only loaned to me and have been pulled and packaged up as they are requested back. I don't have a working floppy controller for it anymore either. So in its future it would be a TIPI only system. I guess while you are all active on this, I should set it up, and try. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 13, 2021 Author Share Posted April 13, 2021 @InsaneMultitasker it sounds like we may have another convert ? 9 minutes ago, jedimatt42 said: I guess while you are all active on this, I should set it up, and try. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 13, 2021 Share Posted April 13, 2021 @9640News There is a one-byte difference in the 0.98 and 1.00 EPROM that indicates (and I use this term loosely) whether the Geneve is Genmod or not. I do not know of any software that uses this byte for any detection purposes. The Geneve OS SCSI low level routines check check the byte to set up the SCSI data transfer method, however, it is a recent code addition based on the SCSI coding Michael and Harald added to the OS routines in '99. While this shouldn't affect Matt's Genmod system (sans SCSI), it will most likely impact any other Genmod+SCSI users, if such a combination still exists today. Maybe a new identifier is needed going forward. Just a thought. 2 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.