Chilly Willy

Gets my vote for authoritative. I did my first commercial apps on my Atari 400, then moved to the Amiga 500, then the A2000, A3000, and finally the A4000. Then I moved to the PowerMac, and finally the PC. During the time I worked on the A2000 - 4000, I did a Zorro card as well as software. Never worked on the ST, but I know how it works. My older brother had the 520ST. My first commercial Mac product was done on the Performa 5200CD. A blazingly fast 75MHz 603e PPC! When I finally switched to the PC, they were at 400 to 600 MHz P3 processors. It was ridiculous how fast PCs and PowerMacs were being updated in that period. Devs hardly had a chance to keep up!

A few thoughts... Why do people always say Apple "invented" the modern GUI with the Mac? There were several mostly similar GUIs under development at the same time by different companies, but because Apple managed to rush their expensive and very limited box to the market THREE MONTHS ahead of the next company, they somehow "invented" the whole thing. Yeaaaaaaaaaah. The "real" successor of a machine is ALWAYS the next machine by the original design team, no matter who they work for or what the machine is. The ST is in no way, manner, or shape the real successor of the Atari 8-bit line. The Amiga is. And yes, the XBox, XBox 360, and XBox One are INCREDIBLY different machines whose only similarity is the company that sells it - Microsoft. I would say that the XBox 360 was NOT the real successor of the XBox - the XBox One is. Why? Because both the XBox and XBox One are basically PCs. MS experimented with the XBox 360, not giving a true successor. The Atari 520ST was a better deal than the Amiga 1000, but the Amiga 500 was a better deal than the ST. I can understand why people went with the ST before the A500 came out. Not only that, WB 1.0 was NOTORIOUS for its instability... but 1.1 fixed that. At the same time, the 256KB expansion for the A1000 came out (giving a total of 512KB of ram) as well as the price dropped, making the A1000 more competitive with the ST. WB 1.2, which is what shipped with the A500, was very stable... yet another reason to get the A500. WB 1.2 was the last Amiga OS with separate support for NTSC and PAL. WB 1.3 not only made one OS for both NTSC and PAL, but also allowed booting directly from hard drives rather than a boot floppy. My A500 has a dual-BIOS adapter with 1.3 and 2.0 on it. Memory Protection was only a feature or Workstations and mainframes in the 80s and 90s. It wasn't really considered a home computer feature any more than multi-user support. You really didn't have the speed or memory to run that many things at the same time, so it wasn't important. Once we got tens and hundreds of MBytes of ram on 200 MHz+ processors, THEN memory protection started becoming important. Viruses had little to do with memory protection, and didn't all the way up until address space randomization. Memory protection was driven almost entirely by sloppy programming. Companies started shipping when bean-counters said to, not when the program was done. That meant crashes, and that meant some kind of crash protection was needed. The most frequent causes of crashing are memory errors of several sorts, so memory protection became very important in cleaning up badly behaved programs. It still is, even today. There were a couple of different crash handlers released for the Amiga to clean up after badly behaved programs. The error and exception handling on the Amiga was amazingly complete and easy to use... but very few programmers ever used it. So a couple different programs were made that you ran at startup and hooked the exceptions, and if the program didn't have its own exception handlers, the crash handler cleaned up for it. They were capable of closing open files, freeing most or all the ram, and even closing screens and windows in most cases. At the worst, you might lose a few KBytes of ram and leave a window open. If Amiga had survived, they probably would have built that into the next rev of the OS. Amiga always did incorporate the best of the software done to enhance previous OS versions.

There have sometimes been troubles with recognizing roms on the MED/EDMD with various OS revisions. Usually, making sure the extension is "right" is enough. Make sure SMS games end in .sms, 32X games end in .32x, etc.

If you look at the hardware for both systems (the Atari 8-bitters and the Amiga), the lineage is clear. It's also the reason I replaced my Atari 400 with an Amiga 500 when I was ready to go 16 bit.

Yes, more than 16 channels is too much for older consoles... unless ALL you are doing is playing music. But 8 should be good, which is why that's what my MOD player code handles. Even with XM, it's pretty rare to need more than 12 channels unless the XM is meant as music for listening, not for games.

