-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Carrera040 Info / Hacking Thread
- Thread starter joethezombie
- Start date
Bolle
Well-known member
I already posted my findings on that somewhere around here in another thread but can't seem to find it right now.
Basically the card actually works when running on a 040 but the mode setup of the DAC fails most of the time for some reason. That also fails with the Carrera 040 so you don't want to switch resolutions or color-depth or your screen will get all white or have funky colors.
Problem with the Turbo 040 is that it is always running in 040 mode so the mode setup of the XCeed fails right away when initializing the card on bootup. In one out of like 20 times it will set a mode where you are slightly able to see what's going on and can navigate your way to the monitors CP.
From there you can start switching modes over and over again and eventually you will get a useable picture.
Not sure if the mode setup is handled in the driver or if the problem is sitting somewhere in the hardware.
Basically the card actually works when running on a 040 but the mode setup of the DAC fails most of the time for some reason. That also fails with the Carrera 040 so you don't want to switch resolutions or color-depth or your screen will get all white or have funky colors.
Problem with the Turbo 040 is that it is always running in 040 mode so the mode setup of the XCeed fails right away when initializing the card on bootup. In one out of like 20 times it will set a mode where you are slightly able to see what's going on and can navigate your way to the monitors CP.
From there you can start switching modes over and over again and eventually you will get a useable picture.
Not sure if the mode setup is handled in the driver or if the problem is sitting somewhere in the hardware.
Bolle
Well-known member
So how did I get this to work after all?
As said earlier we found out that the Carrera would load succesfully when the 16MHz bus clock signal gets shifted 180° before being sent to the accelerator. Everything we could test besides onboard video did work fine that way.
When looking for the cause of the onboard video issues we poked at a lot of different things without much success. @GeekDot disassembled the SE/30 video ROM, dug through the Turbo 040 ROM in search for hints if they patched anything SE/30 related in there and spent countless hours staring at MacsBug :tongue:
Me being useless for this kind of stuff kept poking around with the logic analyser hoping to find any clues on what's going on.
I hooked up some probes to the VRAM to easily find video write cycles and looked at the data bus on the logicboard (starting at D24-31 which connect to the VRAM) hoping to find that we were just experiencing some bad timing on the output drivers of the C040 which caused that no valid data was present on the bus when it should have been there. That was not the case though. Hold times for the data lines and all VRAM related write signals were good. Instead the data outputs have just been turned off for 1 out of 4 bytes that were written to the VRAM.
I went ahead and soldered probe sockets to data pins D24-31 right on the 68040 on the C040 to see what's going on there. No big surprise the data seemed to be there, so for some reason it does not make it's way through the output buffers to the logicboard bus but only for always the same single byte out of the four bytes that get written with each access. The driver is just dumping video data onto the screen base address in longwords. Those longwords get split up into 4 separate bytes when written to the 8 bit wide VRAM.
We took a step back to think about this. The 68040 also supports dynamic bus sizing just like the 68030 but the output byte lanes differ between those two depending on the state of SIZ0-1 and A0-1.
The Motorola design handbook also mentions this in the section about running a 040 on a 030 bus. The proposed design to implement a circuit to shift data around between the bytelanes using muxes does allow for most combinations to work but hints that a full mesh of all bytelanes was considered too complex regarding part count.
On the Carrera the data buffering and bytelane swapping is all done in the two FPGAs so we couldn't easily observe what exactly the logic is doing.
What we could see though is that on VRAM writes all signals named above (SIZ0-1 and A0-1) are cycled through all possible combinations that make sense for byte-wise writing a longword (just as you would expect)
With the bytelanes being spread over both FPGAs I would guess that they also did not implement the possibility to swap all bytelanes around between each other just like the circuit in the Motorola design book.
For one combination of the bus sizing signals the bytelane that's actually connected to the VRAM stays silent on the outputs of the FPGA.
I went on to check what's going on on the other bytelanes. On the LA I could see that there is data present as well on all other data lines even though those are not connected to the VRAM.
To investigate if the data on the other lanes is actually video data that might be useful I desoldered the VRAM from one of my logicboards and installed it again usign a small interposer board so I could route the other bytelanes to the VRAM to see what is going on on them and if any of them produces a useful picture.
Turned out the other lanes contain image data but it is mostly useless:
However when looking at the output of one byteline something interesting caught my attention:
Compare that to the image containing the missing bytes:
As you can see the missing data on the VRAM bytelane (D24-31) is present on another bytelane that otherwise has data that is useless.
To get this straight I cut through some data lines on my adapter and wired in two buffers. One just switches D24-31 back and forth on reads and writes, the other one puts data from D16-23 to D24-31 whenever there is an access to the VRAM location that contains the white stripes.
The address decoding and control logic to do this is implemented in a single GAL. On all other bus accesses the second buffer stays turned off and data is pushed around normally on D24-31.
I modified the decoder to support PDS cards and testing looks good so far that all cards I have here seem to work just fine.
As said earlier we found out that the Carrera would load succesfully when the 16MHz bus clock signal gets shifted 180° before being sent to the accelerator. Everything we could test besides onboard video did work fine that way.
When looking for the cause of the onboard video issues we poked at a lot of different things without much success. @GeekDot disassembled the SE/30 video ROM, dug through the Turbo 040 ROM in search for hints if they patched anything SE/30 related in there and spent countless hours staring at MacsBug :tongue:
Me being useless for this kind of stuff kept poking around with the logic analyser hoping to find any clues on what's going on.
I hooked up some probes to the VRAM to easily find video write cycles and looked at the data bus on the logicboard (starting at D24-31 which connect to the VRAM) hoping to find that we were just experiencing some bad timing on the output drivers of the C040 which caused that no valid data was present on the bus when it should have been there. That was not the case though. Hold times for the data lines and all VRAM related write signals were good. Instead the data outputs have just been turned off for 1 out of 4 bytes that were written to the VRAM.
I went ahead and soldered probe sockets to data pins D24-31 right on the 68040 on the C040 to see what's going on there. No big surprise the data seemed to be there, so for some reason it does not make it's way through the output buffers to the logicboard bus but only for always the same single byte out of the four bytes that get written with each access. The driver is just dumping video data onto the screen base address in longwords. Those longwords get split up into 4 separate bytes when written to the 8 bit wide VRAM.
We took a step back to think about this. The 68040 also supports dynamic bus sizing just like the 68030 but the output byte lanes differ between those two depending on the state of SIZ0-1 and A0-1.
The Motorola design handbook also mentions this in the section about running a 040 on a 030 bus. The proposed design to implement a circuit to shift data around between the bytelanes using muxes does allow for most combinations to work but hints that a full mesh of all bytelanes was considered too complex regarding part count.
On the Carrera the data buffering and bytelane swapping is all done in the two FPGAs so we couldn't easily observe what exactly the logic is doing.
What we could see though is that on VRAM writes all signals named above (SIZ0-1 and A0-1) are cycled through all possible combinations that make sense for byte-wise writing a longword (just as you would expect)
With the bytelanes being spread over both FPGAs I would guess that they also did not implement the possibility to swap all bytelanes around between each other just like the circuit in the Motorola design book.
For one combination of the bus sizing signals the bytelane that's actually connected to the VRAM stays silent on the outputs of the FPGA.
I went on to check what's going on on the other bytelanes. On the LA I could see that there is data present as well on all other data lines even though those are not connected to the VRAM.
To investigate if the data on the other lanes is actually video data that might be useful I desoldered the VRAM from one of my logicboards and installed it again usign a small interposer board so I could route the other bytelanes to the VRAM to see what is going on on them and if any of them produces a useful picture.
Turned out the other lanes contain image data but it is mostly useless:
However when looking at the output of one byteline something interesting caught my attention:
Compare that to the image containing the missing bytes:
As you can see the missing data on the VRAM bytelane (D24-31) is present on another bytelane that otherwise has data that is useless.
To get this straight I cut through some data lines on my adapter and wired in two buffers. One just switches D24-31 back and forth on reads and writes, the other one puts data from D16-23 to D24-31 whenever there is an access to the VRAM location that contains the white stripes.
The address decoding and control logic to do this is implemented in a single GAL. On all other bus accesses the second buffer stays turned off and data is pushed around normally on D24-31.
I modified the decoder to support PDS cards and testing looks good so far that all cards I have here seem to work just fine.
Last edited by a moderator:
olePigeon
Well-known member
I'm not technical in any way, so I tried to follow what you were saying. So demuxing would be breaking up the longer instructions into 2 smaller instructions so an '040 can run on an '030 bus, but that sometimes messes things up because it was (at the time) cost prohibitive and difficult to make a chip that could account for every possible permutation and reroute said data? So looking at your pictures, you were getting a mostly good picture but missing some of the byte information, which you then discovered was being sent somewhere else that you initially thought was useless data ... one of the few times (as mentioned in the Motorola handbook) where the data wouldn't be routed correctly after being demuxed. So now you can direct that errant byte to where it supposed to go, and now you have 100% of the bytes going where they need to? Resulting in a good picture?
Is that right?
If not, either way, sounds exciting.
One down, Applied Engineering TransWarp 040, Fusion Data TokaMac SX, TechWorks NuBUS 040, Total Systems Magellan 68040, Impulse Performance/040, Interware Booster, and Mobius Technologies Speedster to go! (just kidding. :grin: )
Is that right?
If not, either way, sounds exciting.
One down, Applied Engineering TransWarp 040, Fusion Data TokaMac SX, TechWorks NuBUS 040, Total Systems Magellan 68040, Impulse Performance/040, Interware Booster, and Mobius Technologies Speedster to go! (just kidding. :grin: )
Last edited by a moderator:
Bolle
Well-known member
In case of the SE/30 video system at least. Not sure about any other cases where the logic on the C040 might not get it right but they don't seem to matter.
Daystar must have accounted that special occasion on their accelerator already. They are kind of following the Motorola design with the pre-ASIC T040 so I would guess it behaves in a similar way.
Sounds about rightIs that right?
You forgot the Sonnet Presto 040 in your list. Curious if that would work with the same hack. The Mobius Speedster will just work as it is the exact same hardware as the Carrera. Micromac just got their hands on the design probably after Mobius went out of business.
According to what @GeekDot heard from some Micromac guy the FPGA design was done by even another company (called "Fusion" if I remember right)
olePigeon
Well-known member
@Bolle Fusion Data, probably. They made the Tokamak line of accelerators, and were the only company that actually followed through with their IIfx accelerator. I believe it required them to make new GALs (ROMs?) to fix a hardware glitch that Apple never fixed in the IIfx which prevented people from actually releasing 040 accelerators for the IIfx PDS slot. You had to mail in your IIfx board where they replaced them and installed the accelerator.
I think there're maybe 2 people that I know of that have one, and 1 person who has the accelerator but not he modified motherboard (so the accelerator doesn't work.)
Edit: Just an afterthought. A IIfx adapter would be cool, but I'm sure would be very expensive.
I think there're maybe 2 people that I know of that have one, and 1 person who has the accelerator but not he modified motherboard (so the accelerator doesn't work.)
Edit: Just an afterthought. A IIfx adapter would be cool, but I'm sure would be very expensive.
Last edited by a moderator:
Is this a correct summation of the problem:
---------------------------------------------------------------------------
The SE/30 has only an 8 bit data path to the VRAM (D24 - 31).
This requires byte-wise writes to the VRAM, instead of using the 680x0's normal 32 bit data path. This uses a feature of the 680x0 chips called Dynamic Bus sizing.
The 68030 uses a different control signal scheme to signal/setup Dynamic Bus Sizing than the 68040.
In some circumstances, the data for the VRAM which should have been on D24-31 would be on D16 - 23 (which the VRAM can't see) because the 68040 interprets the dynamic bus sizing scheme differently and the GALs/logic on the upgrade card doesn't compensate properly for that particular case.
So software which sets Siz0-1 and A0-1 properly to get 8 bits of data out on D24-31 on the 68030 causes the 68040 to output that data on a different set of data lines?
---------------------------------------------------------------------------
Cool work. What a wonderful job of investigation. I enjoy the way you just casually build interposers for your probing. I imagine there's much more labor spent on those tasks than your off hand mention would suggest.
Seems disappointing to me that the data path to VRAM is only 8 bits wide. Aren't there two VRAM chips? Are they only 4 bits wide each?
---------------------------------------------------------------------------
The SE/30 has only an 8 bit data path to the VRAM (D24 - 31).
This requires byte-wise writes to the VRAM, instead of using the 680x0's normal 32 bit data path. This uses a feature of the 680x0 chips called Dynamic Bus sizing.
The 68030 uses a different control signal scheme to signal/setup Dynamic Bus Sizing than the 68040.
In some circumstances, the data for the VRAM which should have been on D24-31 would be on D16 - 23 (which the VRAM can't see) because the 68040 interprets the dynamic bus sizing scheme differently and the GALs/logic on the upgrade card doesn't compensate properly for that particular case.
So software which sets Siz0-1 and A0-1 properly to get 8 bits of data out on D24-31 on the 68030 causes the 68040 to output that data on a different set of data lines?
---------------------------------------------------------------------------
Cool work. What a wonderful job of investigation. I enjoy the way you just casually build interposers for your probing. I imagine there's much more labor spent on those tasks than your off hand mention would suggest.
Seems disappointing to me that the data path to VRAM is only 8 bits wide. Aren't there two VRAM chips? Are they only 4 bits wide each?
Bolle
Well-known member
PCBs just arrived and I had to quickly cobble a test-candidate together:
Works like a charm with the Carrera 040. One tiny little mistake slipped beyond me before ordering the boards though. Why test things before ordering boards when you know it should work in theory
So for the PowerCache and Turbo 040 to still work with the additional components there's a simple patch wire needed.
Hate it when this happens. At least it's on the back so you won't see it :tongue:
It's been built to offer maximum flexibility... if you only want to use Daystar accelerators there are solder bridges under one of the buffers:
The buffers and control GAL just won't be populated and it basically the same as the old adapter that way.
Gonna do some more compatibility testing now and then I'll build a few adapters for everyone.
Works like a charm with the Carrera 040. One tiny little mistake slipped beyond me before ordering the boards though. Why test things before ordering boards when you know it should work in theory
So for the PowerCache and Turbo 040 to still work with the additional components there's a simple patch wire needed.
Hate it when this happens. At least it's on the back so you won't see it :tongue:
It's been built to offer maximum flexibility... if you only want to use Daystar accelerators there are solder bridges under one of the buffers:
The buffers and control GAL just won't be populated and it basically the same as the old adapter that way.
Gonna do some more compatibility testing now and then I'll build a few adapters for everyone.
jessenator
Well-known member
That's a beaut!
Trash80toHP_Mini
NIGHT STALKER
Fabulous, once again, Bolle. I see you're buffering address lines (for video?) or control signals? Had you bodged them onto the original design to get up and running?
Bolle
Well-known member
It's data lines. I mirror D17-23 into D24-31 just at the right moment to get rid of the white stripes we were having earlier.
Then yes
Cut through the traces on the adapter and jumpered them over to the playground board.
You mean this?
Then yes
Cut through the traces on the adapter and jumpered them over to the playground board.
Trash80toHP_Mini
NIGHT STALKER
LOL, lost that alternative while editing. Sixteen lines had me thinking it was the data for video. :
Nice perf board bodge, had you bread boarded first and then built something more reliable with test points for the LA?
Nice perf board bodge, had you bread boarded first and then built something more reliable with test points for the LA?
Last edited by a moderator:
Bolle
Well-known member
Got lazy in the middle of soldering wires and just stuck them in on top.
Those are the unbuffered data lines from D16-23 that are injected into D24-31.
Having them on dupont wires allowed me to quickly move them to D0-7 or D8-15.
I built it on a perf board right away as I had to solder wires to the adapter anyways.
The LA wasn't needed afterwards, because I could actually see what's going on on the builtin CRT.
You can however see some soldered on LA pins sticking out of the back of that 040 socket
Those are the unbuffered data lines from D16-23 that are injected into D24-31.
Having them on dupont wires allowed me to quickly move them to D0-7 or D8-15.
I built it on a perf board right away as I had to solder wires to the adapter anyways.
The LA wasn't needed afterwards, because I could actually see what's going on on the builtin CRT.
You can however see some soldered on LA pins sticking out of the back of that 040 socket