Geneve V0.99 Eprom

[+9640News]

11 minutes ago, InsaneMultitasker said:

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

Hmmmm.  

 

Need a bit more information.  What does a positive test for a GenMod system do with the low level SCSI routines?  With a GenMod system, you can run all 0-wait state or 1-wait state depending upon the switchbox which the eprom test will not know the difference.  I already modified the number of pages tested so the eprom would be suitable for either a stock Geneve or Genmod system.  That byte would not be in the same location because I put the PAB's for all the devices up early on in the eprom code.  I could always move them, but then that would necessitate two eprom versions if there is going to be a low level SCSI issue.  I'm assuming for now, the PFM/PFM+ maintained the same location for that byte or maybe the code uses another byte detection routine???

 

I have to also comment that if a user has a SCSI in their system, they are not likely to boot from the TIPI since it would be slower, unless they wanted to move away from the V1.0 Knerr eprom.  

 

All things relatively easy to address.  Would the PDMA ON/OFF switch in AUTOEXEC address this issue?

 

Beery

 

 

 

[+InsaneMultitasker]

19 minutes ago, 9640News said:

Hmmmm.  

 

Need a bit more information.  What does a positive test for a GenMod system do with the low level SCSI routines?  With a GenMod system, you can run all 0-wait state or 1-wait state depending upon the switchbox which the eprom test will not know the difference.  I already modified the number of pages tested so the eprom would be suitable for either a stock Geneve or Genmod system.  That byte would not be in the same location because I put the PAB's for all the devices up early on in the eprom code.  I could always move them, but then that would necessitate two eprom versions if there is going to be a low level SCSI issue.  I'm assuming for now, the PFM/PFM+ maintained the same location for that byte or maybe the code uses another byte detection routine???

 

I have to also comment that if a user has a SCSI in their system, they are not likely to boot from the TIPI since it would be slower, unless they wanted to move away from the V1.0 Knerr eprom.  

 

All things relatively easy to address.  Would the PDMA ON/OFF switch in AUTOEXEC address this issue?

 

Beery

 

 

 

PFM doesn't maintain the byte because there are no Genmod Geneves with a PFM, and my updates do not affect the byte. 

The SCSI low level code uses WORD transfers on a non-Genmod Geneve and BYTE transfers on a Genmod Geneve.  See SCSI2\SCSIDMA2_S.  The Genmod detection routine is in SECTOR_S, near the end of the file.

 

 

[+9640News]

6 minutes ago, InsaneMultitasker said:

PFM doesn't maintain the byte because there are no Genmod Geneves with a PFM, and my updates do not affect the byte. 

The SCSI low level code uses WORD transfers on a non-Genmod Geneve and BYTE transfers on a Genmod Geneve.  See SCSI2\SCSIDMA2_S.  The Genmod detection routine is in SECTOR_S, near the end of the file.

 

 

OK, saw the code with the addresses.  That would be something that can be addressed.

 

 

[+9640News]

20 hours ago, jedimatt42 said:

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. tipi_geneve_2021-04-12.zip

 

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)

 

 

Mixed results.

 

No problem on a stock Geneve, and I can boot up with the 0.99 Beta eprom with this Geneve TIPI revision every time on a TIPI, or if the HFDC is present, it then boots from the HFDC.

 

However, on my PFM system, which the PFM doesn't offer a TIPI boot option anyways, I get a hang on a fresh PI bootup when I then turn on the Geneve.  If I cycle power on the PEBox, then it boots. I do not have any TIPI/PI access as the light stays on when I do a DIR.  That system has a SCSI, HFDC, TIPI, Memex setup for 504K, and a RS232.  That is on settings at >0400 and >0800.  In the log files, all I get is what is shown below.  Nothing after I type a DIR to get a Directory listing on the TIP shows up in the log files.

 

2021-04-13 20:44:07,291 TipiService : INFO     physical mode enabled
2021-04-13 20:44:07,291 TipiService : INFO     TIPI Ready
 

Every attempt to get a DIR results in a lockup with the TIPI light remaining on.

[+jedimatt42]

1 hour ago, 9640News said:

Mixed results.

 

No problem on a stock Geneve, and I can boot up with the 0.99 Beta eprom with this Geneve TIPI revision every time on a TIPI, or if the HFDC is present, it then boots from the HFDC.

 

However, on my PFM system, which the PFM doesn't offer a TIPI boot option anyways, I get a hang on a fresh PI bootup when I then turn on the Geneve.  If I cycle power on the PEBox, then it boots. I do not have any TIPI/PI access as the light stays on when I do a DIR.  That system has a SCSI, HFDC, TIPI, Memex setup for 504K, and a RS232.  That is on settings at >0400 and >0800.  In the log files, all I get is what is shown below.  Nothing after I type a DIR to get a Directory listing on the TIP shows up in the log files.

 

