Note that MHZ does not equal MIPS. I don't know how the AVR does it but the PIC chips for example need four (!) clock cycles to execute one instruction. The SX series of chips need only one cycle for most of the instructions. That's why a SX chip running at 50MHZ is more or less equal to 50MIPS.

I seriously doubt anything below 50MIPS is going to work. I had a hard time getting code for a SX just right in order to let it do some patching on fly to get the drive out of recovery mode. But it did work in the end. 

I'm missing the point. First you will need the MCU, second you will need a flash EEprom. Then you will also need a PCB. Software for the MCU and also a PC program needs to be designed. And the device has to be connected to the dvd-rom drive flash EEprom by using at least 30 (!) wires.

All this to 'piss off' a few modchip makers? You didn't even wrote any of the patched firmwares so what's all the fuss about?
Why not simply grab a USB adapter, connect the drive to a PC and be done with it? 

With all due respect, your intentions weren't very clear at all and still aren't very clear. Second eprom? Which second eprom? Why is it needed? How can you flash it with only 2 wires? Which drive do you target? A schematic would be nice. If you simply want to design a circuit which can flash an EEprom then all the talk about LA timing measurements becomes irrelevant. What happened to your original Flash EEprom project by the way?

I might be missing something, but how can a AVR cpu be fast enough? I read in this thread that a 1MHZ AVR would be enough? How can that be? The main DVD CPU controls the OE line, it expects valid data at a particular time. FPGA ok, SX ok, AVR? hmmmm ..

Perhaps it's read-only?

Why not? 

Well, the drive has to seek the disc. It has to read important parameters like the booktype, as I said before: "the booktype is part of a sector which contains other important information besides the book-type.". I think all the low-level hardware stuff (seeking/focussing/laser calibration) is done outside of the main firmware. I do not think it's a job of the firmware, it seems the firmware simply communicates to the outside world by using some low-level hardware registers. In this case, the firmware does not know and has to know in advance what kind of disc in in the drive. It simply has to read the physical format data sector to find out. It's very easy to spot the book-type dectection routine in the firmware, to me it even seems to default to dvd-rom. But bitsetting a burner already forces the book-type to be set to dvd-rom, there's need to force that value to another value.

I haven't seen such statements yet, otherwise I would have posted a reply.

I seriously don't think so.

Why don't you try it without the kit? There's no need for any kit to use this method.

The ubuntu device manager show 'bridge', this is a good sign. Then simply do: ./modeb /dev/sdc and the drive should be in modeb.

Which method? NOPing? The whole NOPing talk is a bit pointless. You have to know exactly what and when to patch/NOP. The boot problems were related to bugs in the patching code which were fixed later on.

You mean something like a bus (logic) analyser? The answer is still and remains no. The data bus is encryped.

Are you talking about movies or games?

I think some clarifications are needed.

The FULL raw original SS (security sector) can be found in the Hitachi RAM memory at 0x00035CE0. The header is 12 bytes long, that's why the normal sector data starts at 0x00035CEC. When I'm talking about offsets, offset 0x0000 = 0x00035CEC

The first 16 bytes are nothing special, they are a copy of the physical format data sector with some minor changes. These bytes also contain the game partition PSN start / end range and layerbreak. They are the same on each disc and are required for the drive to function properly.

The Xtreme SS is a replica of the original SS but with some custom changes made by C4E, I will mention the changes briefly.

The data at 0x200 contains a simple table with all challenges and responses for each CID (challenge ID / entry).
First 4 bytes for the challenge, then 4 bytes for the response and 1 byte is zero, probably the response modifier. This data repeats a couple of times.
This is the data which can NOT be extracted from the Hitachi drive without a custom made firmware.

The CPR_MAI challenge key has been relocated to offset 0x2D0.

At offset 0x661 and 0x730 you will find another table. This table contains the plaintext (descrambled) *drive* challenge/response table.
In the original firmware these offsets contain a scrambled table which is normally descrambled by the drive using the CPR_MAI challenge key.

This is all we currently know about the security sector. The first 0x600 or so bytes are returned to the console and also contains
the *host* version of the challenge/response table. But this data is encrypted/signed just like in xbox1. It's not known how to descramble this
table, this was actually possible on the xbox1.

The function of any other data / offsets is simply unknown.

You should ask yourself the following question: if I can't read the physical format data sector, why would it reliably read any other sector? It isn't as easy as you make it sound, the booktype is part of a sector which contains other important information besides the book-type.

Time to move this thread. I don't see any technical information and / or hacking going on.

If you need / want any help clearly state which media AND burners you have tried. Recommended is: Pioneer 111d + Verbatim.

The book-type isn't 'detected', it's read from the physical format data sector. And if it can't read this sector then it also can't determine the book-type.

Another funny fact, people report that some games always boot at first try and others don't. Yes, it's weird.

Thanks for reporting this. Well then, it seems that way too many factors play a role to pinpoint the actual cause. Can the original Hitachi firmware be blamed or is the Xtreme Hitachi firmware faulty? Without any feedback or support from C4E we can't be really sure. I don't feel the need to analyse the rushed Xtreme firmware, it does have it's share of problems. Mainly related to the very easy way to detect a backup. People will be disappointed sooner or later, detecting a backup is child's play. If I was a game developer I could create an update, put in on Live and block all backups of the game in one go NOW.

No matter how you look at it, it's odd that some people have a 100% success rate with for example a Pioneer 111d and the Xtreme Hitachi firmware. Those people should have problems too if there would be a bug in the firmware don't you think?

If there was a serious problem with the Hitachi firmware then backups made with a Pioneer burner also shouldn't work, but they do. I think the Pioneer burner burns backups which are more 'compatible' with original discs. It probably does something funny with the lead-in / lead-out.

In my experience, if the drive has troubles booting a backup then it's not even able to read the physical format data from the lead-in and this happens very early on. It tries to focus/read a sector but fails for whatever reason.

The booting problems anita999 describes were related to: bug in challenge/response patch, incorrect physical format data patch. After these problems were corrected discs booted each and every time as far as I know.

I have also noticed that an older Hitachi drive boots a backup everytime while a recent Hitachi drive does not? This and the fact that people have good success with the Pioneer does not lead me to believe there's a serious problem with the Hitachi firmware.