Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

Facebook Tests "Satire" Tag To Avoid Confusion On News Feed

Mr Z Re:Gotta say it (131 comments)

Sorry, dude, that's sarcasm. not satire.

about two weeks ago
top

Processors and the Limits of Physics

Mr Z Re:Lightfoot (168 comments)

Wires on silicon aren't a vacuum. The dominant effect is actually RC delay. As you make wires smaller, the resistance goes up (inversely proportional to cross-sectional area). As you make the wires closer together, capacitance goes up (inversely proportional to distance between the conductors). So, as geometries shrink, propagation delays for real signals in real wires on real silicon go up.

I won't even get into buffers which are required to recondition the signal on long routes... (Someone elsewhere on the thread already did.)

about two weeks ago
top

Processors and the Limits of Physics

Mr Z Re:Alpha Particles (168 comments)

Can you propose a non-stochastic process that produces alpha particles, and a way of constructing a family of logic gates out of that process?

about two weeks ago
top

Processors and the Limits of Physics

Mr Z Re:can't cross chip in one clock. big deal. (168 comments)

Sure, throughput is what matters most for operations you can parallelize. However, as Amdahl's Law cruelly reminds us, there's always parts of the problem that remain serial, and they'll put an upper bound on performance. You can't parallelize the traversal of a linked list, no matter how hard you try. You have to invent new algorithms and programming techniques. (In the specific case of linked lists, there are other options that trade space for efficiency, such as skiplists.)

Gustafson's Law does offer some hope: As we build more capable machines, we'll tackle bigger problems to utilize those machines. That's how we're able to, for example, get wireless data speeds on our cell phones operating on batteries that would make wired modem users of just 10-15 years ago jealous.

But, Gustafson's Law only serves as a counterpoint to Amdahl's Law to the extent that you tackle bigger problems, as opposed to trying to reduce current problems to take less time and energy.

about two weeks ago
top

Processors and the Limits of Physics

Mr Z Re:Why not integrate entire C-library functions? (168 comments)

And you think printf() and strtol() are major bottlenecks worth dedicated silicon area why?

Modern CPUs already have many accelerators for high end functions, such as numerical computations, cryptography, and the all important memcpy. (Memory copies are a traditional bottleneck, and general enough that they can be easily offloaded.) They come in two forms—specialized SIMD/vector instruction sets, and dedicated blocks for high-level functions that take multiple microseconds. An example of the former are the SIMD-oriented AVX instructions found on modern x86 chips. As an example of the latter, chips aimed at high end signal processing often have discrete blocks such as FFT accelerators. Others aimed at network tasks (especially DPI) have regular expression engines.

The problem with accelerator blocks is that they do take up area. And if they're powered up, they leak. Leakage current is a significant factor in modern designs. To get faster transistors, you need to drive their threshold voltage down. As you lower the threshold voltage, their leakage current goes up exponentially. So, that circuit better be bringing a lot of bang for the buck if it's going to be sitting there taking up space and leaking.

Another issue with dedicating area to fixed functions is the impact it has on distance between functions on the die. In the Old Days, you could get anywhere on the die in a single clock cycle. With modern designs and modern clock rates, cross-die communication is slow, taking many many cycles. So, when you plop down your custom accelerator, you have to figure out where to put it. Do you put it right in the middle of the rest of the computational units, slowing down the communication between their functions (either lowering clock rate or increasing cycle counts), or do you put it on the other side of the cache, meaning it takes several cycles to send it a request and several cycles to see the result?

This is why many custom accelerator blocks out there today focus on meaty workloads. A large FFT still takes a good bit of time to execute, and there's usually other work the main CPU can do while it executes. Thus, the communication overhead doesn't tank your performance. printf(), on the other hand, generally shows up right in the middle of a bunch of other serial steps. You can't overlap that with anything. Hauling off to a printf() accelerator block generally would make zero sense. If you're really spending that much time in printf(), you're better off rewriting the code to use a less general facility.

A final issue with dedicated hardware is that you can't patch it. Someone finds a bug in your printf() and you're back to using a library version. I could go on, but I think I've made my point.

about two weeks ago
top