2021-04-13 20:44:07,291 TipiService : INFO     physical mode enabled
2021-04-13 20:44:07,291 TipiService : INFO     TIPI Ready
 

Every attempt to get a DIR results in a lockup with the TIPI light remaining on.

 

Ok, I'll see if I can refine it better. I saw one side effect which I thought was fishy before my system had a nervous breakdown. There is some very low level debugging I can turn on and I'll play with the lifecycle of the various services. 

 

Tonight, is just making room to be able to work on this stuff.

[+jedimatt42]

Ok, couldn't resist... got the 4A all on a table of it's own... narrowed down my problems to a failed TIPI-Peb board... must have static zapped it. All the other weirdness went away once that board was removed. 

 

Took the TIPI from my Geneve, and tested this change... https://github.com/jedimatt42/tipi/pull/149/files

 

After coaxing the TipiService to dirty the RCOUT, I needed to clear the TCOUT before triggering the service reset, so the TipiService wouldn't run passed setting RCOUT to 0x00 and then immediately ack the 0xF1 in TCOUT by setting RCOUT to 0xF1...  This could have caused a hang.

 

Increased the wait for the 'dirty' ack to 0x1000 loops, but it will return as soon as it sees the ack. Important bit is that it is not zero.  If the TipiService has crashed in communication, this will timeout, but RCOUT will not be zero, so things should recover.

 

Increased the cru reset loop to 0x0800... this may not have been necessary, but it is still a tiny amount of time. I think I was tricked into this because sometimes my failing TIPI board wouldn't map the ROM in. It's still a sound change. TipiWatchDog responds as an edge trigger anyway.

 

The wait for RCOUT to go to zero has no timeout. This should always happen. (unless the hardware is failing)

 

 

 

My next adventure will be to try this on the Genmod Geneve.

Edited April 15, 2021 by jedimatt42
binary deleted cause the wrong people are downloading it.

[+InsaneMultitasker]

3 hours ago, 9640News said:

However, on my PFM system, which the PFM doesn't offer a TIPI boot option anyways, I get a hang on a fresh PI bootup when I then turn on the Geneve

For reference , here is the PFM powerup routine.  I can't think of any reason for the hang, as there shouldn't be any other PFM DSR activity affecting the TIPI PEB.  (The comparison at >061a is testing the DSR version. The HFDC is revision >0B or higher, meaning a standard floppy controller at >1100 would not have its powerup executed. Probably a hack to keep some corcomp cards from taking over the system).

 

       LI   R12,CI                      >020C,>0F00        '....'         0604
CO     AI   R12,CH                      >022C,>0100        '.,..'         0608
       CI   R12,AE                      >028C,>2000        '.. .'         060C
       JEQ  CJ                          >1316              '..'           0610
       SBO  >00                         >1D00              '..'           0612
       CI   R12,DQ                      >028C,>1100        '....'         0614
       JNE  CK                          >1604              '..'           0618
       CB   @>4001,@CL                  >9820,>4001,>00CC  '. @...'       061A
       JL   CM                          >1A0C              '..'           0620
CK     CB   @>4000,@CN                  >9820,>4000,>00AA  '. @...'       0622
       JNE  CM                          >1608              '..'           0628
       MOV  @>4004,R9                   >C260,>4004        '.`@.'         062A
       JEQ  CM                          >1305              '..'           062E
       MOV  @AS(R9),R9                  >C269,>0002        '.i..'         0630
       JEQ  CM                          >1302              '..'           0634
       BL   *R9                         >0699              '..'           0636
       JMP  CM                          >1000              '..'           0638
CM     SBZ  >00                         >1E00              '..'           063A
       JMP  CO                          >10E5              '..'           063C

 

[+jedimatt42]

Is Beery's hang in PFM, or just with a PFM boot as the starting point?  Is it hanging later in SYSTEM-SYS? Does SYSTEM-SYS ever delegate to the TIPI ROM powerup routine? Or has that all been lifted into SYSTEM-SYS?

Edited April 14, 2021 by jedimatt42

[+jedimatt42]

Things booted on the Genmod Geneve w/Memex and just a TIPI at crubase >1800. 

[+9640News]

5 hours ago, InsaneMultitasker said:

For reference , here is the PFM powerup routine.  I can't think of any reason for the hang, as there shouldn't be any other PFM DSR activity affecting the TIPI PEB.  (The comparison at >061a is testing the DSR version. The HFDC is revision >0B or higher, meaning a standard floppy controller at >1100 would not have its powerup executed. Probably a hack to keep some corcomp cards from taking over the system).

 

 

