roland p

Isn't that copyright infringement?

Just an idea, driving/paddle/spinner controls? That would set this thing apart from other devices. My kids love toys/games with a steering wheel (v-tech)

- An amiga 2000/3000/4000 upgraded to the max (Powerpc/68060, graphics card, 16-bit sound) - PC Engine LT - Gaming PC with 2 Voodoo2's - ST Book - MSX Turbo-r - Commodore SX-64 - Atari 800 with all old peripherals.

Thanks! Well, while the effect is interesting I would still advice against using a black frame every other frame. And since you scroll 2 pf pixels at a time, you could scroll 1 pf pixel every frame at 60fps and have a smoother motion. Win-win!

The ballblazer kernel uses a two line kernel which is just blank every other line. I once had the idea to 'interlace' it, so one frame the odd lines where used, and the other frame the even lines where used. This way, I could effectively increase the vertical resolution. It also resulted in smoother vertical motion (forward/backwards). Well, the audience didn't liked it so I dropped it. But it was an interesting effect anyway. It appears that people prefer things that don't flicker ballblazer_sort_of_interlaced.bin

1. How do you experience 'wider' scanlines? Is there less overscan area? Are there less black borders left/right? 2. What has the horizontal width to do with the number '200', since the number 200 indicates a vertical space. 3. '2 lines wide', I still don't think you can make the lines wider. (widescreen displays can though ) Can you describe this process? I've looked at your game, starblitz, and on my laptop, with the brightness turned down, the scrolling looked nice. There are indeed a black frame every other frame so that causes flicker, but reduces the motion blur otherwise caused by a 'sample and hold effect'. The effect is nice, but I could imagine that it's unbearable on a crt with the brightness turned up. My thoughts on 'Manual Flicker Optimization': You should only use it if there is absolutely no other way. If you use it, you should use muted colors (no max brightness), so the flicker is less visible.

Could you give a technical explanation? Alex' explanation is spot-on and I have nothing to add; the atari just has to conform to the standards of a video signal (probably it is a little bit off, but it's close enough and within the tolerance of crt-tv's).

The computer-in-a-cart idea is not so bad indeed. You could have the flashback systems in seperate carts. The system itself would be really simple, and you don't have the clutter that multiple flashback systems would have.

About that Lee/Mike thing, someone who has emails of both could check the originating ip address HAHA that gave me a good laugh. 'Pink Horsey', these games can be played today! And that name... the RELIX system...

It loops to -9,223,372,036,854,775,808 (I finally managed to catch up after a week!)

A working Z3k with just hdmi and usb (for controllers/memory) would make me very happy already.

I just found some threads here: http://boards.dingoonity.org/gpd-devices/

Not sure if they are comparable. One executes ARM code and the other x86 code.

I think 1280x720 is ok since you can triple everything (320x240). There will always be a resolution that will scale 'bad'. It would be cool if they put a retina screen in it, just for good scaling of low resolutions

This looks nice for handheld emulators/pc-gaming: https://www.indiegogo.com/projects/a-laptop-fitting-in-your-pocket--2#/

Yeah, they are working on a new one that will fix the issues of their previous prototype:

I hope they don't use a bright blue led. Those are SO not retro.

Or the 'actual prototype' tier. That would be fun!

One day I decided to fninsh Shenmue 2, because I thought I was almost there. I started at 9pm and stopped at 6:30 am lol.

FPGA: - No dropped frames - No overhead of an operating system - No framebuffer needed, lowest latency possible - Not sure about this one, but Video and Audio clocks could be generated/divided by the same master-clock, so Audio and Video tight together compared to a PC. I do think modern consoles with architecture that looks like the architecture of a PC (3d stuff) are less critical to emulate. I just found something interesting (probably already mentioned here): http://www.tested.com/tech/gaming/2712-why-perfect-hardware-snes-emulation-requires-a-3ghz-cpu/

Yeah, I remember those kind of statements as well. From their facebook, 7 oktober: 15 oktbober: 25 oktober: 1 november: 23 november: 18 december: Is there any truth in this project???