Geneve V0.99 Eprom

[+9640News]

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

[+FarmerPotato]

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.

[Shift838]

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..

[+InsaneMultitasker]

  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.

[Shift838]

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

[atrax27407]

Where are the TIPI EPROMs located?

[+InsaneMultitasker]

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.

[+9640News]

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.

[+InsaneMultitasker]

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.

[Shift838]

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.

 

 

 

 

 

 

[+Schmitzi]

16 hours ago, atrax27407 said:

Where are the TIPI EPROMs located?

 

Hi, here is the homepage: https://www.jedimatt42.com/downloads.html

 

 

[+9640News]

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.

 

 

[+9640News]

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.

[+jedimatt42]

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.

[+9640News]

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.

 

 

 

 

[+jedimatt42]

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 )

[Shift838]

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!

 

 

 

[+InsaneMultitasker]

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?

[+9640News]

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.

[GDMike]

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

 

[+jedimatt42]

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

[+9640News]

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

 

[+jedimatt42]

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.

[+9640News]

@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.

 

[+InsaneMultitasker]

@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.