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.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
10bT in Duo Modem Slot - not my hack . . .
- Thread starter Trash80toHP_Mini
- Start date
I guess one way to find out is use easy68k and simulate the sucker. Pretend there is a driver call or something.
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.
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.
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.
Why don't you guys just post in Sanskrit or . . . 8-o
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 . . . :I >
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 . . . :I >
it seems as if your pissed off at us about something?
No, I just finished reading all of this. I think he's actually impressed. I know I am.
Not a chance, RUN WITH IT!!!!!!!!!!! [
] ]'> Go team 68kMLA!!!!!!!!!!!!! :approve:
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!
] ]'> Go team 68kMLA!!!!!!!!!!!!! :approve: 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!
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
PS: Great example would be the NADSBox at club100
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 
NoPro! I put "not my hack" in the title so the rest of the gang would take this project seriously! :lol:
edit: Holy crap, Batman! Two Full Pages of serious reverse engineering already . . . and counting!
edit: Holy crap, Batman! Two Full Pages of serious reverse engineering already . . . and counting!
FWIW, I've added mappings for a near full disassembly of the CTP drivers, and a mostly complete disassembly of the DSP driver.
duodsp4.dsk
Nothing popped out at me while disassembling, but I haven't followed it closely. I mostly just set up the mappings.
From the Duo System devnote, it's probably somewhere in the $5000 0000 - $5FFF FFFF range, since that's dedicated to IO devices.
duodsp4.dsk
Nothing popped out at me while disassembling, but I haven't followed it closely. I mostly just set up the mappings.
From the Duo System devnote, it's probably somewhere in the $5000 0000 - $5FFF FFFF range, since that's dedicated to IO devices.
Somewhere? ROFL.... thats a pretty large range. But in the devnote some of this could be eliminated
Well i could take the brute-force method out, wiring the modem slot address/data lines to buffers and then to LEDs.
Then using a small BASIC app i could rotate through the addresses until I hit the one that lights the LEDs. Bad thing about this, is if there is a configuration register or data direction register somewhere that has to be set before this bus will operate, but i doubt it.
Then using a small BASIC app i could rotate through the addresses until I hit the one that lights the LEDs. Bad thing about this, is if there is a configuration register or data direction register somewhere that has to be set before this bus will operate, but i doubt it.
i tried your new disk image, I keep getting map goes to high on the fdisasm.
Yea, I must be missing something. I cannot get this to disassemble with your new setup.
I might have to pull out my 68K duo instead of my PPC duo running OS8. And put a fresh load of system 7 on my 68k duo, and try it again. On a hardware note, I wonder if i will trip any system errors or GPFs if i "scan the band" if you know what mean, until i find the one that controls the modem.
I've been (and will probably continue to be for a week or so) distracted, but...
It sounds like your file doesn't match my file. You'll probably need to get the DRVRs from 7.1, like what I've got.
But... Are you sure the data pump is wired into the address space at all? The PowerBook Duo System devnote includes a pinout of the modem connector, and it is pretty modem specific. No address or data lines in the description.
It sounds like your file doesn't match my file. You'll probably need to get the DRVRs from 7.1, like what I've got.
But... Are you sure the data pump is wired into the address space at all? The PowerBook Duo System devnote includes a pinout of the modem connector, and it is pretty modem specific. No address or data lines in the description.
No, becuase they are not listed in the Devnote. Why they didnt list them, I have no idea. There isnt even a hint of a serial port either. Just control lines they list. I guess it wasnt intended for 3rd party manufacturers to produce modems.
However If you pull the datasheet to the RCV144DPL, you will notice that the IC requires a Data and Address control bus. The IC does also give you a full RS232 serial port, but its Synchronous (USRT) so it requires a clock signal for the Send and Receive control lines, its for the V.24 compressor. But its all done in software/CPU i think on the duo. Plus, why would they have 50 pins on the connector? almost all of them are used it appears.
However If you pull the datasheet to the RCV144DPL, you will notice that the IC requires a Data and Address control bus. The IC does also give you a full RS232 serial port, but its Synchronous (USRT) so it requires a clock signal for the Send and Receive control lines, its for the V.24 compressor. But its all done in software/CPU i think on the duo. Plus, why would they have 50 pins on the connector? almost all of them are used it appears.
Similar threads