It's compiled from C using the crappy gcc JRISC port, then fixed and optimized by hand... except for a few routines that were easy enough to do by hand. So that does factor a bit into the trouble dividing the code into 4K blocks... we all know that C isn't terribly good compared to hand-written assembly except for trivial cases. The hardware manual goes into detail on the bus operation for each of the units. You need that info to avoid wasting bus bandwidth. And I think I goofed on that slightly - it's 2 QUADS, not longs as it's based of the basic DRAM cycle of one 64-bit cycle followed by a 64-bit fast page mode cycle. The bus controller tries to maximize the usage of that bandwidth for the BLITTER, OP, and GPU since those will be the bottle necks on anything substantial. You'll have the GPU crunching the numbers, the BLITTER drawing the data, and the OP drawing the screen, all running at the same time from the DRAM. The unified memory architecture is the main limitation of the Jaguar (my opinion). The 32X has one minor advantage in that the 68000 can run from the MegaDrive work ram independ of the SH2s. You want to run the 68000 in that work ram to keep it off the bus. Any time the 68000 accesses the rom bus, it stops any access by either SH2 from the rom for the entire 68000 bus cycle (up to 15 SH2 cycles). You want the SH2s to cache the rom accesses since cache is much faster than rom, and try not to flood the cache (make large data arrays non-cacheable). Back to the Jaguar - your test is a decent size to test one bank of code staying resident in local ram. I'd like to see something more like Doom - several banks of code loaded and run one after the other. I'd also like to see a test of code run on the 68000 compared to the same code (allowing for differences in the processors) running on the GPU in main. The idea for improving performance by running the GPU in main is that some things are run on the 68000 during a period the GPU is just waiting on the 68000. If the same code could be run on the GPU in main (leaving the local ram with the tight loop code that consumes the most time), you could eliminate some time the GPU is just busy looping, and spend less time given the GPU in main SHOULD be faster than the 68000 on the same code. I hope that makes sense. Well, yes, it's a lot. But for code hand written in assembly. And that's why most Jaguar games I've seen the code to are almost all 68000 for the main logic (either assembly or compiled from C), and hand written assembly for the JRISC. It requires a lot of effort by the programmer to fit the game into that format, which is why ports tended to be pretty scarce on the Jaguar. I look at most of these from the point of view of ports since that's most of what I work on. A port of an existing game (particularly one that's all C) will be rather hard to break up into pieces. Doom is a pretty good example of the work it would take to do it in a way as to utilize all parts fairly evenly. If you write the game from scratch with the Jaguar limits in mind, it's not as big a deal since you would be thinking about these limits while writing the code. I put my name down for one of the next skunkboard runs, so hopefully that occurs soon. I'd love to work on some Jaguar homebrew.

The venerable MOD format can handle more than 4 tracks - I've seen up to 32 tracks. My own MOD player code for the 32X and SCD handles up to 8 tracks, but it's super-easy to add any number of tracks. There's also XM (extended mod) format, which handles up to 32 tracks by default. I made a player for the 32X that works great, so playing XM on the Jaguar should be doable as well. MOD and/or XM should be sufficient for most Jaguar games. When you need a really odd piece of music or sound effects, ADPCM like Tripper plays should be fine.

Put me down for one as well. Thank goodness a new batch is being made - I thought I'd NEVER get one (at a reasonable price)!

