[Coco] Fwd: IP packets on my coco

[Dave Philipsen]

Another option would be to use a chip like the AS6C4008 which will run 
on anything between 2.7 and 5.5V.  Then you might just be able to use 
some TTL logic to make it all work.

Dave


On 6/11/2016 9:17 PM, Zippster wrote:
> I’m not sure what he means by non-transparent  latch, but you would definitely use a latch.
> The link didn’t come up for me so I couldn’t look at it, but...
>
> The GIME is expecting DRAM, so you’ll first get a row address followed by *RAS, which
> you’ll use to latch that address information.  The column address will follow along with *CAS.
>
> At that point you’ll have a full address for a memory location that you can use to address your
> 512K SRAM.  A CPLD is ideal for handling this sort of thing.
>
> If I were to build one, I’d use one of the 5V tolerant Xilinx 9572XL packages.  The board
> would only need the 512K SRAM, the CPLD, 3.3V regulator, and some decoupling.
>
> - Ed
>
>
>> On Jun 11, 2016, at 8:35 PM, Camillus <camillus.b.58 at gmail.com> wrote:
>>
>> Hi Dave,
>>
>> I kind of followed the discussion about tcp/ip stack needed for the 6809 internet project.
>> And your question started me thinking.
>>
>> If you only can pol a certain status of a port for catching communication, then why not add some polling code to an existing IRQ call.
>>
>> e.g. do a LBRA POLLTCP  after the last instruction of an H- V Sync or Ram Refresh interrupt. In that POLLTCP you can just make code to set a flag, or handle the complete reception. Because the code would be accessed as the last instruction in the original interrupt  it would ( I think ) not make a difference to the original handler.
>>
>> I do not see any reason this would not work, and you then have a kind of interrupt controlled polling.
>>
>> just my $0.02 worth of brainstorming
>>
>> PS I do have also a question for U.
>> I found this schematic ( included ) of a 512 Static Ram for CC3. I think it is a project of John from Gimechip.com
>> On this schematic he suggests to put all the logic into a CPLD using a 9 bit non transparent latch.
>>
>> Can you figure out what he is meaning?
>> Is all the logic converted as latch into the CPLD? And how can that be done?
>> I just do not get it. The more so because there is nothing on the net to make that kind of latch in an CPLD.
>>
>> I only can find a 9 bit transparent latch.
>>   
>> If you have the time and feel like it, can you give it a glans and enlighten me...
>>
>> Thanks heeps
>> cb
>>
>> Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird]
>> On 6/10/2016 3:52:59 PM, Dave Philipsen <dave at davebiz.com> wrote:
>> So I have a question since it has been many years since I wrote an OS9 device driver. If the driver is written to poll the device instead of being interrupt driven, how often will it poll the device to check for the necessity to service it? Once each tick?
>>
>> Dave Philipsen
>>
>>> On Jun 10, 2016, at 1:38 PM, John W. Linville wrote:
>>>
>>>> On Thu, Jun 09, 2016 at 09:47:56PM -0500, RETRO Innovations wrote:
>>>> On 6/9/2016 9:35 PM, John W. Linville wrote:
>>>>>> Well, it looks like the datasheet might be wrong...
>>>>>>
>>>>>> Application Note 181 from Cirrus Logic says:
>>>>> https://www.cirrus.com/en/pubs/appNote/an181.pdf
>>>> I was looking for that all day. Glad you found it.
>>>>>> So apparently the 8-bit mode is a bit unreliable in the CS8900A?
>>>> No, it's rock solid on the CBM platform, so I expect it would be the same on
>>>> the Coco.
>>> Except for the whole interrupts thing... ;-)
>>>
>>>>>> With that said, the usefulness of interrupts for servicing an Ethernet
>>>>>> NIC on
>>>> Most folks appreciate the idea of getting an IRQ when a packet arrives. In
>>>> most newer switched Ethernet environments, you won't see any packets until
>>>> one comes for you. Thus, you can safely do other stuff and then an IRQ will
>>>> mean there is actual data for you.
>>> Yeah, I understand the interrupt concept. I know a fair amount about
>>> switched Ethernet as well.
>>>
>>> Despite the convenience of asynchronous notifications, one must also
>>> consider the relative costs of polling versus processing interrupts
>>> and how often one expects to recieve incoming packets while an
>>> application is running. Moreover, I find that a number of otherwise
>>> competent coders have trouble when dealing with interrupt-driven code.
>>> So all-in-all, I still submit that not having an interrupt signal in
>>> this case is not a big deal.
>>>
>>> Anyway, the Cirrus Logic chip vs. the Realtek chip is much ado about
>>> nothing. Either will do the job equally well or equally poorly,
>>> depending on your point of view... :-)
>>>
>>> John
>>> --
>>> John W. Linville Someday the world will need a hero, and you
>>> linville at tuxdriver.com might be all we have. Be ready.
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>