[Coco] Fwd: IP packets on my coco

[Dave Philipsen]

Also, I believe the difference between a 'non-transparent' (normal) 
latch and a transparent latch is that the normal latch latches the data 
on the edge of a clock signal.  A transparent latch would allow the 
outputs to change, following the inputs while the enable is active and 
then when the enable signal goes inactive whatever was on the inputs 
would stay latched to the outputs.

As far as implementing that in a CPLD it would just be a matter coding 
it as a normal latch as opposed to a transparent one.  The CPLD would 
also include some other logic besides the latch.


Dave


On 6/11/2016 8:35 PM, Camillus 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
>