Jump to content

REDuser ethics


Jaron Berman

Recommended Posts

  • Premium Member
I don't think you understand the concept of a hard drive failing. So there isn't any point in trying to persuade you that it's not Red's fault.

 

I think you need to remember who you are talking to. I have a degree in Computer science and I used to be a Game Programmer by trade. I certainly understand the concept of a hard drive failing. But I also know that it's not as common as you think if the build quality is good. Granted, I haven't used hard drives for cameras, only computers. But in computers, a hard drive is generally usable unless the boot sector becomes corrupt in which case the hard drive is effectively useless. Honestly, I've never had a hard drive completely fail on me. I've had bad sectors in spots but never a full out failure with irrecoverable data. Such a crash is uncalled for, even in the hard drive department.

 

It's quite funny that you would assume that I know nothing about hard drives because I shoot on film. I wrote a custom boot strapper for a home made OS (not a Linux kernel) out of ASM language without screwing up my hard drive. I think I may understand hard drives and the way they are constructed a little better than you.

Link to comment
Share on other sites

  • Replies 242
  • Created
  • Last Reply

Top Posters In This Topic

I never knew who I was talking to in the first place. The assumptions I made were based on the fact that you continued to ignore that hard drive failures are a short coming of the digital acquisition workflow on a whole, and not just one company's problem. I never said that failures are common. But backing up digital data is nothing new, and should be a standard procedure for a workflow with any digital camera.

Link to comment
Share on other sites

When people begin to use a new technology they will always suffer issues because the workflow and job assurance responsibilities are different. When P2 technology first arrived we had dozens of reports of issues, but in the end when we do a database search, of the many thousands of P2 cards we've sold, I can count the card failures on one hand, and most of them were initial failure straight out of the box.

 

The technology works. It is almost always the users new to the technology that is to blame.

Link to comment
Share on other sites

It wasn't any harddrive...it was a RED raid drive. If it's so unreliable, why would they even sell it? It seems like this whole RED thing is Caveat Emptor. It's no wonder some of us stick with film. What good is 4k if it never makes it to the editing table?

 

 

Just want to point out that RED Raid drives haven't shipped yet. Red drives have, I have four myself, but the solid state raids have not yet shipped.

Link to comment
Share on other sites

  • Premium Member
Stephen, may I ask if you own a RED? Rumors on REDuser.net is that you do. I don't believe it unless I here it from your mouth.

Stephen and myself co-own a Red One. We are very happy with it.

Link to comment
Share on other sites

Film is great. I/we/RED has never questioned that. RED is an alternative to film (now saying this for the 3rd time)... and it seems like a reasonable one. Spinning drives suck. We all know that. They work 98.5% of the time and then they don't. This is no big secret. You don't have to be Matthew (with his degree) or Ray Charles to see this one. That is why people shooting serious projects on RED are all shooting to Compact Flash. We hope to release our Flash Drives shortly... along with a 16GB CF card. In the near future no one will need a spinning drive for RED, or anything else for that matter.

 

Jim

Link to comment
Share on other sites

  • Premium Member
Don't hard drives fail no matter who they're from? Red or anybody else? So isn't it a risk you take with any digital camera that records to a hard drive? How can you blame Red for something they can't control, or anyone for that matter. Hard drives sometimes fail, it's a fact of life.

But are we talking an actual hard drive failure, or simply a corrupted file on an otherwise perfectly sound hard disk unit? Can they be successfully re-formatted for another attempt?

 

Apart from the 40 gig hard disk that came with the computer I bought about 5 years ago, I have never paid for a single hard disk for it. I have however been able to massively expand my PCs storage space using hard disks that other people have declared beyond all human aid, and given to me "for the magnets"!

 

One low-level format later, and they almost invariably work perfectly.

 

All I am saying is that a lot of so-called "hard disc faults" are simply software problems, often the result of people's ineptitude or possibly the case getting thumped at precisely the wrong moment.

 

Ordinary 3 1/2" form factor hard disk units are intended to be mounted in a desktop computer case and thereafter never moved when the computer is running. Laptop type drives are designed to withstand a bit more abuse, but there is still a limit to what they will put up with. If your laptop falls off your lap while the drive is running, the consequences can be disasterous.

 

Anybody remember the Avid CamCutter (c.1995)? At the time it sounded like a major newsgathering breakthrough - a hard disk based storage unit that could bolt onto an ENG camera in place of an SP Betacam recorder. All the advantages of what we now know as "Non Linear Editing" were suddenly available in the field. Apart from being able to edit a fast breaking news story and go straight to air via a portable microwave link, the CamCutter could be set up on continuous record ready to capture Bill Clinton's next trouser moment and so on.

 

It was way ahead of its time of course, because they soon found that ordinary computer hard disks were hopeless for run and gun type newsgathering. OK for a static shot on a tripod, but if you are going to do that, you might as well just microwave it to the station and record it there.

 

