Jump to content
jamesmilne

MacToTheFuture SE/30 10/100 Ethernet card

Recommended Posts

On 6/25/2018 at 11:57 PM, Bolle said:

I did not see the part where I had to build hundreds of adapters for everyone

This is fair enough. Could you upload the design to OSH park though, so anyone can easily order with a click?

Share this post


Link to post
Share on other sites

Youve probably thought of this already, but what the heck?

 

cutouts-reverse-mount.jpg.c023162b365b003ed0039c69a831f509.jpg

 

Mounting your breakout board backwards allows an RJ connection to Vonets with mounting point for antenna and a little something extra. Empty holes are for bolting up a soldertail VGA or other connector, nothing but empty holes required for an in cable converted Radius Color Pivot II/IIsi breakout.

 

LOVE your project!

 

 

edit: oopsie, delete the GA and substitute "onets" :blink:

Edited by Trash80toHP_Mini
I'm an idiot. :-/

Share this post


Link to post
Share on other sites

On a tangent note, and not meant to derail, but has anyone explored A/ROSE development?  Theoretically it's no longer too expensive compared to when it first came out.

Share this post


Link to post
Share on other sites

Mark's card has arrived and I've plugged it in to my SE/30. Nothing has exploded, which is a good start.

 

Unfortunately, it won't talk to me.

 

Our CPLD is looking for the function code bits to be 0b001, "User Data Space", which I'm guessing may not be set as AFAIK classic macOS always runs in Supervisor mode?

 

Should we be looking for function code 0b101 instead? Or just ignore the function code bits?

Edited by jamesmilne

Share this post


Link to post
Share on other sites

Why not try both? Look for 0b101 and if it still won‘t work go for the bare minimum and only look at the correct address bits.

Share this post


Link to post
Share on other sites

Success!

 

We reprogrammed the CPLD to ignore the FC lines, and now I can read/write registers on the card.

 

I've also discovered that we did not in fact have to swap the byte order of the data bus in order to talk to the LAN9218. Now all my data is round the wrong way :-D No matter, I can bodge around that in software until we make more boards.

 

Now to fire up MPW and write some code to test reading/writing packets...

IMG_3923.jpg

Edited by jamesmilne

Share this post


Link to post
Share on other sites

Getting some progress now.

Auto-negotiation and MDI-X (to automatically handle cross-over) is working.

I've got link/speed lights showing up too.

Green is Link.

Orange is 100Mbit.

IMG_3924.jpg

IMG_3925.jpg

Share this post


Link to post
Share on other sites
13 minutes ago, techknight said:

So what do you mean by byte order being backwards? 

 

You mean D0-D7 vs D8-D15? like little-endian/big-endian issue? 

Yeah, endian issue. The chip is designed to work with little endian CPUs. If you want to use it with a big endian CPU, the data sheet says the hardware designer will need to accomodate this (swap the bytes).

 

I’m thinking that our board is not actually wrong. I need to swap the bytes on the CPU when accessing the registers in the 9218 chip.

 

However when I actually write data into the buffers, which has to be done 32bits at a time, I think the byte-swapping is actually required.

Edited by jamesmilne

Share this post


Link to post
Share on other sites

No idea what I am looking at. an Untitled window with a bunch of hex/binary data. 

 

But hey, glad it works! 

 

Once its fully working, wonder how hard it would be to attach it to the SCSI bus. the communication is "basically" the same, its the method of enumerating the SCSI driver to send data back and forth like a serial port. 

 

But sadly it would take 4 bus transfers for a 32 bit word. so it would be WAY slower. But much nicer on powerbooks with no PDS access. 

Edited by techknight

Share this post


Link to post
Share on other sites

Sorry, I guess that video was a bit cryptic. It is showing a hex dump of the first 128 bytes of each packet it receives over the network. It's receiving various broadcast packets from other machines.

 

For the LAN9218 to work with SCSI, you'd need an FPGA to connect to the SCSI bus and handle all the SCSI protocol stuff, and implement some special SCSI command that could read/write registers.

 

You could maybe do it with a microcontroller, like the RaSCSI project. A microcontroller isn't really ideal for directly interfacing with SCSI. It can take quite a few CPU cycles for an MCU to respond to activity on their GPIOs. Could be done though. The original designer of the RaSCSI was using it with an Sharp X68000 and had written a network driver for it, so we could probably get a network driver for RaSCSI working on the Mac too.

Edited by jamesmilne

Share this post


Link to post
Share on other sites

Rather than going out to the very slow existing SCSI bus for NIC function, how might your CPLD setup work for adapting an UltraSCSI (or SATA) connection across the PDS?

Share this post


Link to post
Share on other sites

The CPLD is a baby FPGA, but it might be enough to interface a SATA controller chip with the PDS slot if it has the right interface.

 

The problem will be finding a SATA controller chip with an interface that isn’t PCI or PCIe, which are not simple to interface to via the PDS slot.

 

Not sure there’s much point in building anything for Ultra SCSI since drives are rare & expensive. It would also be tricky due to the huge number of differential pairs involved.

 

A PDS or NuBus to PCI bridge implemented on the FPGA might be feasible though. I’ve recently bought a dev kit for the Lattice ICE40. The dec board exposes 160 IO pins, which is enough for both PDS and PCI. It can run at 100MHz, so might be capable of interfacing between the two realms.

 

This would also allow interfacing with USB, Wifi, etc PCI chips.

Share this post


Link to post
Share on other sites

I haven't looked lately, but brand new 2.5" SCA server drives were very inexpensive two or three years ago. That's why I suggested UltraSCSI, figuring a SATA or PCI bridge would be much more difficult than emulating a high speed SCSI controller. Disk throughput is the Achilles' heel/megalithic bottleneck remaining in SE/30 and IIsi hot-rodding. [;)]

Share this post


Link to post
Share on other sites

Alot of those drives have dried up recently. Sadly.  They are still out there but the prices per drive have gone up quite a bit. 

 

Wooo that would be nuts. a PDS/Nubus-to-PCI Bridge. 

 

That would open up a TON of opportunity. However everything would need drivers. Eh... 

Edited by techknight

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×