Chilly Willy

One thing to remember is that the SDrive software assumes that ATR files ALWAYS have a header. Rename any ATR files that don't have a header to XFD or they won't work. Similarly, executables need to have one of the common extensions like XEX to be recognized as executables. I spent more time renaming files than anything else.

The GUI will be compatible with Amiga mouses too. Yes, there'll be drivers for joystick, touch tablet, Amiga mice, etc. Right-click functionality will be supported for suitably modified mice. I was just about to ask about Amiga mice... I've got several of those, including the Boing! optical mouse with three buttons.

So how "rare" are the 65XE's without the expansion port? My NTSC 65XE doesn't have it. Never even thought about it since it has all the "normal" ports for an Atari.

Gotta go with the crowd on this. My Yobo FC-16 Go is nice, but the dpad on the unit is "stiff". The wireless pads are nice - just set the FC-16 on a counter/table/whatever and use the wireless controller. That's MUCH better as you can swing the controller all around as needed to use it correctly ( ) while still being able to see the screen (which is really nice, btw). Plug it into your TV and it's a good replacement for a full size SNES.

Wow! That's a really fantastic demo!

Yes, that's what the Amiga team wanted, but that doesn't mean that CBM management couldn't have trimmed it back to something they felt was more markatable for the time. (a chipset evolution specifically aimed at market trends with cost effectiveness in mind might have been better still, but CBM did neither) It's too bad that the bean counters rarely had/have an idea of what the current state of technology was/is. If it was for analog/SD resolution video, you wouldn't want more than 480i anyway (640x480 would be pushing it for SVHS/betacam anyway), and higher color would be more important. (though high-end 3rd party stuff ended up pushing 24-bit color anyway) Yes, 1280x480i 16 color (ECS) or 256 color (AGA) was the intended resolution of Super HiRes. Even dedicated character generators couldn't do as nice a job as the Amiga at that resolution. Of course, at that point your quality was completely dependent on the genlock you bought. I had a pretty cheap one.

By the time they decided to go with the AGA, they probably didn't have time to finish the extra hardware updates to Lisa needed for it. Or perhaps they felt that they would make a separate chip that handled all that which would go in the high-end model, but that chip wasn't ready or had bugs they didn't have money to fix, so they left it out of the A4000. From the comments, they clearly meant for ultra-hires to be that - higher than the regular resolutions... which means lots of vram. They could have gone with less vram and gone with a smaller resolution... 320 or 512 wide, for example. That would have been perfect for games of the time, and they could have mixed vram with chip ram, keeping the vram for displayable bitmaps and sprites. Super high res was made with CG video overlays in mind. Remember that the Amiga was the preferred system for cable and genlocked effects/text.

The sad thing is, the Amiga DID have support for chunky graphics handled via external hardware and vram. Look at excerpts from the hardware manual: The idea was that instead of DMAing data through the active part of the display, the UHRES mode would generate one access per line for bitplane and sprite - that access would be turned into a vram load serial register access by external hardware, which then clocks out the video on the serial port of the vram during the active part of the line, feeding the data to a ramdac. I imagine this "external hardware" would have been built into Lisa 2 (or whatever they called the next video chip that supported UHRES). So there would be only two accesses per line for video data, leaving the rest of the access slots free for COPPER/BLITTER/CPU accesses.

Their forum was down for a couple weeks. It's been back up now about a week, and they sent emails to members to let them know everything was back and working. Wraggster has been posting like crazy to make up for lost time.

I don't mind the menu bar at the top. If you wanted to as much screen space as possible, you could do like the Amiga and hide the menu bar until you press the menu button on the mouse.

5th gen. Up until then, each gen was just more sprites, more colors, more resolution, more speed... more of the "same old, same old". The 5th gen broke out of the 2D / fake 3D rut and introduced many new ways of gaming, as well as allowing the same old 2D games.

I have a generic svideo cable from ebay... looks good to me!

No, it needs to permit the user to place it where the user wants it That's probably too much to ask from an 8bit system with limited memory.

Hehehe - a Jaguar based home computer. That was most of the problem with CBM - the owner and CEO were both more interested in selling pieces of the company to line their own pockets than in keeping Amiga sound. As an example, the hired the guy who made the Peanut to be in charge of engineering. Between that and selling their chip fabs, the Amiga was doomed.

Right... which is part of what makes fast ram fast. Some "accelerator" cards were better than others about how fast the fast memory was. The CBM cards were notorious for not being very fast. Which is why the VERY FIRST upgrade recommended for A1200 owners was "true" fast ram. It could make your A1200 MUCH faster than the stock chip mem only model. CBM really needed to push the Hombre chipset out, but that wasn't meant to be.

