ijor

And as I mentioned, older Steem versions require Pastil.DLL. Did you install the DLL on the same directory as Steem? And, again, you must use a 32-bit Steem version for interfacing with Pasti.DLL I think he is talking about the host drive, not the emulated disk. Older Hatari versions have a limited file selector. You couldn't change the Windows (host) drive.

All the things you mention changed in later versions. Older Steem versions require Pasti.DLL for STX support. This works only with 32-bit versions, not with 64-bit versions. Newer Steem versions have internal STX support. Earlier Hatari versions had a limited file selector. You couldn't change the host drive. This was implemented in newer versions (not sure exactly when).

The MAX V is not 5V tolerant and doesn't have a PLL. I don't recommend buying these chips at Aliexpress,

Mark, I hope it was clear I was joking ...

Seriously!? Coming out and abandoning the FPGA world? Shame on you! Now seriously, I don't expect the bus interface, by itself, being the main problem. I suspect the main problem would be all the parallelism required. I'm not an expert on Sid, but seems to me that Pokey would require more parallel processing than Sid (certainly much more than a cart emulator). You can always use faster micros if you need, there are faster STM32 parts that can run at 500 MHz, but they are more expensive.

But it seems they didn't publish the modified sources as they should for GPL software. That would mean they forgot ? ... or they didn't ? ... Very unlikely either way.

Are you saying that writing a new emulator from scratch was easier than fixing those bugs, or retrofitting libreto to a newer a800 version?

It's interesting that they decided to write their own emulator. They sacrificed the high accuracy that modern emulators have for getting full licensing control?

Sorry, no. I was talking about a "simple" HDMI/DVI transmitter chip. Wouldn't such a video chip would be overkill? Overlying the OSD output at the core is not very complicated. You can grab MiST/MiSTer implementation if you don't want to code it from scratch. You can also grab the excellent full fledged MiSTer scaler by Grabulosaure.

Hi @cathrynm. If you are not an expert, performing a quick googling and just posting the first thing it comes, might not be a very good idea. Many times what Google brings is wrong, inaccurate, misleading, or only partially true. And if you are not an expert, you cannot tell, and you might just be spreading wrong, or at least inaccurate, information. Sorry if I am being a bit too harsh, but I suggest you perform a little bit more research before claiming I am wrong and "HDMI isn't free to use".

Pretty please, do include a direct HDMI connector. Yes, there are DVI adapters and audio injectors, but, obviously, a direct HDMI connector is much better. It is not exact that an HDMI license is required, this has been covered already by several experts. But please, don't cheap out with the HDMI (or DVI) hardware as you did on the Eclaire Use a real HDMI transmitter chip! That's the only thing I really disliked about the Eclaire. I would also recommend including a discrete ARM MCU. They are extremely cheap nowadays and can provide several benefits over a softcore implemented at the FPGA. In return, time permitting, I will contribute a VBXE compatible core In anycase, I think this is a wonderful initiative. Lets us know if you need some funding.

Hi, thanks for your words. The main issue now, probably the only issue at this point, is to find somebody that would build and sell the hardware. A "simple" Antic chip replacement is not very lucrative, it might be difficult to find somebody interested in manufacturing and selling this as a product. We had the idea of developing a "Super" ANTIC with VBXE capabilities built-in, among other things. But again, I don't build hardware, and certainly I'm not a seller ...

Double post, sorry. Please delete.

Yes, most modern MCUs have 5V tolerant inputs (with some limitations). This alone by itself should reduce costs significantly. Add to this that Chinese MCUs (Artery AT32) have rock bottom prices. I suspect that Pokey might require a faster MCU than SID, though. If it works correctly with real hardware, then it is still a RespeQt issue. Not necessarily a bug in the strict sense though. If the software requires cycle exact timing for some reason, RespeQt might not be able to deliver, due to the host limitations.

I'm not sure I understand why you are saying this. Are you saying that a new POKEY core should be developed because you think the Joyride's issue is PokeyMax core fault? I you read what @foft said, it seems the issue is not related to PokeyMax at all.