AtariAge Forums: AtariAge Forums -> EricBall's Tech Projects

Both my new Dell (very fast and near silent) and the two ATI HDTV Wonder cards arrived this week. So after backing up the old system last night I tried to install Mythbuntu today.

The install itself went okay. I think most of the problems I had were self-inflicted. Unfortunately, my capture cards weren't automatically recognized, but I expected that because I had the digital-only VE version. However, even if I had the normal cards, I would have had to jump through hoops to get the cards recognized. But I think that's all okay now, the channel scan picks up the local stations and it's no longer complaining about no local channels.

Unfortunately, I haven't been able to establish connectivity otherwise. The web interface isn't active and the LiveCD front end doesn't want to connect either.

Well, I just bought two ATI HDTV Wonders on eBay, so I guess it's gone beyond plotting.

I've read as much as I can without taking the plunge. In theory it should be fairly simple.
1. Acquire PC to use as a back-end server. This server contains the capture cards and the hard drives to store the recordings. Since I'm dealing with ATSC the CPU specs don't matter.
2. Acquire compatible capture card(s). Sure, there may be cheaper cards out there which you might be able to get working, but it's reasonable to assume if no-one has done it, it can't be done.
3. Download and burn the install ISO. I'm going to play with LinHES as it seems to be minimalist (so probably better for my needs). However Mythbuntu seems to have a more active community (and is on the current release of MythTV.
4. Install & test. In theory LinHES is also a LiveCD which will allow any computer to be used as a front end. If so, that would allow me to use another computer during the test.
5. Get PS3 interface working.

4a. Filesystem configuration:
hda1 is the /boot partition, ext2 formatted
hda2 is the / partition, Reiser3 formatted
hda3 is the swap partition
hda5 is the /usr partition, Reiser3 formatted
hda6 is the /var, ReiserFS formatted
hdb1 is the /mythtv partition, JFS formatted

I have too many unfinished projects. I think of a project and I can think of nothing else. It rattles inside my head, making it difficult to think of anything else. But as I actually start the project the noise quiets down and life returns to normal. But then I get another idea and I can never quite get back to finishing off the project.

Currently rattling around in my head is an idea for an MPEG Transport Stream separator. This relates back to my idea of using my PS3 as a MythTV front end. (That project is stalled for a few reasons, including my unfinished outdoor antenna project.) I have some sample ATSC captures which the PS3 won't play back without "transcoding", which I'd like to avoid. The files are basically raw MPEG Transport Streams, and I suspect the reason my PS3 won't play them is because they 1 - are slightly corrupted and don't begin nicely and 2 - contain multiple channels.

However, the transport stream is a fairly simple container format. The audio & video streams are chopped up into 184 byte chunks, then a 4 byte header is added. (Except for the start & end of frames which have a timestamp or padding added respectively.) The whole mess is then multiplexed together with some metadata packets. So unlike other container formats, my program only has to deal with packets and parsing some of the metadata. Everything else can be passed through unchanged.

The audio and video streams for each channel in the transport stream are identified by the Program Map Table and the PMTs are identified by the Program Access Table. So, to extract a single channel I need to find and parse the PAT and the PMT then copy over all of the packets for just those audio and video streams along with the PMT and a PAT which only contains that channel.

Surprisingly, I haven't found a tool which does this. However, there are other tools which do various repairs on transport streams. So I don't know if I need to implement something like that.

Of course, now that I've ordered a new computer the "dead" one stops crashing and actually transcodes overnight. So now I have a spare computer to find a use for.

I have two SD TiVos - a dual tuner connected to the HDTV for analog and digital cable, and an old Sony S1 in the bedroom for analog cable. I also have an antenna connected to the HDTV for getting OTA (over the air) channels in HD. I'd love to add an HD TiVo but I can't quite justify it for recording network television; and I can't justify the rental cost of a cableco HD PVR when I get HD OTA for free. But would it be possible to use my old computer as a cheaper solution?

An ATSC PVR does two things - first it stores the bitstream to disk and second it decodes that bitstream for display. The first step just requires the right hardware and a large hard disk. The second step is CPU or GPU intensive. So my old computer should be able to handle the first step without any problems, I just need to buy the ATSC capture hardware; but the second step is quite beyond the capabilities of the system. However, if the display were handled by another system, like my PS3 which is already attached to the HDTV, then I'd be laughing. (The old system is also noisy, so I don't want it next to the HDTV anyway.

