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

[Trash80toHP_Mini]

8-o What the . . .

< Peanut Moment >

EEEEEEEEERRRRRRRRRRRRWWWWWWWWWWTTTTTTTTTTTTTT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

xx(

 

[techknight]

Yup. I will do that tomorrow after I get done working on someones virus-ridden PC.

Should be interesting what I find. Hopefully the driver will have all the necessary functions needed to control the modem bus. Then I can develop some simple hardware based off the PIC ethernet controller, and maybe make something work. ASSUMING the DSP is the driver.

I guess one way to find out is run MacsBug and do a modem query or something, itll eventually hop through the driver... I really dont know why I want to go through all this trouble and make a modem slot ethernet adapter, but I like not having wires strung every which way, more in favor of a plug-in solution Besides, I found a couple prototype 2layer PCB production services that are cheap for 5 boards minimum.

Maybe I should make some hardware after ironing out the ability to take control of the modem bus, and produce some test boards. Send one to ya if you want to play with it.

 

[bbraun]

It's a lot of steps just to avoid "here's a disk image, fire it up", but just trying to be as legit as possible.

But hey, on the bright side, it's like a mini tutorial of the tools!

 

[techknight]

Well handing over a disk image isnt going to make me learn anything. lol. I need to learn the lower-level stuff for a reason. If i make hardware that works with macintosh, How do i ever expect to make it work in software besides using peek/poke routines in higher level languages that isolate themselves from the low-level system like the toolbox? (such as RealBasic which I am familiar with)

 

[techknight]

*SNIP*

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.

Do you have the info/commentary for the CTB entries so I can disassemble/do those as well? Thanks.

P.S. Sorry Trash, I took this topic way off.... topic.... lol. For the good I hope.

 

[Trash80toHP_Mini]

NoPro guys . . . I just toss'em out there and see what happens . . .

. . . it's not usually what I expected to be possible, but it's almost always interesting! :approve:

This stuff is waaaayyyyyyy over my pay grade. I was just gonna toss a hacked Micro-ENSC into the HDD Bay of the 2300c, connected to the internal SCSI Connector/Cable, alongside an IDE Hard Disk replacement of some kind. Then I'd stick an RJ-45 onto the Power Board where the Modem's RJ-11 lives and connect it with a wire run to the NIC in the HDD Bay!

Ethernet in the Modem Bay on a custom PCB is a way cooler hack!

This is what I get for procrastinating for ten years on a hack . . .

. . . I get trampled by eager young whipper snappers doing it with technology so advanced as to be indistinguishable from Magic! :I

Go for it guys, just let me know what to re-name my thread! )

 

[techknight]

Well, heres the thing. The Micro-ENSC idea is great, and the easiest approach without getting deep into the system hardware and software configurations.

The problem: Where to get this adapter. and are they being made? could they be made again? I doubt it, and i doubt it.

But FWIW, if this modem slot idea works out, I am going to keep everything open source. open hardware, open software, etc... so anyone can make them. if there is a need for one, make it

if bbraun makes a driver, or teaches me how to make one, im sure he would keep the codewarrior project open source as well too. (i hope)

 

[Trash80toHP_Mini]

That's me . . . the KnuckleDraggin'HardwareHacker type! Take chunks of off the shelf hardware . . .

lop off some bits here, move some other bits there . . . flip the rest of the bits upside down or sideways . . . }

. . . so's they'll fit in somewhere and work in a Mac that nobody thought they belonged inside, much less fit! )

I get a kick out of watching you kids take a more elegant approach . . . than Junkyard Wars! [] ]'>

 

[techknight]

Yea. LOL I did the junkyard approach to the old IBM 600e and 600x series thinkpads. stuck NiMH AA batteries and holders inside the compartment where the Li-Ion originally went. soldered it directly to the system board, and ductaped the bottom hole that held the batteries in place. LOL it worked believe it or not....

 

[bbraun]

The CTBIn/CTBOut drivers come from the PowerBook Setup control panel on 7.1, presumably purely for that Modem: Compatible/Normal radio button!

Anyway, mostly the same as above:

* Open PowerBook Setup in Resedit, copy the CTBIn & CTBOut resources

* Paste them into a new file named CTB.rsrc

* Follow the same steps for transferring the CTB.rsrc file to minivmac, preserving the resource fork