Yeah, that would have been pretty awesome, especially if they'd tweaked the blitter to work more optimally with packed pixels. (not to mention working on the 32-bit bus . . . or at least double the clock speed of the old blitter and just rely on the existing block move/fill capabilities, but 32-bit chunky blitting abilities would have been great, so would be adding fast block/line fill with fast page mode writes for optimal fill rate -for clearing the framebuffer and filling polygons -even better is if the updated blitter could also access fastRAM when needed for faster blitting -efficient use of fast page mode copying, though like the 3DO's use of the same technique, you'd have contention with the CPU -except at least the 68020 and 030 have caches, unlike the ARM60) Or if modifying the blitter caused too many compatibility issues (and adding a whole new blitter was too much cost overhead), they should at least have added basic VGA-type fill/raster op functions. (and require the CPU to do the rest . . . or the old blitter in cases where it was still OK) The blitter worked on words, but if you think about what a number of different FP games of the time did (double the pixels horizontally to draw half the data), the blitter CAN be used in that respect for chunky graphics operations. But it would have been better to update the blitter. That was half the problem with AGA, it just wasn't enough. All they did was add two more bitplanes (going from 6 to 8 ), and the ability to fetch four times the data in the same time to support higher depths in higher resolutions. That's ALL they did... a fairly minor update to just the video. Applying that same update to other systems would have made the AGA much better - for example, four times the data for audio would have allowed four channels of stereo 16-bit 56 kHz sound. You could have done HD format on regular HD floppies instead of needing a special hacked floppy drive (1.4M and 2.8M even! ). The blitter could have been much faster. Could you signal the start and end of vblank for the CPU to know when there free access to chipRAM? (you'd need better than just a simple vblank interrupt for that if you wanted to precisely time it for both the start and end of vblank -more like hblank/scanline interrupts with the proper interval set for the entirety of thhe usable part of vblank) The COPPER controls the video completely. You could EASILY set custom start and end points for the active display for a smaller screen allowing more time for the CPU and blitter. You could also change the depth on the fly for areas like a status bar at the bottom to allow CPU/blitter access earlier than using the same mode for the entire active display. Paula did its DMA in the horizontal blank. The only thing overridden by the video DMA was sprites for wide screens (for scrolling) or the CPU/blitter. Right, you mentioned it using 1 random followed by 1 page mode access, but still otherwise interleaved? (and that page mode -and the 32-bit bus width- was only used for sprites and playfield/framebuffer scanning) But is that the only way it could be used? You'd get much, much better average bandwidth if sustained burst accesses were used (like scanning an entire scanline and then giving the bus back, more like what ANTIC+GTIA did, but with page mode -and exactly what the Jaguar does, but at 64-bits wide as well as in 75 ns page mode). Not only would that give you a lot more video bandwidth in general, but it would give a hell of a lot more chipram bandwidth to the CPU than old fashion interleaving could. (more so if the CPU was fast enough to read/write in fast page mode -even if the CPU was given similar random+page pairs of accesses, that would still onyl be 14.32 MB/s peak bandwidth or half that for sustained random accesses -albeit without contention, while sustained page mode accesses would allow peak bandwidth of 57.27 MB/s, and video only using a small percentage of that time -and have higher theoretical max resolutions . . . but maybe changing the use of chipRAM like that would screw up PAULA, unless perhaps it had additional buffering/enhancements enabled for those access modes) Edit: Wait, it probably does support non-interleaved "bus stealing" access modes too (just like the OCS/ECS, but with 2x the clock speed, 32-bits wide, and with fast page support) . . . though the question would still be whether the CPU could be allowed to saturate the chipram bus like that, or only the video chips. (you'd really want to allow sustained fast page writes for the CPU to quickly copy data from fastRAM -albeit that would be even more useful with packed pixel graphics) That would have been nice, but only graphics (playfield and sprites) benefited from page mode (IIRC). The CPU could write 32 bits, but did so at the "normal" speed.

On NTSC systems, the cpu clock is derived from the color subcarrier (3.579545 MHz). There is a slight variation from system to system. The A400 has a trimmer pot on the CPU card you can use to adjust the frequency slightly. I used it on my A400 to "correct" the colors as they were off as the unit came from the store. I would hope all the systems should have an adjustment control for the system clock, but I'm only familiar with the A400 hardware as it applies to this area.

