Beta

Slashdot: News for Nerds

×

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

OKCupid Experiments on Users Too

Mr Z A/B Testing (75 comments)

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

3 hours 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 a month 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 a month 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 a month ago
top

Apple Announces New Programming Language Called Swift

Mr Z Re:Designed for safety & performance (636 comments)

Oy, is that how they're selling it? As if none of these features existed before Apple did it?

Swift code is transformed into optimized native code

As is any other language that passes through an optimizing compiler that outputs native code. They crowed about a 30% speedup above, which in my experience is sometimes achievable just by tweaking your compiler flags.

about 2 months ago
top

Is LG's New Ultra Widescreen Display Better Than "Normal" 4K?

Mr Z Re:Is this an ad ? (304 comments)

Hasn't made mine hurt.

about 2 months ago
top

Is LG's New Ultra Widescreen Display Better Than "Normal" 4K?

Mr Z Re:Is this an ad ? (304 comments)

You realize, of course, that a 26" 1920x1080 monitor is only 85 DPI, so the same font size (in pixels) on a 26" 1920x1080 monitor would actually look about 40% larger. And, you'd get more text on the screen to boot.

1280x720 at 120 DPI makes for a small screen: 10.7" x 6", which is approx 12" diagonal. Do you do all your coding on a subnotebook or MacBook Air or something?

about 2 months ago
top

Fiat Chrysler CEO: Please Don't Buy Our Electric Car

Mr Z Re:Amazon "lose $ on each book, make it up on volu (462 comments)

Well, they don't magically get cheaper to build just by building more. They get cheaper to build as the manufacturer refines the process, improves the technology, and scales the production lines to amortize the fixed costs of a production facility over a larger number of vehicles. That is, it takes work to make them cheaper, above and beyond just making more.

As long as there's sufficient demand, producers will have enough reason to scale up the production and work to bring the production cost down. Eventually, if all goes well, this begins a virtuous cycle where decreased price increases demand, and increased demand drives further cost reduction and innovation.

This works great if there's enough demand to kick-start the process. Unfortunately, the price of EVs today is too high to drive sufficient demand. Hence the carrot-and-stick incentives to try to jumpstart the virtuous cycle. On the carrot side are tax breaks and government subsidies / loan guarantees. On the stick side are fleet-wide fuel economy standards, price caps and quotas.

Right now, it seems as if most traditional auto manufacturers treat their electric cars either as halo cars, or as tasks they're required to do by law/regulation/whatever but would rather not. I doubt anyone at GM is staking the quarterly numbers on Chevy Volt sales, for example, but it doesn't stop them advertising it. The only competition at this point, though, is positioning, posturing and establishing a brand. That is, competition on the marketing front. The market's still too small to have meaningful competition driving the product development. At least, that's how it seems to me.

Eventually they'll figure out how to bring the costs down. Meanwhile, the early adopters hopefully help build interest and therefore demand in the future. When that happens, I'd expect the real competition to start. You'll see Toyota or GM or someone get into the mega-battery business, like Tesla is currently. Or some other major, bold move like that.

In the meantime, the carrot-and-stick will push both the supply and demand curves to the right, elevating the total units shipped to a modest number until the market can sustain itself.

about 2 months ago
top

Why Scientists Are Still Using FORTRAN in 2014

Mr Z Re:not in the field, eh? (634 comments)

i did give a proviso for run-time alias checks in my comment above. Our compiler will also generate a run-time check for that as well, with a small codesize and runtime cycle penalty.. The FORTRAN equivalent doesn't need the alias check.

I'd expect ICC to be very aggressive, given that Intel has one of (if not the) largest paid, full-time compiler team in the world.

So how about all of FORTRAN's other nifty features, such as array slices? To get the same functionality in C / C++, you have to put explicit strides and bounds everywhere, and sometimes checks to reverse loop directions. In FORTRAN, you can write things like "A(1:100,1:200:2) = B(101:300:2,51:150)", and the compiler is free to choose the best way to do it.

In C / C++, you leave it to the programmer to dictate the loop explicitly and hope the compiler can figure out what you're doing. In my experience, real world programmers get unusually creative with this task, creating awful code. If you write clearly enough and pay enough attention to compiler vectorization reports or other feedback, maybe the compiler + user eventually figures it out. Realistically, most programmers aren't that sophisticated. And even among the ones who are, not all have the time or inclination.