That brings in two more challenges - first is getting the video to the PS3 so it can display it and second is getting the video in a format the PS3 will display. The PS3 can function as a DLNA client, displaying video streamed by a DLNA server. There are several DLNA server applications for PCs, including PS3 Media Server which will automatically transcode video into a format the PS3 can use. Unfortunately, transcoding is even more CPU intensive than simply decoding. So unless the PS3 can display something very close to ATSC this idea still won't work.

Fortunately, (based upon a simple test) it looks like it can. One problem is the PS3 Media Server interface is dang ugly - it's a very simple folder tree structure. So then the question is whether I can find some free software which will behave as a kind of minimalist PVR (ideally controllable via a web interface).

My home computer is close to dead - random reboots and errors which point to a hardware failure. It's at least 7 years old, so I guess it's time for an upgrade. Sigh.

I've spec'd out a Dell replacement for C$878+tax etc. My question is whether there's any real point in looking at other makes etc. Unlike the old machine, I'm not interested in researching each component and assembling it myself. I have consoles for playing games so I don't need the ultimate in performance. I just want good value for money.

I guess my thinking is HP et al are sold via channels like Future Shop, who are going to take a slice of the profit. But Dell can take some of that cost and give me a better price.

I'd look at Macs too if I didn't have a bunch of Windows only software. Macs are great if you can stay inside the box of available software. Unfortunately, I tend to wander off that trail.

Two years ago when Rock Band was released, we gave it some serious consideration for a family Christmas gift. But we ended up giving the whole plastic instrument craze a pass until this year where we used some gift money and took advantage of the post-Christmas sales to buy Beatles Rock Band. The big advantage is we "know" most of the songs.

And we're having a blast. C is getting better banging on the skins, and I play bass while K handles the vocals (although we might swap). We've worked our way through the story mode (on easy for the most part) already, so now we'll probably explore and see what else the game has to offer. We might buy some DLC (like the Sgt. Pepper album) and maybe even one of the other games (since we have the instruments).

I've finally finished (and debugged) my Fast Discrete Hartley Transform for the Propeller. It takes 2^N signed 32 bit input samples and produces the output in the same array. I've measured the following:
16 samples in 12,496 clock cycles
64 samples in 87,648 clock cycles
256 samples in 534,656 clock cycles
1024 samples in 2,899,504 clock cycles
4096 samples in 14,668,112 clock cycles

At 80MHz that's 27.5 1024 sample DHTs per second!

Sample code (unoptimized). Comment if you want more details.

L = log2(N)
for i = 0 to N-1
  j = bitreverse( i, L )
  if j > i then
    t = x[i]
    x[i] = x[j]
    x[j] = t
  endif
next i

for i = 0 to N-1 step 4
  t0 = x[i]
  t2 = x[i+1]
  t1 = x[i+2]
  t3 = x[i+3]
  x[i+0]=(t0+t1+t2+t3)/2
  x[i+1]=(t0+t1-t2-t3)/2
  x[i+2]=(t0-t1+t2-t3)/2
  x[i+3]=(t0-t1-t2+t3)/2
next i

for o = 3 to L
  s = 1 << o
  h = s / 2
  q = s / 4
  for i = 0 to N-1 step s
    t0 = x[i]
    t1 = x[i+q]
    t2 = x[i+h]
    t2 = x[i+h+q]
    x[i] = t0 + t2
    x[i+q] = t1 + t3
    x[i+h] = t0 - t2
    x[i+h+q] = t1 - t3
    for j = 1 to h-1
      t0 = x[i+j] / sqrt(2) 
      t1 = x[i+h-j] / sqrt(2) 
      t2 = x[i+h+j] / sqrt(2) 
      t2 = x[i+s-j] / sqrt(2)
      x[i+j]   = t0 + t1 * cos(2*pi()*j/N) + t3 * sin(2*pi()*j/N)
      x[i+h-j] = t2 + t1 * sin(2*pi()*j/N) - t3 * cos(2*pi()*j/N)
      x[i+h+j] = t0 - t1 * cos(2*pi()*j/N) - t3 * sin(2*pi()*j/N)
      x[i+s-j] = t2 - t1 * sin(2*pi()*j/N) + t3 * cos(2*pi()*j/N)
    next j
  next i
