Jump to content
IGNORED

WHT SCSI and Genve/Genmod Geneve boot issues


jedimatt42

Recommended Posts

2 hours ago, jedimatt42 said:

 

I think my issue may be more related to the SCSI device... during one of the reboots today, the thing actually booted off the SCSI card... was reproducable a couple times after a warm boot... CTRL-SHIFT-SHIFT    But then trying to reproduce from cold, then warm, wasn't possible.  

-M@

If your "G" has the 1.6 upgrade that looks like the card in the pic above and you are able to boot from the SCSI BOOT EPROM intermittently I agree that the storage setup/device you are using is the next place to look. I've never tried your setup myself as we mostly just used SCSI 1 internal hard drives, SyQuest EZ-135 and ZIP drives with the cards during that 1998 - 2004 period. Also SCSI 1 internal CD ROM players were used when Wolfgang's CD Commander software came on the scene.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Ksarul said:

Timing issue? Maybe it is just a hair too slow (or a hair too fast) for the system to register that things are right?

Might be on to something; though with Genmod disabled I would have thought the card would boot fine with the timing reverted to 'standard' speed.  

 

The MDOS DSR uses a few timing loops with the following EQUates: 

 

(umm, what happened to the ability to select a different font, like courrier??)

 

MDOS SOURCE:

* TIMING EQUATES THAT MAY NEED ADJUSTING
* *6 to slow down for Geneve
RSTCNT EQU  200*6            RESET DELAY COUNT
ARBCNT EQU  1*6              ARBITRATION DELAY COUNT 2.2us
BSCNT  EQU  2*6              BUS SETTLE DELAY COUNT  600ns
BCCNT  EQU  2*6              BUS CLEAR DELAY COUNT   600ns
BSYCNT EQU  200*6            BSY* WAIT DELAY COUNT   200ms

 

The SCSI DSR bank 7 routine source shows the following:
* TIMING EQUATES THAT MAY NEED ADJUSTING

RSTCNT EQU  200               RESET DELAY COUNT
ARBCNT EQU  1                 ARBITRATION DELAY COUNT 2.2us
BSCNT  EQU  2                 BUS SETTLE DELAY COUNT  600ns
BCCNT  EQU  2                 BUS CLEAR DELAY COUNT   600ns
BSYCNT EQU  200               BSY* WAIT DELAY COUNT   200ms

  • Like 1
Link to comment
Share on other sites

2 hours ago, InsaneMultitasker said:

(umm, what happened to the ability to select a different font, like courrier??)

Probably the post editor got reset to defaults after I upgraded the forum recently.  So, I'll have to go back and make those changes again.  The editor has three sets of settings for desktop, tablet and mobile, and I can specify which editor icons are available for each.  This time I'll take screenshots after I make the changes in case I have to do so again.  Will fix that early in the upcoming week.

 

 ..Al

  • Like 4
  • Thanks 2
Link to comment
Share on other sites

6 hours ago, InsaneMultitasker said:

Might be on to something; though with Genmod disabled I would have thought the card would boot fine with the timing reverted to 'standard' speed.  

 

The MDOS DSR uses a few timing loops with the following EQUates: 

 

(umm, what happened to the ability to select a different font, like courrier??)

 

MDOS SOURCE:

* TIMING EQUATES THAT MAY NEED ADJUSTING
* *6 to slow down for Geneve
RSTCNT EQU  200*6            RESET DELAY COUNT
ARBCNT EQU  1*6              ARBITRATION DELAY COUNT 2.2us
BSCNT  EQU  2*6              BUS SETTLE DELAY COUNT  600ns
BCCNT  EQU  2*6              BUS CLEAR DELAY COUNT   600ns
BSYCNT EQU  200*6            BSY* WAIT DELAY COUNT   200ms

 

The SCSI DSR bank 7 routine source shows the following:
* TIMING EQUATES THAT MAY NEED ADJUSTING

RSTCNT EQU  200               RESET DELAY COUNT
ARBCNT EQU  1                 ARBITRATION DELAY COUNT 2.2us
BSCNT  EQU  2                 BUS SETTLE DELAY COUNT  600ns
BCCNT  EQU  2                 BUS CLEAR DELAY COUNT   600ns
BSYCNT EQU  200               BSY* WAIT DELAY COUNT   200ms

 

So, in theory I could assemble a more tolerant DSR rom...  

 

Well, good thing I have this week off... :)

 

-M@

 

  • Like 1
Link to comment
Share on other sites

FWIW a solid state storage solution the SCSI2SD device has proven successful. I have recently acquired this version 6.0 device for my SNUG system and so far it's working no problem but as with all things TI/Geneve your mileage may vary. Can be powered 5v or USB. I added the 25 pin SCSI 1 to 50 pin adapter.

IMG-4708.jpgIMG-4709.jpg

Link to comment
Share on other sites

8 hours ago, jedimatt42 said:

Oops, the source on whtech is for DSR version 1.5... Is the source for 1.6 floating around somewhere on the open internet? 

 

-M@

Have you checked the SNUG site? If it's not listed there send Harald Glaab an e-mail as he might be able to point you in the right direction.

Link to comment
Share on other sites

23 minutes ago, Swim said:

FWIW a solid state storage solution the SCSI2SD device has proven successful. I have recently acquired this version 6.0 device for my SNUG system and so far it's working no problem but as with all things TI/Geneve your mileage may vary. Can be powered 5v or USB. I added the 25 pin SCSI 1 to 50 pin adapter.

IMG-4708.jpgIMG-4709.jpg

 

 

Yeah, the ACARD SCSI TO CF works fine on the 4A and Geneve, except during the Geneve's BOOT ROM... so mileage with this GenMod Geneve varies a ton. 

 