Looking back to my array slice example: Now take those slices across function call boundaries in both languages and see how much work the programmer has to do in each language...

My point is, the more work the programmer has to do to help the compiler succeed, the more evidence it's a poor fit for the problem domain. FORTRAN can make it easier for compiler writers because they start with a higher level specification of what the programmer is trying to achieve. FORTRAN also makes it easier for programmers because they stop at that higher level specification of what they're trying to achieve.

about 3 months ago
top

Why Scientists Are Still Using FORTRAN in 2014

Mr Z Re:not in the field, eh? (634 comments)

I'd argue that if you're programming in processor-specific intrinsics, you're not really programming in C++ any more. Standard C and C++ semantics for pointers and arrays really get in the way of autovectorization. So, you have to go to language extensions and kludges (like C99's restrict keyword) to throw the compiler a bone.

Sure, tricks such as whole-program analysis and run-time alias tests can help the compiler find the guarantees it needs to have in order to vectorize. The fact of the matter (and I heard this straight from the mouths of my employer's vectorizing compiler team members) is that stock FORTRAN is simply much friendlier than stock C/C++ for this due to those semantic differences.

Our compiler will autovectorize C code if you pass it enough hints such as minimum loop trip counts, pointer alignment, pointer aliasing guarantees (aka. restrict) and so forth. Even then, there are limits to what it can do. We offer processor specific intrinsics so you can vectorize the code yourself.

Once you start coding in vector intrinsics, you're taking the vectorization out of the compiler's hands and doing it yourself. Each of those intrinsics usually maps directly to an instruction or small sequence of instructions, so there's little left for the compiler to figure out. The compiler then just schedules and register-allocates the code, and handles the non-vector bits around the edges. Sure, you still compile with the C++ compiler, but the C++ compiler is no longer providing the vectorization: You are.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Terabyte flash drives are 10% overprovisioned (264 comments)

I wasn't actually thinking of DoS'ing, but I guess that's actually a valid concern. If a particular write pattern could crap a server, then you may have to worry about a user doing that to your server. I was just putting my "DV engineer" hat on, and trying to think of how I'd break an SSD in the minimum number of writes. It's the kind of analysis I'd hope the engineers that come up with lifetime specs use to give a bulletproof lifetime spec. For example, X years at YY MB/day even if you're writing like an a**hole. ;-)

I don't have a formalized attack against any particular drive, manufacturer or filesystem.

For a multi-user system, just a thought: Could you address it with quotas? If a given user can't write to more than X% of the filesystem, you can bound the "badness" of their behavior.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Oh goody (264 comments)

I'm not challenging the 30 day number, to be sure.

It's not entirely true that write amplification won't appear to speed up the rate at which an SSD erases sectors. SSDs generally have multiple independent flash banks, and each can process an erasure independent of the others. To maximize your erasure rate, you need a pattern of writes that triggers erasures across all banks as often as possible. Each bank will split its time spent receiving data to write, committing write data to flash cells, and erasing flash cells. (My assumption is that a given bank can only be doing one of these operations at a time, which was certainly true for the flash devices I programmed.)

Consider a host sending a stream of writes as fast as it can send it. The writes will land on the drive as fast as the SSD controller can process them and direct them to flash cells. If there are any bottlenecks in that path, such as generating ECC codes and allocating physical blocks in the FTL, it will slow down the part of the duty cycle devoted receiving and committing write data.

A "friendly" write stream would minimize the number of GC cycles the SSD performs, and thus the amount of write amplification that occurs. Thus, the total number of writes to the SSD media is at most slightly larger than what the PC sends, and the "receive-write" portion of the "receive-write-erase" cycle gets lengthened by whatever bottlenecks might be in the PC-controller-flash path. A "hostile" write stream triggers a larger number of GC cycles to migrate sectors. It seems reasonable to me that an on-board chip-to-chip block migration might be quite a bit faster than receiving data from the PC. For one thing, you don't necessarily need to recompute ECC. The block transfer itself could be handled by a dedicated DMA-like controller transferring between independent banks in parallel with other activity. So, generating more write data locally to the SSD could reduce the time spent in the receive-write portion of the receive-write-erase cycle, so you can spend a greater percentage of your time erasing as opposed to receiving or writing.

It seems a little counter-intuitive, but it's in some ways similar to getting a super-linear speedup on an SMP system, which is indeed possible with the right workload. How? By keeping more of the traffic local.

The main effect of write amplification, though, is on the SSD wear specs themselves, as I said. They're stated in terms of days/months/years of writes at a particular average write rate. So really, when you multiply that out, they're specified in terms of total writes from the PC. There's at least one flash endurance experiment out there showing that drives often massively exceed their rated maximum total writes by very large factors. One reason for that, I suspect, is that they aren't sending challenging enough write patterns to the drive to trigger worst case (in terms of bytes written, not wall-clock time) failure rates.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Terabyte flash drives are 10% overprovisioned (264 comments)

OK, I see that SandForce has on-the-fly compression tech, which I imagine would help more reasonable workloads. (Although, if your workload involves a lot of compressed video or images, that compression tech won't buy you anything.)

The point of my thought experiment, though, was how I would construct a maximally bad workload, and it's pretty easy to nullify compression with uncompressable data.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Terabyte flash drives are 10% overprovisioned (264 comments)

A 4TB drive would bother with compression why exactly? It won't improve any benchmarks. Someone like me trying to break the media would just write uncompressible garbage anyway.

A large overprovisioning pool does help stay in the dynamic wear leveling paradigm longer. If the drive performs any amount of static wear leveling, though, where it can get the rest of the sectors into the fun and there's a limited aging ratio / aging difference between the most-erased sector and least-erased sector, then the size of the overprovisioning space doesn't matter too much this attack—rather, the total media size matters.

The point of this attack is to limit the ability of the SSD to separate disk sectors into hot and cold effectively, so you can force the maximum number of erasures through garbage collection cycles. As long as the overprovisioned space is less than the ratio of exposed sector size (512 or 4K bytes) to erase sector size (likely something huge like 512K bytes), you can force a lot of erasures just for GC compaction. The drive will still spread these erasures out as much as possible. With the blended dynamic/static wear leveling model, you'll end up aging all of the sectors roughly evenly.

Once you get one sector to fail and get taken out of service, you're close to making as many more fail as you like, since the SSD did everything it could to age sectors evenly. The additional delta work you need to get it to fail completely isn't very big.

In case my GC point wasn't clear: Consider a simple SSD with a capacity of 32 "blocks", of which it advertises a capacity of 24 to the user, leaving 8 for overprovisioning. Suppose that filesystem blocks get grouped into erase blocks with a 4:1 ratio. Now suppose I've filled that disk up to capacity with a linear series of writes. You might represent it like so, with letters representing FS blocks with data, dashes representing empty clean FS blocks that the FTL can write to, and the groups of 4 separated by dots representing the erase blocks:

abcd.efgh.ijkl.mnop.qrst.uvwx.----.----

Now suppose I write to A, E, I, M. I need to migrate these FS blocks to new locations to absorb the writes. Their old locations are freed, but remain dirty (cannot be rewritten). After these 4 writes, my flash might look like this: (The '#' indicate free-but-dirty FS blocks.)

#bcd.#fgh.#jkl.#nop.qrst.uvwx.aeim.----

Before this SSD can execute my next rewrite, the flash needs to perform a GC cycle to ensure it always has a place to migrate data for GC. So, before processing another rewrite, it performs a GC cycle, migrating blocks until it has at least clean two erase sectors. For the sake of argument, let's assume it employs a simple round robin scheme to spread the GC over the media evenly:

##cd.#fgh.#jkl.#nop.qrst.uvwx.aeim.b--- Migrate 'b'.
###d.#fgh.#jkl.#nop.qrst.uvwx.aeim.bc-- Migrate 'c'.
####.#fgh.#jkl.#nop.qrst.uvwx.aeim.bcd- Migrate 'd'.
----.#fgh.#jkl.#nop.qrst.uvwx.aeim.bcd- Erase first sector.
gh--.####.#jkl.#nop.qrst.uvwx.aeim.bcdf Migrate 'f', 'g', and 'h'.
gh--.----.#jkl.#nop.qrst.uvwx.aeim.bcdf Erase second sector.
ghjk.l---.####.#nop.qrst.uvwx.aeim.bcdf Migrate 'j', 'k', 'l'.
ghjk.l---.----.#nop.qrst.uvwx.aeim.bcdf Erase third sector.
ghjk.lnop.----.####.qrst.uvwx.aeim.bcdf Migrate 'n', 'o', 'p'.
ghjk.lnop.----.----.qrst.uvwx.aeim.bcdf Erase fourth sector.

Now I continue with my dickish attack, and rewrite Q, U, A, and B:

#hjk.#nop.quab.----.#rst.#vwx.#eim.#cdf

Oh, hey, that'll trigger another GC cycle to free up a sector:

#hjk.#nop.quab.rst-.####.#vwx.#eim.#cdf Migrate 'r', 's', 't'
#hjk.#nop.quab.rst-.----.#vwx.#eim.#cdf Erase fifth sector
#hjk.#nop.quab.rstv.wx--.####.#eim.#cdf Migrate 'v', 'w', 'x'
#hjk.#nop.quab.rstv.wx--.----.#eim.#cdf Erase sixth sector
#hjk.#nop.quab.rstv.wxei.m---.####.#cdf Migrate 'e', 'i', 'm'
#hjk.#nop.quab.rstv.wxei.m---.----.#cdf Erase seventh sector
#hjk.#nop.quab.rstv.wxei.mcdf.----.#### Migrate 'c', 'd', 'f'
#hjk.#nop.quab.rstv.wxei.mcdf.----.---- Erase eighth sector

Keep up the pattern, writing to the first FS block in each erase block, and you'll maximize the number of erasures due to GC. Sure, all those erasures take time, but you can bring your time to failure down to a function of the total number of erasures the media can tolerate before it fails in a minimal number of writes. If the media has any parallelism between flash modules (so that it can execute multiple erasures in parallel), you may even be able to get that working in your favor, assuming your explicit goal is to make the drive fail as quickly as possible.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Oh goody (264 comments)

The point of write amplification is solely to get more sectors into the erasure party. A single small write forces the SSD to migrate full sector A to empty sector B.

If you could send direct physical sector erasure and physical write commands to the media, you could just tell it to erase each sector and rewrite its first byte repeatedly until that sector failed, and then march to the next sector.

But, you don't have the opportunity to do that. Instead, you must interact at the filesystem level, and there's an FTL between the file system and the media. So, if your goal is to ruin the media quickly with those two layers between you, you want to minimize the FTL's ability to filter writes out and reduce the required number of erasures.

I'm aware that erase times for sectors are huge, and will slow your I/O rate accordingly. You're right that write amplification doesn't necessary shorten the calendar days to failure, as a different write pattern may have triggered the same number of erasures in the time frame with a larger number of writes. But, writes aren't free either, so there's at least some, err, benefit to minimizing the number of writes required to ruin your SSD, if your goal is to ruin your SSD as quickly as possible.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Oh goody (264 comments)

If you want to write once and forget it, you can fill the thing right to the top of the advertised capacity, and you don't have to worry about failure due to wear. Instead, you have to worry about failure due to electrons migrating off the bits. So, you need to refresh all the bits every so often, much like DRAM, only with a much slower refresh interval. Even if you refresh all the bits on the drive once a day, if you do so in a nice, orderly manner, I'd imagine you won't reach the rewrite limit for the drive in your lifetime.

Still, I'm not sure I'd choose an SSD for that.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Oh goody (264 comments)

Yes, I know what Stacker, DoubleSpace and DriveSpace were as a technical implementation. My point is mainly that modern Windows still offers a mechanism to compress files on a live filesystem. It just lets you select at folder granularity rather than whole-disk granularity. The fact that they're not implemented at the same layer of the stack I didn't think was relevant here.

Stacker et al worked at the sector level so that you didn't need to modify DOS or the umpteen programs that made use of sector-level access to the filesystem, and insisted on that level of access in order to function. Copy protection schemes and disk editors both relied on it. (Defraggers too, although defragging a compressed volume is... crazy.) Databases may have as well; I'm not certain. Windows NT forces programs through a narrower, more controlled window of APIs to access the file system.

I actually had a Stacker'd hard drive back in the day and had read up on all the tech, so it's not like I'm unfamiliar with it.

about 3 months ago
top

SanDisk Announces 4TB SSD, Plans For 8TB Next Year

Mr Z Re:Oh goody (264 comments)

Ok, I just checked in my WinXP box: You can right click on a folder, go to "Properties". Click "Advanced", and there's an option to "Compress to save disk space." I'm too lazy to go get my Win7 laptop to see if that's still there.

So, some version of TroubleSpace...err...DoubleSpace...err...DriveSpace survived beyond Win98.

about 3 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 Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Create a Slashdot Account

Loading...