Jump to content

Chilly Willy

Members
  • Posts

    973
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Chilly Willy

  1. Of course, once you go to software mixing, you lose all of that.

     

    Yes, short loops are bad for SOFTWARE mixing as you hit the loop point more often, increasing the overhead on the loop.

     

     

    Where the TG-16 suffered was low-frequency instruments, and more "random" wave instruments like percussion.

    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.

     

     

    >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.

    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.

  2. This list should be called the "7 biggest video game failures that we spend no time researching because we're too lazy and need some attention."

     

    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.

  3. you technically could use very short looped samples, but that's where the problems come in. The Amiga requires the CPU to loop samples, and that's generally very little overhead for medium/long samples, but now we're talking extremely short (if not single cycle) looped waveforms . . . that's going to eat up a lot of CPU time. (so to do simple chip sounds on the Amiga, you'd want to use longer samples and waste more RAM because of that)

     

    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 TG-16's sound chip would be a prime example of what you wouldn't want to do. (it's sample based, but with hardware looping and only using very small 32 word long samples -which would be a ton of overhead on the Amiga- though another system with hardware looping -like the SNES or Ricoh PCM chip in the FM Towns or Sega CD- would be fine at simulating that -albeit with lower output sample rate -only 32 kHz- in both of those cases and degradation of the samples due to compression on the SNES -granted, that output sample rate only matters if you have really good quality amps in the system, and I'm not sure the PCE/TG-16 used such that the analog output would be beyond 32 kHz)

     

    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.

     

     

    that and you'd be limited to ~28 kHz output max unless you were using PAULA in HD floppy mode)

     

    >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.

     

     

    (Mac actually had 22 kHz 8-bit stereo from day 1 iirc, but it was wired as mono with the 2nd channel dedicated to floppy drive square wave generation -it was also just a simple circular buffer in memory that got scanned out at a fixed rate, so not nearly as flexible as the Amiga or even some other simpler DMA set-ups)

     

    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.

     

     

    I think he meant the MIDI capabilities, since the ST was a preferred system in music studios in its time. Back on topic:

     

    I think another thing that made the sound capabilities of the Amiga so great was how easily one could add a sampler to their machine. Was quite a must for the tracker/demo scene.

    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.

  4. There's a few decent video players that'll simply play what's being fed into a TV tuner/capture card. I remember using Media Player Classic or VLC to do this. No delay if you're not recording, like he said.

     

    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. :cool:

  5. I like the idea of having a Space Harrier style level and a side scrolling style level. It would make the game a bit more fun than just one or the other. Perhaps another idea would be a Zaxxon style level. Imagine Zaxxon with BSG ships and stuff. :)

  6. You don't see Top Dos mentioned here too frequently here. I also liked and used it for several years, but moved to MyDos when I got my first hard drive (MIO) back in the late eighties.

     

    Which version(s) do you use?

     

    1.3

     

    My brother also hacked it to work with his Happy drive speeder upper thingy. :D

     

    We used to do a lot of hacking on the Atari back in the early/mid 80s. It was a lot of fun. :)

  7. Not a big fan of the TG16 controllers and was wondering if there has ever been an adapter that might let you use something else, like a Sega Genesis controller, or maybe an NES or SNES controller?

     

    Has anyone ever built such a thing?

     

     

     

    tototek sells a variety of converters:

     

    http://www.tototek.c...&products_id=57

     

    it gives you psx controller input which may work for you eh?

     

     

     

    It doesn't have 6 button surrport for PS Pads

     

     

     

    why do you need more button support than any of the games allow on the TG16 anyway? color me confused

     

    Homebrew. The moment you decide you never need one, someone has an awesome new game that requires one. ;)

  8. But do any games take advantage of the modes offered by Graffiti? Do Ham-E, DVTV, and FunCclor use this same technique?

    Not that I'm aware of. If there are *any*, I bet there's fewer than that, that were made for the X-Specs. :rolling:

     

    Handful of cool demos however.

     

    I'm not aware of any, either. It was just too little, too late when it came out. PC video cards had taken over the market. I did add Graffiti support to FUSION (the Mac emulator for the Amiga). However, it needed SuperHiRes (1280 wide) sixteen color mode to make the Mac 640 wide display, so it didn't help OCS/ECS folks, just AGA folks. We were going to add support for the Graffiti to our PC emulator (PCx), but the Amiga market was dead by then, so it never happened.

     

    Personally, I think Amiga should have made something like Graffiti part of AGA. It would have made it much easier for PC programmers than AKIKO.

  9. I got a AvenuePad 6 NIB from Japan on eBay for about $40 shipped. They aren't hard to find, just hard to find CHEAP. ;)

     

    Given how poorly the PCE did outside Japan, it's not too surprising. Even an old beat-up TG-16 system with one controller and maybe a game or two runs $60 to $80 on eBay. Duo or SuperCD2 systems easily cost hundreds of dollars. It's not as bad as the NeoGeo, but far worse than NES/SNES/SMS/SMD.

  10. @Save2600:

     

    I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

    AFAIK, no... it doesn't do anything like that. Has an extended resolution though, not native to the Amiga. HighGFX it's called. Maybe that's what you were thinking...

     

    Check out the Individual Computers website:

    Another novelty is the built-in Graffiti emulation. Software that makes use of the Graffiti modes can display 256 out of 4096 colours without HAM artefacts.

     

    I've never used Graffiti - I can only assume it's similar techinlogy to HAM-E and DCTV - a "cookie" based color inserter

    Hmm, so it's definitely NOT adding more bitplanes and color registers? (ie not 256 indexed colors from 12-bit RGB like the TT SHIFTER can do -or as the C65 was supposed to)

     

    Graffiti actually gives the Amiga ModeX graphics, exactly like VGA on the PC. The way it works is the Graffiti has four shift registers that connect to the digital RGBI lines on the video port. With the appropriate palette on the Amiga, this allows you to use 8 bit chunky data in four bitplanes - each bitplane steered to one of the digital lines. Like ModeX, those bytes in the planes represent four interleaved columns. The graffiti has a RAMDAC on board to provide the palette and analog RGB out needed.

     

    The first few lines of the video are used to trigger the Graffiti and load the palette in the RAMDAC, after which all the data is a "standard" ModeX display. Having a Graffiti makes ports of old ModeX VGA games really easy.

     

    Note that 320 wide ModeX means four bitplanes of 80 bytes per line. 80 bytes => 640 wide bitplane, or hires on the Amiga. So a single 640x200 16 color display gives the 320x200 ModeX display. Now remember that 16 color hires uses all available memory access slots in the active display on OCS/ECS systems. So Graffiti on OCS/ECS means full DMA contention, and the associated slow-down when updating graphics. On AGA, it means 0 contention... one of the nice things about AGA.

    • Like 1
  11. I don't understand why NEO dose not just put a SD slot on there Multi Carts, it would make the design much cleaner. Also less confusing when I first started looking at there carts I was like I need a GBA adapter ?

     

    I just don't understand why they stick with there adapter thing.

     

    To be honest, I think it was to help sell GBA flash carts. They probably over produced the hell out of them, and looked at ways to sell them on other platforms. The only recent one they make is the Neo2-Pro, which was needed to make the N64 Myth more attractive.

     

    If you want an engineering reason, flash goes bad eventually. Especially if you write it all the time. Having the flash on a separate cheaper cart that can be easily replaced means it should be better in the long run.

     

    Given they were going to use a GBA flash cart, having an SD interface in addition to the GBA connector and the USB connector probably seemed like too many connectors. Especially as they already had GBA carts with SD/MicroSD interfaces.

  12. I read something on a forum somewhere which seemed to imply that the neo-myth folks are scrambling to add micro-sd card support to some of their flash carts.

     

    That would be wrong. The SD/MicroSD card support is through GBA flash carts with an SD or MicroSD card port on them. The two most commonly used are the Neo2-SD and Neo2-Pro. Perhaps they were suggesting that bundling one of those with the Myth might be better for sales of the Myth in question and you misunderstood... or maybe they misunderstood. That would be better for NeoFlash - instead of shipping the Myth (SNES, MD, N64, etc) with a regular flash cart, ship it with a Neo2-SD/Pro.

     

     

    It seems like they keep lowering the price as all the newer and better carts are coming out that have functionality users actually want, and since KRIKzz hit the scene, functionality we never even dreamed of.

     

    Err - newer and CHEAPER you mean. "Better" is not necessarily true as the Myth carts generally have more features than any other flash cart out, other than built in SD card support (needs the Neo2-SD or Neo2-Pro as mentioned above). For example, no other flash cart for the MD has extra RAM, EEPROM save support, or the FM chip for SMS mode.

     

    It is also the nature of competition to drive prices down. That's a GOOD thing, and I'm glad to see more flash carts appear as that has always been my biggest complaint about the Myth carts - too expensive.

     

     

    I only bought the PCE flash cart from the NEO team. At least that has usb connectivity and does not require a proprietary piggy-back cart to run. I still find it to be lacking though and I would love to see KRIKzz take a stab at one some day ;)

     

    Me too. I'd snatch up a KRIKzz PCE card in a heart beat! :D

     

     

    I can not wait for the new N64 flash carts. I may even sell my Z64 w/ the CF drive hack and my CD64 .

     

    The KRIKzz N64 cart does sound good, and his prices are always nice. It should do well against the competition.

  13. Yes, but what about the actual memory accesses?

     

    It was my understanding that the OCS/ECS chipRAM was all accesses at 280 ns (that's 2 7.16 MHz clock cycles or an effective 3.58 MHz), or 560 ns interleaved performance. (4 clock cycles per access to share 50/50 with the 68k -with no wait states on the 68k end)

    So the peak bandwidth of the OSC/ECS would be 7.16 MB/s (16-bits at 3.58 M transfers/s).

     

    14.3 MHz wouldn't mean anything unless the RAM was configured to be fast enough to allow single cycle accesses. Even 140 ns accesses would be much too fast for random accesses (and thus any interleaved accesses), and if burst-mode was supported, it would mainly have been useful for scanning out the playfields/framebuffers and similar examples of sequential accesses within a consistent shared row of DRAM cells.

     

    I already told you - twice accesses as many in the same time. As to the actually hardware used, as I understand it, the first cycle in fast fetch is regular, and the second is via fast page mode, or something similar. It's partly why there was an alignment issue. It's also why it was only for sprites and playfields.

  14. The AGA chipset is a curious beast, and the A1200 just makes it even curiouser. AGA uses a 32 bit bus to chip ram that runs at twice the frequency used in the old OCS/ECS chipset. The "normal" mode used to fetch video data was backwards compatible - it fetched 16 bits every other time. You could change the fetch mode to "wide", which fetches 32 bits instead of 16, "fast", which fetches 16 bits every time instead of every other time, or "fast-wide", which fetches 32 bits every time. Some video modes need fast-wide fetch to get all the data they need. The fetch mode also affects the sprites - in wide or fast mode they are 32 pixels wide instead of 16, and in fast-wide mode are 64 pixels wide.

    Is that just for the framebuffer management, or also for blitter, copper, etc, operations? (32-bit phrase capabilities could be pretty useful for the blitter, at least for traditional 2D stuff)

     

    The change in width was just for sprites, and playfields just got more data more quickly. Everything else still worked with words like normal for compatibility reasons. Fast/wide also affected the alignment of data - there was a "bug" where moving the screen made part of it disappear - that was when the screen started on the wrong alignment for the fetch mode. Much like in fast-wide where sprites were 64 bits wide, video data had to be 64 bit aligned to fetch properly. There was no attempt to make the BLITTER better since the CPU was faster for AGA class machines. Of course, if they had made the BLITTER better, that might not have been true, so it's a bit of a circular argument.

     

     

    Also, when you say double the speed, do you mean double the speed of the OSC/ESC chipset going full-bore and saturating the bus (halting the CPU or using fastRAM)?

     

    Double the clock rate when accessing memory. You had twice as many access cycles per line compared to OCS/ECS. While the OCS/ECS did everything at 7MHz, AGA did everything at 14MHz.

     

     

    Without fasRAM, you're a lot worse off though, that definitely hurt the CD32. (1 MB chipRAM and 1 MB fastRAM could have meant a substantial performance boost, though still would have left it pretty underpowered for the generation -maybe if they added a decent, relatively low-cost DSP or GPU-like coprocessor it could have become a real competitior . . . of course CBM collapsed in 1994 anyway, so that's moot)

    Better would have been to invest in a custom design that met similar requirements, but was more cost optimized for their target and catered to in-house manufacturing (assuming CSG still had an advantage in vertical integration over outsourcing to overseas chip vendors), or at least cut out overhead by owning the IP. (at the expensive of R&D overhead . . . which wouldn't have paid off if a similar off the shelf product had reached sufficient volumes/competition/cost reduction to outstrip those in-house advantages -various off the shelf DSPs or TI's 340 series GPUs)

     

    The CD32 would have been MUCH better with 2MB chip + 2MB fast and a 28MHz 030. 2MB chip and a 14MHz 020 was just too weak for the time. 2+2+030 would have been closer to consoles of the mid to late 90s. AKIKO + BLITTER could have helped with chunky affine texture mapping, but it still would have lagged behind the PSX, Saturn, and N64. It would have needed a separate rasterizer (maybe in a beefed up BLITTER) to compete at the same level as those consoles.

    • Like 1
  15. everdrive64 has own dma controller for direct transfer between SD/USB and dram, so i not use n64 bus for transfer and not limited by cart port perfomance.

     

    Great! That means super-fast loads... actually, it should load faster off SD than the N64 can DMA the data to RDRAM. :D

     

    Chilly Willy by the way, do you know why n64 cart port access works so strange: if i want write few bytes to cart area without dma, then i should to read something before write, otherwise writen data will not be correctly received by cart?

     

    Possibly because the port is multiplexed around words. It's geared towards reading blocks via DMA, and any less than that seems to require "filler" cycles or a REALLY BIG DAMN LONG delay. The N64 NeoMyth has this trouble. It makes it "fun" for reading the SD card since the Neo2-SD or Neo2-Pro carts use a GPIO interface to the SD card, meaning the CPU has to do multiple reads to read the SD data... eight reads per long. I alter the bus timing in the bus controller to improve the speed, but it still tops off at about 650 KBytes/sec.

     

    Did you every look at this page?

    http://www.crazynation.org/N64/n64_cart_info.htm

     

    The bus timing diagrams are really great.

  16. Good news, angelwolf71885 over on AssemblerGames forums found that the SD association does offer the use of DS mode (12Mbytes/sec.) and HS mode (25Mbytes/sec.) for free. Sounds like the ED64 will support these modes. So it sounds like the majority of games will be possible to load within 0.3 to 1.5 seconds.

     

    Well, it will if the control chip is programmed to transfer the data straight from the SD card to the ram itself. You couldn't use the N64 CPU (or DMA) to handle the transfer and expect any real speed. Why? Because the cart port is SLOOOOOOOOOOOOOOOOW. Nintendo made the cart port slow to take advantage of slow (cheap) roms. You can change the timing on the cart port to an extent, but it will still be pretty slow using the CPU. To get those high speeds SD supports, the control chip needs to handle the data transfers independent of the cart port.

  17. The AGA chipset is a curious beast, and the A1200 just makes it even curiouser. AGA uses a 32 bit bus to chip ram that runs at twice the frequency used in the old OCS/ECS chipset. The "normal" mode used to fetch video data was backwards compatible - it fetched 16 bits every other time. You could change the fetch mode to "wide", which fetches 32 bits instead of 16, "fast", which fetches 16 bits every time instead of every other time, or "fast-wide", which fetches 32 bits every time. Some video modes need fast-wide fetch to get all the data they need. The fetch mode also affects the sprites - in wide or fast mode they are 32 pixels wide instead of 16, and in fast-wide mode are 64 pixels wide.

     

    The CPU in the A1200 is an MC68EC020; it has a 32-bit data bus, and a 24-bit address bus. The "16-bit expansion" is the PC Card slot on the side, and it uses the old 16-bit PC Card specs... which is slow. Don't use it for ram expansion. The belly slot uses all 32 data bits and all 24 address bits; it is also full-speed, so ram in the belly slot will be fast. To get more than 8 MBytes of fast ram, you HAVE to have an accelerator in the belly slot; as mentioned, the 68EC020 only has 24 address bits, so it can only address 16 MBytes of space, of which only 8 MBytes can be fast ram. An 030 or better accelerator will have all 32 address bits and allow for more fast ram.

    • Like 2
  18. Just tried to get on again, got this message:

    Seems Dr. Robotnik won this round, but Sega-16 will be back in short order. Please check back soon.

     

    In the meantime, a lot of the regulars can be found at the Digital Press boards.

    I think that's the name of a user, but they could have used it just as a bad guy name from the Sonic games.

     

    It was meant as a play on the game as the site IS SEGA-16. As mentioned earlier, it was a particular hacker group responsible, and for a short period of time redirected the sega-16 home page to their own, not a sega-16 user.

  19. EverDrive64 supports all saves modes just like 64drive. Also not all games with 6105 require a 6105. Most will work fine with 6102, but Banjo Tooie is one of the few (there may be one other one) that checks for the 6105. Sucks because its a good game, but what can you do? I wouldn't be surprised if someone hacks the ROM eventually to work someday.

     

    Oh? Wasn't sure about the saving, Igor hasn't said much lately. The other game is Jet Force Gemini, but somebody already did a hack supposedly to work on the NeoMyth64.

     

    Not really needed if you have a CIC6105 cart plugged into the Myth. I think you're thinking of someone who tested the old JFG hack for the z64 on the Myth (it worked). I did my JFG testing with a 6105 cart plugged in.

×
×
  • Create New...