Re: Falcons Device 6 and 7 problem


"Mark Bedingfield" <atari030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:4381a280$0$9866$afc38c87@xxxxxxxxxxxxxxxxxxxxxxx
> Phantom wrote:
>> "Mark Bedingfield" <atari030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
>> in message news:43802058$0$13102$afc38c87@xxxxxxxxxxxxxxxxxxxxxxx
>>
>>>Phantom wrote:
>>>
>>>>Greetings,
>>>>
>>>>
>>>>>From my understanding of the Falcon, there was a problem with the
>>>>modem port that would not allow it to achive higher Baud rates.
>>>>
>>>>For this reason, the infamous software patchs were created to
>>>>fix this problem. Most Falcon owners probably know what I'm
>>>>talking about.
>>>>
>>>>Any way, Is there a Hardware fix that one can do that would
>>>>eliminate the need for the software patchs?
>>>>
>>>>If such a fix is known, is it somewhere online?
>>>>
>>>>I for one would like to fix the hardware and not have to use
>>>>the patches if possible.
>>>>
>>>>And if one can add another modem port to the Falcon, thats
>>>>a upgrade I'd like more info on as well.
>>>>
>>>
>>>The most common problem is that older software would not run at
>>>greater than 19,200 baud. The cure is to use more recent comms
>>>software and it pays to use HSmodem as well. Hsmodem replaces the
>>>routines used by tos, in much the same was NVDI etc works. Just more
>>>efficient code.
>>>Some early Falcon's had a bug where the serial port would not work
>>>until the machine had been reset. FWIR it was only a handful of
>>>Falcon's effected.
>>>
>>>Mark
>>
>>
>> Hi Mark,
>>
>> Yes, I know that HSModem is the most common software fix for this
>> problem. But it is rather old, but still works fairly well.
>>
>> I was just wondering if there was a hardware fix, so one did not have
>> to use HS Modem to get higher Baud rate speeds?
>
> No, because it is a software problem, not hardware. The only thing you
> could do is patch TOS itself.
>>
>> I believe that the part of the problem had to do with software that
>> accessed a modem port that was not really there. And HSmodem
>> fixes this problem thru software. Maybe I'm not totally correct on
>> the
>> above, but seems I recall it being something like that.
>
> There were a few redirectors in the early days that allowed programs
> like Freeze dried terminal to work on a Falcon. The Falcon's serial
> ports aren't the same as an ST's so you had to fool it into using
> another port. Serial 1 instead of Modem 1, IIRC. But you could not go
> past 19,200 baud, in that scenario. The Falcons serial ports are
> designed to go a lot faster than an ST's, upto around 115k baud, in
> theory IIRC.
>>
>> I was wondering if one could put a modem port in the correct place
>> so software would be able to access it with out a software patch.
>
> It is in the correct place. ST's support 4 serial ports, Serial 1 & 2
> and Modem 1 & 2. The ST only had serial 1 whilst the Falcon had Modem
> 1. The Falcon used the SCC chip and the ST the MFP. The Mega STE has 3
> serial ports (the lan could be used as a forth, as also you could in
> the Falcon). The TT has 4.
>>
>> And or sometype of hardware path/upgrade to eliminate the use
>> of HSmodem if one wants.
>
> You don't necessarily need to use HSmodem. Hsmodem replaces stuff like
> flow control routines in TOS, it is a just a OS bug fixer. Use Mint
> and you don't need it. Not sure about Magic.
>>
>> I have often wondered if HSmodem is compatible with some of
>> the newer hardware upgrades and some software as well.
>
> Most likely just not necessary as the custom TOS may have had the bugs
> fixed, if it hasn't then you will most likely need it also.
>>
>> Not trying to put HSmodem down. As it is about the only known
>> software fix for the problem that I know of.
>>
>> I would like to see a newer software patch at the least.
>
> IIRC, mint now has the modern equivalent of HSmodem built in.
>
> Anyway it is like this,
>
> ST/E/FM MFP
> MegaST MFP
> MegaSTE MFP SCC
> TT030 MFPTT SCC
> Falcon030 SCC
>
> Atari just dropded the MFP port, because it was slow. The MFP could
> only go to 19,200 baud unless you overclocked it to 38,400. In the
> overclocked state you need HSmodem to drive it as TOS is not capable
> by itself. The SCC was a high speed uart, not designed to be
> compatible with the MFP at all.
> Programs like Connect can talk to the SCC quite happily without
> HSmodem.
>
> http://www.atarimagazines.com/startv5n6/tterrific.html
>
> Has some interesting info on the serial ports, worth a read.
>
> Mark

Thanks for that info, it will come in handy.

I really need to get a Falcon Field Service Manual so that I can
learn more about the chips in there. Some I know well, others
I don't.

I know that Stalker also has custom code to work the Falcons Modem port
to
very high Speeds. Never used Connect that much, I prefer STalker. The
Back Talk Script is interesting as you can write your own stuff with it.

IIRC, there was a article somewhere on adding another Modem or Serial
Port
to the Falcon. It's been so long, that I forget where I saw that at.
Maybe on a
Atari CD that I have here.

phantomm@xxxxxxxxxxxxx



.

Relevant Pages

  • Re: Any BOSS4 Gurus?
    ... > port and not the ... > You also have make sure of the baud rate ... > switches on the ERS board. ... > going in and resetting the dip switches ...
    (alt.machines.cnc)
  • Re: Why is the serial port so slow in Linux?
    ... port, I have connected pins 2 and 3 (the ... to read the serial port. ... integer baud. ... int ascii_loopback; ...
    (comp.os.linux.misc)
  • Re: Any BOSS4 Gurus?
    ... port and not the ... You also have make sure of the baud rate ... switches on the ERS board. ... going in and resetting the dip switches ...
    (alt.machines.cnc)
  • Re: Serial Communication in Visual C++
    ... int CCommTalk::Write(const char *pBuf, int nBytes) { ... I don't see any problem that could cause a significant delay. ... Visual C++ can certainly keep the port busy at 9600 baud, ... It should take about 50 milliseconds to send your 50 char buffer at 9600 baud. ...
    (microsoft.public.vc.language)