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

[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 <offset>, 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]

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.

[techknight]

Ya, I see those. But thats it. no meaty stuff. I guess I am going to have to figure out what those pea.l instructions are i guess. I have no idea what addressing mode this instruction uses.

[bbraun]

Yup, welcome to my life at the moment. I usually keep a copy of the 68k PRM open while going through the listing.

As an example, here's my current disassembly project of the netBOOT and ATBOOT drivers from the IIsi ROM. It's not exactly fast or sexy work...

[techknight]

I guess one way to find out is use easy68k and simulate the sucker. Pretend there is a driver call or something.

[bbraun]

I don't think it'll get very far in easy68k, but you could write an app that'll open the driver, then trace through it using macsbug... But that will only get you through the open routine. The Control and Status routines each key off the csCode element of the ParamBlock structure, a pointer to which gets passed in A0 (DCtlEntry structure pointer is in A1, return value in D0), so you pretty much either need to disassemble those routines to figure out what values get passed in and what they mean, or set a macsbug breakpoint on those routines and fiddle around with stuff until they get called, then follow them through.

[techknight]

Ya, its totally broken in easy68k becuase it doesnt understand the PCrel function that the disassembler used. And it complained about the addressing modes. I am assuming everything in a driver is going to be a relative addressing mode, because it doesnt know what the OS is doing and where the OS places it in memory. You would think anyway...

Ill try the macsbug thing, ill probably use a terminal program and try to talk to the modem. This way, i can see what address the modem resides.

[Trash80toHP_Mini]

Why don't you guys just post in Sanskrit or . . .

I've re-titled your hack thread, lemme know if it's acceptable . . .

< drags knuckles back to cave workshop to take his frustrations out on a blank of flint, flaking atlatyl dart points . . . >

[techknight]

it seems as if your pissed off at us about something?

[gobabushka]

No, I just finished reading all of this. I think he's actually impressed. I know I am.

[Trash80toHP_Mini]

Not a chance, RUN WITH IT!!!!!!!!!!! Go team 68kMLA!!!!!!!!!!!!!

Dinosaurs get pissed off at themselves for becoming Dinosaurs!

BTW: check the last post of the first page, I requested a suitable title and offered to change it to anything you suggested. This stuff if fabulous!

I'm just embarrassed that I can't follow even 10% of a great discussion/learning experience/hacking project . . .

edit: Right on the money! I am VERY impressed!

[gobabushka]

Hey, don't feel too bad. I'm right there with you barely following this. I've always wanted to be that level of hacker but couldn't. So I'll sit on the sidelines and cheer y'all on. I'm with Trash80toHP_Mini, keep goin with this. It's projects like this that keep our old machines alive and still productive.

PS: Great example would be the NADSBox at club100

[techknight]

ok. good. I was just afraid. Well you know how it is, a person can read text a 1000 different ways and put thier own assumed personality to it. Sorry