Finally handling BD+ (?)

pc_trace.bin: http://uploaded.to/?id=vk3u12

cmd01_trace.bin: http://uploaded.to/?id=ppqht6
cmd02_trace.bin: http://uploaded.to/?id=w66t6q
cmd19_trace.bin: http://uploaded.to/?id=dfkqk2
cmd35_trace.bin: http://uploaded.to/?id=t8scb6
cmd38_trace.bin: http://uploaded.to/?id=cp2j1y

Each "trace" extends beyond the first trap call.

It is difficult to get this so please be patient. I will post the remaining files as soon as possible.

[Disabled]

Thanks a lot, that might already help. The VM is ok for 17 ADDs (that are a whooping 226 instructions) and has a bad register on the 18th with 7 instructions inbetween. I'll look into it and report back.
Btw: You recorded them in little endian, did you?

*edit* I didn't find anything usefull. There are 3 registers and one memory adress involved between the two adds that might provoke the error. And they could of course be wrong because something entirely else is wrong I don't know about...
I made a little statistic of the ops used till that point:

Op0(0):Op1(18):Op2(0):Op3(0):Op4(0):Op5(0):Op6(0):Op7(0):Op8(0):Op9(1):OpA(0):OpB(0):OpC(0):OpD(3):OpE(0):
OpF(0):Op10(0):Op11(0):Op12(0):Op13(1):Op14(0):Op15(0):Op16(4):Op17(1):Op18(9):Op19(21):Op1A(0):Op1B(8):
Op1C(4):Op1D(0):Op1E(0):Op1F(0):Op20(0):Op21(0):Op22(2):Op23(0):Op24(0):Op25(0):Op26(0):Op27(0):Op28(0):
Op29(0):Op2A(0):Op2B(0):Op2C(4):Op2D(6):Op2E(7):Op2F(38):Op30(15):Op31(0):Op32(0):Op33(0):Op34(0):Op35(43):
Op36(0):Op37(0):Op38(41):Op39(0):Op3A(0):Op3B(0):Op3C(0):Op3D(0):Op3E(0):Op3F(0)

Originally Posted by Disabled

You recorded them in little endian, did you?

yes.

Originally Posted by Disabled

I didn't find anything usefull.

I also recorded a trace of the program counter. (see above). I think that should help you.

[Disabled]

Thanks a lot, the PC might help. At least it reduces the possible wrong registers to two as a jump is not taken. The cmd2 trace does not help though, as there is no SUB till that point, but it might help in the future.

*edit* If you can dump the registers real quick, a dump after the 125th cmd (PC=1AB74) might be usefull...

*edit* I'm done here for today. If every trace has the same difficulty no matter what cmd you trace, please try to do the ones with a high apperance like Op 0x35 (LDW) or 0x38 (SDW) or 0x19 (ADDIE).

*edit* I hacked the code to correct the PC after it didn't jump. After that the PC and ADDs are correct for another 230 instructions, that are 20 instructions after the first trap and this time its the correct trap #110h and you already did a memdump and regdump at that time. The registers are all correct at that point, but the mem looks utterly different... wait its little endian... ok, now there are just a few instances where they differ. But a lot is written correctly to the memory so my SDW has to be ok (and no other store is used). So the error has to be somewhere else...

*edit* I did some intensive testing but didn't find anything. I tried to look at every command issued until the first error occurs. With comparisons I changed the outcome and I just deactivated some other commands. The theory was that if one cmd is wrongly implemented, if I change them the first error would still be issued at the same place (or later if I accidently corrected it). But with every cmd I tested, the error came early or I could somehow other rule that cmd out. I'm a little puzzled now, what could be the problem.
Our memdumps differ at 3 locations. The first is 0x0000 where you overwrite it with zeroes. Then there are two locations, the one is 16 bytes you overwrite with FFs the last one is 40 bytes you again overwrite with 00s thats all. I don't write to these adresses at all (I at least scanned for accesses to adress 0x0000 without success). But you stored 00s and ffs that appear pretty often, so if they go somewhere else, they probably won't produce a different mem compared to the source...

