Chilly Willy

Yes, quite so. I started off with a stock A400 with the cassette drive. I immediately got the 32K memory card for the A400, and a BKey keyboard to replace the stock keyboard. I later got the Mosaic 64K memory card for the 400/800, and a Percom floppy drive. I used a Sony Trinitron TV to make the RF look as good as possible. Still have that old TV... and the 400, of course. It's retired with dignity after having faithfully served so many years.

My family used to play four player MULE on my A400 back in the day. You WANT at least two players to collude on prices in the final round. It's the only way to get a fantastic finish. What you want to do is try to claim as much of the high and medium crystite plots as possible, and to put them all together in blocks as blocks of plots produce more than individual plots. One person needs to take one for the team/colony and make food and energy. For the very last round, buy as much extra energy and food as you can, and switch EVERYTHING to crystite, no matter whether the plot has any on it or not. Then in the last round auction, you need a player with at least one unit of the resource to sell, and one player with the most money to buy. The INSTANT sales are allowed, RUN FOR ALL YOU CAN AS LONG AS YOU CAN pushing the price up as high as possible. At the very last second, the other player will sell one unit. Do this for EVERY resource. However, crystite increases by 4 in the auctions, so you can drive its prices higher than anything else, which is why you want to focus on it the last couple of rounds. The worth of the colony is the final round auction price for every resource multiplied by how many of the resource everyone has. Driving the price as high as possible for everything in the final auction makes for insane scores for the colony... or the colony fails if pirates come and take all crystite, or the one player making food and energy gets hit in the last couple rounds. So there is some luck involved, but four players colluding can make insane colonies, and even two players can make really great colonies.

Never saw the 3DO version. I saw quite a few ports of 3DO games to the PSX, like Gex, They were fun games, and if I had had a 3DO, I'd have gotten them for it. I just couldn't see plunking down $700 on a console at that time.

I loved the PSX version of Road Rash... always keep meaning to try the SCD version to see how it compares.

Vic and I are still working on it. We're close to the next major update, but still no bunny at the end. 😎 I think the bunny ending was removed from the Jaguar version (and all related derivatives) was for space reasons. It's a pretty BIG background pic that was deemed not important. The main thing we're waiting on before the release is the fix of the levels with the Cyber Demon and the Spider Mastermind.

The Atari 400/800 POKEY directly drives the serial lines of the peripheral port. A couple years of heavy use can wear out the serial drivers in the POKEY. The rest of the POKEY works fine, but nothing on the peripheral port will respond until you replace the POKEY. I wore out two POKEYs on my 400 before finally retiring it.

Sega of America wanted a low-end extension of the Genesis since it was super popular in the US still. They saw a market for low-end vs high-end, and the Saturn was going to be VERY high-end, well out of the range of most of the Genesis people SoA was trying to keep in the Sega camp. Sega of Japan wanted everything else to go away so they could force everyone onto the Saturn. No backwards compatibility, all new game library to build from scratch, and pricey new hardware. While SoA did win in their bid to get the 32X, and it had a phenomenal launch, SoJ bollixed things up royally by killing support for almost every other Sega platform out. And it's easy to imagine what Doom 32X should have been like if Sega had given it the time needed to be done properly - just go get Doom 32X Resurrection and try it. That's what Sega COULD have done if they weren't in a tizzy to get Doom 32X out before Christmas. https://doomwiki.org/wiki/Doom_32X:_Resurrection

The key to enjoying Chaotix is to completely forget that it's related to the Sonic franchise. Treat it like a completely independent game, and don't expect it to play anything like any Sonic games, and maybe you'll like it better. I certainly do.

I used an Olivetti JP101 Sparkjet printer hooked to my Percom parallel port. Was a great printer. So great, I kept using it with my Amiga 500 (had to write an Amiga printer driver for it). The JP101 looks like this: http://chrisacorns.computinghistory.org.uk/8bit_Upgrades/Acorn_JP101.html

All his games are fun. That one is one of my favorites, along with Necromancer. I actually got Necromancer on cassette - it took FOREVER to load. 😄

Star Raiders was great fun, and I played it a lot (still do), but I put the most time into MULE. It's especially great as a true multiplayer game. Up to four players on the 400/800, and we often colluded to make some remarkably rich colonies. The game that "wowed" me the most? Probably The Eidolon. Fractal caves with cell animated enemies? One of the greats. Rescue on Fractalus would be a close second to it.

The specs for twee v3 are here: https://github.com/iftechfoundation/twine-specs/blob/master/twee-3-specification.md

It depends on what you mean by "window is shrunk". DOS Doom runs full screen at 320x200 or 320x240 in Mode X. It pretty much drove Mode X as a feature for VGA cards. When you shrink the draw window so that it shows the textured border around the display, it's drawing less than 320 columns. DOS Doom also had "Detail" modes: high detail was up to 320 columns, while low detail was pixel doubled just like the Jaguar and 32X ports. Low detail was often used on 386 systems to help keep the speed up. If DOS Doom is running in low detail, it's no different in how much it draws at full screen - 160 columns. If it's running in high detail, then yes, it will always be more columns than the Jaguar is drawing. I'd like to see how the Jaguar version ran at 320 wide. Doom 32X Resurrection is pretty good in 320 wide mode - at least as fast as the original was in 160 wide mode.