next o

This weekend while my wife was in Miami and my son was at school or asleep I played far too much Half Life 2. I got the game as part of the Orange Box for the PS3, which I bought to play Portal. But HL2 is an FPS and thus is verbotten in my wife's opinion. But what she doesn't know. . .

Based on the walkthrough, I've played through over half of the game (maybe even two thirds). And although I had fun, it wasn't quite as satisfying as the original.

I will say that I thought many of the environments were extremely well done. City 17 felt real. You could feel the oppression, depression and collapse. The sheer hopelessness is amazing. Ravenholm was convincing as a zombie town. And the train bridge captured the feeling of climbing hundreds of feet over the river.

But there were many other things which I didn't like. The biggest is how linear the game is. You can't get lost, although you may have to search a little to find the next exit. But when I was trying to escape City 17 I quickly realized I simply had to follow the most obvious path and I would be on the right track, which kinda defeated some of the fear & tension.

Also high on my list of dislikes is how long the loads take. Maybe it's just the PS3 port, but I found it very annoying when the action stops as it loaded the next section. Since the game is linear, couldn't the next level be loaded in the background half-way through the level? It's also kinda sad when I can predict when a set scene is going to occur.

I also found the story worse than HL1 - in spite of it being more complex. Why the G-Man brings you back and where the new Combine aliens came from is never really explained. And maybe Dr. Breen isn't the "bad guy", he's just trying to make the best of a near hopeless situation.

Finally, the NPC and enemy AI doesn't seem to act as intelligent as HL1 - i.e. charging mindlessly into overwhelming fire. (Although it's kinda nice when I had the big gun on the car. I'd park the car, spring the trap, then run back to the car.) And although it's initially distressing when "friendly" NPCs get killed, I quickly realized there was no impact. (And if they are dumb enough to attack a gunship with an SMG standing out in the open, then the predictable will happen.)

Most developers understand it is possible to trade off space for speed, e.g. unrolling loops or using table lookups instead of complex calculations. This is particularly true for low level programming where you are often trying to squeeze out the maximum speed in the minimum space. But I've recently discovered Propeller Assembly (PASM) it's possible to maximize speed and minimize space simultaneously.

The Propeller is different from most processors in there are no dedicated ALU registers. Instead, any 32 bit entry in processor RAM may be used as a register. Thus processor RAM can be looked at as a 512 entry register file. Or 496 instructions (16 of the registers are dedicated to I/O), with each instruction taking a single register. Or 496 32 bit data values. It is even possible (and sometimes necessary) to modify an instruction using ALU operations.

In the program I'm working on, I've programmed two 16.16 x 0.16 fixed point multiplies; multiplying one value twice (by cos & sin). In pseudo code:

  frac = fixed & 0xFFFF
  int  = fixed >> 16
  frac_cos = cos * frac
  int_cos  = cos * int
/* because the algorithm destroys the inputs, they must be reloaded */
  frac = fixed & 0xFFFF
  int  = fixed >> 16
  frac_sin = sin * frac
  int_sin  = sin * int

Now, in a normal speed optimization, you'd look and see that the same value is being calculated twice. So to speed things up, you save the value (more space) so the calculations don't have to be done again. But in PASM this sometimes doesn't save any time and ends up taking additional space!

  mov  frac, fixed       // frac = fixed
  and  frac, H0000FFFFF  // frac &= 0xFFFF   H0000FFFF is a register which has the appropriate value preset
  mov  sav_frac, frac    // sav_frac = frac  save the value in a temporary register
...
  mov  frac, sav_frac    // reload value

As you can see, calculating the value requires 2 instructions. Saving the value requires 1 additional instruction, and the reload is an instruction. So calculating the value requires the same number of instructions as save+reload, but the save+reload requires an extra register (sav_frac). So save+reload isn't any faster and requires more space!

Obviously this is a simple example which only required one instruction to calculate each value. But the converse is also true. In another part of the program I am finding it's better to maintain additional variables rather than calculating the necessary value from the loop counters.