10bT in Duo Modem Slot - not my hack . . .

[Trash80toHP_Mini]

. . . but somehow this tidbit got the ball rolling!

eBay: USB to TTL Converter Module . . .

. . . looks like it might be fun try to to hook one up to the serial port of the Duo's Modem Bay Connector. }

PL2303HX USB to TTL Converter Module

Dunno what for . . . but I'm sure a use for something like this will come to me . . . even if it's not in a Duo! )

techknight & bbraun are running away with themselves on this one . . .

Go team 68kMLA!!!!! :approve:

 

[techknight]

Well I studied the powerbook duo modem connector, its a datapump connector hooked to the bus, and not a serial port, at least not that I had seen. In order to put a serial port thats usable on the modem connector, you would nee one of apples VIA chips i guess.

And that converter goes 1 direction, it gives USB computers a full RS232 serial port thats TTL compatible. For Arduinos and other crap. You could use one to plug a regular mac into your PC USB port for doing null modem file transfers, or if running XP, Basilisk localtalk access.

 

[Trash80toHP_Mini]

In order to put a serial port thats usable on the modem connector, you would nee one of apples VIA chips i guess.

If there isn't a VIA ASIC on the Duo MoBo, one can be pilfeed from one of my extra DuoDock Boards . . .

. . . or not . . .

. . . for under $4.00 shipped, it looked like it might be neat to have in the HackCrapBag-o-Tricks! }

 

[techknight]

Well, I am not entirely sure of the data pump interface on the Duo modem, but you might even be able to get away with just a simple VIA/SCC or just SCC itself attached to the header connector. But I dont have the spec sheet of the 144 data pump IC.

But in theory since its a direct backbone connection to the databus, you could even make a custom made WiFi card or ethernet card to go into this slot, which would require an entirely custom driver to make use of the data pump mechanism, but it would work in theory.

There are a crapload of realtek chipsets, and other chipsets out there that have a vast amount of public support on in the embedded market, could even use one of these and use a C library thats already out there, to be embedded inside a codewarrior project. Right up bbrauns alley. I could do the hardware, but i dont know codewarrior or low-levels of the system software, so i would need him to write an ethernet driver using public libraries. lol.

The only pitfall I see is I dont know how fast the modem datapump backbone is. just one of those things if you can get at least a 1megabit throughput, itll be decent.

 

[techknight]

Actually i finally found the datasheet to the data pump IC here:

http://www.datasheetarchive.com/dl/Datasheets-8/DSA-153646.pdf

Believe it or not, the datapump actually extends a serial interface via the V.21 interface. So technically, you could use the datapump itself as a serial port. Of course, limited to 14.4 (yuck).

But the datapump does use a 5-bit addressing scheme, and 8 databits plus a chipselect, R/W control lines, and an IRQ signal to the host microprocessor (which is probably the VIA).

This is nice, becuase we could put anything in there, within the means of the 8-bit data bus. So technically they do make and support 8-bit based ethernet controllers, so thats easy. But still need a driver and figure out where the "modem" is mapped in the duo addressing system.

 

[Trash80toHP_Mini]

. . . or slap a DeclROM on the PCB and snag all 32 bits off the Docking Connector's Pins . . .

. . . and write a PDS driver per DCaDftMFH! }

 

[techknight]

too ugly. Id rather just plug a card into the modem connector on the duo, and call it done, all in one integrated solution with no messy wires running every which way, and it gives me a nice RJ45 jack on the back where the modem RJ11 once was. I've got a weird way of doing things, "different".

Anyway.. I need to find out where the address space is for the duo modem card. There is a data pump driver in ROM supposidly, which will have to be hooked to disable it. But at the same time, i need to find its location, as obviously this will reveal the address space.

Edit: Then again, i could emulate the data pump and the driver/software would establish a false PPP to it, but its reality an ethernet connection. But that limits its uses a bit, like not being able to use ethertalk appleshare, etc....

probably going to be easier to disable the data pump driver with a system extension that contains the proper ethernet driver.

As far as the DeclROM thing, i have limited knowledge in the area, and I dont have that particular book. So thats out the window.

 

[Trash80toHP_Mini]