Processors and the Limits of Physics

Mr Z Re:Power use is NOT proportional with voltage (168 comments)

That's true for active power. (V^2/R). For leakage power, it's even worse. That looks closer to exponential. I've seen chip for which leakage accounted for close to half the power budget.

Supposedly FinFET /Tri-gate will help dramatically with leakage. We'll see.

about two weeks ago
top

Ask Slashdot: Why Are Online Job Applications So Badly Designed?

Mr Z Re:Why? (278 comments)

I only enter mine into two, but both are crap.

The crappier of the two, amazingly, was not written in-house. We apparently bought that turd! (A site-customized/bastardized version of SumTotal Unified Workforce Interface (assuming I found a link to the correct turd), in case you're curious. It's non-modular!)

about two weeks ago
top

Verizon Throttles Data To "Provide Incentive To Limit Usage"

Mr Z Re:Kill auto-play videos (316 comments)

Could be. Most of the links I run into trouble with are from generic news aggregators. It isn't like I'm surfing the underworld or anything. I guess everybody's out for a buck these days, though.

about three weeks ago
top

US Intelligence Wants Tools To Tell: Who's the Smartest of Them All?

Mr Z ACRONYM? (162 comments)

Acronyms Can Really be Obnoxious Names, You Mean?

about three weeks ago
top

Verizon Throttles Data To "Provide Incentive To Limit Usage"

Mr Z Re:Kill auto-play videos (316 comments)

Maybe it's AT&T's network, or maybe my phone (BB10), but the videos often don't load quickly enough for me to notice them until it's too late. My only hint is that the browser gets strangely unresponsive, and then 5 seconds later it pops over to full screen nonsense.

I've been known to just kill the browser app outright when that happens, as it's quicker than trying to get the video player to quit.

I freely admit that some of the trouble may be phone specific. Still, auto-play videos suck.

about three weeks ago
top

Verizon Throttles Data To "Provide Incentive To Limit Usage"

Mr Z Re:Kill auto-play videos (316 comments)

There are a couple popular news sites that seem to have moved to HTML 5 videos that don't need a flash plugin. I don't know how to block their videos on my phone. Turning off flash doesn't help, since it isn't involved.

The browser does have a switch between 'mobile' mode, which gives me a turn-of-the-century web browsing experience (not what I want), and 'desktop' mode, which usually (but not always) much better.

about three weeks ago
top

Verizon Throttles Data To "Provide Incentive To Limit Usage"

Mr Z Re:Kill auto-play videos (316 comments)

Unfortunately, there isn't a way to determine a site is sleazy prior to clicking on a link.

about three weeks ago
top

Verizon Throttles Data To "Provide Incentive To Limit Usage"

Mr Z Re:Kill auto-play videos (316 comments)

Oh, and give me a way to say "Never play a video under any circumstances, unless I explicitly say 'play this video.'" KTHXBYE.

about three weeks ago
top

Verizon Throttles Data To "Provide Incentive To Limit Usage"

Mr Z Kill auto-play videos (316 comments)

I'm not on Verizon, nor am I on an unlimited plan. Still, I seem to hit my bandwidth cap more regularly these days. What seems to kill my utilization these days are websites with auto-play videos that I can't kill simply by blocking Flash.