[derbeDeus]

In an older post you had

Originally Posted by Oopho2ei

Is there a list of BD+ discs so i could choose which one to buy?

Edit: here are some:
28 Days Later
28 Weeks Later
August Rush
Cast Away
Dan in Real Life
Die Hard 1-4
Dogma
...

I don't think
August Rush (Warner)
Dan in Real Life (Walt Disney)
Dogma (Sony)
Gattaca (Sony)
No Country for Old Men (Walt Disney)
Sleuth (2007) (Sony)
are BD+ titles. They are just titles released on March 11, 2008 together with Hitman, Independence Day and I Robot from Fox.
The only titles that have BD+ so far are the ones from Fox and MGM (but that's still Fox contribution).

[ala42]

The load and save commands of the post #23 simulator can not work. Big and little endian cpus use the same address order when accessing bytes, shorts and longs. Shorts and longs have a different byte order. When emulating a big endian cpu on a litte endian cpu you have two choices:
- swap the bytes for long and short accesses
- swap all longs during program load time and swap addresses for short and byte accesses. No byte swapping needed as this is already done at load time. Longs can be read as they are, shorts can be read as they are from a modified address (XOR 2), bytes can be read as they are from a modified address (XOR 3). This will work only if short and long accesses are made on word boundaries.

The post #23 simulator uses a mixture of both, byte swapping and address swaping, which can not work.

Originally Posted by bmnot

By the way, what's actually the long term goal of the BD+-VM? I'd say, bringing it to a form in which it can be easily integrated into other programs such as KenD00's DumpHD (which is by the way Java, too).

A open source reference design (written in a well known programming language) of a working emulator. I hope KenD00 will find the time to add BD+ support to DumpHD.

Originally Posted by Disabled

If you can dump the registers real quick, a dump after the 125th cmd (PC=1AB74) might be usefull...

ok

Originally Posted by Disabled

If every trace has the same difficulty no matter what cmd you trace, please try to do the ones with a high apperance like Op 0x35 (LDW) or 0x38 (SDW) or 0x19 (ADDIE).

I will have them soon.

Originally Posted by Disabled

The registers are all correct at that point, but the mem looks utterly different... wait its little endian... ok, now there are just a few instances where they differ. But a lot is written correctly to the memory so my SDW has to be ok (and no other store is used). So the error has to be somewhere else...

This is a memory snapshot directly before program execution starts: http://uploaded.to/?id=5rgdzs

Also i haven't studied the exception handling (of e.g. division by zero) yet. So if an exception occurs the result of an instruction is currently undefined. I assume you just ignore them?

Originally Posted by derbeDeus

I don't think
August Rush (Warner)
Dan in Real Life (Walt Disney)
Dogma (Sony)
Gattaca (Sony)
No Country for Old Men (Walt Disney)
Sleuth (2007) (Sony)
are BD+ titles. They are just titles released on March 11, 2008 together with Hitman, Independence Day and I Robot from Fox.
The only titles that have BD+ so far are the ones from Fox and MGM (but that's still Fox contribution).

I took the list from: http://www.avsforum.com/avs-vb/showthread.php?t=993757. Do you think BD+ will soon no longer be used?

[Disabled]

Originally Posted by Oopho2ei

This is a memory snapshot directly before program execution starts: http://uploaded.to/?id=5rgdzs

Shouldn't that be exactly the first 2MB (minus header) from the 20MB file you gave us? Padded with zeroes of course.
I'm not at home right now to compare that myself.

And you are right. I don't handle exceptions and overflows and such in any way, so they are just passed from c++ to the vm.
Perhaps it would be better to invest time into that first, as it has to be done anyway and if the errors occur because of that, I will never find them unless perhaps you post the trace for every command issued.

@ala42 That VM in post #23 was never in production, it was a prototype and never ran a single line of BD+ code. But please have a look at the vm in post #60 and feel free to comment or add or restructure the code in any way you like. Sadly it is not the latest copy I have at home, but all I added was debugging code, so the VM should handle everything excactly the same way.

[ala42]

The vm from post #60 does the same swapping of both data and addresses, so it has the same problem.

Originally Posted by Disabled

Shouldn't that be exactly the first 2MB (minus header) from the 20MB file you gave us? Padded with zeroes of course.
I'm not at home right now to compare that myself.

It should be (except the conversion from big endian to little endian you should do). But maybe it is changed before execution. You can check that now. Making a snapshot is done very easily compared to getting those traces.

Originally Posted by Disabled

I will never find them unless perhaps you post the trace for every command issued.

I have added cmd35 and the others will probably follow until these issues are fixed. See posting #61.

Also please listen to the suggestions from ala42. This big endian/little endian conversion and addressing could be our problem.

I have looked at the first trap call "trap_110". It has 5 parameters:
trap_110(0x1A64C, 0x5550, 1, 0x5570, 7);

Parameter 1,2 and 4 are compared with the memory size (0x400000).
Parameter 3 (p3) is used to calculate the following: 192*p3+408 = 600 (258h). The result (600) is compared with 0xFFFFFFFF.
The last parameter (parameter 5) is first compared with 0xFFF10000 and then with 6. The result of all this is a status code 0x80000001 which is stored in r01. Depending on the parameter values passed the status code changes 0x80000000, 0x80000002 and others. The last parameter seems to specify which function is finally called. With those parameters as give above the selected function simply returns after a short check and both memory and register file (except r01 which takes the status code) remain unchanged.

Now any ideas what this trap could be good for?

[Disabled]

Originally Posted by ala42

The vm from post #60 does the same swapping of both data and addresses, so it has the same problem.

Sorry I didn't answer your post accordingly the last time, Im not at home till saturday and will have access to the net very rarely.
As I understand you say there is a problem with accessing word and byte length memory are you? Till the first error occurs, there are only word length accesses to the memory, so I ignored the correctness of these commands till now.

I compared your memory dump and it is indeed different to the 0000.whatever file. A quick analysis showed two parts are different and those were exactly those I missed in the comparison before the first trap. There still seems to be a difference before the first trap that isn't in your last dump of the mem.

Your newly posted cmds traces showed the first error occured after the 40th cmd issued, but that was due to the the B3FFFFFC in my mem where your mem has a 00000000. So I ran the mem_setup.bin and then the first error occured at an interesting point:
*edit* I wrote "0x19 (ADDIE)" so you dumped 0x19 and named it 0x18, as 0x18 is the opcode of addie, so the following is wrong */edit*

76
     20CA4 E0410004 SDW R2, R1, #4h
00:02:04:7C vs 00:02:04:7C
R1:1150, R2:2047C, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
77
     20CA8 60420400 ADDIE R2, R2, #400h
00:00:11:5C vs 00:02:08:7C

So R2 contains the right data after the 76th cmd issued, but if I add 400 its wrong? I can't figure out how your "thing" is calculating this, but then again its late, so I'll leave this question to another one/time.
Last minute analysis: I think I at least did an error in dissassembling the addie cmd (for the screen output), I think I used the unextended immediate. But then 400 is the same in both and I'm pretty sure the vm itself used the right immediate...
Thats it for today.

[ala42]

Originally Posted by Disabled

Sorry I didn't answer your post accordingly the last time, Im not at home till saturday and will have access to the net very rarely.
As I understand you say there is a problem with accessing word and byte length memory are you?

Correct. As posted above, big endian and little endian cpus use the same addresses when accessing bytes, so the LB/SB handler must not change the address with xor 3. Same for the LW/SW opcodes.

Post #20 tells you to do the xor 3 (^3). The only logical reason is that the byte order is already swapped inside all 32 bit words, so this has to be corrected. When you check the memory dumps posted later you see these dumps are already swapped, as expected.

You have to decide on which data the simulator should run: Original like in the svm files or pre-swapped like in the dumps. The simulator Oopho2ei is analysing obviously uses the pre-swapped data for performance reasons running on a little endian cpu, as the word and long data do not need to be swapped each time when reading instruction words or data. The disadvantage is that byte and word addresses have to be modified, but this still might be faster.

I hope this clears up the confusion a bit

There seem to be only two traps with 5 parameters:

UINT32 TRAP_Aes(UINT8 *dst, UINT8 *src, UINT32 len, UINT8 *key, UINT32 opOrKeyID);

and

UINT32 TRAP_PrivateKey(UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID);

By the way, here's a nice list of the traps, as taken from the patent text (more details on traps are also in this text: http://appft1.uspto.gov/netacgi/nph-...DN/20070033419):
http://uploaded.to/?id=tb40lb

Now i think that trap 110 is TRAP_Aes:

By specification, the last parameter of TRAP_Aes (opOrKeyID) can have the values (0xFFF10000), (0xFFF10001), (0xFFF10002) or (other). And you said, it was compared to 0xFFF10000 in your trace... Maybe this call of trap 110 is executing some kind of AES-setup / AES-check?

For TRAP_PrivateKey, the last parameter seems to be 0 in most cases.

So, I recommend to read the details on TRAP_Aes and TRAP_PrivateKey in the patent text. Anyway, if it's not TRAP_Aes, then I would guess it's some new trap which is not documented in the patent text..

[KenD00]

Originally Posted by Oopho2ei

I hope KenD00 will find the time to add BD+ support to DumpHD.

Time seems to be the minor problem this time, knowledge is the bigger one . I really enjoy reading this thread, very interesting stuff but honestly, assembler just isn't my language. If this progresses to something like BD+-Aligned Unit in -> Aligned Unit out i will gratefully use it .

A general note regarding the "traces" from posting #61 and others: If an instruction fails with an error/exception the result is omitted from the "log". So only increment the counter for commands which completed successfully.

Originally Posted by schluppo

Now i think that trap 110 is TRAP_Aes:

This may be right. To decrypt the section 2 of file 00001.svm trap #110 is used like this:

for (i=...,i<...;i++) {
... // some code
trap_110(....)
... //some code (see posting #34)
trap_230(...) // this is trap_xorblock(...)
... // some code
}

[derbeDeus]

Originally Posted by Oopho2ei

I took the list from: http://www.avsforum.com/avs-vb/showthread.php?t=993757. Do you think BD+ will soon no longer be used?

No, I was just looking for a BD+ list. I saw that link too and only Fox tiles were BD+.
I'll make a separate thread to maintain an up-to-date list of BD+ titles.

And yes, 110 is TRAP_Aes

[Disabled]

Wow I feel a little stupid. First everyone seems to know more than me about the VM and then I again made a stupid error.
I asked for the trace of 0x19 (ADDIE) but ADDIE is 0x18, so you dumped 19 and namend it 18, that was the error in the previous post.
I corrected the filename and then there the cmd 0x19 didn't seem wrongly implemented.
The first error that occurs now is after an LB, so now the endianess might catch me. I will investigate and report back.
Indeed the LB loaded a wrong adress and after I changed it, the VM works flawless! I can't find a single problem until the 840th cmd is issued, that is trap 520 and after that, things go wrong...

[Inventive Software]

Progress so far is amazing gents, I await the results with baited breath.

here's some thoughts (edit: that is thoughts as in "ideas", not thoughts as in "usable c-source") about how to implement the traps into a vm (according to oopho's trace of trap executions).

switch (trap_number) {
        ...
        case 110: TRAP_XorBlock(r29, r29+4, r29+8);
        ...
        case 230: r01 = TRAP_Aes(r29, r29+4, r29+8, r29+12, r29+16);
        ...
	default: break; //trap_number unknown
}

void TRAP_XorBlock(UINT32 *dst, UINT32 *src, UINT32 len)
{
UINT32 *d;
UINT32 *s;
memcpy(d,dst,len);
memcpy(s,src,len);
dst = d ^ s;
}

UINT32 TRAP_Aes(UINT8 *dst, UINT8 *src, UINT32 len, UINT8 *key, UINT32 opOrKeyID)
{
// implement AES according to patent specification here
}