• 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.

Carrera040 Info / Hacking Thread

Kinda like taking stuff apart to see what's inside before powering up to see if it works? [:D]

Cool, so it's not multiprocessing, it's flip flopping control of the bus as needed? My scanned info and ill considered WAG was something I doubted after the edit window closed.

.  .  .  there's a ton of SwapMMUMode calls in the code...
Click to expand...


Might flip flopping bus control between 68030 MMUMode and 68040 MMUMode to set the system up CPUDIS flip or flop be the reason for those all those calls in the driver?

edit: What's the mechanism within the IIci schematic for CPUDIS synthesization?

p.s. BBCode works much better when you remember the switches. :blink:

 
Last edited by a moderator:
Ah-ha!

It does get to the point to tell the Carrera to take over on the SE/30 as well.

Bildschirmfoto 2018-02-23 um 20.00.33.png

That does tell us at least that the SE/30 is not deaf on the address range and the Carrera does indeed respond to the loading INIT.

EDIT: It's also not the onboard video that's making problems here. Removed VROM and stuck in the Pivot... crashes in the same spot.

 
Last edited by a moderator:
Forgot that... 7.1, MODE32, stock ROM, 32bit enabled.

EDIT: I also wonder where that CPUDIS signal is going on the IIci motherboard.

DCaDftMF says:

[SIZE=11pt]The CPUDIS signal [/SIZE][SIZE=10pt]is [/SIZE][SIZE=11pt]used during diagnostic testing to disable the Mc6s030 on the main logic [/SIZE][SIZE=12pt]board [/SIZE][SIZE=11pt]and tristate its outputs. An emulator in the cache card can assert CPUDIS and, after waiting for the [/SIZE][SIZE=12pt]end [/SIZE][SIZE=11pt]of the current bus cycle, drive all signals. [/SIZE]
Click to expand...

 
Last edited by a moderator:
Dang! I was hoping to infuse a bit more compatibility, good job! [;)]

Have we got IIci and IIcx or IIx Schematics available. Wondering about CPUDIS and if the IIci can be reverse engineered to the point that we can introduce logic to produce it onto the passive IIcx adapter at the very least.

Thought I'd posted this one cleaned up in the Performer thread. Guess not, but here it is from the raw screen shot:

68030-SMT.JPG

My primary suspect on the IIci's MC68030 is Pin 65 /MMUDIS, solder on another wire to check to see if it blips when CPUDIS does its thing on the Cache Slot?

edit: joe, could you buzz pin 65 to see if and where it might land on the Carrera IIcx adapter's ersatz IIci Cache Slot?

 
Last edited by a moderator:
Trash80toHP_Mini said:
might flip flopping bus control between 68030 MMUMode and 68040 MMUMode to set the system up CPUDIS flip or flop be the reason for those all those calls in the driver?
Click to expand...
Just for clarification: SwapMMUmode has nothing to do with 030 vs 040. This most often called function switches from 24 (dirty) to 32 (clean) mode... and back.

It needs to be called as soon you need to access anything beyond 8MB.

 
Bolle said:
Ah-ha!

It does get to the point to tell the Carrera to take over on the SE/30 as well.

View attachment 21724

That does tell us at least that the SE/30 is not deaf on the address range and the Carrera does indeed respond to the loading INIT.
Click to expand...
Very nice! Good to have you in same „setup state“. 

How many probes does your LA have? Can you check/see 0x53000000 activities (in and out)?

I‘m getting closer and closer to the crash point... the tricky thing is, that the CP crashes into the grey boot screen, even from MacsBug. So a simple „go“ and the look at the PC/SP, stack and registers doesn’t work here...  

Here's an example getting closer to the "point of no return", CP icon loaded, back in enumeration of the init resources...

/monthly_2018_02/large.Macsbug.jpg.cb7f53876e8d2a79b817835556eb58eb.jpg

A 2nd screen would help, but my Color Pivot doesn’t have a cable and I prefer spending time with understanding the code than hunting for parts.
(Will have just the next week before going on vacation for 16 days...)

 
Last edited by a moderator:
GeekDot said:
You took the V1 from this archive, right? That's what I'm using on my SE/30, too.

Which System version are you running? Have you installed it "for every Macintosh" as described in the Carrera ReadMe? 

Error 10 explained:

"There are many routines in the Macintosh ROM that can be called by placing instructions in a program that aren't in the 68000's vocabulary. When the 68000 encounters such an instruction, it looks it up in the instruction table. This table gives the location of routines paired with each instruction. If it finds an entry in the table for the instruction, it branches to the routine. If there's no entry for the instruction, you see one of these errors."

What kind of ROM is yours? I'm using the BMoW image in an Rominator II. 
Click to expand...
Yes, V1 from that archive. I am running System 7.5.3 with the 1.8b1 extension. I think the ROM is based on a IIsi and has patched the ROM/RAM check and has a boot disk, the ROM SIMM was built by Doug. It looks like you are running an older OS, I wonder if you might get to a further debug point if your try a later one?

 
Trash80toHP_Mini said:
Have we got IIci and IIcx or IIx Schematics available. Wondering about CPUDIS and if the IIci can be reverse engineered to the point that we can introduce logic to produce it onto the passive IIcx adapter at the very least.

My primary suspect on the IIci's MC68030 is Pin 65 /MMUDIS, solder on another wire to check to see if it blips when CPUDIS does its thing on the Cache Slot?

joe, could you buzz pin 65 to see if and where it might land on the Carrera IIcx adapter's ersatz IIci Cache Slot?
Click to expand...


This diagram would be more suitable for the Iicx adapter:

68030-BACK.jpg

/MMUDIS is not connected to any pin the CACHE slot on the adapter.

CPUDIS is not connected to any pin on the CPU socket

Also, notice /BR /BG and /BGACK are pin disconnected from the logicboard's CPU socket, instead relying on the CPU present on the adapter.

 
Nice work on that diagram, joe. I figured the QFP pinout was a bit less confusing and is numbered for doing schematic doodling.

What are the relationships between the PowerCache adaptation of the oddball memory addressing control signal setup SE/30 and the way such is handled in the IIsi and now the IIcx?

Gotta be something there? Happy to see my crazy WAGs being knocked down systematically, BTW. [:)]

 
Running out of jumper wires and could use a second analyser already :p

At least I could find some calls to 0x53000000... still learning how this thing works.

IMG_4030.JPG

 
Ha ha!  I love seeing these things being ripped apart and analyzed.   I did the same to crack the equations on the DayStar adapter, using a 90deg angle socket to expedite analyzer lead connections:

IMG_1422rr.jpg

But I digress, back to the job at hand....

The IIcx adapter is a simple 1:1 for all signals that exist on the IIci CACHE slot.

The only difference, as explained prior, is /BR, /BG, and /BGACK (used for bus arbitration) are pin disconnected from the main logicboard.  Instead, those signals are isolated to the adapter's onboard 68030.  Signals on the CPU that don't exist on the CACHE slot are simply not connected.  Likewise with CACHE signals not present on the CPU, also being not connected.

Once my 68030 sockets arrive, I will attempt using the IIcx adapter in the SE/30.

 
I wonder if we should leave some of the undocumented connections open on the adapter and only connect the bare CPU signals... My guess still is that they might use the presence of certain signals to detect the exact hardware. If only bare 030 signals are connected at all it leaves us with only the IIcx or IIx...

 
Something about this IIci screen is naggin' at me:

View attachment 21723

/CPUDIS state change for a cycle occurs on the same edge as "Pin Disconnected on IIcx Adapter" /BR, and /BGACK signals change state. This happens within the window where "Pin Disconnected on IIcx Adapter" /BG Low.

Done with WAGs for the time being, just wondering what happens in the IIcx where /CPUDIS does not exist and the three bus arbitration signals are "pin disconnected" for such a cycle?

edit: the SE/30 PDS slot's borked bus mastering setup (as differentiated from IIsi in DCaDftMF) has been nagging at me all along, but now  .  .  .

 
Last edited by a moderator:
Regarding the IIcx adapter, I have a Daystar one that lacks an onboard 68030. Not sure if knowing this is useful in the investigation or if the Carrera IIcx adapter (or whatever that was earlier in thread) is supposed to be different.

Interested to see where this thread leads.

4966095F-C27F-4CFB-9FEE-C0987F6D6E84.jpeg

 
You must log in or register to reply here.
Back
Top