Chilly Willy

The P and B frames are where nearly ALL the compression occurs. An MPEG stream without P or B frames is pretty worthless, and won't come close to the size even cinepak achieves. Atari wasn't interested because it sounds like it wasn't usable. You need at least P frames to be useful as a video compression format. This MPEG decoder wouldn't have handled VCDs at all. If he really claims it achieves the same rate as cinepak and is resolution independent, it sounds to me like it's only handling postage-stamp size video frames, then upscaling to the set resolution. That also fits with the mention of custom dithering routines. It was probably doing like 128x80 I-frame only video, then dithering up to 320x224 or whatever.

The JagCD can read the VCD just fine, the problem is decoding the MPEG1 video. Old consoles like the Jaguar/3DO/32X/PS1/Saturn are only able to handle complex compressed audio (MPG3, OGG, etc), not video. That's why videos for such older consoles tend to be like cinepak or indeo. That's why the PS1 had a MJPEG decoder in hardware - to give the better video in real-time. The Saturn had an MPEG video decoder card you could get. I don't think the 3DO had anything like that... and I know the Jaguar and 32X certainly didn't.

Here's the important part about compatibility with other formats: It's reading raw data, not "cooked" data. With the proper software on the Jaguar, pretty much any format can be read. That's also the downsize - you HAVE to do all the data decoding on the CPU.

Sounds at least like most of the electronics work - you may be able to sell it for parts. Getting a known working console would be better than trying to fix it yourself unless you are experienced in fixing these things yourself. Ah! The joys of messing with 25 year-old consoles.

Before I knew better, I used it on a CPU fan, which wound up having to be replaced. I use proper lubricants for plastic fans now. Holy crap! Don't people read warning labels? The one on WD40 is pretty clear about ingesting it, inhaling it, getting it in your eyes, or even on the skin. I think it's probably the main reason alcohol is used for cleaning... not nearly as harmful if you get it on/in yourself.

WD40 will dissolve plastics and similar. It's why they tell you to never use WD40 on computer fans. I imagine that a little amount will act as a cleaning agent much like alcohol, but stronger. Oh, and an emery board (nail file) can also be used on those really bad contacts if you don't have really fine sand paper.

It could just be a dirty cart port. Many people like to use some very fine sand paper wrapped around a credit card to lightly buff the springs in the cart port to make sure you get good contact. The fact that the menu ran at one time, but you had games that would fail part way through seems to make that possible.

