[Diagram]SCPH-1000/3000 PU-7 MM3 Stealth Install
[Diagram]SCPH-1000/3000 PU-7 MM3 Stealth Install
Hi Community, It started when I bought a SCPH-3000 from eBay. Because these Japanese Systems are not that common here in the EU.
I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.
There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.
And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.
(Click on the pic)
PS1 is love
2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.
I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know
I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.
There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.
And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.
(Click on the pic)
PS1 is love
2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.
I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
Oh, that's really nice of you. I suppose similar points will be present on the PU-8 series? Up until now, it was thought that those boards wouldn't support full stealth chips.
You didn't get this unit from "h-ecke" by chance?
You didn't get this unit from "h-ecke" by chance?
Here you go, full stealth is also possible on PU-8, you're right. However, the diagram below is not mine. So i didn't test it yet. But it should just work!
(All credits go to an unknown guy from EurAsia forums)
Please Ignore that strange looking chip on the left top of the board, its for some kinda color correction he said.
Only the Numbers are for the Modchip install.
I will do a proper PU-8 diagram in the future, but these boards are pretty expense here.
Edit: Oh and yes "h-ecke" sold them to me.
(All credits go to an unknown guy from EurAsia forums)
Please Ignore that strange looking chip on the left top of the board, its for some kinda color correction he said.
Only the Numbers are for the Modchip install.
I will do a proper PU-8 diagram in the future, but these boards are pretty expense here.
Edit: Oh and yes "h-ecke" sold them to me.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
Awesome, thanks!
There's also many install pics around for the later PSX boards, where they tell you to grab a reset signal from all across the other side of the board. This is so silly, as the same signal is right there at the HC05, near Pin13.
There's also many install pics around for the later PSX boards, where they tell you to grab a reset signal from all across the other side of the board. This is so silly, as the same signal is right there at the HC05, near Pin13.
What you call Pin 13 on that 52pin HC05 is pin 20 on a 80pin HC05.
Yes that Pin 13 is connected to the reset lane. So a physical reset actually resets the drive controller too. One of the PS1 PCB reset lanes is like this: PSU-->Reset Signal-->?Diode?-->Resistor-->HC05(Drive controller)
So, in theory it should also be possible to take it straight from the PSU reset signal (As on mine PU-7)
I guess they took another point on newer PS1 because its easier to solder on, or they were lazy who knows
Yes that Pin 13 is connected to the reset lane. So a physical reset actually resets the drive controller too. One of the PS1 PCB reset lanes is like this: PSU-->Reset Signal-->?Diode?-->Resistor-->HC05(Drive controller)
So, in theory it should also be possible to take it straight from the PSU reset signal (As on mine PU-7)
I guess they took another point on newer PS1 because its easier to solder on, or they were lazy who knows
Last edited by Traace on May 3rd, 2017, 6:41 am, edited 1 time in total.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
I honestly think they didn't have service manuals and were too lazy to ring out a better connection point :p
Thats pretty neat that you were able to figure that out, nice work!Traace wrote:Hi Community, It started when I bought a SCPH-3000 from eBay. Because these Japanese Systems are not that common here in the EU.
I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.
There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.
And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.
(Click on the pic)
PS1 is love
2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.
I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know
No! I hate modchip diagrams! Can somebody explain why those modchip diagrams always consist of nothing but numbers and arrows? I understand that commercial modchip manufacturers don't want other people to figure out how modchips are working. But if you don't have that kind of commerical interests, and if you know that one of the pins is a Reset signal, why can't you annotate that as "Pin Y = Reset"?
Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.
Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?
Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.
Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?
Well this one is made for a public release in mind therefore I didn't make it to "complicated". I understand your point and its a pretty good one. Normal People just don't care what signal comes to what pin/point, they don't care how this chip actually works. It might also to consider that most people just don't have the time to read a couple of ps1_specs pages(thanks for that btw) think about what they read there and apply their new knowledge afterwards.Sad but true. In my opinion we have to change the peoples mind first, so we don't confuse them with more advanced diagrams that nobody can apply.nocash wrote:No! I hate modchip diagrams! Can somebody explain why those modchip diagrams always consist of nothing but numbers and arrows? I understand that commercial modchip manufacturers don't want other people to figure out how modchips are working. But if you don't have that kind of commerical interests, and if you know that one of the pins is a Reset signal, why can't you annotate that as "Pin Y = Reset"?
I just tested normal anti-modchip games(like The Legend of Dragoon US) in my SCPH-3000 tho, to get it running i had to patch the boot to JPN of course. You refer to them correct?nocash wrote: Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.
I hope that helps(80-pin QFP):
Code: Select all
VDD - pin 1 -> Mainbaord VDD
GP5/T1CKI/OSC1/CLKIN - pin 2 -> Unused for MM3
GP4/OSC2/CLKOUT - Pin 3 -> Connected to HC05 Pin 42 (This one has something to do with Stealth support)
GP3/MCLR/VPP - Pin 4 -> Mainboard Reset
VSS - pin 8 -> Mainboard VSS
GP0/CIN+/ICSPDAT - pin 7 -> ? I/O with GP1 ?
GP1/CIN-/ICSPCLK - pin 6 -> ? I/O with GP0 ? -> Connected to HC05 pin 32
GP2/TOCKI/INT/COUNT - pin5 -> Unknown
Yes, it comes from a SCPH-3000 Systemnocash wrote: Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?
Last edited by Traace on May 4th, 2017, 7:37 pm, edited 1 time in total.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
I'm sure you/we/someone can add a small legend to your diagram, saying what point is what
Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p
Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee
Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p
Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee
Thanks for the pin-outs & confirming that it's a SCPH-3000 board! I've added a note in the http://www.psxdev.net/forum/viewtopic.p ... 4284#p4284 thread, saying that the 424660 cdrom/firmware is also used on that board.
Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?
HC05 pin32/80 is PortB,bit1, ie. the SCEx signal transferred at 250 baud, connecting there makes sense for modchips.
HC05 pin40/80 is PortC.bit1, ie. the SPI-bus output, which should be unused in pre-SCPH-9000 consoles. That doesn't make sense to me.
HC05 pin39/80 is PortC.bit0, ie. the SPI-bus input, that would make more sense (to watch the SUBQ signal for knowing the position & when to output SCEx on which sectors).
The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).
Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?
HC05 pin32/80 is PortB,bit1, ie. the SCEx signal transferred at 250 baud, connecting there makes sense for modchips.
HC05 pin40/80 is PortC.bit1, ie. the SPI-bus output, which should be unused in pre-SCPH-9000 consoles. That doesn't make sense to me.
HC05 pin39/80 is PortC.bit0, ie. the SPI-bus input, that would make more sense (to watch the SUBQ signal for knowing the position & when to output SCEx on which sectors).
The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).
-
Shadow Verified
- Admin / PSXDEV
- Posts: 2670
- Joined: Dec 31, 2012
- PlayStation Model: H2000/5502
- Discord: Shadow^PSXDEV
I'll write a program to do it. Easy enough. Read the ROM into RAM, CRC32 it and then print the results on screen.nocash wrote:Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
Yes,true. thanks for the noticerama3 wrote:I'm sure you/we/someone can add a small legend to your diagram, saying what point is what
Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p
Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee
It ain't goes to HC05 40 (my eyes lied:D ). The correct Pin is HC05 42 ( I edit the pinout above)
Seems like that is the reason why we still need to patch the region of a US,EU Game to JPN in order to run them on Japanese systems.nocash wrote:The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
Shadow, those tools already exist. There is a checker tool that displays the BIOS CRC and compares it to a known list.
Another tool can dump the BIOS to memory card or over SIOCONS.
http://forum.redump.org/topic/4991/new- ... l-cd-unit/
http://www.psxdev.net/forum/viewtopic.php?f=66&t=395
Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.
Another tool can dump the BIOS to memory card or over SIOCONS.
http://forum.redump.org/topic/4991/new- ... l-cd-unit/
http://www.psxdev.net/forum/viewtopic.php?f=66&t=395
Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.
HC05 pin42/80 is PortC.bit3, ie. drive SPEED, the TOC/SCEX is read at single-speed, and other sectors are (normally) read at double speed, so that should actually work for sensing when to output the SCEX signal, but only if the games are really using double speed (which might apply for most or all games, but it would be very easy to produce a game that defeats that kind of modchips by using single speed for SCEX reading).
Ah, and, at double speed, the SCEX signal would be 500 baud instead of 250 baud, and the cdrom firmware won't recognize 500 baud signals at all. Ie. at double speed, the game can't really detect if there's a 500 baud SCEX string coming from the disc (instead, it can only detect if a modchip outputs a 250 baud SCEX signal despite of running in double speed mode).
The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).
Ah, and, at double speed, the SCEX signal would be 500 baud instead of 250 baud, and the cdrom firmware won't recognize 500 baud signals at all. Ie. at double speed, the game can't really detect if there's a 500 baud SCEX string coming from the disc (instead, it can only detect if a modchip outputs a 250 baud SCEX signal despite of running in double speed mode).
The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).
Unfortunately I just bricked my old German "PS Hacker v2" yesterday (Hate those clones anyway ), but yes it should workrama3 wrote: Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.
That's interesting, thanksnocash wrote:HC05 pin42/80 is PortC.bit3, ie. drive SPEED, the TOC/SCEX is read at single-speed, and other sectors are (normally) read at double speed, so that should actually work for sensing when to output the SCEX signal, but only if the games are really using double speed (which might apply for most or all games, but it would be very easy to produce a game that defeats that kind of modchips by using single speed for SCEX reading).
When I leave HC05 pin42/80 disconnect from the Modchip, Stealth is not given anymore, the rest (beside region patching) works.
Oh, the tool above is pretty nice.
CRC "3539DEF6"
Romstatus "Dumped"
"Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
System Rom "1.1 01/22/1995"
Edit: Both SCPH-3000 were tested now. Same result.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
Okay, thanks. The extra-info that I was after is the part number (the whole text on the ROM chip), the package (40pin?), and the board name and mechacon part number (ie. PU-7, 1-655-322-15 and 42660 (unless the other SCPH-3000 board is different)).Traace wrote:CRC "3539DEF6" ...Romstatus "Dumped" ..."Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
Just check here to see how the whole info should look like: http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065
Or, if you could make a photo of the PCB front side would be nice, too. Currently you've only the back side.
Ahh I see, It shouldn't be a problem to look that up. You can expect that information this weekendnocash wrote:Okay, thanks. The extra-info that I was after is the part number (the whole text on the ROM chip), the package (40pin?), and the board name and mechacon part number (ie. PU-7, 1-655-322-15 and 42660 (unless the other SCPH-3000 board is different)).Traace wrote:CRC "3539DEF6" ...Romstatus "Dumped" ..."Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
Just check here to see how the whole info should look like: http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065
Or, if you could make a photo of the PCB front side would be nice, too. Currently you've only the back side.
Update: http://www.psxdev.net/forum/viewtopic.p ... 290#p12290
Last edited by Traace on May 8th, 2017, 12:55 am, edited 1 time in total.
Gaming Devices (Sony only):
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
PS1: 1xSCPH-7502 (Still unmodded)
PS2: 1xSCPH-70002 (FMCB)
PS3: 1xCECHG04 4.81.2 Rebug CFW
-
Shendo Verified
- C Programming Expert
- Posts: 250
- Joined: Mar 21, 2012
- I am a: Programmer
- Motto: Never settle
- PlayStation Model: SCPH-7502
- Discord: ShendoXT
- Location: Croatia, EU
Oh, first I actually only published dumper in the .exe form but I got a bunch of people PMimg menocash wrote:The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).
for instruction on burning a working CD. So instead I published a bin/cue image.
I attached exe in the dumper release thread.
Dumper also shows CRC32 but I haven't included a "already dumped check".
If anyone wants to improve upon it I released the source.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.
-
TriMesh Verified
- PSX Aptitude
- Posts: 225
- Joined: Dec 20, 2013
- PlayStation Model: DTL-H1202
- Location: Hong Kong
It's pretty much a hack. Mayumi (and MM3, since it appears to have been largely copied from Mayumi) there are two different operating modes depending on which sort of board the chip is installed in.nocash wrote: Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.
On PU-7 / PU-8 / PU-18 / PU-20, the code attempts to work out where in the boot sequence the console is by monitoring the X1/X2 speed control line. It's not as simple as just switching the data on and off - there are a series of delays for each part of the boot, and the speed line is basically used just as a hint to know exactly where the boot is right now. You can't just gate the data using the speed line because the anti-modchip test is carried out using CD-Audio play mode, and that's X1 too.
Basically the logic is:
After reset or door close, delay for a bit (two different delays for reset or door close) then start looking for the speed to switch to X1 (first protection check) - after this is detected, wait for the speed to switch back to X2 and start another timer. Then wait for the speed line to go back to X1 again (second protection check - this is also why it screws up on the very early boot ROM, since that doesn't have this check). At this point, it just waits for the door switch and then the whole cycle repeats.
That's the basic process - the code also has some code to detect the situation where you are booting using something like Caetla rather than the boot ROM, since that changes the timing and using the same timing as the original boot ROM would make the console fail the second protection check.
On PU-22/PU-23, it's a lot simpler. This is a special mode that's enabled when the chip is installed in a newer console (what used to be the modchip gate line is connected to WFCLK on the newer boards, and the code looks for a clock on this pin and if found enables PU22/PU-23 mode). In this mode, the chip monitors the XLAT line between the control MCU and the servo amp chip and cuts of the SCEx strings when it detects a pulse on it. There is also an initial delay so that it isn't triggered by the setup phase when the chipset is reset. It's basically relying on the fact that the MCU doesn't talk to the servo amp during the read TOC phase, but does as soon as it's finished. Despite (or maybe because of) it's simplicity, this mode works really well.
Who is online
Users browsing this forum: No registered users and 1 guest