ijor

Once again, pasti.dll works only with the 32-bit Steem version, not with the 64-bit one.

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.

If you have older, non-ANSI, code, it might be just easier to run the original compiler under emulation. Emulators can map host folders to emulated hard disks. So you don't even need to bother copying your source files between the host and the emulator.

Please don't abuse forcing REFRESH low. It won't work with an ANTIC FPGA replacement. And to be honest, I'm not 100% convinced it is the best thing to do even for a "standard" ANTIC.

We are talking here about replacing individuals chips in an original Atari motherboard, not recreating the whole computer with a single FPGA. Not saying it is better or worse, just a different thing. A FPGA based XL was already implemented by @foft in his EclaireXL product.

I'm afraid I don't remember exactly. I remember it fits comfortably in the MAX10 02. I would need to run a compilation to get a better estimation. Of course, it also depends on a few factors, such as how you would handle the analog signals or the clocking.

That is the faster speedgrade -7. The slower speedgrade (-8) is slightly cheaper, although some variants might be out of stock at this time.

It's handled by the WD1772 FDC, which is in the XF's PCB.

All MFM FDCs devices support write precompensation. The 1050 already enables write precompensation for the inner tracks on MFM (enhanced or double density).

Ah, no. I was talking about the "latest" FPGA devices from the main manufacturers, Intel and AMD. Lattice usually concentrates in "niche" FPGA markets. I'm not familiar with this Lattice FPGA family, but this particular tiny FPGA might not fit. For comparison, the smallest Intel FPGA, MAX10 02, has 2K LEs.

There is no need to use 5V tolerant FPGA. As noted already, you use voltage level shifters instead. That's how most FPGA based add-ons are designed, including PokeyMax, Sophia, UltimateCart, etc. Pokey, or any of the custom chips for that matter, fits in the smallest modern FPGA, that costs less than $10.