Very nice! 🤩

That may or may not be true. If the polygons are texture mapped, they can easily use far more memory than a height map. If just flat colored, then it depends on how many polygons all the models have (vertex/color data consumes memory).

https://imgur.com/a/bOfi9Xx comes from a post on DoomWorld in the D32XR thread: https://www.doomworld.com/forum/post/2410505 Someone made a cart, posted here: https://www.doomworld.com/forum/post/2489933 We're close to another release. Among many bug-fixes and minor optimizations, we've added back the screen melt.

Holy Moly! I won? I mean, of course I won. 😁 Thanks for running the contest. I suppose you'll PM me about it... my sympathies to everyone else. Saw some really great computers and numbers... some funny ones, too. Merry Xmas to everybody.

314159

H32 mode is for backwards compatibility. It's basically the same as the Master System video. They started with the SMS VDP and added to it to get the MD VDP. MD games are supposed to run in H40 mode for better resolution, more sprites, etc., but MD games CAN use the 256 wide mode when porting a game that is only 256 wide and they don't want to spend the money changing the graphical assets for the new resolution. If a game NEEDED more sprites, you moved to H40 mode and paid an artist to update the graphics.

Yeah, that's a good way to think of it. Because it runs slower in H32 mode, there's fewer cycles for fetching data, which is why there are more limits on things like the number of sprites per line (16 instead of 20).

The MD uses BGR444 where the lsb of each color is ignored, for 3 bits per color, or 512 total colors. This mode of display I tend to call Direct Color DMA for obvious reasons: the pixels are direct color mode (BGR444 in big-endian format with the lsb of each color ignored), and are DMA'd to the background color register of the VDP. Filling the whole screen requires a bitmap that is 198*224 (for NTSC, PAL could be taller), where 160 of the 198 pixels is visible. That 198 pixels is the entire display line, including the horizontal blanking period. Yes, the whole overscan region is visible. Shifting the 160 wide image left and right can put part of it in one side of the overscan or the other. You COULD make your software use the overscan region if you want, but why would you? In narrow mode, the dimensions of the bitmap is 161*224, where 128 pixels are the normal visible line. You don't have to fill the entire display side to side, but the bitmap is still 198 or 161 words wide, and all will be DMAd to the VDP. You don't have to use all 224 lines, either. Stopping the DMA early leaves more time for the CPU. In fact, set the DMA for something like 198*180 words, and when the cpu starts as the DMA ends, set the VDP to show a normal graphics HUD under the DCD region. In any case, yes, DCD pixels are two normal pixels wide. It can be any of the possible 512 colors the VDP can show. This limits what this mode is good for. Anything that needs fine detail is not going to get it, so that is right out. That would be better done with the normal 320 wide graphics.

Yeah, that was my listing from my then brand spanking new AT88-S1PD (back in 1983-ish?). I had ordered the old single density single sided drive, but they graciously upgraded my order at no cost! I've still got the drive. Edit, and yes, I forgot all about the exception vectors at the end of the rom. 😳

The SRAM is at $5000, the IO is at $4000, and the ROM probably was $F000. If you look at the code, it's all PC relative, so it could go anywhere. At the time I disassembled it, I didn't know where anything at all was. I wrote my own 6809 disassembler that worked on ram in the Atari at $C000 as I had the MOSAIC memory expansion, which put banks of RAM at $C000. The disassembly you see is what was generated by the program. I pulled the BIOS from my Percom, put it in an Atari cart with a socket for the ROM chip, dumped it like any other Atari cart, wrote a 6809 disassembler, generated the listing, then went through it figuring out what was being done based on the serial protocol. I got the schematic later from Percom - that was a real stroke of luck, they just sent some random guy the schematics to the drive they sold him. My Percom came with a DSDD drive, a connector for another internal floppy mechanism (I had another 5.25" drive there for some time, but eventually replaced it with a 3.5" drive), and a connector for your printer. I can't say why it doesn't work with Altirra's Percom emulation. It is possible there's a bug in the lst file... is was rather old when I converted it from the Atari to the Amiga, and then when I went from Amiga to PC. Or it could be in the emulation. No idea. If it emulates the 6809, 6821, 6850, WD1795, and some ram, all at the appropriate places, it should work. The BIOS does need a DSDD drive as that was what was in mine. No idea how it would respond to a SSSD drive, for example.

Well, you can still get "modern" CD drives, but yes, a truly modern optical disc drive is a BD that also handles DVD and CD (although some have dropped CD support, so be careful). Say you get such a drive with something like an IDE interface and connect that into the SCD with an appropriate BIOS replacement. It'll be no different for many games. For many, you'll be able to load data at a higher speed, making levels load faster; so those will be better, for a set definition of better. It's not like you'll really make any use of a 50X CDROM in a SCD - the rest of the machine can't handle that throughput. I'd be happy using a 2X drive on the SCD. By the way, the SCD chipset DOES have a bit to control 1X vs 2X on the CD speed. All drives were 1X, so that aspect of the SCD was never exploited or part of the BIOS. That might be a better thing to shoot for when working on a SCD drive upgrade... or replacing the drive completely with an SD card. Optical discs are so last millennium.

You can find a schematic and my annotated firmware disassembly of the Percom AT88-S1PD drive on this page: