×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Comments

top

Eizo Debuts Monitor With 1:1 Aspect Ratio

Mr Z Re:Linux kernel is mostly 80-column (326 comments)

Yep, I'm with you here.

I did a stint with 132 columns awhile back (back when I was running Linux on a machine that wasn't quite powerful enough to run X11), and I found the extra horizontal space to be mostly wasted. If I did start putting comments or code over there, it'd often get "lost".

Now, I do use a wide format for certain debugging applications. It also works well for spreadsheets. But for source code? I've definitely got an 80 column mind, despite ever having used punch cards or paper tape. I went from 28 columns to 40 to 80 as I learned programming in the 1980s. 80 columns is a very comfortable width. 132 pushed it too far.

80 columns actually corresponds pretty well to the amount of text you'd have on a type-written page on standard letter size paper (or A4, if you prefer). You get 60 to 72 characters across (assuming 1" margins) depending on whether you're 10CPI or 12CPI, and that's roughly how wide programs are when written within 80 column boundaries.

2 days ago
top

Google Quadruples A.M. Turing Award To $1M

Mr Z Re:Lamport (42 comments)

Indeed!

A few years back, I was implementing Leslie's Bakery Algorithm. (Which, to be sure, you should look up his original paper, not the bastardizations you sometimes find in textbooks. That paper and more are available here.)

In my implementation, I wanted to SIMD-ize one of the steps to make it more efficient. I thought the transformation was valid, but wasn't certain, so I emailed Dr. Lamport. I was pleasantly surprised when Leslie actually replied to my email.

And yes, the transformation was valid. *whew* Our multiprocessor DSP software got a little faster that day.

Anyway, there's some fascinating stuff on his page full of papers. The link again: http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html

about two weeks ago
top

There's No Such Thing As a General-Purpose Processor

Mr Z Re:Hyperbolic headlines strike again (181 comments)

I think part of the problem is that the axes aren't linear. If you know the problem you're trying to tackle a priori you can tackle it with multiple magnitudes of greater efficiency. For a fully specified, unchanging problem, I'd expect 3 orders of magnitude or better in most spaces, because you'd build exactly the hardware you need, and strip away all the hardware that supports unneeded programmability—you build a hardwired ASIC. Even in the programmable space, spending a bit of effort matching your problem to your processor can bring huge gains in efficiency, at least 5x. Also, consider that efficiency isn't just run time, but rather a function of power, performance, and cost.

The algorithms that run on a hearing aid would sop the hearing aid's battery before they were even fully loaded if you tried to run them on a typical desktop processor. But, they're baked down to a hyperefficient DSP or ASIC that's tuned specifically for the problem.

You cite a SPEC benchmark that runs faster on an A7 than an A15. Is that in clocks or wall-clock time? I suspect it's dominated by pointer dereferences, such as a linked list traversal. Load-to-use latency (which isn't a function of cache organization, but rather pipeline depth) becomes a dominant term for those workloads.

Backing up a bit: My problem with your thesis is that you assume there's a "best GPP" and then seek to prove there's no one processor that could possibly be that on the basis that across random applications, the winner varies. Your argument seems to be, at the limit: "if you don't tell me your application ahead of time, I can't pick a best processor, so therefore there's no general purpose processors."

It's the other way around. There's a cluster of processors that are OK at a range of random tasks. They're distinguished from special-purpose processors by the fact that the special purpose processor performs at least 5x or more (and likely orders of magnitude in some cases) better than the average for the cluster. That's true even if some of the processors in that cluster are 2x more efficient than the others. A processor is a GPP if there's few or no problems for which it's orders of magnitude more efficient than its cohort. 2x is nothing to sneeze at, but a specialized processor should reach much higher. 5x at a minimum.

