Slashdot Mirror

"Atari 2600 cartridges are 4 kB maximum."

Not really, once they figured out some simple logic circuits they could bank switch more ROM than that, and probably address RAM chips too.

http://www.schells.com/ccbackg...

Atari 2600: Cuttle Cart 2 (although it requires a 7800, it supports 2600 images as well)
Game Boy (Color): any of the numerous GB Xchanger-type copiers
SMS: Tototek SMS-PRO
Genesis: Tototek MD-PRO

As far as I know, the only one of those consoles that doesn't have some sort of flash memory, is the NES. The problem, of course, is mapper support. I do seem to remember someone working on a flashcart with support for the most common mappers, but I haven't heard anything recently. Even then, a common cart containing the desired mapper can be modified to accept EPROMs (although this is admittedly harder that merely downloading a ROM to the cart).

Can the average person just go online and buy rewritable cards for the Atari 2600, NES, 8-bit Game Boy, Sega Master System, and Sega Genesis?

You can purchase 2600 and 5200 homebrews here:

http://www.atariage.com/store/

A 7800/2600 "CuttleCart" (which allows you to play games from a MMC card) can be purchased here:

http://www.schells.com/cc2.shtml

You'll note that the CuttleCart3 will be for the Intellivision. There used to be a cart called the "IntelliCart" that used a serial cable, but it's been unavailable for several years. There doesn't seem to be anyone releasing Intellivision homebrew carts despite the thriving homebrew community. So you'll need to find a used IntelliCart, or purchase a CC3 when it comes out.

Homebrew Odyssey^2 games can be purchased on PackRatVG's site here:

http://www.packratvg.com/o2hbrews.html

Even more O2 homebrews, along with Colecovision and Vectrex homebrews can be found here:

http://www.classicgamecreations.com/

Note that O2 homebrews tend to be a lot better than many of the original games.

I don't know much about the NES homebrew scene, but I do know there are a lot of them. Look around and you'll probably be able to find carts for purchase.

Nobody will know until they actually have one to open up. I doubt it will be easy to mod, but it's still possible. It certainly won't be this easy. (I'm glad I got one, because it's unlikely he'll make another production run without a lot of interest. Plus, the MMC slot part isn't available any more, so it needs some re-design, too.)

FYI: 234 Intellicarts were produced and one was lost by the postal service.

But if we could only combine current media (an 8/16 MB compactflash card could hold every version of every game ever written for this machine) you'd have something.

Unfortunately, it's not cheap, and it requires a much-harder-to-find Atari 7800, but it's a big step in the right direction.

t would be nice to find programmable ROM cartriges for the 2600.

Sorry, but the Cuttle Cart has been discontinued. I'm sure there are alternatives, though.

Another interesting idea is for some small company to develop gameboy-size atari 2600 pads with most of the games built in. Could even be incorporated into cell phones, now that I would buy.

Go ahead.

But if we could only combine current media (an 8/16 MB compactflash card could hold every version of every game ever written for this machine) you'd have something. Especially now that Sean Kelly doesn't seem to be able to offer his carts for sale any more. Sorry.

I should really have split this to 3 different posts to max the karma benefits. Oh, well. Maybe I'll get the rest in offline karma.

Here is a fairly comprehensive list of the homebrew games that have been released for the 2600 in recent years:

2600 Homebrew Search Results

And here is a list of games that are currently in development for the various Atari consoles. This list changes pretty frequently, and there are some projects not yet listed as the authors aren't very far along with them (Yes, I know that last link is listed in the linked story, just including it here for the convenience):

Titles In Development

A list of Atari 2600 games that have been hacked to change the graphics, sounds, colors, and more!

Atari 2600 Hacks

And finally, many games that were only released in either NTSC or PAL formats have been modified to work with the other television standard. This is useful for people who have the ability (such as through a Cuttle Cart) to play these binaries on a real television:

Atari 2600 TV Format Conversions

Enjoy!

I'm sure I had a point...

Okay - Cuttle Cart. Play any 2600 ROM on real hardware by encoding it as audio and playing it into the cart. A complete collection of Atari 2600 ROMs is six or seven 99-track CDs. That includes a large number of unreleased prototypes, modern releases and hacks.