Just gotta toss my own two cents in... First, I've seen a couple people that just constantly scream "BCD, BCD, BCD!" Yes, the 68000 is much faster at BCD than the GPU would be in main... hell, I'd bet the 68000 is faster at BCD than the GPU in LOCAL! The answer is DON'T DO BCD ON THE GPU!! There are nearly always ways to get rid of BCD operations, and when there isn't? I'd make the 68000 do the BCD operation. It's just that simple. If the 68000 can do the job faster, use it. If it can't, don't! Second, a couple people seem to think it's simplicity itself to divide the code into 4K or even 2K chunks. Would that it were so... I like using Doom as an example as I'm very familiar with Doom in general (having worked on ports to several different platforms) and Doom on the Jaguar in particular (since it forms the base code for the 32X version as well, and I'm a big 32X coder). Doom on the Jaguar divides the task of running the game between the 68000 and the GPU, with each being roughly able to run at the same time. The 68000 runs nearly all the game logic, while the GPU runs nearly all the rendering code. Remember that Carmack himself worked on this code. The rendering code had to be broken into NINE SEGMENTS of 4K each. The 68000 runs all the game logic, starts the first GPU segment, then waits until the third segment is done. By that time, the rendering has finished using the game variables that will be changed by the game logic (player position, etc). The 68000 then starts on the next tick worth of game logic. Each GPU segment interrupts the 68000 to blit the next segment into local ram, with the last segment triggering the 68000 to build the next OP list. The GPU uses the blitter as it goes where it can for drawing. If the 68000 finishes the game logic before the rendering is done, it must wait on the rendering. So the 68000 has one spot where it always waits, and another spot it MIGHT wait. It's possible the GPU might finish the rendering before the 68000 finishes the game logic (for example, your nose right up against a plain wall), and so it has one place it MIGHT wait as well. So we see a few things here for a decently complex game: First, dividing the tasks between the 68000 and GPU is not trivial, and you can wind up with either or both busy looping, waiting on the other. Second, dividing the code the GPU needs to run into 4K chunks isn't trivial - forget about the 2K nonsense... unless the code IS trivial. You'll know (as the programmer) whether or not the GPU code is trivial to divide up. Third, certain tasks are easier/faster on one processor than the other, local ram or main be damned. Use the proper processor for the tasks! If you have BCD you can't code around, use the 68000! The benchmark (and I use the term loosely) in the opening post is rather misleading, especially for the big conclusion drawn from it. It does a trivial task in local ram, then the same trivial task in main ram. Naturally, the local ram will blow the doors off the main ram, so it wins handily. From this one trivial result, it's then assumed that no possible task could ever be so much better in main ram as to overcome the speed of the same task in local ram... which starts by assuming the task can even FIT into the local ram. It also assumes that the task in local ram will never change, and that any speed lost in loading the local ram is trivial compared to the task. That may be true... or it may be false. It's simply ignored. It also ignores the fact that for many operations (not BCD, clearly), the GPU in main ram will be faster than the 68000. You don't need MIPS to figure that out, just look at the bandwidth - the 68000 never fetches more than a single word at a time, and the bus master doesn't cache any data for the 68000. The GPU fetches longs at a time, and the bus master is designed to optimize two long fetches at a time where possible. Unless your code deals exclusively with bytes or words, the GPU WILL be faster simply because it better utilizes the bandwidth of the main ram. This is another example of matching the task to the proper processor. If your code is fairly easy to run in parallel and/or uses lots of bytes or words, you probably want to use the 68000 instead of the GPU for that code. If the GPU needs to wait on the 68000, and the code the 68000 is running is working on mostly words and longs, it may be better to run the code on the GPU in main ram. If it fits in local memory, it's probably better to make it into another local ram segment and upload it. If it DOESN'T fit, what are you going to do? Wait on the 68000, or use the GPU in main ram? My suggestion for benchmarks is this: make a trivial task that is easy to expand into different sizes. Run the task on the 68000, run the task on the GPU in main, and then upload and run the task (in N segments) on the GPU in local ram, and compare the times. Do 4K (so one segment on the GPU in local), then increasing sizes... 8K, 12K, 16K, etc, and see if there is a point at which the extra overhead on the local ram transfer makes running in main better. Maybe change the trivial task as well - make a trivial byte operation, a trivial word operation, a trivial long operation, and a trivial operation that combines all three. Those results would tell us a LOT more than the one present in the opening post.

I loved my 410! Sure, it wasn't very fast, and every third or fourth time you'd get an error and have to reboot, but it was FAR better than cassettes for other systems (especially the C64), and not THAT bad. The ability to play audio while loading data was also a big plus for the Atari cassettes. Of course, once I got my Percom DD floppy, I never used the cassette again.

Nintendo tends to ignore most demos. Most people can't run them, and they really aren't a game. If you made a game using the Nintendo SDK that you tried to sell, then they'd probably call in the lawyers. There are a number of flash carts for the N64 now, so homebrew can be done. Now it's a matter of getting rid of the Nintendo SDK. ScummVM for the N64 doesn't use it, for example, so there's really nothing Nintendo can say about it.

I'm an engineer, but starting to get arthritis, so if the soldering is TOO fine it can be a pain - literally! As long as it's not 100 lines of surface mount, I can probably handle it.

US 65XE, so no love for ECI.

Don't forget the two OS settings: the first being noisy/quiet. I always made my cassettes so that they did a short block that switched to quiet mode, then continued the load. The second OS setting was fast/slow - this did not affect the baud rate or frequencies, it changed the delay between blocks. BASIC always used slow mode so that the basic loader could do something with the block before the next block started loading. Boot cassettes all use fast mode.

Ah, I'd forgotten about the web page. Anyone know a good plug-in ram expansion for the 65XE?

I have two 65XE consoles, an 800XL console, and two 400 consoles. So requiring more than 64KB of ram would prevent me from using it until I got some kind of ram expansion. I also have the 1Mbit AtariMax flash cart, so I could use a version that required a cart like that (lots of flash banks). It might be time to start looking at what systems would be best targeted to reach the most people.

It only blocks it slightly. The door opens enough to change discs without unplugging the CDX. I do it all the time... just use a LITTLE more care when exchanging CDs and you're fine. It's not like the X'Eye where the 32X physically holds the CD door closed completely.

Yeah, a way to always run would have made the game better. I thought the frame rate was fine as well. It's not like Doom on the Mac was any better.

I don't know why people hate the Metal Head graphics so much. Looks good to me. Anyway, I really love the flat polygon look in SWA - the huge space battles with the Star Destroyers in particular. I liked the flat polygons of VRD more, as well. There was just something about those flat polygon games that early textured games couldn't match.

Hmm - seems most of my latest N64 stuff was on fileden... which is gone now. I'll have to repost some of that on my MediaFire account. Anywho, here's the homepage for libdragon: http://www.dragonminded.com/n64dev/ I'll try to put together some updated arcs for my N64 stuff. You can find my thread on the Yeti3D Pro port here: http://www.neoflash.com/forum/index.php/topic,7454.0.html That archive IS on mediafire, so you can get it. I was also able to compile scummvm for the N64, but the existing port is a little old. Working on an update with the latest scummvm code is on my TODO list.

Yes, the N64 cart bus is a bit "messy" to deal with. There are now a few different flash carts for the N64, and the games that didn't work with the common CIC chips in those carts now have patches that remove the protection. The Everdrive64 is a fine cart for the N64, being fast, inexpensive, and handling 99% of games without patching. You need to patch those games that use the oddball CIC chips, but the patch is built into the menu now, making it easy to play the games. The main home brew you see for the N64 are demos - people showing off lots of tricks and such. Those were all done with the Nintendo devkit. A lot of hacks (like for Mario 64) don't work on real hardware - it's pretty much like a lot of old hacks for the Genesis: the people doing the hacks test them on emulators rather than real hardware. With the advent of good CHEAP flash carts for the N64, I hope some of the folks working on N64 hacks get one and fix the issues with their hack. Again, like on the Genesis, the primary issue is having data on odd addresses. The MIPS requires you to use special instructions to access data on odd addresses (if not accessing as individual bytes). I have been helping work on making libdragon better. That's a nice SDK for the N64 that uses no Nintendo code, and works on real hardware. It's a bit low-level for most N64 emulators. You can run libdragon based home brew using MESS. I made a music player called SMP, and did a port of Yeti3D Pro. I'll be doing some other stuff when I get some time. I'm working on something for the 32X at the moment.

You're confusing the two main chips: the N64 is comprised of the CPU, which is a 64-bit MIPS 4300, and the RCP, which is made up of those elements I listed (the 32-bit MIPS + GPU + VU + DMA). It has BOTH 64-bit and 32-bit MIPS. Rare and Lucas Films did their own RSP libraries rather than rely on the regular Nintendo libraries. It would have been nice to see more devs doing their own libraries - you would have seen much better games. Clearly, that wouldn't have occurred until the end of life for the N64, and by that time, Nintendo had switched to an entirely different SDK given the entirely different architecture of the GC. None of the programming effort you put into the N64 RCP would carry over, so very few devs tried. And yes, some dev groups are more "privileged" than others in getting info. All the info I gave about the RCP wasn't known to most folks until long after the N64 was dead. I'm hoping that home brewers can make more of the extra knowledge than simply relying on the old N64 dev kits. In particular, I'd like to see an RSP library that allowed doing 2D games on the N64 that rival 2D games on a platform like the Saturn. 2D games of that nature are sadly lacking on the N64 as Nintendo geared their RSP libraries to 3D, not 2D. The N64 has the POTENTIAL to be a 2D powerhouse... with the proper RSP library. So remember this: N64 = CPU + RCP CPU = MIPS 4300 RCP = RSP + RDP RDP = 3D GPU RSP = MIPS 32-bit custom cpu + VU + DMA By the way, all audio is done using the RSP. The vector unit is used for most all audio calculations. The N64 itself only has a single DMA-driven stereo audio output. The RSP would act to fill buffers the DMA audio out would then play. That's why Nintendo's audio compression was rather calculation intensive - it used the vector unit to convert the compressed data into sample blocks. That was easier on the RSP than regular ADPCM compressed audio. A lot of N64 games only use 32-bit code. That helps make the N64 emulators faster. There's generally no reason to change the bulk of code from 32 to 64 bit on 64 bit CPUs. What makes 64-bit mode faster on the AMD64 design is not really the 64 bit width, it's the extra registers that the design added. The extra registers are also much more general purpose - the registers don't have a dedicated single use, like holding a count value, as in the old x86 design. As far as Doom pushing the rendering onto the GPU RISC, the 68000 isn't really all that good with 3D calculations. Versions of Wolf3D that run on the 68000 use highly optimized assembly for the entire rendering engine, and they aren't nearly as complex as the rendering in Doom. The rendering in Doom could have been done by the 68000 along with the game logic, but it would have made it slower and not taken advantage of having the GPU RISC.

Most educational cassettes would stream (text) video from the data channel while the audio channel played the teacher's lecture. So you'd see chemical formulas and such on the display while the teacher talked about them. It was an ingenious method of taking advantage of stereo audio cassettes on the computer.

The Jaguar and N64 share nothing in common. The RISC processors in the Jaguar are not MIPS in any way, shape, or form. They are custom RISC processors designed by Atari vaguely based on the 680x0 ISA with more registers. MIPS is completely different other than both having 32 registers. The primary reason people used the 68000 so much in the Jaguar is simple - it had a fairly robust C compiler, while the JRISC had a super-buggy C compiler that had to have all generated code edited by hand. Games of the time were mostly C, so you either had to edit a bunch of badly generated assembly for JRISC, or you used the 68000 for most of the game with only time-critical code converted over to the JRISC. Look at Doom as a prime example - the majority of the game logic is C running on the 68000, with only the level rendering converted from C to assembly for the JRISC and edited by hand to work. A secondary reason was the bugs in the hardware preventing JRISC code from running from main ram. At that time, JRISC code had to be cut into blocks small enough to fit into the local ram and uploaded (usually via the blitter). Again, Doom is a prime example. The JRISC code is chopped into 9 pieces, and executed one block after another. On the flip side, the primary limitation of the N64 was Nintendo's SDK. They wanted everyone using the SDK - no banging on the hardware directly. You can see from the SDK that Nintendo had thoughts of upgrading the N64 over time, and wishing to have backwards compatibility. That didn't pan out as they went to an entirely new architecture for the GameCube, but at the time, they clearly thought they might continue with an upgraded version of the N64 hardware. So the RCP was essentially a black box that you only used via Nintendo's libraries. It was actually a very simple chip: it's a 32-bit MIPS processor with separate 4KB blocks of ram for instructions and data (called the RSP), a 3D GPU (called the RDP), a DMA channel, and a vector unit geared towards handling 3D vectors and blocks of pixels. Once you grasp how simple the RCP is, doing your own libraries is not as hard as Nintendo implied it was. The main processor for game logic in the N64 was a 64-bit MIPS processor. It had good C support, so it was easy enough to program for, or for making ports of games written in C.

I think a cart that is part SD interface and part graphics enhancer is the way to go. The cart would provide lines of graphics and sprites at a set address, but to go a little further, have it maintain a couple layers internally for a nice parallax background. Since better graphics requires more data, having a built in SD card interface would go a long way towards providing the extra data. Maybe have it provide audio data as well as graphics (streamed PCM from SD card to the POKEY, e.g.).