* Grab this disk image, the same as before, except there are CTB and DSP folders differentiating the two.

* Inside the CTB folder, run GetRsFrk as before, which will generate the "bin" file.

* Run the FDisasm tool to generate the listing

For me, the CTBIn driver header started at $104 again (a good sign this is repeatable!) starting with the word 4d 00, with the Open function starting at $168.

I've labeled the open/prime/control/status/close functions of the In and Out drivers again. It looks like they do some jumping around and the FindCode tool wasn't able to follow all the jumping. If you think there's more code at a specific address, launch the FindCode tool, type in the hex offset you want it to start disassembling at, then hit cmd-g/FIle->Go and it'll update bin_map and bin_names, and run FDisasm again for you, updating the listing file.

For example, this seems to use PEA.L , then branches, does some other stuff, pops the address off the stack, and JSR's to it. FindCode couldn't follow that with all the gunk in between, so you'll need to tell FindCode to disassemble at that offset (if it really is pushing the address of code onto the stack, sometimes that's pushing the address of constant data and if you disassemble that you'll get garbage).

 

[techknight]

Ive seen worse when disassembling and trying to use the ST version of the 68HC05 and 68HC11 with IDApro as they added a 16 bit extended opcode system on top of the original 68HC05 compatible 8 bit system, using indirect jumps, etc.... nuts. So i know exactly how that is. I just am not familiar with 68k YET.... but i will be. cant be much different than the older 68HC series.

BTW, do you know if the CTB driver took any branches/called into another driver resource? or was it contained within itself. Anyway, I am off to bed, and ill start crunching this code tomorrow when i get finished with this stupid PC over here.

 

[bbraun]

I haven't done much disassembling of these beyond the initial entry points, it was mostly intended as a starting point for you to take a look. However, DRVRs shouldn't be branching directly to stuff outside themselves. They'll use A-Traps and reference low memory globals, but that's more or less it. The A-Traps here will typically show up as an undisassembled data constant, although if you include the trap_names file from one of the ROM disassemblies on the FDisasm site, FDisasm will correctly display what A-Trap is being called. Including the abs_names file will do the same thing for low memory globals.

The caveat to calling out to another resource is a driver can load another resource using GetResource or similar (it'll show up as an A-Trap, if you include that file), then once loaded, start executing it. The .netBOOT driver does this, it loads the .ATBOOT DRVR resource, installs the driver, then opens it.

 

[techknight]

ugh. this is a pain. lol. I am trying to get all my mac emu files transferred over from my main machine, to a junk laptop that is modern enough to be an intermediate machine. Why? because i need a floppy disk to transfer files between my duo and my main machine as I have no floppy drive.

I dont have a null modem cable made either, so I have to use floppy to transfer between machines, with an in-between machine thats networked to my main machine. Since the in-between machine runs windows 98, and my main machine runs windows 7, they dont "talk" to each other, so I have to use FTP to transfer between the two.

fun... but ill get there.

 

[Trash80toHP_Mini]

:lol: Been there, done that!

SCSI & USB ZIP Drives & Disk(s) are the answer to all your EtherNet/SneakerNet trials and tribulations.

I can lend you all three for this project, or I can loan you a SCSI <-> EtherNet Box to make your life easier for this project . . . unless you have some interesting trade goods! [] ]'>

 

[techknight]

I have a parallel ZIP drive, and an internal IDE Zip drive. But that aint gonna help me on my powerbooks. lol.

I also have an internal style Jaz drive, but i lost my external jaz drive. it used the weird type of SCSI cable i had to have an adapter for.

 

[techknight]

ok, i followed your steps, but I got an error on the fdisasm. Map goes to high....

Edit: NVM, i think both resource drivers have to be in the same file. hang on....

 

[techknight]

hmmm.. it didnt disassemble. it gave me a listing, but it appears to be all garbage, and all in dc.b

 

[bbraun]

Scroll down, see if there's disassembly starting at around $180ish. The first part of the file is just the resource for header information, which isn't relevant, and isn't executed code...

 

[techknight]

ok, yes i see. But it appears that it only disassembled one subroutine.

 

[bbraun]

You should see labels for E_CTBIn_Open, E_CTBIn_Prime, etc. which should each be a Bra instruction, that goes to L0, L1, etc. labels.