(Meanwhile, Lik-sang have recently denied a credit card payment because of some peice of information that Australian banks don't give out.)

I'd comment on this story if I could actually download a sample, but 46 minutes for 2.75MB is code for "This download will break in 3... 2... 1..."

But what about recoil?

Oh, it's self-coiling.

Take your buzzword bullshit elsewhere, troll.

Or another.
--
Program Intellivision!

Information can travel no faster than the speed of light. Period.

One problem with these high clock rates is that you end up having to pipeline things rather excessively all over the place. I'd imagine at 750GHz that even a single 64-bit ADD would be pipelined over multiple cycles, due to transport delay!

Think about it: Light travels about 1 foot per nanosecond (30cm). At 1GHz speeds, a signal could travel well across a die if it were unimpeded (eg. could travel at the speed of light). In fact, it could theoretically travel most of the way across the motherboard in one clock period. At 750GHz, light travels 0.4mm per clock tick -- about 1/20th the way across a typical CPU die (assuming a die in the range 8mm x 8mm to 10mm x 10mm die -- not too far off what we build today). We're talking 20 pipeline stages just to get from one edge of the die to the other, if we can travel at the full speed of light in a vacuum. And the bad news is that we probably can't -- just look at todays CPUs!

What'll happen is that highly parallelizable problems will speed up, and inherently serial problems will end up staying the same. All of your number crunching for playing video games will rocket along since the calculations can be pipelined and parallelized, but the twisty, turny, five-instructions-and-a-branch control code won't speed up much.

Because the Pong game on Keen's wristwatch is K-rad!

What shell are they using?

And just how many copies of this hypervisor could you run at once on the same machine? Hmmm? What was that, only one? Thought so.

Multitasking VM86 sessions does not mean you've fully virtualized the CPU.

And in other news, Water is Wet, Gravity Sucks, and Nader Still Lost.

There's no "global maxima" associated with the concept of "better". Different flavors are better at different things. I suppose that's the concept you were grasping for? If so, why invoke the concept of "winning", when you're not necessarily pitting the different flavors head to head?

When I say "X is near Y", that just means they're in the same proximity. When I say "X is nearly Y", that means that X is almost Y, but not quite. When referring to numerical quantities, this can be explained like so:

• "X is near Y": abs(Y - X) < epsilon, where epsilon is a small, positive value.
• "X is nearly Y": Y - X < epsilon, where epsilon is a small, positive value.

See the difference?

The article above says "nearly 1 in 250", which implies that the odds are below this, but near this. The actual odds are "1 in 249", which are greater odds, not lesser odds (meaning, more likely than 1 in 250, not less likely). You could've avoided the whole thing by saying "about 1 in 250", or even "about 0.4%".

*sigh

Have you seen the reprint of K&R 2? It's the same number of pages as the copy I bought several years ago, but they used such a thick stock that the book is actually thicker than O'Reilly's "C++: The Core Language". It's nearly 3x as thick as my original copy. Absurd.

(Ok, so maybe the pages aren't 3mm thick, but still...)

Something tells me the author did the calculation for 3nm, not 30nm...

Did you mean "One point twenty one gigawatts!!!!"

Now get back to work on that flux capacitor.

Sure would be nice if the fact checking at space.com were just a tad better than /. :)

Get YOUR facts straight, bub. The 83 million mile figure applies to Pioneer 6 which is orbiting the sun and is 35 years old, not Pioneer 10 which is 28 years old and has left the Solar System .

Lots of the early probes failed, IIRC, it's just that nobody remembers the early failures.

Yeah. It's too bad MTV doesn't air the rocket-crashing-on-the-launchpad "M" commercial anymore. (You know, one of the classics from the 80s.) Now I got that damn theme going though my head: Dum, Da Dum, Da dum, Da da da daDUM, Da Dum, Da dadada, Da dadadaDUM, Da Dum, Da dadada, Da dadada...

Ok, so my posts tonight aren't exactly value-added. It's Saturday, ok?

Hell, just the three-way TCP handshake would tie it up for quite awhile... (think RTT).

My English teacher once told me that two positives don't make a negative. Two words for her: Yeah, right.

My English teacher once told me that I was using double negatives. I said to her, "No I'm not!"

Whatever. Whenever I close workman, the tasklist_applet just "goes away". I ended up adding a button down there to restart it, otherwise I can't bring my windows back once I've minimized them.

Actually, my computer won't detect > 8.4GB, and there's no BIOS upgrade for it either. (It's a Gateway OEM version of a prereleased Intel board. The final release Intel mobo has BIOS upgrades available, but the Gateway version does not.) Anyway, I refused to install any of that EZ-BIOS / MaxBlast / Whatever crap on my system to avoid the exact problems you're having booting multiple OSes.

The funny thing is, I can't so much boot a DOS / Windows floppy let alone boot Windows if my 17GB Maxtor is enabled in the BIOS. It hangs right after "Starting MS-DOS..." or "Starting Windows..." when it goes to query the BIOS for drive info. Whoo hoo! Even funnier is the fact that LILO has no issues with the drive, and I just tell Linux what the correct geometry is and life is good for Linux.

So, what I do is this: In those rare (about twice a year) cases that I boot Windows, I just disable the IDE controller in the BIOS and boot from my SCSI drives. (Yes, I have both in my system -- SCSI for all the important stuff, IDE for my CD-ROM master images and other non-critical bulk storage.) To boot Linux, I re-enable the IDE and LILO takes over from there. Tada!

Anyway, I feel your pain. If you want to dual-boot Linux / Windows on your EZ-BIOS machine, I'm sorry, but you can't. (At least, no way that I know of.)

And why doesn't Linux work on your spacious machine? I started out with a 486 DX/33 with 8MB RAM, and I even ran X. (Well, ran probably isn't the right verb, but you get the idea.)

The hugely annoying thing here in DFW is not knowing whether a number is supposed to be long distance or not. I've got a bunch of friends who live in Arlington, and I live in Plano, and it's a pain to remember who I need to dial 1 to call, and who I don't. Never mind the fact that when I call "long distance" (40 miles to Arlington), I get charged more than when I place phone calls to Boston or Sacramento.

I feel your pain. I live in North Richland Hills and work in Dallas. I pay SWB an extra $17 a month for "Extended Local Calling" because NRH seems to be a vacuum as far as reasonable phone service goes. My ZIP code shows up as a Fort Worth ZIP code because I'm so close to Fort Worth, yet even Fort Worth is long distance w/out the extended calling area. Bleh.

Thankfully, they're all local calls on my cell-phone. I'm thinking of calling SWB and taking my land-line down to "lifeline" status -- eg. a dialtone and 911 access, not much more. Right now, I pay $80/mo for that phone, and don't use it nearly as much as I use my cell phone. (Yes, $80/mo for ONE LINE, with extended local calling area, call waiting, and touch-tone service. Yes, touch-tone is still "optional".)

It might have to do with how the LATAs are structured in your area. If the call is within the same LATA (Local Access and Transport Area), then you shouldn't need an area code. If it's inter-LATA, you may need an area code, even if the area code number is the same. LATAs are structured differently than area codes, and so make things even more confusing. Wheee....

Right, but there aren't any 724 exchanges in there, I'd imagine. Unless you have 10-digit dialing, you can't have an exchange and an area code be the same, unless you want to rely on a flaky system of timeouts to disambiguate.

Typically, if your call is within your area code, you don't need to dial the area code, just 1 followed by the last 7 digits. If the number isn't long-distance, you only dial the last 7 digits. This is referred to as "7 digit dialing." In the larger metroplexes, where the metroplex itself is covered by multiple area codes, this just starts getting silly, because a number can be local, but not in your area code. Many of these metroplexes have converted to 10-digit-dialing, which means for all local calls, you must dial all 10 digits, and for long-distance calls, 1 plus the remaining 10 digits.

To give you an idea of the current state of the universe, in the D/FW area we have 972, 214, and 817. Chicagoland has several, none of which I can remember. Detroit has 810 and 313 (and maybe more since last I looked). It's getting freakin' ridiculous. And I've done nothing to make it better -- my fiancee and I both have mobile phones.

One of the nice things about 10-digit dialing is that it now opens up new exchanges and new area codes. It used to be that area codes always had a 0 or 1 as a middle digit, and that exchanges never did. This allowed the switch to be able to tell an area code from an exchange. In areas w/ 10-digit dialing, they can bring in new area codes which violate this rule (eg. 972 in the Dallas area). Once 10-digit dialing is establised, they can start brining in exchanges which violate this rule as well (for instace, my fiancee's cell phone is in the "817-800-xxxx" exchange.)

We have 10-digit dialing here in the D/FW metroplex, and it works fine as far as I'm concerned. I've often wondered when they'd go ahead and just switch the whole nation. It's rather annoying to have to remember as you're traveling whether a given area is 10-digit or 7-digit. I haven't heard anyone complain about 10-digit dialing being annoying as comparied to 7-digit.

So who was making the fuss? Any legitimate reason other than "I don't like it"?

Yes, but the standard didn't need extending at all.

Strictly, no. Pragmatically, yes. There is (unfortunately) too much code which uses long where int would suffice (at least on modern machines).

long could just have been made 64-bit (or 128 or 256 or whatever).

Agreed. Indeed, that's what TI's compiler does for the C6000-family DSPs. The long type is 40-bits wide, since the DSP supports a 40-bit type in hardware (for high-precision filters). Unfortunately, it breaks code which assumes long is exactly 32 bits, and it causes code which only needed 32-bits (but which otherwise doesn't break) to run much less efficient. It's very annoying when a customer compiles their code and says "the output is big and slow, your compiler sucks", when really the problem is that their variables are declared as longs rather than ints.

That said, you could argue the case for needing a new type to hold integers larger than the machine's word length

Personally, I'd be happy if there was a portable way to get at something like a carry bit, so that arbitrary precision arithmetic isn't so painful. Right now, if I want to do arithmetic at a size larger than the largest available integer type, I either have to jump through hoops to figure out what the carry was supposed to be and do math at the maximum machine word size, or do math at some smaller size and use upper bits to represent the carry. Annoying, annoying, annoying.

and retain a traditional unsigned long as the word length (so that you can cast to and from pointers).

Ick! Ick! Ick! Actually, on the platforms I'm interested in, sizeof(int) == sizeof(void *) , but not necessarily sizeof(long) == sizeof(void *). Assuming you can typecast a pointer to an integer type and back is asking for trouble. (Although historically (and for old K & R C compatibility), typecasting between a pointer and an int is usually possible and fairly reliable across 32-bit environments.)

Cool! I had missed that in C99. I knew about some of the other features (some of the initializer stuff, restrict pointers, the new complex type, etc.) but I had missed that one.

Thanks for the pointer!

For cases where you have lots of little things packed together, you have bitfield structure members. (Not that those have nice packing guarantees, but they are implementation-defined and thankfully the implementations I've worked with are sane.)

Ideally, your code shouldn't rely on data types being exactly some width, but rather rely on them being at least some width. After all, signed integer overflow is actually undefined by ANSI, though every platform I've run into says it behaves as you'd expect 2s complement arithmetic to behave. Of course, none of that stops people (including myself) from writing code that relies on the specific width of the data types.

What we really need are the "unspecified width integral types" such as we have today in int and friends, and a new set of types (or type aliases) for "exact width integral types". The latter might not get complete support from a conforming compiler, but at the same time, could make life for a bitfidler like me much nicer.

... didn't get the joke. The mother language of B and (later) C was BCPL. So it stands to reason that the next two languages should be P, and then L. Of course, some in the perl community have claimed they're the PL...

ObPun: Back before C was called C, it was called New B. I guess even Ritchie and Thompson aren't immune from l33t sp33k.

i.e. The "long long" hack in C99 is just plain stupid. How is C/C++ going to be patched *cough hacked cough* to support 128-bit integers? "long long long"?

You could make long long 256-bit, long 128-bit, int 64-bit, and short 32-bit if you really, really needed to. The standard certainly permits that.

What really grinds me is that so many people assume sizeof(long) == 4 or worse sizeof(long) == sizeof(int) == 4. On the C6000-family DSPs, long is actually 40-bits long whereas int is 32-bits. You'd be surprised how many people this trips up.

And don't forget, randomly switching from night to day to night. "You stupid, stupid people!"

Hehehehe! :-) Thanks for the chuckle. 'Course, I'm only 25.

Huh? Token Ring vs. Ethernet only makes a difference for your local segment of LAN, and represents only the lowest layer of the protocol stack, the PHY (Physical) layer. You still get TCP and IP layered over that if you wish. You're only going to run Token Ring to a router or thereabouts.

Sheesh. Kids these days. They type "winipcfg" and they think they know networking.

Hey, no problem! I guess it would've just been nice to at least mention software pipelining if you're going to mention rotating registers at all. :-)

In any case, no worries.

Register windows and rotating registers are two different things entirely. The former is used for context switching between functions. The latter is for hardware-assisted, software-controlled register renaming in software pipelined loops.

Register windows slide up and down, providing a (theoretically infinite) stack in the register file. Each positioning of the window provides a "context", which represents the set of registers provided to a function at the function-call boundary. The chip implements a fixed number of contexts, and if you exceed the sliding window in one direction or the other, you take a fault and the fault handler slides the context for you. Presumably, you stay within the chip's implemented contexts most of the time and avoid faults. Such a technique saves you from having to push/pop as many registers around function calls.

Rotating registers work in a modulo fashion, with N registers (configured by the user on IA-64, as I recall) rotate every time a special branch is taken. (On IA-64, they have a "software pipeline branch" which triggers register rotation.) That's a completely different purpose.

A separate facility that IA-64 provides is a set of rotating predicates that can be used to provide "stage predicates." This gives you a mechanism for generating prologs and epilogs from a software pipeline kernel. This is the "avoiding bloat" bit you referred to. While this is still part of the rotating registers, it deserves special mention because it's a distinct use from the other uses of rotating registers that I've discussed elsewhere on this article.

And as for bitwise rotation, the IA-64 does provide that with the shrp instruction. You just provide the same argument to both halves of the pair.

Uhm, the code you posted looks just like what I posted, unless my tired eyes missed something. Anyway, the point is that yes, the adds must occur in order, but the adds from one iteration can now occur in parallel with a future iteration.

Let me illustrate "graphically" what a single-cycle version of this loop might look like on an infinite resource machine. I'll use || to show instructions in parallel. I'll put the first full iteration in bold -- the subsequent iterations which are placed in parallel will be left unbolded.

• b = *a++
• b1 = b || c = b + t || b = *a++
• b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++
• b3 = b2 || e = d + v || b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++
• loop: *g++ = e + b3 || b3 = b2 || e = d + v || b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++ || if (i++ < N) goto loop

Note that there is a considerable "pipe-up" to the loop kernel. They don't call this software-pipelining for nothing!

Write-After-Read hazards are particularly interesting in the case of software pipelined loops. First, some terminology: a value is live from its earliest definition to its last use. In the example above, x is live from the first statement until the second within the body of the loop. In a given loop, a value may be live for quite a long time. However, the initiation interval for the loop might be quite short. This can lead to problems, such as violated Write-After-Read hazards.

Ack, it's late and I'm tired, and I forgot to link this back to my introduction of loop-carried dependences. In this case, the way you avoid the violated W-A-R hazard is to introduce a new dependence known as an anti-dependence. An anti-dependence is a dependence on the use of data relative to its destruction; in contrast, a flow dependence is a dependence on the creation of data relative to its use.

In this example, an anti-dependence exists from g[i] = e + b to b = a[i] on the next iteration. This forms a cycle in the dependence graph, and gives us a much larger recurrence bound. This leads to an artifically high iteration interval and low performance.

We break this recurrence by inserting the moves I mentioned in the remainder of my post, or by using rotating registers. Sorry for my lameness there.

With all the wild speculation going on around here, I thought it might be worth throwing some actual links in here to real information.

• Itanium Processor Family Home -- has links to all sorts of IA-64 material.
• The IA-64 Architecture Specifications and Guides -- lots of good documentation links.
  • Architecture Software Developer's Manual Vol 1, rev 1.1: Itanium (TM); Application Architecture
  • Architecture Software Developer's Manual Vol 2, rev 1.1: Itanium (TM); System Architecture
  • Architecture Software Developer's Manual Vol 3, rev 1.1: Itanium (TM); Instruction Set Reference
  • Architecture Software Developer's Manual Vol 3, rev 1.1: Itanium (TM); Processor Programmer's Guide
• And don't forget Itanium[TM] Processor Microarchitecture Reference.

I haven't read all of these myself, but I have poured over the details that are most relevant to my work. :-)

Have fun.