Chilly Willy

The latest AtGames use a slightly updated emulator that fixed a few graphics bugs, but still has crappy audio. What I want is a way to do native games on them. Instead of using a crappy emulator, have native games using the full power of the arm processor.

Yes. Just google for them and you'll find plenty of places selling them. Not anything like Best Buy, but online places.

Just remember that the AtGames consoles are pure crap. There's a reason most people call them ShatGames. I consider the AtGames handhelds to be just good enough and cheap enough to warrant giving one to a little kid to play Genesis games on. They are NOT for adults who would take care of a more expensive handheld. For example, an adult would MUCH rather have a PSP with a Genesis emulator than the ShatGames. A GP2X or similar running an emulator would also be a better purchase for an adult. I suppose if you were going on vacation and were worried about losing your handheld, the ShatGames handheld would be cheap enough that you wouldn't care if it were lost or stolen. That would be about the only reason to get one.

Except that Commodore USED to own the largest chip foundry in the business. It was downright CHEAP for them to do these things. The end was started when management sold off the chip division to make a quick buck to stick in their pockets. At THAT point, new chips were expensive, which led to doing less in R&D. Again, it was PURELY MANAGEMENT that sunk the Amiga. Not hardware, and certainly not software. Absolutely incorrect. The 680x0 family was just as "easy" to increase clock rates as the x86 family. You clearly don't recall that the way the x86 increased its clock rates was to move to an entirely different internal architecture and add a layer to translate the old x86 opcodes into the new opcodes. It adopted a RISC internal architecture. And if you bothered following the 680x0 family, you'd see that with a minimal amount of R&D, Motorola converted the 680x0 into the ColdFire, a RISC processor using most of the 680x0 instruction format, with a compatibility library for the now unsupported opcodes. Doing that, they were able to boost the clock rates an order of magnitude. They didn't bother trying to go any further as these were aimed at the normal 680x0 market - embedded microcontrollers, not PCs. Motorola NEVER sold all that many 680x0 chips for PCs, so they were more than happy to let IBM foot most of the bill on updating the PowerPC - its replacement in the PC market.

Too many sellers on ebay don't pack the items properly. I had a SNES I bought get damaged in shipping and needed to be replaced. I've had carts and discs I bought sent in unpadded envelopes with no packing material. Stupid shit like that. Some folks don't seem to have a lick of sense when it comes to shipping electronics/games.

Nice! A classic 2D platformer. Very retro...

There are some cheap third party controllers that don't do that, but all Sega pads should, and the better third party ones will as well. I've got one third party pad that doesn't even have the MODE button! So it certainly doesn't do that.

Have you tried other CDs to see if it has similar problems? Maybe that first CD has dirt/scratch it can't handle. Does it do the same thing every time you reset, or do you have to let it sit off a while before it works again? If it just plays noise until you turn it off and let it sit, it's not an alignment problem, but a heat or bad component problem. Basically, we need more info to determine what the problem may be.

That was my thought... it doesn't have a GUI, and here you have a GUI. It's always good to look over things like this. Even if you can't use it, you may get ideas on making your own stuff better.

@flashjazzcat: Have you seen this? https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj It's a post on Fuzix by Alan Cox, a kind of unix for 8-bit systems that runs in as little as 32K ram/32K rom.

Some games don't like the 6-button pad. Hold the MODE button on the pad while powering on the Genesis to switch the pad into 3-button mode.

The YM2612 was fine for the Genesis. They merely needed to do the following to have exponentially better audio: Connect the YM2612 IRQ line to the Z80 so you can use the damn timers. Make the rom access bank register parallel instead of serial. That's it! There's more they could have done, but just those two changes would have put the Genesis audio on a whole other level.

No idea, but if they only restricted them in the middle 80's, it wouldn't have been an issue in the late 80's or the 90's.

You should be looking at the total bitrate when determining if it will play on a CD. You need all the components - video, audio, and the container accounted for. Since the JagCD is 2X, the very max the total bitrate can be (without concerning the buffering) is 2.8 Mbits/sec. That will max out the CD at 2X, with no allowance for errors (so be sure to test the discs after burning for any errors). I don't know what kind of controls QTPro gives you since I use FFMPEG for my encoding. FFMPEG always encodes cinepak in constant quality mode, where -q:v N sets the qscale - the quality constant to shoot for while encoding. Values of N of 1 to 5 work well for low-res videos at 12 to 15 FPS for 1X CDs, or 24 to 30 FPS for 2X CDs. If you needed 24 to 30 FPS at 1X for some reason, 10 to 14 is the range to try. One reason you might want your video targeting 1X - you give yourself time to retry a read in case of errors or loss of tracking by the CD.