Yeah, I couldn't think of a reason either.  I'll test Matt's new update tonight.

[+9640News]

5 hours ago, jedimatt42 said:

Is Beery's hang in PFM, or just with a PFM boot as the starting point?  Is it hanging later in SYSTEM-SYS? Does SYSTEM-SYS ever delegate to the TIPI ROM powerup routine? Or has that all been lifted into SYSTEM-SYS?

OK, there are two times in the PFM+ system that your first revision from Tuesday AM caused a hang.  Haven't tested this morning's change.

 

I should indicate that the Tuesday AM revision on a PFM system never allowed me to access the TIPI.

 

First hang was on a fresh reboot of the PI, then turning on the Geneve/PFM.  The system locked up.

 

Second hang, was if following the first  hang, I rebooted the computer without power cycling the PI, the system would boot from the PFM+.  When I would do a DIR on the TIPI to get a file listing, it would then lock up.

 

I will test the PFM+ system tonight with your Wednesday AM (in my timezone) when you posted the last update.

 

 

[+InsaneMultitasker]

10 hours ago, 9640News said:

Yeah, I couldn't think of a reason either.  I'll test Matt's new update tonight.

Perhaps still timing-related.  The PFM order of operations is similar but with the TIPI at the end of the sequence who knows for sure.  Sounds good on the testing. 

[+9640News]

19 hours ago, jedimatt42 said:

Ok, couldn't resist... got the 4A all on a table of it's own... narrowed down my problems to a failed TIPI-Peb board... must have static zapped it. All the other weirdness went away once that board was removed. 

 

Took the TIPI from my Geneve, and tested this change... https://github.com/jedimatt42/tipi/pull/149/files

 

After coaxing the TipiService to dirty the RCOUT, I needed to clear the TCOUT before triggering the service reset, so the TipiService wouldn't run passed setting RCOUT to 0x00 and then immediately ack the 0xF1 in TCOUT by setting RCOUT to 0xF1...  This could have caused a hang.

 

Increased the wait for the 'dirty' ack to 0x1000 loops, but it will return as soon as it sees the ack. Important bit is that it is not zero.  If the TipiService has crashed in communication, this will timeout, but RCOUT will not be zero, so things should recover.

 

Increased the cru reset loop to 0x0800... this may not have been necessary, but it is still a tiny amount of time. I think I was tricked into this because sometimes my failing TIPI board wouldn't map the ROM in. It's still a sound change. TipiWatchDog responds as an edge trigger anyway.

 

The wait for RCOUT to go to zero has no timeout. This should always happen. (unless the hardware is failing)

 

tipi_geneve_2021-04-13.zip 1.88 kB · 5 downloads

 

My next adventure will be to try this on the Genmod Geneve.

OK, I tested this version again with the PFM+.  MDOS did a clean boot .  Thought everything was great.  Went into GPL mode with Rompage.  Trying to load TIPI.TIPICFG resulted in a file not found. It is not recognizing things in GPL mode.

 

I made a few revisions to the counter loops changing both to >2000 without success and a few variations leaving one the same, and increasing/decreasing the other.  No luck with a PFM+ system.

 

Beery

 

[+InsaneMultitasker]

36 minutes ago, 9640News said:

OK, I tested this version again with the PFM+.  MDOS did a clean boot .  Thought everything was great.  Went into GPL mode with Rompage.  Trying to load TIPI.TIPICFG resulted in a file not found. It is not recognizing things in GPL mode.

 

I made a few revisions to the counter loops changing both to >2000 without success and a few variations leaving one the same, and increasing/decreasing the other.  No luck with a PFM+ system.

 

Beery

 

Does it still work if you place the original EPROM into your TIPI? 

[+9640News]

3 minutes ago, InsaneMultitasker said:

Does it still work if you place the original EPROM into your TIPI? 

Yes.  I'm able to boot with the HFDC, and if I pull the SD card from the DREM, it boots from the TIPI.  I can go into GPL mode with Rompage and load TIPI.TIPICFG with no issue.

 

Beery

[+InsaneMultitasker]

14 minutes ago, 9640News said:

Yes.  I'm able to boot with the HFDC, and if I pull the SD card from the DREM, it boots from the TIPI.  I can go into GPL mode with Rompage and load TIPI.TIPICFG with no issue.

 

Beery

Try loading the OS via the PFM menu (do not program from the menu) and see what happens. 

[+jedimatt42]

Chasing the loop counters in the TIPI card ROM is not going to have an effect. The values in there are already generous.

 