Even cheap home video cameras based on hard disks have to have elaborate early shutdown systems to detect if the camera is in the process of being dropped, park the hard disk and switch to buffer RAM unil the disk can be safely used again.

 

And don't talk to me about optical disk cameras, where one little scratch can make a disk unuseable and unrecoverable. Mini DV still has an awful lot going for it! (So does HDCAM for that matter).

 

The point is, in static computers, the hard disks themselves don't fail all that often, the problem is nearly always the signals driving them.

 

Anyway, why can't somebody simply produce a module that will take say 16 cheapo 4G SD cards and parallel-access them. That way just about any speed SD card would work, and you could shop around for the best bulk deal.

Edited by Keith Walters
Link to comment
Share on other sites

  • Premium Member
I wrote a custom boot strapper for a home made OS (not a Linux kernel) out of ASM language

Interesting -- I used to write 8086/8088 assembly code. There are fun things like filling the prefetch que with register increments, and then overwriting the code in memory with NOP's to see how long the que is -- that's a way of identifying which of the early Intel chips you were running on. Now the chips return an ID if you want. What chips did you write to?

 

 

 

-- J.S.

Link to comment
Share on other sites

There are fun things like filling the prefetch que with register increments, and then overwriting the code in memory with NOP's to see how long the que is -- that's a way of identifying which of the early Intel chips you were running on.

 

John that sounds interesting. Care to illustrate a little more how you used to do this trick? Thanks.

Link to comment
Share on other sites

  • Premium Member
What chips did you write to?

 

Define "write to?" You don't really "write to" CPUs. With the 8086, you use CPU registers as extremely temporary holders of data which I guess you can argue are "written to." But honestly, registers are just there to aid the CPU in arithmetic functions. Also, they can be used to set hardware interrupts based upon the values of certain key registers. (Let me not forget their use as movers of data to memory! Also help Push and Pop the stack...ok, they are the shiznit.)

 

To answer your question, I wrote code for the basic 8086 system. Honestly, there isn't a massive difference between the 8086 and the 80386 except for longer addressing schemes (32-bit segments and registers), and expanded interrupt handling. But the system is backward compatible and the logic is easy to utilize once you've mastered 8086.

Link to comment
Share on other sites

  • Premium Member
John that sounds interesting. Care to illustrate a little more how you used to do this trick? Thanks.

 

 

Here's the subroutine I was referring to. The 8088 had a 4 byte prefetch queue, the 286 was 8 bytes, the 386 16 bytes, and the 486 onward had larger queues, but didn't necessarily keep them full, so the length test was irrelevant.

 

 

