Jump to content
IGNORED

TI disk controller DSR


Recommended Posts

I looked at nouspikel and found this.

 

* All routines assume that R12 contains the disk controller card's CRU 
* and that the card has been turned on.
       LI   R12,>1100     Disk controller CRU
       SBO  0             Must be on to talk to the FDC

I wonder if I can test this with my RS232 Forth?  Standby...

 

 

  • Like 1
Link to comment
Share on other sites

Posted (edited)
7 minutes ago, TheBF said:

I looked at nouspikel and found this.

 

* All routines assume that R12 contains the disk controller card's CRU 
* and that the card has been turned on.
       LI   R12,>1100     Disk controller CRU
       SBO  0             Must be on to talk to the FDC

I wonder if I can test this with my RS232 Forth?  Standby...

 

 

if you want to directly talk to the FDC without using the DSR you can, you are right the first two lines will enable the card at the >4000 space (of course all other cards have to be disabled for this to work), and then the FDC is memory mapped in at the bottom of the DSR space around the >5FF0 area, with registers for FDC controller. -- Of course remember any code you write that directly uses the FDC will only work on the matching controller, be it TI, or CorComp, or Myarc.

Edited by Gary from OPA
  • Like 3
Link to comment
Share on other sites

Seems to work.  I tried loading a file after DISKOFF was run and the system hangs.

Without DISKOFF it loaded the file normally. 

 

Who knew a 55 year old language could be so useful? :) 

 

 

 

COM1 - Tera Term VT 2024-07-05 3_26_04 PM.png

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Thanks for testing. I love how simple it is to make such tests in Forth. It's a whole involved process under the psystem (enter assembly source code with editor, assemble, create test program, compile it, and finally link it to the assembly routine 😅).

Now is the DSR still visible when an SBO 0 is issued?

I'm essentially trying to hide the TI controller's DSR from the pcode card so it only sees the TIPI drives. The pcode card by default will scan the entire CRU range for active disk controller DSR's and assign PCB's (peripheral control blocks) for each drive found in VDP RAM. The problem here is that the Editor barely fits in VDP RAM with only the TI controller present, so when we add the TIPI drives, it runs out of stack space and crashes. My plan is to try and disable the TI controller's DSR when the SYSTEM.STARTUP file is run at startup, but this may still not work because the DSR scan happens before the startup file is run (obviously) and it is likely that the PCB's are not adjusted once the TI controller DSR is disabled. I'll test it out today and see if it works or not...

  • Like 4
Link to comment
Share on other sites

First step under emulation: I am able to disable the disk DSR. Next step is to test on real hardware with a TIPI in place.

 

;disable ti controller's dsr
;usage: tidsroff

        .proc    tidsroff
        .def     pmeret
        mov      r12,@pmeret      ;save the pme pointer
        li       r12,1100h       ;cru address of ti disk controller
        sbo      0               ;turn of dsr
        mov      @pmeret,r12     ;restore the pme pointer
        b        *r11

pmeret  .word

        .end

 

  • Like 4
Link to comment
Share on other sites

2 hours ago, Vorticon said:

Thanks for testing. I love how simple it is to make such tests in Forth. It's a whole involved process under the psystem (enter assembly source code with editor, assemble, create test program, compile it, and finally link it to the assembly routine 😅).

Now is the DSR still visible when an SBO 0 is issued?

I'm essentially trying to hide the TI controller's DSR from the pcode card so it only sees the TIPI drives. The pcode card by default will scan the entire CRU range for active disk controller DSR's and assign PCB's (peripheral control blocks) for each drive found in VDP RAM. The problem here is that the Editor barely fits in VDP RAM with only the TI controller present, so when we add the TIPI drives, it runs out of stack space and crashes. My plan is to try and disable the TI controller's DSR when the SYSTEM.STARTUP file is run at startup, but this may still not work because the DSR scan happens before the startup file is run (obviously) and it is likely that the PCB's are not adjusted once the TI controller DSR is disabled. I'll test it out today and see if it works or not...

ah. ok. i thought you were trying to access the TI FDC directly. --- Only other solution if the software disable doesn't work, is to mod the card hardware wise, add a physical switch to the FDC so its not there when you power up into P-Code mode, you could tie it to the physical switch of the P-Code so when you enable the P-Code card, you physically disable the FDC at the same time. -- I want to look at modding the P-Code DSR myself, edit the power-up system, so I can have the P-Code card on at all times, and enter it via a CALL, instead of needing the hardware enable/disable switch. -- Has the P-Code DSR source code ever been published? -- So many things I want to improve on P-Code, I have two cards and barely use them, would be nice to also have a real 80col screen when using the F18A or v9938 as well.

Link to comment
Share on other sites

1 hour ago, Gary from OPA said:

ah. ok. i thought you were trying to access the TI FDC directly. --- Only other solution if the software disable doesn't work, is to mod the card hardware wise, add a physical switch to the FDC so its not there when you power up into P-Code mode, you could tie it to the physical switch of the P-Code so when you enable the P-Code card, you physically disable the FDC at the same time. -- I want to look at modding the P-Code DSR myself, edit the power-up system, so I can have the P-Code card on at all times, and enter it via a CALL, instead of needing the hardware enable/disable switch. -- Has the P-Code DSR source code ever been published? -- So many things I want to improve on P-Code, I have two cards and barely use them, would be nice to also have a real 80col screen when using the F18A or v9938 as well.

I'm not aware that the pcode DSR has ever been published. And yes, my other option was to simply put a switch on the controller's power regulator to physically turn it off when not needed.

 

The pcode card can be turned on and off in software, so one option is to keep the card's switch on all the time. On first boot it would go into the psystem, where you can just turn it off as in the code below then do a soft reset of the console which should get you into a normal boot, theoretically. Seems to me though that it's just easier to turn the switch on/off as needed.

 



pcodeon li      r12,1f00h       ;activate the pcode card
        sbo     0
        mov     @pmeret,r12     ;retrieve the pme pointer
        b       *r11
        
pcodoff mov     r12,@pmeret     ;save the pme pointer
        li      r12,1f00h       ;deactivate the pcode card
        sbz     0
        b       *r11

 

As for 80 columns, you can redirect input/ouput to an external serial terminal connected to the TI via the serial port. The psystem is all text based, so that works quite well, but obviously you lose the ability to use the TI-centric units...

  • Like 1
Link to comment
Share on other sites

@Vorticon I might be misunderstanding the intent here, but the instruction SBO 0 will "turn on" the device at CRU address >1100.  The EPROM at >4000 will be "visible" as a result.  Conversely, the instruction SBZ 0 will "turn off" the device and the EPROM will not be "visible" at >4000.   The only way that I know to ensure a card is inactive via software is for the loaded program to never turn it on - neither directly nor through a system call.  In the PCODE system, I seem to recall from @apersson850 past comments that the devices are enumerated/polled at startup.  Maybe the device list could be modified to exclude the TI FDC and free up the memory, without resorting to a hardware switch.  

3 hours ago, TheBF said:

Seems to work.  I tried loading a file after DISKOFF was run and the system hangs.

Without DISKOFF it loaded the file normally

It seems to me that since DISKOFF is enabling the controller card at >1100 via SBO 0, and the DSRLNK typically starts its scan at >1000, the DSRLNK routine is incorrectly finding a valid card at >1000, and thus has a conniption fit when it tries to perform the IO using the wrong address.  Without DISKOFF, the DSRLNK device scan works as intended, DSRLNK finds the controller card at >1100, and all is well when IO is requested.  

 

Except for cases where the programmer is tracking what is happening and knows there will be no conflicts with concurrent card usage, only one peripheral card should ever be turned on/made visible at a time.  All peripheral cards should be "off" before entering a DSRLNK-related routine, including most routines that cache the CRU address for re-entry.  

  • Like 2
Link to comment
Share on other sites

1 hour ago, InsaneMultitasker said:

 I might be misunderstanding the intent here, but the instruction SBO 0 will "turn on" the device at CRU address >1100.  The EPROM at >4000 will be "visible" as a result.  Conversely, the instruction SBZ 0 will "turn off" the device and the EPROM will not be "visible" at >4000. 

You are correct. It should indeed be SBZ 0. That said disabling the DSR that way seems to do absolutely nothing on real hardware under the psystem. I wonder if the psystem is bypassing the DSR and talking directly to the FDC? In any case, the only option seems to be a hardware switch. I'm assuming that the DSR scanning startup code is in ROM and not modifiable...

 

Link to comment
Share on other sites

3 hours ago, InsaneMultitasker said:

@Vorticon I might be misunderstanding the intent here, but the instruction SBO 0 will "turn on" the device at CRU address >1100.  The EPROM at >4000 will be "visible" as a result.  Conversely, the instruction SBZ 0 will "turn off" the device and the EPROM will not be "visible" at >4000.   The only way that I know to ensure a card is inactive via software is for the loaded program to never turn it on - neither directly nor through a system call.  In the PCODE system, I seem to recall from @apersson850 past comments that the devices are enumerated/polled at startup.  Maybe the device list could be modified to exclude the TI FDC and free up the memory, without resorting to a hardware switch.  

It seems to me that since DISKOFF is enabling the controller card at >1100 via SBO 0, and the DSRLNK typically starts its scan at >1000, the DSRLNK routine is incorrectly finding a valid card at >1000, and thus has a conniption fit when it tries to perform the IO using the wrong address.  Without DISKOFF, the DSRLNK device scan works as intended, DSRLNK finds the controller card at >1100, and all is well when IO is requested.  

 