The symptoms now sound like a completely different problem.

 

Edited April 15, 2021 by jedimatt42

[+9640News]

9 hours ago, InsaneMultitasker said:

Try loading the OS via the PFM menu (do not program from the menu) and see what happens. 

That will be a test for tonight..... when I get home.

[+InsaneMultitasker]

3 hours ago, 9640News said:

That will be a test for tonight..... when I get home.

Sounds good. From your post #115, I couldn't tell which system you were re-testing, though it sounded as if you booted from the TIPI which leads me to believe it was not the PFM system.    My thinking is that the OS in the PFM might be affected or something is wrong with the TIPI card in that system, if indeed you restored the TIPI back to its original EPROM and no longer could access any of the TIPI drives. 

[+9640News]

23 minutes ago, InsaneMultitasker said:

Sounds good. From your post #115, I couldn't tell which system you were re-testing, though it sounded as if you booted from the TIPI which leads me to believe it was not the PFM system.    My thinking is that the OS in the PFM might be affected or something is wrong with the TIPI card in that system, if indeed you restored the TIPI back to its original EPROM and no longer could access any of the TIPI drives. 

Matt's last update worked fine on the non-PFM system.  On the PFM system, it had issues.  When I restored the February eprom, all was well.  It is not obvious to me what the issue would be.  I did look through the first source file for the eprom and there are various CRU bits being set at the hardware level which made me wonder whether it matters to the TIPI over in GPL mode.  It is a long stretch.

[+InsaneMultitasker]

8 minutes ago, 9640News said:

Matt's last update worked fine on the non-PFM system.  On the PFM system, it had issues.  When I restored the February eprom, all was well.  It is not obvious to me what the issue would be.  I did look through the first source file for the eprom and there are various CRU bits being set at the hardware level which made me wonder whether it matters to the TIPI over in GPL mode.  It is a long stretch.

OK.  If I am available this weekend, I'll program an updated TIPI EPROM and test with my PFM+ Geneve to confirm with a second system.  The PFM BIOS isn't much different than a Geneve boot EPROM, though some timing may be different.   GPL ROMPAGE forces a powerup of all devices, so even if the PFM had an issue at startup, rompage mode should still work.  Neat problem  

 

[GDMike]

I received my beta eprom and at first I couldn't figure out what was going on with the no video. I was chasing my hdmi from tipi cable for 5mins..duhh...

Ok. I got a swan photo but I can't boot. I replaced the sys sys and load sys files and I got the same error. Does it have to have the latest mdos? I couldn't boot from the old MDOS at all.

[+9640News]

7 minutes ago, GDMike said:

I received my beta eprom and at first I couldn't figure out what was going on with the no video. I was chasing my hdmi from tipi cable for 5mins..duhh...

Ok. I got a swan photo but I can't boot. I replaced the sys sys and load sys files and I got the same error. Does it have to have the latest mdos? I couldn't boot from the old MDOS at all.

What controller card(s) do you have in your system?

 

If you are using the V0.99 eprom, then the filename must be SYSTEM-SYS.

 

If your controller card is a HFDC, then you must place LOAD-MFM at HDS1.DSK1.LOAD-MFM  and if booting from HFDC floppy, it should be DSK1.LOAD-MFM.

 

If you have an IDE controller, then files are at IDE1.LOAD-IDE and IDE1.SYSTEM-SYS

 

If you have a SCSI controller, then files are at SCS1.LOAD-SCS and SCS1.SYSTEM-SYS

 

If with a TIPI card, then files are at DSK0.LOAD-TIP and DSK0.SYSTEM-SYS , or as TIPI.LOAD-TIP and TIPI.SYSTEM-SYS,  or once booted, as TIP1.LOAD-TIP and TIP1.SYSTEM-SYS

 

 

[+9640News]

Also, I think you are following it, but it is questionable depending upon your other cards, whether you can immediately boot from the TIPI without a TIPI eprom upgrade.  Some people can boot, others can't at the moment.  Still working out things with TIPI eprom.

[GDMike]

24 minutes ago, 9640News said:

Also, I think you are following it, but it is questionable depending upon your other cards, whether you can immediately boot from the TIPI without a TIPI eprom upgrade.  Some people can boot, others can't at the moment.  Still working out things with TIPI eprom.

I'm using a gotek drive as

disk 1( logical 0). And a regular floppy as drive 2.

Geneve tries booting from gotek, then errors, and something screws up the folders and I can't switch folders. So I have to restore from backup and then I'm able to switch folders on the gotek again.

I'll try (floppy method one more time).

I'm not understanding how to setup the tipi boot procedure yet.