There are 3600 jiffies per minute (NTSC, it's 3000 for PAL). Now just divide the beat into that to get the value for quarter notes. All the rest are just various fractions/multiples of that value. For example, 3600/120 = 30, which is what you got for the quarter note at 120 bpm. A half note is twice that, while an eighth not is half that. And so on.

So, will their be emails or PMs on sending money (hopefully with paypal or something) and our shipping address?

Really old Genesis consoles may need to have all the caps replaced. It's fairly common.

I checked it out - it uses raw sectors as well. He does a nice job of giving you something to work with... you take all your data files and make them into one file that is burned as a track. Then you read files by simply reading the track, but skipping the first N bytes to where the file you want it. Kinda like a ROM filesys, but on a CD with raw sectors.

Yes. There's a library for *nix that will take raw CD data and do all the error detection/correction to give you cooked sectors. Then ISO9660 + Joliet extensions is super easy to do. I do my own ISO9660+ code on my SegaCD demos, and it's tiny the amount of code you need. The library to do CD error correction isn't that big either. It would certainly make creating homebrew CD easier.

The reason JagCDs are so picky is that they don't use cooked sectors. If you've ever looked at the CD code for the Jag, they use raw sectors which rely on the base CD error detection (and minor correction) just like CDDA audio. This does allow for more storage on a CD, which Atari plugged every chance they got, but made CDs more likely to fail. Note that the PSX used the same mode for video data, but standard ISO on cooked tracks for the code/data for the game. Using raw mode instead of cooked for video/audio is fine since a minor glitch in that data isn't fatal. You see or hear a glitch and then it's fine. If that glitch were in the program code or data, you'd see/hear a crash as the program failed.

The Gate... that's the one where they use the kid's rocket at the end, right? That wasn't TOO bad. CHUD was pretty good as well.

They need to reboot The Last Starfighter... like Star Trek! Yeah!

I'll have to check around - I have both the final "Star Raiders 2" as well as the original when it was still called "The Last Starfighter" and had all the references from the movie. At the time, I always wondered why they did that as the original was better seeing as it matched the movie rather well, while it was NOTHING like Star Raiders 1.

Thanks! That's the first computer I bought with my own money. I worked at a TV repair shop one summer in 82 to buy it. I had considered the A400, the Coco, and the TRaSh-80, and went with the clear choice. It has a BKey full-stroke keyboard, the Mosaic 64KB ram upgrade, it's third POKEY (the POKEY seems to wear out real quick on the 400), and had a 65C02 for a while. I really love my old A400... still have it, and it still works!

How does a proprietary C/C++ compiler for *NIX and (old) Windows help Jaguar devs?

Yeah, there's a nice thread over at SpritesMind on it. He's doing a REALLY great job at porting this. Can you imagine if Sega had done a similar job back in 93-ish? BTW, he just released a new version that's even smoother on the gameplay.

Yeah, it's the easiest way to handle the boot process while keeping the disk in a single format. Well, I suppose the Atari ED method where ALL sectors are 128 is the absolute simplest method, but then the sector numbers can become too big. Switching to a bigger sector keeps the number smaller, but then you have that issue with sectors 1 to 3. It's just too bad they didn't go with a 512 byte sector, which would have made PC transfers a little easier. At least we didn't have to deal with that GCR crap that CBM and Apple computers had.

VR works on ALL Sega models except the Model 3, which works with a simple mod, running a wire to the cart slot. It works on most old Asian clones, and some of the newer clones that were derived from the Model 3 chip if you also do the Model 3 mod. As to the game not working, could be bad pins on the cart edge... either shorted or open. Can't tell which without actually checking the cart with the proper equipment. You could try the cart on a different Genesis to see if it works or fails the same as on yours. That would narrow it down to the cart being the problem, or the console.

They DID support the "?" speed command, but didn't add the hardware needed to divide the UART clock. My thoughts were to add that hardware, but like I said, got interested in the Amiga and lost interest in the A8. The most I wound up doing with the Percom was to add a 720K slave 3.5" drive to it. Well, that and my own printer driver to output images to an Olivetti Sparkjet printer.

Old 8-bit systems used buffer drivers on EVERYTHING because the CPUs were notorious about not sinking enough current for more than a couple chips. The question wasn't why they used a buffer, but why they used an INVERTING buffer. One guess - I have a data book on a few old PC floppy controllers where the typical usage schematic included showed an inverting buffer used. These chips required the data to be inverted. Maybe when they designed the 810, it originally used one of those, but switched to the last second to a new model that DIDN'T use the inverted bus, but by then the boards were already made with the inverter in place. More info... the Percom uses a 6809 processor - I disassembled the BIOS in the Percom along with getting the schematics shortly after getting the thing... I was interested in whether a hack could have been made for faster transfers on the Percom like the Happy was for the Atari floppy. I switched to my new Amiga 500 before anything came of that.

That looks just like mine. Don't know if I still have the manual, but it really doesn't need one now, does it? The card edge on the back is for a 50-pin Centronics cable for the printer. The pin header on the back is for an optional slave floppy drive (the Percom can handle two floppy drives, and I had a 3.5" floppy connected to it so I could transfer data to/from a PC easier). Certain DOSes support double-density on the Percom... I always used TopDOS. When the Percom is doing double-density, ALL the sectors are 256 bytes instead of 128, but the first three sectors only return 128 bytes of data for backwards compatibility with the single-density boot. You have to write your own floppy code to read/write Atari disks on a PC since PCs default to 512 byte sectors (most controllers handle 128 to 1024 bytes per sector), with half the sectors per track (9 instead of 18). Also, the Atari (and hence all compatibles) used an inverting buffer on the data lines to the floppy controller, so all data on Atari floppies are inverted when read on a PC.

I have to disagree here. The progression from A8 OS to Amiga OS is clear if you look at it closely. The A8 OS consisted of several relocatable "libraries" and "devices" that were accessed using jump table entries. You had two primary interfaces: the CIO and the SIO. All libs/devs had common vectors that did different things depending on what it controlled - both the screen and the floppy had the same CIO functions for things like in/out. The Amiga OS consisted of several relocatable libraries and devices (and resources, which were mainly limited libraries) that were accessed using jump tables. All libraries and devices had common vectors that did different things depending on what it controlled. It's just the level of complexity that went up considerably on the Amiga... mainly because you had the memory for said complexity. The A8 had to keep things as simple as possible both to limit the size of the rom, and because of the limitations of 8-bit CPUs. You can see the clear progression from the CIO to libraries, and the SIO to devices when you consider it from a programmer's point of view.