Except for cases where the programmer is tracking what is happening and knows there will be no conflicts with concurrent card usage, only one peripheral card should ever be turned on/made visible at a time.  All peripheral cards should be "off" before entering a DSRLNK-related routine, including most routines that cache the CRU address for re-entry.  

Good point.  I had to take off for the evening so I couldn't retest. My mistake with not trying SBZ.  

 

Link to comment
Share on other sites

So I clipped the ground connection for both the voltage regulators on the card (7805 and 7812), hooked them up to one pole of a switch with the other pole directly connected to ground. This should essentially power off the card when the switch is off.

20240707_201627.thumb.jpg.c55f939eacb66d59a021fc410581929d.jpg

 

Or does it? With the switch off, the drives still spin when I attempt to load something from disk although I do end up with a device error eventually. This should not happen. What am I missing? 

I wonder if I have a bridge on the 7805 between the ground wire and ground pin. Would having only the 7805 powered but not the 7812 explain what I am observing? I won't be able to test the connection again till later tonight.

 

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, jedimatt42 said:

You shouldn't switch ground, you should switch voltage in, if you use this approach. 

 

For many regulators the tab you screw to the PCB is also ground.

Why not?

Link to comment
Share on other sites

40 minutes ago, HOME AUTOMATION said:

Without a return path, it would behave more passively, like a series connected diode/resistor circuit.:ponder:

I have a vague idea of you mean by that. Would that explain the observed behavior?

Link to comment
Share on other sites

30 minutes ago, InsaneMultitasker said:

I would think the better route is to disable the card via logic selection line(s) versus having an unpowered chips/card on the peb bus.  The Horizon ramdisk is a card that does the former.  @Ksarul may have an idea or two.  

I'm all ears! But as far as having an unpowered card on the bus, doesn't the pcode card do just that when turned off?

Link to comment
Share on other sites

2 hours ago, Vorticon said:

Why not?

In voltage regulators, ground is not really ground as you think of it being.  There are still a number of passive paths from input to output.

7805-block-schematic.png.2f8395d6b15fcbd7f2ba291cc8c24a7e.png

  • Like 3
Link to comment
Share on other sites

7 hours ago, Vorticon said:

I'm all ears! But as far as having an unpowered card on the bus, doesn't the pcode card do just that when turned off?

A chip without power connected to the data and address busses is going to exhibit some kind of undocumented effect on the signal lines. They are not built for that. 

There are things called **tri-state buss drivers that let the input and/or output pins go "high-impedance", in effect, not touching the the signal lines electrically. 

The 74xx245 chips on the disk card are such chips so we just need to know what bits control them. 

 

 

**Not to be confused with a public transportation employees who are into threesomes.   

  • Like 5
Link to comment
Share on other sites

Posted (edited)

There will be a single pin on the disk controller card that controls whether the card is visible to the system or not - it's basically the output of the CRU on/off signal. Switching on that pin would be safer than powering off the card - which probably won't work due to the chips still being attached to the I/O bus.

 

I think I'd focus on CRU bit 0 from the 74LS259, as that's the on/off bit. If you switched that to either be connected normally, or pulled via a resistor, you should be able to disable the card. I would think you would pull down to ground via 1k or so, but unusually Theirry Nopuspikel's page doesn't include a schematic, and apparently there's some custom logic handling the interface. I'm not entirely sure if low or high indicates on here. I AM ALSO NOT SURE WHICH PIN IS BIT 0. (You could identify the pin if you can see which one triggers the LED).

There's a second gotcha with disabling the FDC - if you boot with it disabled, then enable it later, accessing anything will likely crash. The FDC is not tolerant of not having its buffers set up in VDP by the reset code. if you reset first, then disabled it at the master title screen, that might work. But you may hit similar issues if anything tries the equivalent of CALL FILES - I had thought that TIPI lets the FDC handle that if it's installed.

Edited by Tursi
  • Like 2
Link to comment
Share on other sites

Posted (edited)

Reviewing the schematic of the ti fdc the best way I think to disable it is to add a switch to the PCBenable line going to the PAL that does all the decode logic.

 

That would be pin 9 on the u18 custom logic chip. Normally it is always HIGH so bringing that pin LOW to ground should make the card 100% invisible to the system.

 

Now, on the P-CODE card they have the switch going thru some caps/resistors and a double OC buffer to de-couple the switch to remove any bounce and to make sure there is no temporarily connection between 5volts and ground incase the user toggles the switch while the system is on.

 

But, you should be safe enough on the FDC if you just make sure only to use it when power is off or install a "break before make" switch or 3 position switch so there is a middle do totally nothing position between the on and off sides to separate signals fully  when switching between the PCBEN high and pulled to low ground.

Screenshot_20240709-021124.png

Edited by Gary from OPA
  • Like 1
  • Thanks 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...