Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


kskunk last won the day on January 5 2012

kskunk had the most liked content!

Community Reputation

381 Excellent

About kskunk

  • Rank

Profile Information

  • Gender
  • Location
    Atari Mecca Sunnyvale, CA
  • Interests
    Making hardware and software for Atari 8-bits and Jaguars

Recent Profile Visitors

12,614 profile views
  1. I love this quote from OMNI documentation dated March 1984. It lines up perfectly with the stories we've heard of Warner Atari: Amazing that someone working for Atari, on a document intended for Atari management, would casually mention how incompetent their leadership was.
  2. Absolutely amazing. I really appreciate the work you do on the Atari Museum. I love reading classic datasheets and design manuals. It really improves my understanding of what Atari was thinking year by year.
  3. If it says "JAPAN", that's Toshiba. The number starting with 6SC is a Toshiba ASIC process number, telling you the die size, density, layer count, etc. I don't have any first-hand knowledge of these issues, but CryanoJ has at least one explanation above, about differences in the Object Processor. Normally, in mass production, you try to use every component in stock, even if it means mixing and matching chip revisions and PCBs. So, where possible, like on your board, they did! The fact that your Jaguar works fine means the differences must be very minor. No, there's only one. But, there's a lot of history in the netlist! For example, you can see that we have the Motorola version, and it came later. You can find parts of the Toshiba version commented out. You can see dates here and there, marking when bugs were fixed. Also, you can see bug numbers, which give some sense of when they were found and fixed. (Higher are probably later.)
  4. That makes sense! I can see changes in the Object Processor for the Motorola version: There's a "Motorola TOM" comment in OBDATA.NET with the previous logic commented out. In the same file, there are other references to TOM1/TOM2, so the OP is probably an area that saw changes after V1.0. Do you remember any more details? Were there any mentions in the dev docs?
  5. I don't think there's any difference you'd notice. I looked into this a long time ago, and found: 1) Tom V1.0 made by Toshiba in December 1993. 2) Tom V1.1 made by Toshiba in March 1994. 3) Tom V1.0 made by Motorola in September 1994. The dev manuals don't mention any difference, but we can also check the netlist (design) for Tom. The netlist does not show any changes in the time period between V1.0 and V1.1, so I think the design itself is unchanged. Instead, it's probably a change in the chip process or implementation - something to reduce cost by yielding more good chips. The netlist does show changes between Motorola and Toshiba chips. In fact, they are quite different implementations of the same design. Still, despite major differences between Toshiba V1.0 and Motorola V1.0, I haven't heard of people noticing problems. These kinds of changes are typical. They save a buck or two, and multiplied by 100K units, that's worth the effort. But unless you screw it up, developers and customers shouldn't notice a thing.
  6. kskunk

    Jaguar 2

    That's true and a source of confusion, but I'm pretty sure this code is for the "second" Jaguar II. Midsummer - the new chipset - was also called Jaguar II by Atari engineering during its development. (I guess they recycled the name.) In Eric Smith's weekly status reports from 1995, he consistently uses "Jaguar II" when describing his modifications to sample code to support Midsummer features. This code could be related to that effort. If you match up the code in question to the Midsummer datasheet, you'll find it's an exact match: /* if running on Jaguar II prototype, fix up DSP access */ buts = (*(volatile long *)0xf02114) & 0x0000f000; /* get GPU version */ if (buts == 3) { /* if version 3 */ *(volatile short *)0xf00056 = 0x0060; /* mess with TEST1 register */ } The above code detects Oberon, then configures it to talk to Jerry instead of Puck. This matches with another piece of history: In Midsummer, 0xf02114/GPU_CTRL bits 12-15 are documented as follows: 1 Pre-production test silicon (Jaguar One) 2 First production release (Jaguar One) 3 Pre-production test silicon (Midsummer) In Midsummer, setting 0xf00056/TEST1 to 0x60 does the following: 0x20 enable the Jaguar One Jerry interface 0x40 delay the DRAM write strobes by one half clock cycle - KS
  7. The actual slowdown is so brief it's negligible. To stay at 1.19MHz, you'd need to access RIOT on every cycle. In practice, a single RIOT access costs just 0.5 cycles and reads both joysticks at once. Controller logic is usually hundreds to thousands of cycles. (And involves TIA too.) So, bypassing RIOT could not even save 0.1% in a typical game. Hope that helps!
  8. In the 80s, me and my friends (bored schoolkids) learned how to "hack" Atari 800 games. Graphics and text are easy to find and edit on disk. Later on, one of us got an EPROM burner and within weeks we had moved into NES cartridge hacking. The burner could read the ROMs into a file on disk, where we would edit the text and graphics, then burn our changes. It was the same process we had mastered on the Atari 800. It was very impressive to other schoolkids that we made "our own Nintendo game" with our names on the title screen and crappy amateur graphics. Nevermind that the program and levels were identical - we never understood or modified the code! A more devoted/experienced programmer could go further and modify the 6502 code of an existing game - gradually turning it into something different. But starting from scratch is unlikely. Anyway, it wasn't that expensive, at least not by 1990. And I doubt we were the only ones to do it. All you need is lots of free time while you wait for the UV lamp to finish.
  9. Yes, I used a LogicPort analyzer with 2ns resolution to design the Skunkboard. I tested all the memory controller settings to make sure there was plenty of margin for my 16-bit bus trick.
  10. The access time in this mode is too short for early-90s bulk mask ROM, so it would not work. (No problem for 21st century Skunkboards, of course.) I tested it. It does not work. The buffers inside the Jaguar are too slow.
  11. I don't think I can adequately summarize all the hardware differences - their designs are so different, apples and oranges. But, there's not a huge difference between the ROM speeds when it comes to graphics performance. The Jaguar total ROM bandwidth is 10.6MB/sec (32-bit ROM at 2.66MHz/376ns) Neo Geo graphics come mostly from sprite ROM at 12MB/sec (2x16-bit C ROMs at 3MHz/333ns) Neo Geo can use 100% of its 12MB/s sprite bandwidth, but the Jaguar can obliterate that with a portion of its giant RAM bandwidth (100MB/sec). And that's what Jaguar games do - 2MB is a ton of RAM when your biggest cart is 4MB. It's not like every level uses every background and every character simultaneously - they use a fraction, and the RAM is a fine cache for that. Nor is the Jaguar that slow at 2D. The Neo Geo has a slight edge when every single sprite is scaled (1536 pixels/line vs ~1200 w/OP overhead), but the Jaguar can keep up with the Neo Geo's typical mix of scaled, unscaled, and fix (overlay) graphics. The Jaguar's 68K is crippled compared to the Neo Geo's, so CPU utilization would be a sore spot (as always), necessitating something like Minter's GPU Object List Builder to keep everything moving at 60Hz. My opinion is that the Jaguar is harder to program, but could offer comparable 2D performance. Neo Geo was making expensive games - with expensive ROMs and expensive art. Atari was making everything the cheapest they could. That probably explains more of the difference than any single technical factor like ROM speed or bugs. The USB ports are like a 6x CD - 0.9MB/sec. I wrote a USB-stick-reading benchmark for Tursi, who released it to the world. I sat back with fantasies of (other people) turning the Jaguar into a 64-bit computer with USB peripherals. But, it turns out programming USB is a lot of work. I left all that difficult programming work for other people - so far, no takers. (Seems fitting for the Jaguar...) - KS
  12. The ROM is addressed like RAM. But it would be terrible for performance to leave it in ROM - built-in RAM is up to 10x faster. Nearly every game copies to RAM first. Since the Jaguar's biggest ROM was 4MB back then, copying select assets into 2MB was no problem. Compression was often used. You can look at the memory map online to see why. The Jaguar has 24-bit addresses (like the 68K). They first split the space in half - a fast half, for RAM, and a slow half, for ROM and peripherals. They carved out 2MB of the slow half for peripherals, the boot ROM, JagCD (and its boot ROM), etc. That leaves 6MB of slow ROM - the limit of the cartridge. Of course, the Jaguar could bank switch for bigger ROMs, like any other system (even the NeoGeo did). If the Jaguar had lasted long enough for 8MB ROMs to be cheap, it probably would have had some. - KS
  13. It varies on a game-by-game basis, so there is no one answer. "Atari" (as a copyright owner) is not dead. If you want to buy a legal copy of Star Raiders right now, here you go: http://atari.com/buy-games/arcade/ataris-greatest-hits Generally, the programmers won't get anything. Even in Atari's early days, they didn't pay royalties to programmers. (That policy famously led to the founding of Activision!) Later, Atari gave bonuses to employees who wrote successful games, so they wouldn't quit. But once they quit/were fired, they get nothing. There are exceptions: Some games you remember as "Atari" games were written by 3rd parties, and sometimes those parties get the profits. In other cases, one of the many Ataris over the years sold off the rights, and now some other company owns it. At least in the US, all games are still under copyright and all of them have rightful owners. So to be legal, toys with built-in games must sign a license deal with Atari (or others), and by license, Atari gets part of the profits. With 40 year old games, the owners sometimes don't know/don't enforce their rights. A few toy makers take advantage of that and just steal the games. I've bought at least one toy with pirate ROMs in it. In that case, some Chinese company got the profits. - KS
  14. My family had a 1027 that lasted from about 1985 to 1993. We used it for the same reason as other people in the thread - the high school had stupid rules against handing in homework that 'looks like it came out of a computer'. The printer required no maintenance other than new ink, though I doubt we printed more than 1000 pages over its lifetime. It finally got boxed up and put in a barn where a few hot summers ruined it. It was definitely my favorite printer for a while. It had a great output quality to price ratio - we couldn't have afforded anything with better output back then.
  15. What a fun project! I design toy electronics for a living, so my professional instincts go straight to the bottom line: With a $49 MSRP, $10 is the absolute max you can spend on the electronics. (Unless you don't want a shell, joystick, box, manual, retailer margins, company profit, marketing, etc.) The screen is going to eat nearly half of the $10, assuming you want a backlit color LCD about the size of an old Mini Arcade. (At that price, it won't be anything like tablet quality.) With ~$5 left, it's incredibly tight. Unless you're expecting really good volumes (>1M units), you probably can't afford the software engineering to target a small CPU or tiny OS. Unfortunately, Android + MAME probably won't fit in this price range, either. (But it's very close - it might be possible this year.) For power, Alkaline cells are the cheapest option - with low-power components and a backlight suitable for indoor use, four AA batteries could last 16 hours of play time. Lots of kids will lose interest before then. (Sadly.) Including a power brick is the most expensive option, so lots of toys just include a USB cable or jack. Every home has USB power somewhere. Rechargeable batteries aren't free, but $1 could get you 1 hour of life from a rechargeable battery + USB charging system. (Again relying on the customer to supply their own USB power.) Anyway, if I were asked to develop a toy like this, I would go straight to a low-cost handheld game manufacturer in China. Look no further than Alibaba - you'll find several manufacturers who build emulator-based handheld color LCD gaming systems that wholesale for ~$15. At these prices there's not much margin for engineering, so I'd find an existing design and wrap it up in new plastics, then customize the software as much as the budget allowed. Good luck and keep us posted as things progress! - KS
  • Create New...