Commander X16

3 hours ago, desertfish said:

Intel Atom cpus are extremely slow compared to regular contemporary cpu's so it's not really surprising they can't run the emulator fast enough.

My PC who it's running Windows XP has a Intel Pentium 4 1.8Ghz without HT and has 512MB SDRAM.

But my Lenovo PC from 2008 what I got 2019 there the Emulator is running in full speed and has a Intel Pentium Dual Core E5400 and 4GB DDR2 800Mhz of RAM and its running Windows 10 64-Bit.

Also how about a Super Mario Kart, Streets of Rage, Kirby Super Star/Kirby's Fun Pak and a Sonic CD Port for the Commander X16?

Super Mario Kart relies on SNES Mode 7 graphics tricks to function, so it would be very difficult to create a game for the Commander X16 with similar functionality.

9 hours ago, OguzhanKuyubasi said:

Also how about a Super Mario Kart, Streets of Rage, Kirby Super Star/Kirby's Fun Pak and a Sonic CD Port for the Commander X16?

A X16 port of Sonic CD would be quite interesting.

2 hours ago, xanthrou said:

A X16 port of Sonic CD would be quite interesting.

Can we start with the Master System version and work our way up to that? ?

21 hours ago, kelli217 said:

Can we start with the Master System version and work our way up to that? ?

Makes sense actually. Starting with consoles like C64, Apple II, Master System, NES/Famicom, VIC-20, CP/M, MS-DOS of CGA/Tandy/EGA era, is always a good idea. Then, when we learnt enough, we would slowly move towards 16-bit era consoles/computers like Amiga, Sega Genesis/Mega Drive, SNES, MS-DOS of VGA era (which is a bit difficult to do), TurboGrafix-16, PC-FX and Macintosh.

On 1/26/2021 at 3:44 PM, BruceMcF said:

I am expecting if there is a playable "Doom Port", it will be more like an upgraded version of the VIV-20 " Doom port" than something that can actually execute a WAD ... IOW a port of a WAD rather than a port of an engine.

Is it possible to make FMV for X16?

31 minutes ago, xanthrou said:

Is it possible to make FMV for X16?

Only with certain tight constraints. Streaming off the SD card presents a pretty tight bottleneck, and the CPU can't really handle decompression.

Yeah, RLE is about all it can handle.

Isn't that LZSA decompress routine in the kernel supposed to be quite fast?