Don't worry, bbraun has it, I have it and he's beginning to look intothe DeclROM gig! [] ]'>

If you need any info from it, PM me.

 

[bbraun]

I picked one of these things up because, well, for <$3 who doesn't need USB to TTL serial?

I was reading over the Duo System dev notes, and I couldn't really find information on where the data pump is mapped into the address space. It looks like disassembly of the datapump driver might be the most expedient way of getting the address mapping...

JFYI, for disassembly, I've been using the fdisasm tool from minivmac. It allows distribution of annotations separate from the ROM to allow collaboration without distributing the copyrighted material, which I kind of like. It took a little bit to setup the minivmac instance and learn the meanings of the various files it uses and their syntax, but once I got the hang of it, things have been going well. If you're interested, I can probably setup the annotations for the driver's entry points.

I've been using it for a different project on the IIsi ROM.

FWIW, you don't NEED declroms... If you're going to occupy a nubus slot or pseudo-slot address space, you probably should. Outside of that, your declrom probably won't be probed anyway. If you're fine with hardware just sitting there not doing anything unless you have the proper software installed, you just need a non-conflicting address space to occupy AFAIK. You could probably even use the RAM expansion port and have a device occupy the top end of the RAM expansion address space (leaving a dead zone between the top of whatever RAM you do have and your device to help foil detection).

 

[techknight]

hey bbraun, any info you can legally give on trying to isolate the driver out of the ROM would help me out.

I am serious, I want to make a NIC that fits where the modem used to go, utilizing the original bus if possible.

I will have to fire up my duo and dump the ROM image so I can analyze it.

Using the RAM slot isnt a bad idea, considering if I make a new modem card NIC, i would have to map it out exactly as it contains both the power/standby button as well. But thats no big deal in Eagle or pulsonix or some other CAD package. The footprint of the edge connector might be a bit difficult to reconstruct though.

 

[techknight]

The Modem slot though, has 5 bit addressing with an 8 bit bi-directional data bus, including a Read/Write line, plus an IRQ line. It also has a Chip Select line, so that tells me its bus has to be mapped through one of the VIAs, or System I/O controller.

Should be sufficient for a basic NIC, but if i wanted to integrate, say, an SD card reader or something other, it might slow things down, unless i hooked into the RAM address slots, which give me direct processor access.

 

[techknight]

As far as the ethernet controller, I have been looking at these:

http://www.eetasia.com/ART_8800434318_1034362_NP_6dc505a4.HTM

PIC has a new 8-bit microcontroller that has a PHY and MAC Ethernet interface built-in. With this being a fully flash-able, programmable microcontroller, we can make this thing do whatever we want to lessen the load off of the Duo itself. It has a built in packet buffer, etc.... and they have a free TCP/IP stack code already made for this MCU family, so MacTCP wouldnt even be needed. lol. it could be handled entirely in the PIC's hardware, and just have an apple driver handle the hardware-based TCP/IP stack.

Possibilities are endless. Plus its bootloader supported so i can flash the PIC to whatever when its in-system via the bus.

Hell, you could even write a net-boot application and putting the image/location information inside the RAM of the PIC, so when the machine reboots it could in theory fetch a boot image from a server and boot the mac, albeit probably slow. Plus a modified ROM would be needed.

 

[bbraun]

Weird, I took a look at the ROM on my 270c. Usually drivers are DRVR resources in the main ROM. The 270c has the following drivers:

.Backlight, .Sound, .Sony, .MPP, .ATP, XPP, .netBOOT, .ATBOOT, .EDisk, .BCScreen, .ENET

I don't recognize .BCScreen, but everything else seems pretty normal, I'm not seeing an obvious driver for the data pump. Perhaps it's not really a driver in the normal DRVR sense, but a set of routines somewhere following a different layout convention? Or gets loaded through an onboard declrom somewhere.

Also, .AIn, .AOut, .BIn, .Bout are the normal serial & printer port drivers, but I don't see them in ROM either.

FWIW, I'm using ROMmie, which is a pretty nice tool for extraction, it includes both a dump of the ROM and parses out the resource data into a .rsrc file suitable for use with Resedit or Resorcerer or similar.

 

[techknight]

Well, thats odd. the developer note said it had a Data Pump Driver in the ROM. hmmm..... it didnt say anything about a DeclROM either.

it also says in the developer note, there is an extension and a control panel for the express modems in the Duo. Maybe thats it? And it all goes through the communication toolbox.

 

[bbraun]

There is a Slot 0 (I'm pretty sure that's appended to the end of the normal ROM) declrom which includes the builtin video driver, but that's the only additional declrom I see. I didn't see any special pointer to a non-video driver.

 

[techknight]

I pulled out the modem from this 270C i stripped to parts (busted screen).

The modem module appears to have no ROM. just some logic ICs.

Just some logic ICs, a low drop out regulator, and a few analog parts such as a dual op-amp, etc...

 

[bbraun]

After boot (which includes any System/INIT loaded drivers...) I have the following drivers installed:

.Sony, .Sound, .Sony, .AIn, .AOut, .BIn, .BOut, .MPP, .ATP, .ASYC00, .XPP, .netBOOT, .XPP, .EDisk, .AppleSoundInput, .SLM, .DSP, .ipp, .CTBIn, .CTBOut

.ASYC00, .SLM, .DSP and the .CTB* drivers are possibilities. Presumably .CTBIn/Out is communications toolbox...

The loaded driver's device control entry should indicate whether a given driver exists in ROM or RAM, but my driver inspection tool isn't sophisticated enough to decode that yet.

 

[techknight]

.DSP is it. Rockwell refers to the Data Pump as the DSP alot.

I read carefully the document, first line of the Data Pump says, "The Data Pump driver is at the lowest end of the modem software..."

So its an INIT or DRVR in the software....

Also, the CTB is the communications toolbox that communicates with the driver to the internal modem. the CTB has a custom serial driver, so un-aware serial modem apps can treat the internal modem as if it were a serial port through emulation in the CTB.

 

[bbraun]

The .DSP driver comes from the System file on my 7.1 machine.

Here's the process I went through to create the basic annotations, and it's probably a good idea to follow along exactly since the end file's offsets important. It's an exercise left to the reader to get a minivmac instance up enough to run the basic tools below. Mine is running 7.0.1 FWIW.

You can probably also get by without minivmac, and just run the fdisasm tools locally on the duo. I just used minivmac for convenience, since I tend to spend a lot of time making multiple iterations of the annotations & disassembly, and it's just easier and faster on a modern machine with minivmac.

* From 7.1, I duplicated my System file because if you open the live System, Resedit complains.

* Opened the duplicate in Resedit.

* In the DRVR resources, copied (cmd-c/Edit->Copy) the .DSP resource. My version has a size of 17082.

* Created a new file in Resedit called "DSP.rsrc" (file name gets encoded in the file, so using the same name is probably a good idea). And paste the copied DSP DRVR into it.

* Used Compact Pro's hqx encoding for safe transport to a modern machine that runs minivmac. This particular encoding probably isn't necessary, anything that you can use to copy the file into minivmac while preserving the resource fork is probably fine.

* Once inside a working minivmac instance (I used ImportFl to get the DSP.rsrc.hqx file into minivmac), remove the binhex encoding or whatever other wrapper format you used.

* Attach this disk to minivmac. You should see bin_names, bin_map, format, and the fdisasm utilities I'm about to mention. The fdisasm utilities are all GPL with source and licenses obtainable from the following links.

* Place the DSP.rsrc file on the mounted duodsp disk.

* Run GetRsFrk to dump the resource fork into the data fork, so it'll be included in the disassembly. It'll generate a "bin" file in the same directory. This is the file used by all the fdisasm related tools.

* Run fdisasm. It will generate a listing file. That's the disassembled text. I usually export it from minivmac using ExportFl, since it's usually easier to just view text on the host system.

Hopefully, after all that, you'll have the disassembled file. The driver its self started at offset 0x104 for me, and starts with the word 0x4440. I've named the driver's open/prime/control/status/close entry points (defined in bin_names) and commented where the DRVR resource header starts (defined in the format file). You can add your own comments to the format file, and name labels, procedures, etc. in the bin_names, then rerun fdisasm to generate a new listing with the new comments/names inline.