Ah, yeah, that would probably do it, depending on how good the player is in skipping errors.

What's disappointing to me is that they left out the 32X specific files. You can tell the code had both in it originally - there are still conditional compiling in many files that check if you're compiling for MARS vs JAGUAR. The primary missing file is marsonly.c (corresponding to the jagonly.c file that comes with the code). The other would be the 32X specific makefile. There might have also been 32X specific rendering code files like the GPU files.

Sounds like the setting was kiloBYTES per second instead of kiloBITS per second, which is what you normally pass to encoders. 1X CD rate (cooked, not raw) is about 1.2 Mbits per second. 2X is twice that. However, note that most cinepak encoders are actually outputting constant quality, not constant bitrate. So you get variable sized frames that average out to about what you asked for. You need to watch the encoder and keep the rate low enough that the maximum bitrate is never exceeded (unless you buffer the data ahead of the decoder, and then you can exceed the max by how much your buffer stores ahead of the decoder). Now that's weird... why would it have a limitation like that? That's part of why I want to work on my own decoders. I don't have any trouble playing 30 minutes on the N64 with my ROQ player. When playing long videos, the USUAL issue isn't hanging, it's keeping the audio in sync with the video. My current playing code syncs the video to the audio since the N64 can't guarantee an exact playback frequency. So I let the audio play back at the N64 rate, knowing it's off by maybe half a percent, then use the amount of audio played as a timestamp for advancing the video. It works great at keeping the video in sync, and is super easy to do on consoles. Anyway, thanks for releases all this stuff! It will be handy for some folks, and gives me more to look at while working on my own stuff.

The YM2151 has two more channels (8 as opposed to 6), and needs an external DAC. The YM2612 uses an internal DAC, and you can switch FM channel 6 to PCM output.

Funny. I'm using an A6. They're cheap as hell. The main thing these APUs need is both ram sockets filled to allows for dual fetch. Otherwise the graphics bog the CPU down.

I'm not sure what the greatest is... and what was greatest to me someone else might call shit. Music is really very subjective. I personally like that old Amiga tracker music. Anything that sounds like that will be better in my opinion than anything else. Never got into FM music, although I do recognize great FM music when I hear it. My favorite Genesis FM music is Ecco - The Tides of Time.

Might I suggest an AMD A8 APU? A cpu and gpu all in one... perfect for accelerating both the processing and graphics of your A8! At least you're keeping a sense of humor about the whole issue. Just keep on as you are... you're doing great!

The sound in the PCE/TG16 is a little before its time. It uses tiny wavetables to make sound. There are 32 five-bit samples for each channel in the sound processor. You can control the frequency and volume for effects. This is basically the same as later sound systems like the AWE64, just much smaller in scale. The tiny sample size limits fundamentally how low the frequency of the sound may be. It also limits how complex an instrument can be - it must repeat every 32 samples to avoid clicks. You can do some nifty things with this - one of the neater is streaming the samples on the fly, allowing for 5-bit PCM with volume control. You can also set two channels to set volumes and stream two channels of samples for 10-bit PCM at a fixed volume. Games that stream PCM generally use the hblank int for sample rates at multiples of 15kHz, 7kHz being rather common. The two biggest problems with Genesis audio are 1) they didn't tie the INT line from the YM2612 to the Z80, so the timers cannot interrupt the CPU, making them almost worthless; and 2) the lack of any ability to channel data to the DAC at a set rate - you have to use cycle counting on the Z80 (or HINTs on the 68000) to get a set rate on PCM. A lesser third problem is that Sega used a serially loaded register for the bank the Z80 uses to access the rom. A parallel loaded register would allow the Z80 to easily handle PCM at higher frequencies; the serial register takes about 100 clock cycles to load.

My first thought on the topic was "I looked outside last night and it was still there," but I checked out a few newsletters from the link. Seems like a pretty nice user group. Too bad there aren't any like that near where I live. This group has been around a LONG time. Good to see some of those old groups still hanging on.

That's a good thing... most studies on usability show that users perceive speed more from the UI than the app. As long as the part that interacts with the user is fast, they'll feel it's faster than the same app running twice as fast, but with a slower interface. That's particularly true with menus... I myself cuss at menus that take 10 to 20 secs to render on Windows or linux on my 3.5GHz AMD64 while nodding in satisfaction at the menu popping up almost instantly on my 266MHz Celeron running AROS. It just FEELS faster, so it must BE faster... at least, that's how it makes you feel.

http://krikzz.com/forum/index.php?topic=339.0 You're welcome.