-M@

  • Like 1
Link to comment
Share on other sites

4 minutes ago, jedimatt42 said:

 

I would not have imagined that applicable... the WHT card uses the same DSR as the SNUG ASCSI?

 

-M@

There was a working relationship between WHT and SNUG that resulted in the 1.6 upgrade for the WHT series and the ASCSI2. I'm not familiar with developments post the 1.6 upgrade and Gazoo's SCSI boot and MDOS tweek for PDMA. 

  • Like 1
Link to comment
Share on other sites

It would be nice if Harald or someone else has a full, working set of DSR source that could be posted publicly for situations just like this. 

 

That said, I believe I have v1.5 DSR code sans the low level bank routines and a copy of the v1.6 DSR low level code - though if memory serves, it wouldn't fully re-assemble the last time I tried.   The snippet I shared earlier is from a troubleshooting session; MDOS 6.70 and below have no awareness of the SCSI card interrupt and so with certain operations, if the SCSI card generates an interrupt the system will freeze.  Anyway, I'll look through my files for the DSR code during the next few weeks if it isn't obtainable elsewhere.

  • Like 2
Link to comment
Share on other sites

5 minutes ago, InsaneMultitasker said:

It would be nice if Harald or someone else has a full, working set of DSR source that could be posted publicly for situations just like this. 

 

That said, I believe I have v1.5 DSR code sans the low level bank routines and a copy of the v1.6 DSR low level code - though if memory serves, it wouldn't fully re-assemble the last time I tried.   The snippet I shared earlier is from a troubleshooting session; MDOS 6.70 and below have no awareness of the SCSI card interrupt and so with certain operations, if the SCSI card generates an interrupt the system will freeze.  Anyway, I'll look through my files for the DSR code during the next few weeks if it isn't obtainable elsewhere.

I agree, I also understand the limits of today's SNUG. They got overwhelmed by the USA market for the SGCPU series. They were not that many people to begin with and certainly not in existence as a business. I seem to recall one SNUG member getting over a hundred e-mails in one day. Some wound up burned out and I'm not sure how many members make up the club today or if the club still meets. I wish SNUG ASCSI2 DSR code weren't proprietary and could be made available to trusted TIer's. I have an ASCSI2 sitting here that I got for repair and about 3 WHT "G," which is also proprietary, with fried programmable logic needing repair. At one point I was told I would get some PLD's in a shipment of the EVPC2 cards when they came out but that shipment never came to pass. I still have some Lattice IspLSI 2064A chips I ordered for the "G" cards at the time. My last contact with SNUG was when I sold the remaining SNUG SPVMC stock I had in the USA here on AA.

Link to comment
Share on other sites

Michael identified a bug in GPL where the pagemap for speed 1 is not updated properly if you choose another speed first (i.e., choose speed 5, ENTER gpl, shift-shift-ctrl to return to the gpl menu, select speed 1, enter GPL again).  If you select speed 1 first you are OK for that session. 

 

During review of this bug (oversight?) we confirmed that GPL Speed 1 enables a wait state via CRU bit at 0x1efe.  Speeds 2,3,4,5 disables the wait state.  Michael documented related info in ninerpedia:

 

https://www.ninerpedia.org/wiki/Geneve_GPL_Interpreter

https://www.ninerpedia.org/wiki/Geneve_CRU_definitions

 

Link to comment
Share on other sites

I don't expect I'll ever hear back from SNUG regarding my request for the source... but we do have the Geneve boot rom source running around... 

 

Seems that in theory, the boot rom should/could clear the external waitstate cru bit, to enable the waitstate generation for executing in the DSR/peb space...   I'm not sure how that interacts with the zero-wait-state switch for the gen-mod...  I've assumed that was about controlling the CPU generated wait-state, not the external one... or does it control both?

 

-M@

Link to comment
Share on other sites

8 minutes ago, jedimatt42 said:

I don't expect I'll ever hear back from SNUG regarding my request for the source... but we do have the Geneve boot rom source running around... 

 

-M@

I have source code for the original Geneve eprom with the swan that boots from the Myarc HFDC.  It should be floating out there, but if someone needs it, give me a shout.  I'm pretty sure it is also on the MAME HD image folks got from me as well.  

Link to comment
Share on other sites

13 minutes ago, jedimatt42 said:

 I've assumed that was about controlling the CPU generated wait-state, not the external one... or does it control both?

The CPU cannot create wait states. Do you mean the Gate Array?

 

Edit: The 9995 CPU can create wait states, but only as a fixed configuration (pulling down READY on reset) until the next reset. This is used in the 99/8.

Edited by mizapf
Link to comment
Share on other sites

6 minutes ago, mizapf said:

The CPU cannot create wait states. Do you mean the Gate Array?

 

Edit: The 9995 CPU can create wait states, but only as a fixed configuration (pulling down READY on reset) until the next reset. This is used in the 99/8.

Clearly I misunderstand the pages on Ninerpedia when reconciling with what I think I know about the 9995.

 

The question still stands: what does the physical waitstate switch on a genmod Geneve control?

 

-M@

Link to comment
Share on other sites

Typically, for all accesses except SRAM/SRAMX (32K expansion), the Gate Array pulls down the READY line towards the PAL. This would mean that for all accesses to memory on the Memex, you would have 1 wait state.

 

The switch, as far as I understood, inhibits the READY low signal from the Gate Array. Thus, the READY=0 does not reach the PAL, and it is not propagated to the CPU.

 

(This is what I am currently working on in the MAME emulation. Previously I did it according to some theory what it would take to realize the Genmod, and now I try to understand what is really going on. ? )

 

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...