And please note I'm mentioning efficiency. It's not raw cycles or even wall clock time. Maybe a better measure is "energy per function", or "energy per function per dollar." (Although the latter is a bit dubious, as you buy the hardware once, but you use it many, many times. Lifetime costs are best approximated by energy costs over the lifetime of the device, if you're doing significant compute.)

You mention GPUs. Sure, GPUs provide cheap FLOPs, and they can even start to run arbitrary C programs. But, what %age of those FLOPs get utilized when running random programs? You might get a 4x speedup offloading some algorithm to your video card, but is that a win when your video card's raw compute power is 100x your host CPUs? Would you buy a Windows machine powered only by a GPU, running everything from your statistical regression to your web browser?

(I may exaggerate, but only slightly.)

To me, "general purpose" means, "I run the compiler, and for the most part, I get what I get. If there's some hotspots, maybe I can tune for this specific architecture. Most of the time, I don't worry." Specialized means "by selecting this processor for this task, I know up front I need to spend time optimizing the implementation of the task to this processor."

Perhaps the qualm is that really that's more a function of the application than the processor. OK. I can buy that. But, when you look across the space of processors that get deployed in that way, you'll see that most processors tend to end up one one side or the other of that line fairly often, and few are on the fence. You find very few DSPs and GPUs asked to run Linux or Windows kernels and applications (the core code, not the stuff they compile to be offloaded, say, in a shader language). You find some number of x86s asked to run signal processing applications, but only where they can afford the cooling.

about two weeks ago
top

First Experimental Demonstration of a Trapped Rainbow Using Silicon

Mr Z Re:Mind-blowingly cool, but... I don't get it. (79 comments)

Due to self-interference, the light bumps into itself on the way out, and subsequently can't get out. At least at my limited level of understanding, it's the wave-light nature of light at play here.

I imagine at some point, the trapped photons all get absorbed and the original energy dissipates as heat.

about three weeks ago
top

First Experimental Demonstration of a Trapped Rainbow Using Silicon

Mr Z In the future... (79 comments)

In the future, instead of complaining about letting the blue smoke out, we'll complain about letting the blue light out.

about three weeks ago
top

The Effect of Programming Language On Software Quality

Mr Z Re:Also which languages that beginners choose. (217 comments)

FWIW, I technically had some C++ before Perl, but not enough that I count it.

Re: Perl: I'm much the same way with Perl. I use Perl for lots of quickie projects. Great for anything I'm only going to spend at most a couple days developing.

Perl's also great for much larger projects too, where runtime performance isn't absolutely critical but flexibility and development ease is paramount. We actually have some fairly significant projects at work that are written in Perl.

One of them, which embeds Perl in another language as a metaprogramming language. I couldn't imagine trying to write that in C++ without a dedicated team. But, a set of hardware designers are effectively maintaining the tool in the background thanks to it being written in Perl.

about three weeks ago
top

The Effect of Programming Language On Software Quality

Mr Z Re:Also which languages that beginners choose. (217 comments)

As for which language is your gateway language, it probably depends on what era you started programming in, too. My path was Microsoft BASIC => Assembly => Turbo Pascal => C => Perl => C++11, with some shell scripting and other goodies around the fringes. I've probably written more C than anything, but C++11 rules my future. Turbo Pascal was my short-lived gateway to C, where I then spent most of my career. I wrote some truly regrettable neophyte-programmer code in C there at the beginning, so really C was where I grew from a college-aged hacker to someone who can actually program. Now guess how old I am. ;-)

I guess for an analysis like this, you really need to limit yourself to people who consider themselves competent programmers. Those VB macro whizzes in accounting likely consider themselves accountants, not programmers. Likewise for the physicist with a pile of creaky MATLAB models.

BTW, I have to agree with you 100% on make and bash. I consider myself above average on make as compared to my coworkers, but that's an extremely low bar. And while I've done some crazy stuff in bash in the past, these days I'll hop over to perl for anything more than 10 - 20 lines, especially if I find too much 'sed' showing up or find myself wanting an actual data structure.

about three weeks ago
top

The Effect of Programming Language On Software Quality

Mr Z Re:Take away for me (217 comments)

I finally brought up the PDF. It appears the authors consider C++ weakly typed because it allows type-casting between, say, pointers and integers.

While this is strictly true, I find myself avoiding such things whenever possible. Main exception: When talking directly to hardware, it's often quite necessary to treat pointers as integers and vice versa.

I guess to fairly evaluate a language like C++, you need to categorize programs based on how the language was used in the program. If you stick to standard containers and standard algorithms, eschewing casting magic except as needed (and using runtime-checked casts the few places they are), your program is very different than one that, say, uses union-magic and type punning and so on every chance it gets. (I've written both types of programs... again, FORTRAN in any language.)

One of my more recent projects was written ground-up in C++11. It relies on type safety, standard containers, standard algorithms, smart pointers (shared_ptr, unique_ptr) fairly heavily. It's been quite a different experience to program vs. my years of C programming. Way fewer dangling pointers, use-after-free errors, off-by-one looping errors, etc. But, the paper lumps both languages into the same bucket. That hardly seems fair.

about three weeks ago
top

The Effect of Programming Language On Software Quality

Mr Z Re:Take away for me (217 comments)

BTW, this ACM Queue article was linked from the blog post I linked above. It's another good, somewhat relevant read, IMHO. It makes largely the same point, though: It's more the programmer than the language.

about three weeks ago
top

The Effect of Programming Language On Software Quality

Mr Z Re:Take away for me (217 comments)

I wonder if you can do an analysis of code bases across languages for the same team? I regularly write significant amounts of C++ (these days, C++11), Perl and assembly language. Those are three rather different languages, with strong, weak and largely non-existent type systems, respectively.

Of course, all three languages also open themselves to a wide range of programming styles, and I imagine if you picked any other set of languages you could make a similar statement. But if you measure the same programmers programming in across them (assuming a reasonably high level of proficiency in all of them), then perhaps you can determine what portion of the effect is due to the programmer vs. due to the language.

After all, Real Programmers can write FORTRAN in any language.

about three weeks ago
top

Microsoft Works On Windows For ARM-Based Servers

Mr Z Re:Link = Download? (113 comments)

Remove the / from the end of the link and it works. Annoying.

about a month ago
top

FTDI Removes Driver From Windows Update That Bricked Cloned Chips

Mr Z Re:Alternatives? Same problem.. (572 comments)

And that helps this how? The counterfeits aren't mask copies, but rather microcontrollers programmed to emulate FTDI chips. This isn't a "ghost shift" problem like many counterfeit consumer goods.

about a month ago
top

FTDI Removes Driver From Windows Update That Bricked Cloned Chips

Mr Z Re:Computer Missues Act 1990 (572 comments)

Vigilanteism, in other words. May fill a sense of personal justice, but that doesn't make it legal.

about a month ago
top

FTDI Removes Driver From Windows Update That Bricked Cloned Chips

Mr Z Re:USB VID is meant for a specific organization (572 comments)

As a matter of fact, I'm releasing a product soon that falls exactly into this category. I specifically chose to keep the VID/PID unmodified, as the product has a mode where it needs to look like an ordinary serial port.

Sure, I could get modified OSX, Windows and Linux drivers to teach it about a new PID so that ordinary comms software works, but it's far simpler and less risky for a small guy like me (we're talking a few hundred units total) to just go with the flow and make it work with the generic drivers everyone likely already has.

about a month ago
top

FTDI Removes Driver From Windows Update That Bricked Cloned Chips

Mr Z Re:Computer Missues Act 1990 (572 comments)

You're technically correct that the chip hasn't been physically damaged. However, it's effectively dead, and FTDI's EULA revision makes it clear that they intend to render non-functional any clones they detect:

Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.

about a month ago
top

FTDI Removes Driver From Windows Update That Bricked Cloned Chips

Mr Z Re:Computer Missues Act 1990 (572 comments)

I recently built a big pile of boards with an FTDI USB chip on them, as part of my retrogaming hobby. I bought from a reputable source, I think. But if it turns out that I got an illegitimate batch of FTDI chips, I now own a pile of bricks until I pay to get them reworked. I don't know yet, since I haven't tested them in Windows with the latest driver.

Counterfeiting harms the original producer of the chips, and this extends the harm to OEMs that use the chips (who may or may not be innocent), and their customers (who most certainly are innocent).

I can't see how this is a good thing for anyone.

As someone said recently at work: "Deposits to the 'trust bank' are always small. Withdrawals are always large." In other words, it takes years to build trust, but you can obliterate it in seconds. FTDI may have done just that.

about a month ago
top

Barometers In iPhones Mean More Crowdsourcing In Weather Forecasts

Mr Z Re:I wish I could read (79 comments)

Ok, so I wasn't the only one.

about a month ago

Submissions

top

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

Mr Z Mr Z writes  |  about a year and a half 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 7 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 8 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 12 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?