Jump to content

kskunk

Members
  • Posts

    448
  • Joined

  • Last visited

  • Days Won

    5

kskunk last won the day on January 5 2012

kskunk had the most liked content!

Profile Information

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

Recent Profile Visitors

13,491 profile views

kskunk's Achievements

Moonsweeper

Moonsweeper (5/9)

387

Reputation

  1. The main bus is never that fast. All reads are minimum 2 cycles, and often more. You really need to benchmark on real hardware to get a handle on this. Ballpark estimates will lead you down the wrong road.
  2. You should benchmark it. It's a fun way to dip your toes into Jaguar development, and you'll learn more in one afternoon than you can pondering ideas for a year. Spoiler: Reading the line buffer is a lot slower than you're thinking, since it only has a 16-bit read port. You can also blit into the CLUT RAM, which is more convenient than the line buffer. But it has the same slow 16-bit read port. Blitting into the line buffer is still useful, if you don't try to read it back. You can 'race the beam', writing pixels right before they're displayed.
  3. I picked up some parts from Best at that building in 2007. I live nearby, so I asked to "pick up" when I placed my order, and then I got a phone call to arrange a time. I remember a normal-enough front office with a desk and filing cabinets, and a brief conversation with the friendly-enough owner. I would've found any excuse to talk Atari for an hour or peek back into the warehouse, but he was all business, so I went on my way. He didn't strike me as the "talk your ear off, hang out all afternoon" kind of person you sometimes meet in this hobby. Alas.
  4. The answer is in the photo: Google. Google bought the building a while back, along with many nearby buildings, including some of Atari's old manufacturing and warehouses. Bit by bit, that area is being rebuilt with taller, shinier, Google offices.
  5. 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.
  6. 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.
  7. 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.)
  8. 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?
  9. 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.
  10. 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
  11. 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!
  12. 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.
  13. 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.
  14. 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.
  15. 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
×
×
  • Create New...