(Edit to add: Unfortunately this board doesn't retain the columns. "Fetchlen" and "Marker" should be labels.)

 

 

FetchLen:

; Finds the length of the processor's prefetch queue, returns it in DX:

; A certain number of the INC DX's after the REP STOSB will

; be executed because they get into the CPU's prefetch queue

; before the REP STOSB replaces them with NOP's.

; Both INC DX and NOP are single byte instructions.

 

mov cx,cs

mov ds,cx

mov es,cx ; Point all segments to code,

cld ; normal direction, just to be safe.

 

mov di,off(marker) ; point to the INC DX's

xor dx,dx ; start DX at 0

 

mov al,090h ; 90h is the opcode for NOP, and

mov cx,0000Ah ; we want to write ten of them.

 

cli ; no interrupts during self-modification

repz ; Write ten NOP's over the INC DX's.

stosb

marker:

inc dx ; Ten INC DX's, of which only the ones

inc dx ; in the queue when REPZ STOSB runs

inc dx ; will get executed before they're

inc dx ; overwritten by NOP's

inc dx

inc dx

inc dx

inc dx

inc dx

inc dx

 

; Put the INC DX's back so that the routine can run again.

mov al,042h ; opcode for INC DX

mov cx,0000Ah ; ten of them

mov di,off(marker) ; back where they were

repz

stosb

 

sti ; allow interrupts again

ret

 

 

Now, isn't that a weird piece of code? ;-)

 

 

-- J.S.

Link to comment
Share on other sites

  • Premium Member
mov cx,cs

mov ds,cx

mov es,cx ; Point all segments to code,

cld ; normal direction, just to be safe.

 

mov di,off(marker) ; point to the INC DX's

xor dx,dx ; start DX at 0

 

mov al,090h ; 90h is the opcode for NOP, and

mov cx,0000Ah ; we want to write ten of them.

 

cli ; no interrupts during self-modification

repz ; Write ten NOP's over the INC DX's.

stosb

marker:

inc dx ; Ten INC DX's, of which only the ones

inc dx ; in the queue when REPZ STOSB runs

inc dx ; will get executed before they're

inc dx ; overwritten by NOP's

inc dx

inc dx

inc dx

inc dx

inc dx

inc dx

 

Just think, back in the day ASM was considered user-friendly. :lol:

Now they have high-level languages that you can practically talk in slang to.

Link to comment
Share on other sites

  • Premium Member

I have to post a code snippet of my last game project since John posted a code snippet. This is done a routine I wrote for a tile loader for a game I wrote written in Visual C++ with inline assembler.

 

void TILE_HANDLER::LoadSpriteV3(int TileInst, int left, int right, int top, int bottom,

int LibTileNum)

{

/* This app is the workhorse of the whole thing.*/

int AbVert; //Absolute vertice reference point

float Xref, Yref;

int Ysolve,Xsolve; //Algebraic

float Xpos, Ypos; //Actual coords of texture data

 

//Calculate texture data

Xref = (float)1/LIB_X_TILES;

Yref = (float)1/LIB_Y_TILES;

//Solve for X/Y (Asm)

_asm{

mov eax, LibTileNum ;

shr eax, 5 ;

mov Ysolve, eax ;

mov eax, LibTileNum ;

mov ebx, Ysolve ;

shl ebx, 5 ;

sub eax, ebx ;

mov Xsolve, eax ;

}

//Figure out texture coords now

Xpos= Xsolve * Xref;

Ypos= Ysolve * Yref;

 

//Vertice data here

AbVert= TileInst * 6; //Have reference point now!

int i;

for(i=0;i<6;i++) //Unchanging

{

square[AbVert+i].rhw = 1.0f;

square[AbVert+i].z = 0.0f;

}

square[AbVert].x = (float)left;

square[AbVert].y = (float)top;

square[AbVert].tu = Xpos;

square[AbVert].tv = Ypos;

square[AbVert+1].x = (float)right;

square[AbVert+1].y = (float)top;

square[AbVert+1].tu = Xpos+Xref;

square[AbVert+1].tv = Ypos;

square[AbVert+2].x = (float)left;

square[AbVert+2].y = (float)bottom;

square[AbVert+2].tu = Xpos;

square[AbVert+2].tv = Ypos+Yref;

square[AbVert+3].x = (float)right;

square[AbVert+3].y = (float)top;

square[AbVert+3].tu = Xpos+Xref;

square[AbVert+3].tv = Ypos;

square[AbVert+4].x = (float)right;

square[AbVert+4].y = (float)bottom;

square[AbVert+4].tu = Xpos+Xref;

square[AbVert+4].tv = Ypos+Yref;

square[AbVert+5].x = (float)left;

square[AbVert+5].y = (float)bottom;

square[AbVert+5].tu = Xpos;

square[AbVert+5].tv = Ypos+Yref;

 

return;

}

Link to comment
Share on other sites

  • Premium Member
Yes surely, it is.

There's lots more where that came from:

 

 

* Prefetch Queue Measurement

 

* Flag Forcing

 

* Stack Pointer Push

 

* Shift to Oblivion

 

* Segment Wraparound

 

* Ascii Adjust Number Base Change

 

* Hardware Interrupted Repeat & Segment Override

 

* INT 6 Trapping of Undefined Opcodes

 

* MOVSB/MOVSW/MOVSD Bus Width Comparison

 

 

But we're probably way too far off topic by now. I can send you everything from my old CPU identification file as e-mail attachments, if you'd like.

 

 

-- J.S.

Link to comment
Share on other sites

  • Premium Member
Well, it is compared with machine language. Isn't "Inc DX" a whole lot clearer than "042h"? ;-)

 

Yeah, but I still think less than 0.5% of the population is capable of ASM programming. I only use it when I have to which anymore is only inline. Writing full ASM modules is not a task I would look forward to these days.

Link to comment
Share on other sites

Hi Max,

 

We bought it from a Mr Boddington, I don;t want to reveal the serial no due to possible warantee issues. ;)

 

Stephen

Well, after that nice Mr Rhodes wrote out such a positive technical evalution, how could you not?

(I have to say I was really moved by the man's humility, in admitting how wrong he was. You just don't see that sort of thing any more).

Link to comment
Share on other sites

  • Premium Member

I know Max is pulling my leg now. Max wouldn't lower himself to associate himself with a digital medium. I honestly believe Max uses film to record family scrapbook material in addition to movie projects. Max is the ultimate purist and for that, I admire him. I love film but even I don't have a problem with DI or telecines. Sometimes I think it would be fun to actually cut on film.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

Forum Sponsors

Broadcast Solutions Inc

CINELEASE

CineLab

Metropolis Post

New Pro Video - New and Used Equipment

Gamma Ray Digital Inc

Film Gears

Visual Products

BOKEH RENTALS

Cinematography Books and Gear



×
×
  • Create New...