What's really annoying is that the videos load in the background, and on a few occasions, have started playing after I've already locked the display and set my phone down. I only notice them because my phone starts making noise (when I don't have it set to 'silent'). It kills my battery and eats the bits I paid for on the assumption I'd be using them for things I actually wanted.

I honestly don't have a problem with throttling actual abusers. But, modern website design seems to make "abusers" out of more of us than there otherwise would be.

For the unlimited crowd, perhaps there should be tiers there, also. How about two levels? The lower tier would be "no overage fees" unlimited, meaning you don't get random dings for going over arbitrary caps, but you might get throttled occasionally. Rather than a hard cap, there's a soft limit. The upper tier would be "no limits, no throttling," meaning you could stream all the video and download all the torrents you want, but you pay a significantly higher fee for it. I'd happily sign up for the former service just to avoid the fees associated with the occasional data-heavy month. Folks who want to treat their phone as a cable-less cable modem can pay a few bucks more to avoid the throttle.

I think the problem currently is that 95%+ fall into the first group, and the remaining 5% or fewer really need a different class of service. The current "unlimited" label doesn't really make a sufficient distinction between the two.

Of course, the cynical would point out that such a tiering system would open itself to a whole new brand of marketing abuse...

about three weeks ago
top

OKCupid Experiments on Users Too

Mr Z A/B Testing (161 comments)

Isn't that what A/B testing is all about?

about a month ago
top

Evidence of a Correction To the Speed of Light

Mr Z Re:Which means (347 comments)

Also, there's a semantic looseness as well that bothers me. The proposed solution doesn't really require changing the speed of light in a vacuum. Rather, it points out that photons will undergo certain interactions which mean that light as a bulk phenomenon will appear to go slower than the maximum speed light can travel in a vacuum because of those other interactions.

When computing relativistic effects, such as Lorenz contractions, etc., the upper speed (not including all those interactions) still remains the limit, at least as I understand it.

about 2 months ago
top

How Disney Built and Programmed an Animatronic President

Mr Z Do you remember the future? Forget it! (97 comments)

"Hey Paolo! He broke the President!"

I remember many years ago reading an article (probably in Wired; these days, it'd be a blog post) where someone described walking around EPCOT Center while listening to this exact album. Sounds like quite a trip, really.

And then there's this article from several years ago that's also fitting. Apparently Disney was working on their version of the Holy-Grams too..

about 2 months ago
top

How Disney Built and Programmed an Animatronic President

Mr Z Prepare ...for a period of simulated exhilaration! (97 comments)

Firesign Theatre was definitely excellent stuff. "I'm Arty Choke, and we're just a joke. So it's back to the shadows again..."

about 2 months ago

Submissions

top

Under the Smogberry Trees: Kickstarter aims for Dr. Demento Documentary

Mr Z Mr Z writes  |  about a year ago

Mr Z (6791) writes "A favorite of geeks, nerds and quirky folk everywhere, Dr. Demento has been a fixture since 1975, bringing funny, demented music to us all. Dr. Demento both inspired and helped launch many artists, including such diverse talents as Weird Al Yankovic and Richard Cheese.

The group at Meep Morp Studio are working to put together a documentary about both the good Dr. himself as well as his alter ego, the globally respected musicologist and historian Barret Hansen.

The catch? They have a a Kickstarter here that still has 40% to go in the next 5 days. That's a pretty tight deadline. But, if even a small fraction of Slashdotters that have enjoyed Dr. Demento over the years pitch in a nice dinner's worth of dollars each, this documentary will get made."

Link to Original Source

Journals

top

Space Patrol: Almost there

Mr Z Mr Z writes  |  more than 6 years ago

Production continues to move forward. The ROMs are all programmed, and the CPLDs are close behind. PCBs are getting fabbed right now, and when they come it, they'll be stuffed shortly thereafter. If we hurry, we may be able to ship something by year's end.

Manual and overlay are finalized, box layout's finalized, trial box looks good... It's all becoming real!

top

Space Patrol: Teaser Edition now available

Mr Z Mr Z writes  |  more than 7 years ago

Space Patrol: Teaser Edition is now available, with source code! The Teaser is identical to the full release, except:

  • No splash screen
  • No Easter eggs :-)
  • Each course ends at checkpoint J instead of checkpoint Z

The full version will be available when the cartridge gets released. Sign up for the cartridge announcement at David Harley's Space Patrol page.

top

Space Patrol: The Final Stretch!

Mr Z Mr Z writes  |  more than 7 years ago

Space Patrol, as mentioned here is entering the home stretch. I figure I have a week of solid coding left to do on it, meaning I'll probably be finished with it by the end of January. (It is a hobby.) Currently, I'm adding the final few missing pieces:

  • Scoring, including high-score tracking.
  • Game over and continues.
  • Splash screen.
  • General cleanups, including maybe a few cycle-count reductions.

Once I get the game done, I'm going to begin working on an extra secret special feature that, if I can get it to work, will make this one of the most unique Intellivision games of all time. Whoo hoo!

top

Space Patrol!

Mr Z Mr Z writes  |  more than 7 years ago

I'm actually working on Space Patrol again! It pretty much sat on the shelf for 2-3 years. I've dusted it off and really put some work into it.

I made a post about it on my LiveJournal. David Harley, who is helping me with level design, has his own page up on it on his website.

So far we have 2 complete worlds finished. We're adding 6 more. The engine itself is 90-95% complete. Now it's for all the work around the edges--sound effects, level data, transitions, scoring and dying.

top

Good, working code heading for the wastebin *sniff*

Mr Z Mr Z writes  |  more than 11 years ago

Shameless rambling about a personal project...

I'm working on a video game that is similar to Moon Patrol. It's a game for the venerable, underpowered Intellivision video game system. You can find more information and a developer's kit on the Intellivision on my SDK-1600 page.

Well, I spent Thanksgiving up through now working on various aspects of the game. One large piece was working out a method for controlling the 'bad guys.' I figured I'd write a small interpreter that would read a "Bad Guy Motion Program", and move the guys around. I even wrote a very simplistic assembler to assemble the command words for the interpreter. The whole thing actually works pretty reliably.

Turns out, though, that I need something else. My current approach is 'timer based.' That is, the motion programs are essentially of the form "Set velocity to dx,dy", "wait XX tics", "set velocity to dx,dy", "wait XX tics", "fire", "wait XX tics", "leave the screen." The problems are twofold:

  • In Moon Patrol, at least, the bad guys are cued into the level and cued out of the level by location. That is, when I cross a particular marker, the bad guys show up. When I cross a different particular marker, they leave. I'd like similar behavior for my game, but the timer method causes the bad guys to leave too soon if the tank is driving slowly, and too late if the tank is driving quickly.
  • The bad guys always move in EXACTLY the same pattern. In Moon Patrol, at least, the bad guys move consistently only if you move consistently. That is -- their movements seem rule based, not hardcoded.

So, I'm going to have to scrap my current interpreter. I'm torn between writing a new interpreter (or extending this one) to allow me to write rule-based motion programs for the bad guys, or just writing the rule-based programs directly in CP-1600 assembly. The latter is less convenient, I think, but will likely be smaller and is more likely to fit in my cycle budget.

So it appears I will probably scrap the interpreter.

The interpreter wasn't much, but it was something. And it worked. And I was proud of it. It provided some neat concepts, such as a looping construct that combined initialization, decrement, and branching into a single instruction. FWIW, here's how the looping instruction worked:

I offer two loop-counters per program. The LOOPA instruction uses the 'A' loop counter, and LOOPB uses the 'B' loop counter. The counters are initialized to 0 at the start of the program. Upon reaching an instruction of the form "LOOP[AB] label, count", the loop instruction checks the corresponding loop counter. If it's 0, it's initialized to the specified count and a branch is made to the label. If it's non-zero, it's decremented, and if the result is non-zero the branch is taken. That's it.

Here's an example motion program that causes a bad-guy to move in a box-shaped spiral:

####
## sample motion programs
####
MP_BOX PROC

@@box
. . . . GO (3) rg1
. . . . GO (3) dn1
@@boxb GO (3) lf1
. . . . GO (2) up1
. . . . LOOPA @@box, 5 # do the box 5 times

. . . . GO (2) rg2
. . . . GO (2) dn2
. . . . LOOPB @@boxb, 4 # slide over and do this 4 times total.
. . . . GO (9) lf3
. . . . DIE
. . . . ENDP

The names "lf1", "dn2" represent directions and velocities. The number in parentheses is number of ticks to wait after the instruction executes (at a 30Hz tick-rate). Nothing particularly mind-bending.

Now it looks as though I might bin all this code and write up motion programs in straight assembly. *sigh*

Ah well, here's the interpreter (or at least the heart of it) for posterity.

;; ======================================================================= ;;
;;. UPBGM -- Update Bad Guy Motion.. Called on a 30Hz tick.. . . . . . . . ;;
;; ======================================================================= ;;
UPBGM. PROC
. . . . PSHR. . R5

. . . . MVII. . #BGMPTBL, R4
. . . . CLRR. . R1

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. Iterate through the motion programs . . . . . . . . . . . . . . ;;
. . . . ;;. R0 -- scratch. . . . . . . . . . . . . . . . . . . . . . . . . ;;
. . . . ;;. R1 -- Slot # for MOB (within group 1). . . . . . . . . . . . . ;;
. . . . ;;. R2 -- Program counter for current record . . . . . . . . . . . ;;
. . . . ;;. R3 -- scratch. . . . . . . . . . . . . . . . . . . . . . . . . ;;
. . . . ;;. R4 -- Pointer to BGMP state tables . . . . . . . . . . . . . . ;;
. . . . ;;. R5 -- scratch. . . . . . . . . . . . . . . . . . . . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
. . . . B . . . @@first_bgmp. . ; skip first INCR R1

@@next_bgmp:
. . . . INCR. . R1. . . . . . . ; next slot #

. . . . CMPI. . #5,. . R1. . . ; Is this the end?
. . . . BGE . . @@done_bgmp . . ; Yes, done.

@@first_bgmp:
. . . . SDBD
. . . . MVI@. . R4,. . R2. . . ; Get program counter
. . . . TSTR. . R2. . . . . . . ; If it's zero, motion program is inactive
. . . . BNEQ. . @@active_bgmp. ; Non-zero, it's active.

. . . . ADDI. . #3,. . R4. . . ; Skip rest of record.
. . . . CMPI. . #BGMPTBL+25, R4 ; Is this the end?
. . . . BLT . . @@next_bgmp . . ; No, do the next one.
. . . . B . . . @@done_bgmp . . ; Yes, done.

@@active_bgmp:
. . . . MOVR. . R4,. . R3
. . . . MVI@. . R4,. . R0. . . ; Get delay counter for this motion program
. . . . ADDI. . #2,. . R4. . . ; point to next record
. . . . DECR. . R0. . . . . . . ; Count down the delay counter.
. . . . MVO@. . R0,. . R3. . . ; Store the updated delay counter

. . . . BPL . . @@next_bgmp. . ; If not expired, go to the next program.

@@expired:
. . . . MVI@. . R2, . . R0. . . ; Get next program word.
. . . . INCR. . R2
. . . . MVO@. . R0, . . R3. . . ; Store out lower byte as delay count.
. . . . XOR@. . R3, . . R0. . . ; Clear delay byte
. . . . SWAP. . R0. . . . . . . ; Extract command byte.

. . . . SUBI. . #64,. . R0. . . ; Less than 64?. It's a motion command.
. . . . BMI . . @@cmd_move. . . ;
. . . . SLL . . R0,. . 1
. . . . ADDR. . R0,. . PC. . . ; Otherwise, vector to the other commands.
. . . . B . . . @@cmd_loopa . . ;. 0 : LOOPA
. . . . B . . . @@cmd_loopb . . ;. 1 : LOOPB
. . . . B . . . @@cmd_jump. . . ;. 2 : JUMP
. . . . B . . . @@cmd_fire. . . ;. 3 : FIREA
. . . . B . . . @@cmd_fire. . . ;. 4 : FIREB
. . . . B . . . @@cmd_fire. . . ;. 5 : FIREC
. . . . B . . . @@cmd_die . . . ;. 6 : DIE
. . . . B . . . @@cmd_attr. . . ;. 7 : ATTR
. . . . B . . . @@cmd_seths . . ;. 8 : SETHS
. . . . B . . . @@cmd_clrhs . . ;. 9 : CLRHS
; . . . B . . . @@cmd_wait. . . ; 10 : WAIT aka. NOP.

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. WAIT/NOP:. Just set the delay counter and go to next command.. ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_wait:

@@finish_cmd:
. . . . SUBI. . #5,. . R4. . . ; Rewind to program pointer in record.
. . . . MVO@. . R2,. . R4. . . ; \.
. . . . SWAP. . R2. . . . . . . ;. |-- Store program counter as double-byte
. . . . MVO@. . R2,. . R4. . . ; /. . data
. . . . ADDI. . #3,. . R4. . . ; point to next record.

. . . . B . . . @@next_bgmp. . ; No, do the next one.

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. LOOPA/LOOPB:. Count down the loop counter.. If it goes -ve, . . ;;
. . . . ;;. we're just starting the loop so initialize it and branch. . . . ;;
. . . . ;;. If it goes 0, the loop is just finishing, so fall through.. . . ;;
. . . . ;;. Otherwise, store updated counter and branch.. . . . . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_loopb:
. . . . INCR. . R3. . . . . . . ; Point to loop counter B
@@cmd_loopa:
. . . . INCR. . R3. . . . . . . ; Point to loop counter A

. . . . MVI@. . R2,. . R0. . . ; Read argument to loop into R0
. . . . INCR. . R2. . . . . . . ;

. . . . MVI@. . R3,. . R5. . . ; read loop counter
. . . . DECR. . R5. . . . . . . ; count it down
. . . . BMI . . @@init_loop . . ; if it goes negative, we need to init it.
. . . . BEQ . . @@done_loop . . ; if it goes to zero, it's expiring

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. +ve case:. Store updated counter and branch.. . . . . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@exec_loop:. . . . . . . . . . ; otherwise it was an active loop.
. . . . MVO@. . R5,. . R3. . . ; store updated loop counter

@@loop_jump:
. . . . ANDI. . #$FF,. R0. . . ; execute the jump.
. . . . XORI. . #$80,. R0. . . ;
. . . . SUBI. . #$80,. R0. . . ;
. . . . ADDR. . R0,. . R2. . . ;

. . . . B . . . @@finish_cmd. . ; finish this command.

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. -ve case:. Initialize the loop counter and branch.. . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@init_loop:
. . . . SWAP. . R0. . . . . . . ;
. . . . MVO@. . R0,. . R3. . . ; initialize the loop counter.
. . . . SWAP. . R0. . . . . . . ;
. . . . B . . . @@loop_jump

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. Zero case:. Zero out the counter and don't branch.. . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@done_loop:
. . . . MVO@. . R5,. . R3. . . ; store updated loop counter
. . . . B . . . @@finish_cmd. . ; and that's it.

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. JUMP:. Just read the argument into the program counter.. . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_jump:
. . . . MVI@. . R2,. . R2
. . . . B . . . @@finish_cmd. . . . . . ; Done.

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. MOVE:. Read the X velocity, Y velocity into SPXYV table.. . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_move:

. . . . MOVR. . R1,. . R5. . . . . . . ;\
. . . . ADDR. . R5,. . R5. . . . . . . ; |-- convert slot number to sprite
. . . . ADDI. . #SPXYV, R5. . . . . . . ;/. . X/Y velocity table pointer

. . . . ADDI. . #@@xvel_tbl + 64, R0. . ; Index into X velocity lookup table
. . . . MOVR. . R0,. . R3

. . . . MVI@. . R3,. . R0. . . . . . . ; Get X velocity from lookup
. . . . MVO@. . R0,. . R5. . . . . . . ; Write it to X vel for this sprite

. . . . ADDI. . #@@yvel_tbl - @@xvel_tbl, R3. . ; Index into Y vel lookup tbl
. . . . MVI@. . R3,. . R0. . . . . . . ; Get Y velocity from lookup
. . . . MVO@. . R0,. . R5. . . . . . . ; Write it to Y vel for this sprite.

. . . . B . . . @@finish_cmd. . . . . . ; Done.

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. FIREA:. Make this bad guy drop a bomb. . . . . . . . . . . . . ;;
. . . . ;;. FIREB:. Make this bad guy fire a crater-maker. . . . . . . . . ;;
. . . . ;;. FIREC:. Make this bad guy shoot horizontally to the left.. . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_fire:.
. . . . MVII. . #@@firetype - 6, R3
. . . . ADDR. . R0,. . R3
. . . . MVI@. . R3,. . R0. . . ; read X/Y velocity
. . . . INCR. . R3
. . . . MVI@. . R3,. . R3. . . ; read sprite attribute index
. . . . CALL. . BGFIRE
. . . . B . . . @@finish_cmd

@@firetype:
. . . . DECLE. ((VBIAS + $40) SHL 8) + (VBIAS + $00) ; drop the bomb
. . . . DECLE. SPATBL.b2

. . . . DECLE. ((VBIAS + $40) SHL 8) + (VBIAS + $40) ; drop the crater maker
. . . . DECLE. SPATBL.b1

. . . . DECLE. ((VBIAS + $00) SHL 8) + (VBIAS - $80) ; fire left.
. . . . DECLE. SPATBL.b4

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. DIE:. Time for this guy to die.. . . . . . . . . . . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_die:
. . . . CALL. . BGKILL
. . . . B . . . @@finish_cmd

. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. ATTR:. Set the Sprite Attribute for this sprite.. . . . . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_attr:
. . . . MVI@. . R2, . . R0. . . ; Get attribute
. . . . INCR. . R2
. . . . MOVR. . R1, . . R3. . . ; \
. . . . ADDI. . #SPAT,. R3. . . ;. |-- Store attribute number into slot
. . . . MVO@. . R0, . . R3. . . ; /. . in sprite attribute table.

. . . . B. . . @@finish_cmd

. . . .
. . . . ;; --------------------------------------------------------------- ;;
. . . . ;;. CLRHS:. Set the horizontal-scroll bit for this sprite. . . . . ;;
. . . . ;; --------------------------------------------------------------- ;;
@@cmd_clrhs:

. . . . ;; ---------------------------------------------------------------- ;;
. . . . ;;. SETHS:. Set the horizontal-scroll bit for this sprite. . . . . ;;
. . . . ;; ---------------------------------------------------------------- ;;
@@cmd_seths:
@@do_hs:
. . . . MOVR. . R1, . . R3
. . . . ADDI. . #@@shl_tbl, R3
. . . . MVI@. . R3, . . R3
. . . . MOVR. . R3, . . R0
. . . . COMR. . R3
. . . . AND . . SPHSCR, R3
;;. . . ADCR. . PC
. . . . XORR. . R0, . . R3
. . . . MVO . . R3, . . SPHSCR

. . . . B . . . @@finish_cmd

@@shl_tbl:
. . . . DECLE. 1, 2, 4, 8, 16
. . . .

@@done_bgmp:
. . . . PULR. . PC

@@xvel_tbl:
. . . . DECLE. VBIAS - $20, VBIAS - $40, VBIAS - $60, VBIAS - $7F. ; lf0..lf3
. . . . DECLE. VBIAS + $20, VBIAS + $40, VBIAS + $60, VBIAS + $7F. ; rg0..rg3
. . . . DECLE. VBIAS,. . . VBIAS,. . . VBIAS,. . . VBIAS. . . . ; up0..up3
. . . . DECLE. VBIAS,. . . VBIAS,. . . VBIAS,. . . VBIAS. . . . ; dn0..dn3

. . . . DECLE. VBIAS - $20, VBIAS - $40, VBIAS - $60, VBIAS - $7F. ; lu0..lu3
. . . . DECLE. VBIAS + $20, VBIAS + $40, VBIAS + $60, VBIAS + $7F. ; ru0..ru3
. . . . DECLE. VBIAS - $20, VBIAS - $40, VBIAS - $60, VBIAS - $7F. ; ld0..ld3
. . . . DECLE. VBIAS + $20, VBIAS + $40, VBIAS + $60, VBIAS + $7F. ; rd0..rd3

. . . . DECLE. VBIAS,. . . VBIAS - $08
. . . . ;; directions 33 .. 63 not defined yet.. in no hurry....

@@yvel_tbl:
. . . . DECLE. VBIAS,. . . VBIAS,. . . VBIAS,. . . VBIAS. . . . ; lf0..lf3
. . . . DECLE. VBIAS,. . . VBIAS,. . . VBIAS,. . . VBIAS. . . . ; rg0..rg3
. . . . DECLE. VBIAS - $20, VBIAS - $40, VBIAS - $60, VBIAS - $7F. ; up0..up3
. . . . DECLE. VBIAS + $20, VBIAS + $40, VBIAS + $60, VBIAS + $7F. ; dn0..dn3

. . . . DECLE. VBIAS - $20, VBIAS - $40, VBIAS - $60, VBIAS - $7F. ; lu0..lu3
. . . . DECLE. VBIAS - $20, VBIAS - $40, VBIAS - $60, VBIAS - $7F. ; ru0..ru3
. . . . DECLE. VBIAS + $20, VBIAS + $40, VBIAS + $60, VBIAS + $7F. ; ld0..ld3
. . . . DECLE. VBIAS + $20, VBIAS + $40, VBIAS + $60, VBIAS + $7F. ; rd0..rd3

. . . . DECLE. VBIAS,. . . VBIAS
. . . . ;; directions 33 .. 63 not defined yet.. in no hurry....

. . . . ENDP

And there it is. (The dots are added to preserve the original formatting, although it appears I'm not entirely successful. Ah well... it's pretty close.)

--Joe

top

This whole Friend/Foe/Fans/Freaks thing

Mr Z Mr Z writes  |  more than 11 years ago

Heh. My journal -- probably a bit like pissing in the ocean. It feels good, but nobody notices. ;-)