Interesting, did that actually come out before AGA? (it definitely seems like a nice upgrade path to make as a true standard -same for the ST for that matter . . . I'd actually thought the TT SHIFTER had used packed pixels, but apparently it was just 8 bitplanes like AGA -but with 12-bit rather than 24-bit RGB . . . which also makes the lack of the BLiTTER in the TT even stranger -if it was 8-bit packed pixels, ditching the blitter in favor of software 68030 manipulated graphics would make more sense) Yes, it came out before AGA. There had been talk it would be part of AGA, but talks broke down between CBM and the makers of the Graffiti. If they HAD built Graffiti into the AGA, they could have had it run in 8 bitplane mode, giving two independent chunky playfields. That would have RULED games of the time. It uses all the available slots at full 7.16 MB/s bandwidth, or normal interleaved 3.58 MB/s bandwidth? (if the former, that would mean the CPU and blitter could only work in vblank in those modes . . . and given displaying 640x200x4 would take 5 MB/s, that would seem to be the case -actually, going below that bandwidth should end up with graphical garbage or tearing and not slowdown) The former. Just like 16 color hires on OCS/ECS, things would grind to a halt when trying to access chip ram during the active display. You would have definitely wanted some fast ram with such a system. Page mode was added to AGA. Remember my explanations of the fetch mode? The OCS/ECS did regular FULL cycles. At least it interleaved custom and 68000 accesses for realtively free CPU accesses on most commonly used video modes. AGA Amigas didn't even have AKIKO though, wasn't that only used in the CD32? (normal Amiga 4000s/1200s had to rely on CPU/blitter driven packed to planar conversion) AKIKO was only on the CD32, which limited it's usefulness. That's why I said CBM would have been better off with something like Graffiti in the AGA. AKIKO was added later to get past the fact that they couldn't get a license on Graffiti.

Great! I'm looking forward to it... I really like the B&W Mac look the GUI has. It would be nice to see this GUI with things like editors (word and program).

Yes, short loops are bad for SOFTWARE mixing as you hit the loop point more often, increasing the overhead on the loop. That's where software PCM playback would come into play. (and the fast interrupts and scanline or timer interrupts) Yeah, one software PCM channel for percussion is probably the best way to handle that. Oh, right . . . I knew that too, but for some reason I confused that with floppy timing (probably to so with PAULA also handling FDD DMA/control). Wouldn't that also be inclusive of the ECS then? (for the 640x480 non-interlaced mono/4 color modes) Amiga HD floppies work on ANY Amiga because they drive changes speed. The Amiga reads/writes the floppy just like normal, but with twice the track data. As far as sound goes, the frequency was limited by the line rate, so yes, ECS could go beyond the OCS limit, but the color restrictions at 30kHz would be more severe as you mention... instead of a 16 color limit in hi-res, you have a 4 color limit. I seem to remember that some video cards had an option to set the Amiga video to a B&W blank 30kHz mode while on the video card to allow for higher frequency sound. That would only work on AGA or ECS.

Yeah, it's full of biased opinions, misinformation, and complete fabrications. It's clearly just trolling. @Eltigro - it's clear the author has never bothered to play any of the systems he dissed. For the small library the 32X had, it has a surprising number of great titles. The article sounds like he heard someone complain about Cosmic Carnage and based the 32X part on an exaggeration of said complaint.

Uh... no. The Amiga handled looping in hardware. While VERY short loops could cause some issues because of DMA limits (all DMA was linked to the horizontal blank), you just copied the loop a few times to make it a little longer and Bob's your uncle! Using "chip" sounds in Amiga MODs was fairly common, with sample lengths less than a dozen bytes in some cases. The Ricoh PCM chip samples need the end marker (0xFF) repeated as many times as needed to cover octave multipliers (if you play the sample at one octave higher, you need at least two 0xFF bytes; two octaves needs at least four bytes; etc). As mentioned above, the Amiga had no overhead on small samples, but was limited on OCS/ECS systems to 28kHz. While the TG-16's 32 byte sample limit seems extreme, most synthesized samples repeat in about that size, given the fundamental limit for low-frequency sounds of one wave per sample. What makes most sounds longer is the envelop, which the FAST ints on the TG-16 coupled with separate volume and panning settings allow you to control via software rather than using a long sample. In that respect, the TG-16 sound is very similar to the Ricoh, but with much shorter samples. Where the TG-16 suffered was low-frequency instruments, and more "random" wave instruments like percussion. >30kHz video modes. As mentioned above, all DMA is linked to the horizontal blank. The sound gets two samples per channel per scan line, the floppy two, etc. That's why the Amiga HD floppy spun at half-speed rather than making the floppy controller read/write twice as fast... that DMA limit on <30kHz screens. Yes, the Mac did one stereo sample per scan line (which was ~22kHz). On older systems, one channel was used for the PWM motor speed control to make the floppy spin faster or slower to fit more data on the media. Once Apple started using drives with built-in motor speed control, Apple made subsequent models stereo out. The buffer was a set size that corresponded to two vertical periods, so people filled one half the buffer using the vertical interrupt. Weren't there plug-in A/C modules for digital sampling/recoding (and playback) on the ST? (be it simple software managed parallel interfaced DACs, or actual hardware assisted modules) Probably. There were for most computers of the time. I have a parallel port digitizer I used with my Amiga... I forget which brand it was at the moment.

I have a TV tuner in my (super) old Mac Performa 5200. I used to do the same thing with it for quite some time with my Genesis - regular broadcast TV and the Genesis through the TV card. The nice thing there was Apple built support into the os for the card, and it came with a remote control, so I could flip between full screen and a window and change the volume at the touch of a (remote) button.

I think Rescue on Fractalus and The Eidolon are the top of the heap for first person games on the A8. Project M will rival them once it's done. For platformers, I think Necromancer is at the top. For shooters, maybe Drop Zone.

The Percom drives could control two floppies, so I took a 3.5" drive in a 5.25" adapter and connected it as the second drive in my Percom. That made it easier for transferring files to the PC.