Chilly Willy
-
Content Count
842 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Chilly Willy
-
-
Yes, that old tracker music was really awesome! You can still get a lot of that off sites like the ModArchive. Here's a link to one of my favorite tracker musicians from the Amiga, Scorpik.
-
It boots in A800. Need to check it on the SIO2SD. But it's v1.5! A couple revisions newer than my own copy.
-
Anyone have a Top-DOS version 1.3 download? Non-hacked?
I'll find a clean version.
-
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.
We used to do a lot of hacking on the Atari back in the early/mid 80s. It was a lot of fun.
-
I always loved TopDOS. That was an excellent DOS.
-
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.
-
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.
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.
-
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.
-
@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.
-
1
-
-
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.
-
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!
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.
-
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.
-
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.
-
1
-
-
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.
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.
-
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.
-
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.
-
2
-
-
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.
-
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.
-
I played this on my Atari 400 all the time. It was one of the first really nice looking fighters.
-
The only thing was that games used several types of chips I think to store saved games.
Yeah - 4Kbit EEPROM, 16Kbit EEPROM, 256Kbit SRAM, and 1Mbit FRAM. You can find out which games used which CIC chip and save memory here:
-
I went with the Percom... I have one and they are AWESOME! They use a 6809, can control two floppies (just plug in the second drive guts to the controller board), and handle DD/DS (QD) automatically if the drive handles that. I was able to copy a lot of stuff over to the PC by making the second drive a 3.5" floppy and then writing a program on the PC side to dump the data from images of the 3.5" disks. You could also get a printer port on the Percom (mine had one).
An interesting note: I disassembled the BIOS inside the Percom and it was programmed to handle "warp" speed IO, but the code wasn't turned on in the BIOS. I always wanted to burn an eprom with a modified version to see how it handled it.
-
I actually just got done playing Metal Head on the 32X
I love that game, the music is awesome. If you hold A+B+C and Start as you turn on the system, you can change the portraits to anime girls, which is pretty cool.I love Metal Head... and I did not know about that Easter egg. Thanks!
-
Iggy*SJB' date='Wed Feb 23, 2011 8:46 PM' timestamp='1298515580' post='2218048']I would add Disney and Paramount to that list, as they are companies that have actively pursued legal action people who put up fansites for copyrighted works (in fact, when Paramount made their "Star Trek" site a paysite in the mid-90's, they tried to shut down any fansite that had "Star Trek"-related material on it, and sued many of those sites' administrators).
Any idea what their stance on "fan fictions" might be? I don't mean to derail the thread, but that kinda hits home.
Check the author guidelines at fanfiction.net - they keep a list of all the companies/authors who get all pissy when you "steal" their characters. Star Trek fanfiction is in something of a resurgence now, and Paramount seems to be fine with it. There's even a bunch of different fan-made shows for Star Trek that airs with Paramount's blessing.
-
I love my FC-16 Go... I use it far more than my actual SNES.
Like Stoney says, it's actually easier to set the thing on a table (or other support object) and use the wireless controller. With the AV out to a TV, it can even completely replace your SNES altogether.
I got the charcoal colored one... very cool looking.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Battlestar galactica
in Atari 8-Bit Computers
Posted
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.