Anyway, I was clicking through my 'user' pages today (clicking aimlessly, noticing how much snappier Moz 1.1 feels relative to 1.0 on this Solaris box), and noticed that whoa, I have fans!

Up until now, I've entirely avoided the whole friend/foe mechanism. For awhile now, I've checkmarked "unwilling to moderate", and "hide scores". I also browse at '0'. (I used to browse at -1, but it really was too noisy.) Moderation just doesn't seem all that reliable or meaningful, and so I largely ignore it. Too much $3 crack going around. (I don't mind being modded up occasionally though -- if my post is really worth "promoting" to those who browse at higher thresholds.)

The friend/foe mechanism just seemed like another bad idea. It seemed to have the potential to turn Slashdot into a popularity contest like highschool. Either that, or it'd lead to even greater segmentation of the posting populace, with everyone auto-modding up their friends and ignoring everyone else. A sort of "show me only what I agree with and want to hear" mechanism that does little to encourage intelligent discourse and does everything to silo individual cliques. So I just ignored it.

I've thought it over more, now. I certainly don't mind if others mark me as friend or foe. (Although I'd certainly wonder why someone might choose to mark me 'foe'.) I don't have any qualms about marking someone 'friend' anymore either. I don't plan to use the moderation adjustment facility though. I ignore comment moderations for the most part anyway, and I see no reason to change that.

So, I've marked a couple people 'friends' today. Some are longtime acquaintences (either in meatspace or on /.). Others were in my list of 'fans'. And if someone posts a helpful response to one of my posts, or posts something I think is particularly insightful, I may just mark 'em 'friend.' Or maybe not. Who knows.

Well, enough rambling. This post is so long, I've received about 9 or 10 spam emails in the meantime:

Mutt 1.0i@caffeine:=spool/incoming*(reverse-threads) [3173/3173(1% of 71M)][b=0|
. 1 . NDL Sep 26 Jacelyn0828c77@h ( . .25) [Spam] High investment potential ret
. 2 . NDL Sep 26 Rockne Renate . .( . 117) [Spam] Why Wait... Rates Below 4.75%
. 3 . NDC Sep 26 cedrickmills0123 ( . .11) [Spam] how would you like to increas
. 4 . NDL Sep 27 Zared Lucio . . .( . .71) [Spam] Stop going bald, time is stil
. 5 . NDL Sep 27 Brittany Bond . .( . 130) [Spam] In Debt? Get Help!---Free Quo
. 6 . NDL Sep 26 Frayne Clio . . .( . 167) [Spam] Coral Calcium Discovery Lette
. 7 . NDL Nov 25 refi_loans_2@yah ( . .70) [Spam] dont loose sales - take credi
. 8 . NDL Sep 27 celularshop@hotm ( . .38) [Spam] Fwd: Faith is all that is req
. 9 . NDL Sep 27 brellis10@hotmai ( . .54) [Spam] Attn: Do it yourself.

As Stimpy would say: Joy!

--Joe

Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>