Localtalk HSKo, HSKi and GBi

[twelvetone12]

Which connect to DTB, CTS and DCD respectively on the SCC. Does anybody know if they are used by the localtalk driver? In "Inside Appletalk", appendix A-4, there is a schema of the connections to the connection module, and these three signals seem not used, but I could not find any documentation. My guess is that they are used only in rs232 or GeoPort mode and not localtalk, but if anybody has more insight it would be appreciated!

 

[cheesestraws]

As far as I know, they're not used at all for LocalTalk.

 

[twelvetone12]

Ok, I want to use them to try to "see" the AirTalk status via software, I'm not sure if I actually can since the port will be used by appletalk. I also have a couple "spare" signals that go though the power manager and I will have some jumpers to play around.

 

[cheesestraws]

Warning: this post is a guess . My bet would be to use DCD.

The SCC manual says about DCD:


"General purpose input pins" sounds like what we need. Now, I don't think you'll be able to read this via the AppleTalk driver but don't forget that the SCC's registers are memory mapped. So I think you can peer into read registers without interfering with the workings of the AppleTalk driver, and what you want is in read register 0.

 

[twelvetone12]

Don't worry I'm guessing a lot here too
Yes that was my plan, in theory I should also be able to play with DTR so I should be able to reset the esp. My backup is a couple of input lines (modem busy, ring detect, modem inserted, all inputs unfortunately) that go to the power manager chip, and can be read with a PMop call. But for those I'm not sure if they will have side effects, like ring detect could wake the machine from sleep and busy prevent it to sleep. It will be fun to see

 

[dougg3]

I want to say that the Farallon EtherWave Printer Adapter uses the HSKi pin as a clock for its super high speed mode when you have the full driver installed on your Mac, but the driver had to do special magic to enable the SCC to recognize it. That's the closest I've seen to any of those pins used for LocalTalk, but even then, it wasn't really "LocalTalk" anymore per se.

 

[joevt]

There's a few ways to clock the SCC.
- RTxC - can be switched between external GPi and internal 3.672 MHz clock. I don't remember if the GPi on my Macs allowed this.
- TRxC - from external HSKi
- DPLL - digital phase locked loop from RXD. I don't remember trying this.
- Baud Rate Generator - uses a baud rate generator constant which is clocked by either RTxC or PCLK. The PCLK varies between different Mac models so it's not a good choice for super high speed modes unless you have two Macs that can match (perhaps by using different BRG constants to make differing PCLKs equal). I think 22 MHz was from a B&W G3.

The clock can be further divided by X1, X16, X32, X64. Asynchronous modes require X16 or greater. X1 is used for synchronous modes.

TRxC can be used to output the clock from XTAL Output, Transmit Clock, BR Generator Output, or DPLL Output. I don't remember if that actually worked on my Macs (LC, Power Mac 8600, B&W G3).

I used the SCC to do communication to a PlayStation Multitap with multiple memory cards and controllers at ≈1MHz externally clocked (555 timer with potentiometer). I used basic logic chips and flip-flops to do the translation (no microcontroller). It had to transmit bytes to receive bytes.

 

[cheesestraws]

Yes: but this thread isn't about externally clocking the SCC, it's about sending a "is it working" bit through to software through the SCC. (Even though both those posts are very interesting in and of themselves)

 

[twelvetone12]

I tried this on port A with Appletalk and sadly it crashed almost instantly, port B works. My guess is that, since I need to modify the control register, I mess with what the appletalk driver is doing. Do you think I could quickly turn off interrupts, do my thing, and restore them? or is it too brutal?

EDIT: after more tinkering I'm not sure I completely trust the MacTech article I found that talks about SCC, I will study the scc manual and report back...

 

[twelvetone12]

Turns out I'm just dumb I thought that SCCRd and SCCWr in THINK C were pointers, so this would be true

*SCCRd = <offset of the scc>

while they are not pointers, just "regular" variables, so

SCCRd = <offset of the scc>

for some reason printf would not print the address of these variables, so I did not figure it out until I inspected it with the debugger.
But the good news is, it seems I can read CTS and DCD and manipulate DTR without crashing AppleTalk! Tomorrow more tests

 

[joevt]

Turns out I'm just dumb I thought that SCCRd and SCCWr in THINK C were pointers, so this would be true

*SCCRd = <offset of the scc>

while they are not pointers, just "regular" variables, so

SCCRd = <offset of the scc>

for some reason printf would not print the address of these variables, so I did not figure it out until I inspected it with the debugger.
But the good news is, it seems I can read CTS and DCD and manipulate DTR without crashing AppleTalk! Tomorrow more tests

How are they defined in Think C? I don't see how a regular variable can get the contents of low memory variables.

In Think Pascal, they are constants in SysEqu.p

SCCRd = $1D8;                   {[GLOBAL VAR] SCC read base address
   SCC base read address [pointer]}
SCCWr = $1DC;                   {[GLOBAL VAR] SCC write base address
   SCC base write address [pointer]}

So I think you would access them like this:

VAR
    scc : Ptr;
BEGIN
   scc = Handle(SCCRd)^;

In more modern Apple Universal Interfaces and Headers, there exist low memory accessor functions. In C, you would use them like this:

Ptr scc = LMGetSCCRd();

 

[twelvetone12]

I think THINK C is doing some magic here... SCC* are defined in SysEqu.h which seems normal:

SCCRd = 0x1D8, /*[GLOBAL VAR] SCC read base address SCC base read address [pointer]*/

And then in LowMem.h which seems... strange c:

Ptr SCCRd : 0x1D8;

I found a terse explanation in the manual:


My guess it that it's some sort of extension they have? It is handy, but absolutely non obvious!

 

[cheesestraws]

Yes, I think this is Think C magic. A bit odd and startling, but not unhandy.