Zorro III memory card... now with Ethernet

[tnt23]

A new 1.2 revision of Z3SDRAM, an open Zorro III memory card design, is now sharing up to 64MB of SDRAM and an Ethernet controller (based on DM9000 chip from Davicom) on one PCB. Also the new board can be used in Zorro II configurations, as the rest of Zorro signals are now also been routed to the FPGA.



The hardware side seems to be functional, and SANA-compatible dm9000.device is in its early development stage (read: I was able to compile the 'hello.c' somehow).





The project page will hopefully be updated soon: http://code.google.com/p/z3sdram/

[tnt23]

Well, as soon as Poseidon is USB stack and Z3SDRAM has no USB host (yet) - I'd say yes, Poseidon would work even without Z3SDRAM

[tnt23]

I doubt I could invent something to exceed the 8M barrier for ZII, but volunteers are welcome to try

[tnt23]

Very interesting. Are these for sale?

I have one spare unpopulated PCB left. More PCBs could be ordered for those who don't mind sourcing the components, soldering and JTAGging on their own. Besides, there's no device driver for the network part yet.

[tnt23]

Your posted sch & pcb files on Google project page for  Z3SDRAM, appear to be Altium or PCAD. When you update project page for Z3SDRAM, are you going to post Gerber files for the PCB for the  Z3SDRAM project as well?

The schematics and PCB are in old PCad 200x format. My local PCB house happily accepts PCad PCB file saving me the trouble of converting it to Gerber. If someone wants to do the conversion they are welcome.

Anybody willing to help in developing device driver for the DM9000, you are more than welcome, too.

[tnt23]

For the CS8900 driver I was using the 3C589 sources available on Aminet. Same thing with DM9000 driver, both were based on (widely vandalized) 3C589 code. I was able to do TX and was fiddling with RX part under Roadshow just before switching to DM9000 chip.

[tnt23]

How do you feel about open sourcing the resulting driver? As things stand, we do not have enough SANA-II Ethernet driver examples which can be reviewed and adapted by anybody interested in the matter. The networking driver source code, as part of the original SANA-II kit, explains how one might create a SLIP driver, but that is so obsolete it's not even funny any more.

I would not mind sharing the driver at all, only there's a bit of chicken and egg problem. To come up with a decent driver I'd take a look at a sample one written by someone else (and preferrably not in assembler). It is really great 3c589.device  sources are available, although the code seems rather complex to me. I think I'm going to hack it quickly to get ping or DHCP reply before posting.

[tnt23]

As far as I can tell from my past experience, 3c589.device is a good SANA-II Ethernet device driver design. It may appear to be complex, but this is in fact how you would implement this kind of driver. It properly separates the basic device I/O, the individual hardware units, and the low level hardware access. This is really how it's supposed to be done.

Well, give me some more time and we'll see the difference I have just implemented my first /INT2 server (which I am very proud of), and the resulting progress so far is slightly over zero.

[tnt23]

There are some minor issues, but basic RX code is working. SANAUTIL network tool opens device, requests orphan packets and dumps them.

[tnt23]

TX code is working now, too. Packets sent from Amiga are seen on the remote side. (Will have to set up a way to grab screenshots instead of using my mobile phone's camera.)



Remote host (Raspberry Pi running tcpdump):



For that reason I've bought the RoadShow TCP/IP stack last night

[tnt23]

I guess it's too late to talk you out of buying Roadshow, but the demo version should be able to handle test setups like these just fine

Well, I've got enough reasons to reboot on my own to deal with demo's 30 minute expiration

[tnt23]

sgrab ?

Will take a look. So far I have tried MasterGrabber and GrabScreen, both kinda work, producing IFF files, and I was hoping for JPG/PNG output.

[tnt23]

Can you post a better picture of the actual card? Thanks!

I'm afraid this one is the best I can do without my DSLR (another one taken with flash is even worse). Should you want some particular closeup just let me know

[tnt23]

I had a quick look at the 3c589.device source code, and it looks good to me (I'd probably rewrite the basic device I/O code to be more paranoid, though, and the cleanup procedures in case of errors should be reworked).

So I've been having fun with sashimi and MiamiDX and at some point have tracked an issue with my driver's code freezing when calling S2_CopyToBuff hook. I will have a look into buffer management the MiamiDX provides when opening the device, but here's a piece of code (borrowed from the abovementioned 3c589 sources) that puzzles me.

An opener structure is being allocated:

Code: [Select]

/* Set up buffer-management structure and get hooks */

request->ios2_BufferManagement = opener = AllocVec (sizeof (struct Opener), MEMF_PUBLIC);

And then it is being filled using GetTagData () calls. If I get it right GetTagData () returns either found tag value or default value (second param). However, the same (uninitialized) opener->rx_function var is provided as the default value:

Code: [Select]

opener->rx_function = (APTR)GetTagData (rx_tags [i], (UPINT)opener->rx_function, tag_list);

This would probably make sense if the AllocVec () call used MEMF_CLEAR in addition to MEMF_PUBLIC, but this is not the case. Even if the allocated memory has been zeroed previously why not provide NULL as the default value? The same very source uses NULL just a couple lines of code further:

Code: [Select]

opener->filter_hook = (APTR)GetTagData (S2_PacketFilter, NULL, tag_list);
opener->dma_tx_function = (APTR)GetTagData (S2_DMACopyFromBuff32, NULL, tag_list);

Or perhaps there is some reason of (not) doing so?

Looked into cnetdevice assembler sources, default value is also NULL:

Code: [Select]

; get copyfrom functions:

 move.l  #S2_COPYFROMBUFF,d0
 moveq   #0,d1
 move.l  a2,a0
 jsr     _LVOGetTagData(a6)



[tnt23]

This is awesome and please don't take this question as a complaint, but with RAM being so cheap, why only 64MB? Is there some limitation that I'm unaware of? Is this so it can be used in Zorro II in addition to Zorro III? I actually am unaware of the limitation per card for these devices in regards to addressable memory.

64M was the biggest SDRAM chip I was able to find in TSSOP package. The common approach is to have two or more chips on board, but I wasn't brave enough to route another one. Zorro III itself is able to address more than 1G per card.

Speaking of Zorro II, the limit is 8M there, unless someone comes with some sort of banking driver or something.