Support Uthernet II card

[tomcw]

Uthernet II uses the WIZnet W5100 for hardware TCP/IP stack (the original Uthernet used the cs8900a ethernet controller) . (Datasheet here.)

http://a2retrosystems.com/products.htm:

Apple II Ethernet Module - This product is based on the Wiznet W5100 chip. It has an embedded hardware IP stack. Contiki, IP65, Marinetti and ADTPro have been updated to work with the new card.

So far no requests for supporting this card, but there's this comment on http://a2retrosystems.com:

You may also want to go and grab a copy of the latest Applewin
and check out the Uthernet I emulation.

There is no Uthernet II emulation :(

Anyway, I'm creating this issue as a placeholder for potential future work.

[patrickbst]

I will second the desire for U2 emulation, since that is the currently available card and what many might have in their real apples.

[tomcw]

Streaming demo using Uthernet II:
https://github.com/KrisKennaway/ii-vision

And posting on csa2, Streaming video:

Something caught my eye when I was reading the manual - the W5100 has 16K of onboard memory for TCP send/receive buffers, and the Apple II interface is via an I/O address that auto-increments the address pointer on the W5100.

This means that iterating through the received TCP data is very cheap on the Apple side if all you care about is reading in sequence.

Actually this is the fastest possible way for the 6502 to read data (without DMA) since we’re just reading a single memory address repeatedly, and we can read up to 8k at a time this way before we have to deal with socket buffer management.

[audetto]

Hi
missed this issue.
Anyway, I wrote an emulation for the Uthernet II card which reuses all the tfe-pcap code as Uthernet I.

The card supports 4 type of sockets: MACRAW, IPRAW, UDP and TCP.

MACRAW works almost the same as Uthernet I, and one sends Ethernet II frames via libpcap.

The other types are more complicated to emulate, but would be easier to use for the 6502 as they abstract away part of the low level network mechanics.

Currently

• Contiki uses MACRAW
• A2osX uses MACRAW (uthernet2.drv) and IPRAW (uther2.ai.drv), see https://github.com/A2osX/A2osX/blob/master/.Docs/Technical%20Spec.md#drvdrivers
• will check ii-vision

There exists another emulation of the w5100 chip, in the ZX fuse emulator. See this message where I asked a few questions: https://sourceforge.net/p/fuse-emulator/mailman/message/37269523/
Their implementation emulates TCP and UDP, lacks some commands and as usual, cannot handle DHCP without priviledges.
But it seems clear that to emulate higher network levels, libpcap is not enough.

[audetto]

ii-vision uses the more advanced socket modes tcp, which is currently NOT implemented.

https://github.com/KrisKennaway/ii-vision/blob/master/player/main.s#L179

But I would like to try it.

I have not found a disk, not do I know how to build one. Does anybody have it?

[audetto]

For reference, the code is available here
https://github.com/audetto/AppleWin/blob/master/source/linux/network/uthernet2.cpp

[audetto]

ii-vision uses the more advanced socket modes tcp, which is currently NOT implemented.

https://github.com/KrisKennaway/ii-vision/blob/master/player/main.s#L179

I found how to compile the code.
It is indeed a interesting challenge.

A few things are hardcoded in the assembly file, like IP addresses and slot location, so ability to compile is useful.

[audetto]

Here it is: II Vision running on the emulated Uthernet II

https://www.youtube.com/watch?v=bP5tueMYD2U

[tomcw]

That great @audetto! AFAIK this is the first emulation of Uthernet II, so a really great result!

How easy would it be to port it back into AppleWin?

btw, your YouTube video has no sound, but "II Vision" supports both video and sound. Why is there no sound?

[audetto]

First the easy answer. I don't know, converting an mp4 to the II vision format has been very complicated.
If you have a file already converted, I can try it.

The W5100 emulation is platform independent, but it has 4 modes of operation

• MACRAW: it can reuse the same TFE code from Uthernet I (using pcap, or libslirp in linux)
• IPRAW: apparently unused (but see A bug in UTHER2.AI.DRV.S.txt? A2osX/A2osX#163)
• TCP / UDP: they require real Linux / Windows sockets

If you want to run a server (in TCP / UDP mode), listening to clients, this might require some extra work and port forwarding.
But for pure client software, it should just work.

[audetto]

Hi

I have worked with Oliver to allow Uthernet II to work on AppleWin Windows with Visual Studio.
You can see a provisional (fully working) branch here https://github.com/audetto/AppleWin/tree/u2win

I would like to propose a PR in the near future to integrate it properly in AppleWin.

As I mentioned here #949 pcap is not a great choice on Linux, so I would like to achieve 2 goals at the same time

1. add Uthernet II to AppleWin
2. use the same network backend for Uthernet 1 & 2 (pcap in Windows and libslirp in Linux)

To cut a long story short, it would simplify the above tasks if Uthernet 1 were a Card too.
Is anybody already working on the migration of Uthernet 1 to a Card, or are there reasons against it?

[tomcw]

I have worked with Oliver to allow Uthernet II to work on AppleWin Windows with Visual Studio.

This sounds great!

Is anybody already working on the migration of Uthernet 1 to a Card, or are there reasons against it?

No one is working on this, and it is a definitely a good thing to do - so please proceed.

Ultimately all the cards should be migrated to a Card (...I currently have work in progress to migrate Mockingboard to a Card).

[tomcw]

@audetto: your work in PR #1047 has been merged into master.

You listed these remaining items to do:

• full save state (to the degree where this is possible)
• further clean up (i.e. deletion) of TFE/PCAP code (all the string manipulations can go)
• Card interface really needs to include Destroy and Reset as virtual methods
• SerialCard and Uthernet have similar semantics: open a device, but their behaviour is different (former does not require a reboot, latter does) and they should all handle the interface name in the Card constructor

[tomcw]

@audetto - in terms of AppleWin user-level documentation for the Uthernet II card support, can you list what is implemented (full/partial) and what is not?

Protocols:

• (Closed - presumably just means Socket is closed)
• TCP
• UDP
• IPRAW - not supported due to W5100 bug?
• MACRAW
• PPPoE - not supported

[tomcw]

btw, W5100 errata v2.6 is here.

Erratum 1 talks about a bug in UDP/IPRAW modes, when SEND and RECV occur at the same time, but no mention of the IPRAW bug described in that A2osX issue.

[audetto]

These errata are interesting, but not easy to understand.
I cannot claim full hardware implementation of the W5100. Only what I was able to trigger via software.

I have written an implementation of IPRAW, but the only software using it (a2osx) has a bug (a real one in software), so it is extremely hard to test it properly.

Will extend the html files to describe the Uthernet II.

[burniouf]

Let me complete some coding on another piece of software and i wil go back on A2osX networking & Uthernet II IPRAW support

[tomcw]

@audetto - check out @oliverschmidt's new release: https://github.com/oliverschmidt/A2Stream

[audetto]

You remember the odd ANN3 issue we discussed recently? We were testing A2Stream.

Anyway I found that the code was not handling TCP connection failures very well. The is PR for this: #1070

A2Stream calls for a new audio card: the output tape! anyone?

[oliverschmidt]

You remember the odd ANN3 issue we discussed recently? We were testing A2Stream.

For sure. The knowledge I gained from that resulted in https://github.com/oliverschmidt/A2Stream/blob/main/a2stream.c#L409

[tomcw]

@audetto - the Uthernet II support is looking good, and given Oliver's a2stream release, then what better time to do a release with your U2 card support. Are you happy for me to do a release? Or is there more to do?

[oliverschmidt]

The final sprint of A2Stream was almost completely done using a prerelease of @audetto's Uthernet II emulation on Windows. So I can say that at least that use case works great. BTW: The actual sound emulation of AppleWin is way better than I would have expected it could be - but there's still a well noticeable quality gap to the real thing.

[tomcw]

Hi Oliver,

It's always great to learn of cases when AppleWin was used in development situations, and also good to know that @audetto's Uthernet II emulation has been well exercised!

but there's still a well noticeable quality gap to the real thing.

Possibly related to this issue #579 ?

The distance in time between the clicks determines the frequency of the note produced, but the distance in time between the references determines the volume. This is because each reference toggles the cone, pushing it either in or out. The volume of air moved is greatest when the references are spaced an equal time apart. If, instead, the silent reference is shifted closer in time to the previous or next audible reference, the volume diminishes.

[oliverschmidt]

My problem with #579 is, that it makes a statement - that I don't want to comment on - but doesn't state what exactly AppleWin is supposed to do wrong.

[sicklittlemonkey]

One (obvious) interpretation is that the next speaker sample output should be scaled down in amplitude if within certain deltas of the previous speaker access.

[oliverschmidt]

So it's 'obvious'? That reminds me why I'm not part of the AppleWin development team anymore. Bye.

[audetto]

@audetto - the Uthernet II support is looking good, and given Oliver's a2stream release, then what better time to do a release with your U2 card support. Are you happy for me to do a release? Or is there more to do?

I am sure there is, but I think it is in a very good state for a release. Go ahead.

After the release, what should I do for the code I wrote to log the network traffic

1. do nothing
2. commit it, but #idfef it out (like RIFF)
3. add a cmd line option (like --log)

[sicklittlemonkey]

@oliverschmidt

So it's 'obvious'? That reminds me why I'm not part of the AppleWin development team anymore. Bye.

Are you annoyed by my comment for some reason? I'm not sure why. No offense was intended.

I'm just saying it's easy to dream up some obvious/naïve/unsophisticated interpretation of how the effect might be emulated.

But how to accurately simulate the physics of a speaker cone isn't at all obvious to me. I studied computer science, not engineering or computational physics. There are many other things that I wish I had studied ...

Cheers,
Nick.

[tomcw]

Hi @audetto -

After the release, what should I do for the code I wrote to log the network traffic

IMO, it'd be very handy to be able to generate a PCAP from the command line, so option-3 sounds good to me.

[tomcw]

FYI: new AppleWin 1.30.9.0 release here with @audetto's Uthernet II work included.

[oliverschmidt]

Are you annoyed by my comment for some reason? I'm not sure why.

Really? If A writes that he has a problem with understanding something and B answers that this something is obvious than this statement is likely considered by A as offensive.

No offense was intended.

I see. Thanks for clarifying.

#579 opens with stating:

An undocumented fact about the Apple's speaker is that it doesn't click every time you reference an address in [$C030..$C03F], but every other time.

I consider this plain wrong. Just write

0300: STA $C030
0303: RTS

and you'll clearly notice a click every time you do 300G.

Apart from that...

• I have no idea what could/should be done to "solve" Obscure bug in speaker implementation #579. The most important (but for sure not only) reason for that is, that - after looking at the AppleWin speaker code - I have no mental model of how that code works - and I don't see me investing the time necessary build such a model.
• I'm almost sure that Obscure bug in speaker implementation #579 is not related to any deficiency in reproducing the A2Stream sound output.
• I've noticed a reference to DAC522 in the AppleWin speaker code. Therefore I'd like to mention that the sound output model of A2Stream is absolutely identical to that of DAC522.

Regards,
Oliver

[oliverschmidt]

FYI: new AppleWin 1.30.9.0 release here with @audetto's Uthernet II work included.

Cool - thanks for the info :-)

[audetto]

aw.zip

Extra logging to debug TCP issues.

[tomcw]

Hi @audetto - what are these TCP issues?

Perhaps best to move any further issues to a new issue, and then I will close this (since AppleWin with U2 support got released).

[audetto]

Oliver reported an issue whereby the TCP socket is closed with WSAECONNRESET just before its natural end, so the last few seconds of the stream are lost.

The suspect is that this only happens on a non-virtualised Windows PC (which I don't have right now), and so far have been unable to replicate, nor do we have any idea why this happens.

There are not enough data points to pin point anything in particular.

We can close this and reopen another one when we have more information.

[tomcw]

Closing this, as Uthernet II card is now supported.