Any thoughts on Neo Geo AES+?

[Xan]

Does it really do the same, though? The Mister core, while incredibly accurate from the user's perspective, is still an approximation. Doesn't look like the AES+ is improving over that. They're selling it as if SNK handed over the original designs and we all? know that's not the case. There're no technical benefits over current FPGA as they imply, much the contrary.

Besides, I personally would not call it a replica if you're adding digital video out and overclocking switches. The latter particularly is going to make most people believe that slowdown-free versions have some sort of officialism now.

I blame people who have been screaming "it's FPGA, not emulation!" in regards to things like Mister for the last couple of years for some of this confusion. Otherwise it should be clear to everyone by now that FPGA isn't magically more accurate than software emulation unless perhaps the chips are implemented 1:1 using the original schematics.

From everything I've heard, this sounds like a replica. Does making a new chipset that does the same as old chips which aren't being actively produced anymore count as "emulation"? At what point does it stop qualifying? Is the MegaDrive 2 an emulator of MegaDrive 1?

MD2 vs. MD1 is more about sound quality differences, but MD3 AFAIK has some games that won't work on it because they rely on bugs that were fixed in the newer chip. Some SMS stuff also won't work on MD, despite being one of the cases where they really did bother to do actual hardware backwards compatibility.

If you compare the 1chip SNES vs. playing PS1 games on PS2, both can differ visually from their respective earlier hardware, but in one case it's because they had to take shortcuts in chip design (or just weren't faithful to the earlier design), and in the other case they took shortcuts in the software emulation of the GPU. Some people have made the case for the 1chip being a sort of "official clone". The problems it has are arguably even more severe than in the PS1 on PS2 case.

The fine line for me is using a real console but doing the mapper chips for NES/GB/GBC in FPGA, or using palettes on the NESRGB. The really fine line is using flash carts purely for ROM access, because while this is normally indistinguishable, it doesn't seem to be entirely clear either how close this gets to the timings of the original ROM chips. Probably just relevant for high-level speedrunners in practice though.

[jd213]

I blame people who have been screaming "it's FPGA, not emulation!" in regards to things like Mister for the last couple of years for some of this confusion. Otherwise it should be clear to everyone by now that FPGA isn't magically more accurate than software emulation unless perhaps the chips are implemented 1:1 using the original schematics.

TBF, the Neo Geo is fairly simple hardware-wise. Seems there are a few minor unresolved issues on the Github, though. Would be interesting to see how an accuracy test (like the NES one) would perform.

MD2 vs. MD1 is more about sound quality differences, but MD3 AFAIK has some games that won't work on it because they rely on bugs that were fixed in the newer chip. Some SMS stuff also won't work on MD, despite being one of the cases where they really did bother to do actual hardware backwards compatibility.

For the Genesis 3, pretty sure only the VA2 has the incompatibilites in the Sega ASIC itself. They can be restored on the VA1 since its ASIC just wasn't fully connected to the cart slot points, and it's still compatible with Gargoyles.

[bobrocks95]

So where do I plug my cartridges in on this MiSTer thing everyone is saying is way better?

[Xan]

TBF, the Neo Geo is fairly simple hardware-wise. Seems there are a few minor unresolved issues on the Github, though. Would be interesting to see how an accuracy test (like the NES one) would perform.

Visual accuracy is one thing, but if talking about a replica of the original you'd want to match the original timings as well. I don't know to what extent they can or even want to go if this is just reverse engineered.

On the PS1, the old GPU is noticeably slower at doing transparency than the new GPU. On top of that, the older hardware revisions had bugs that were worked around in newer libraries, which is another possible source of slowdown. So not even counting differences between disc drives, if you'd run a demo on an early vs. a late console, it could go out of sync, certainly if there is any kind of transparency on screen. And this is just between two revisions of the same hardware.

At least analog output lets you run at the correct refresh rate and not get stutter, which is a pretty big deal as well.

[Sumez]

The really fine line is using flash carts purely for ROM access, because while this is normally indistinguishable, it doesn't seem to be entirely clear either how close this gets to the timings of the original ROM chips. Probably just relevant for high-level speedrunners in practice though.

Tech-heads here correct me if I got anything wrong, but this is how it works on the hardware I'm familiar with

Quality or design of ROM chips don't actively affect the timing of anything. They can be a bottleneck, but the rest of the hardware needs to know it in advance. The timing of reading data is controlled entirely by the CPU design and its clock frequency. If the ROM doesn't support the speeds that the CPU tries to access the data at, you'll just get faulty data (or maybe damaged hardware? doubt it though). Just like you can overclock a CPU, but at one point it's gonna stop working or overheat.

This is why the SNES has a "fastrom" setting. It was assumed that some cartridges would be produced on cartridges with mask ROM ICs which couldn't keep up with the SNES CPU, and as such it would be slower while accessing that, also causing in the games running slower, and ultimately being more prone to slowdown. It eventually turns out a lot of games that were programmed to run with fastrom disabled actually work fine with it enabled. I just think devs didn't want to take the chance, because you couldn't just patch games back then

[Xan]

One would expect it to work as you said, but there is a report of DS games loading faster on a flash cart compared to the real cart. There is this, as well.

[SavagePencil]

In general, the CPU issues a read and waits for the ROM to respond.

[orange808]

I blame people who have been screaming "it's FPGA, not emulation!" in regards to things like Mister for the last couple of years for some of this confusion. Otherwise it should be clear to everyone by now that FPGA isn't magically more accurate than software emulation unless perhaps the chips are implemented 1:1 using the original schematics.

That's been going on for more than a couple years. Analogue started this mess.

When I shared references to a very helpful essay from byuu, it was met with nasty flaming. It felt like reddit in here. Reddit is a cesspool.

There was also so some unhelpful comments from a regular that suggested the open source software emu community hadn't contributed significantly to these new FPGA emulators and a silly claim that these FPGA emus are developed from scratch with nothing but a scope and a lot of moxie.

That's bollocks and we all know it. It's still emulation and we all stand on the shoulders of giants.

[orange808]

All hardware has very distinct characteristics, even with official hardware redesigns.

Take the Atari 2600 Jr.

It's well known that Atari discouraged competition by spamming the fabs with orders for TIA chips and that created a surplus. There were plenty of proper TIA and 6507 chips available to make a new cheaper Atari 2600. But, the motherboard and design still created some unexpected headaches.

The problem is that the VCS/2600 has no frame buffer and programmers were working directly on the metal; devs exploited some very specific timing and even small changes could break commercial software.

The Jr is incompatible with cycle 73 and 74 HMOVE calls and there were carts that employed that trick for a variety of advantageous purposes. The redesign is completely incompatible with some of the machine's library.

Of course, that's extreme. The Neo Geo doesn't give userland that kind of access to the hardware.

[PC Engine Fan X!]

All hardware has very distinct characteristics, even with official hardware redesigns.

Take the Atari 2600 Jr.

It's well known that Atari discouraged competition by spamming the fabs with orders for TIA chips and that created a surplus. There were plenty of proper TIA and 6507 chips available to make a new cheaper Atari 2600. But, the motherboard and design still created some unexpected headaches.

The problem is that the VCS/2600 has no frame buffer and programmers were working directly on the metal; devs exploited some very specific timing and even small changes could break commercial software.

The Jr is incompatible with cycle 73 and 74 HMOVE calls and there were carts that employed that trick for a variety of advantageous purposes. The redesign is completely incompatible with some of the machine's library.

Of course, that's extreme. The Neo Geo doesn't give userland that kind of access to the hardware.

For orange808,

What 2600 games are incompatible with the Atari 2600 Jr. console setup? Atari did release it back in 1986 at retail with some notable brand new 2600 games including Williams' Stargate (aka "Defender II"), Crystal Castles, Dark Chambers, Desert Falcon, Solaris, Midnight Magic, etc.

PC Engine Fan X! ^_~

[Sumez]

One would expect it to work as you said, but there is a report of DS games loading faster on a flash cart compared to the real cart. There is this, as well.

That's very different technology compared to Neo Geo hardware
DS games don't even use ROM

In general, the CPU issues a read and waits for the ROM to respond.

Source?
I'm not a CPU designer, but from my knowledge, the CPU sends the address to read from, and assumes the data is on the data bus when it reads it. Look at the pinout for a ROM IC. There's no signal to indicate the data being ready. I've also done it myself using bitbanging while debugging an arcade PCB to check if the needed data was correct.

[Sumez]

The Jr is incompatible with cycle 73 and 74 HMOVE calls and there were carts that employed that trick for a variety of advantageous purposes. The redesign is completely incompatible with some of the machine's library.

This is perhaps a better example of what I was getting at than the MegaDrive 1/2 thing.
The point being that, yeah, there will be tiny hardware differences which are mostly irrelevant. And yeah, there *might* be some which could even affect some obscure scenarios even if it isn't proven! That's not unlikely at all. For those console redesigns it was certainly the case.

Does that make it "emulation" though? I mean, we really gotta draw the line somewhere, and honestly I think if making a new ASIC to work the same as the original hardware is still "emulation" to someone, then everything is emulation. The MegaDrive 2 and 2600 jr sure would be! There'd be no reason to even address that.
"Emulation" just means another thing that works like the original thing, so yeah, it's not incorrect to call it that. But it sure as fuck is different from a computer program designed to work like a Neo Geo

[Bassa-Bassa]

I myself didn't call the AES+ "emulation", mind, I said it's being based (as per Furrtek's comments) on emulation and reverse engineering, therefore, Plaion's catch phrases implying it's better than FPGA are bollocks much like Analogue's, given that the system hasn't been entirely documented for a 1:1 replica.

Will this AES+ only get the (minor) issues currently known for Mister's core and will we all agree that it's good enough? Possibly, but new issues may be found with the time and those won't be fixed here. Whichever the case, and also because of the new features as I mentioned, calling it a "replica" is much of a stretch if you ask me, and many people are ordering it because they're expecting that (or something made/designed by SNK and sadly funded by bin Salman, oh noes).

[orange808]

What 2600 games are incompatible with the Atari 2600 Jr. console setup? Atari did release it back in 1986 at retail with some notable brand new 2600 games including Williams' Stargate (aka "Defender II"), Crystal Castles, Dark Chambers, Desert Falcon, Solaris, Midnight Magic, etc.

PC Engine Fan X! ^_~

If memory serves, Mattel was the only one that used it.

He-Man is the most popular example. I think Burgertime uses it as well, but I would need to look again. It's sad that I don't remember, because I did a disassembly of Burgertime to see if they patched later versions of the cart. (They didn't. We just had a bad dump.) The fancy bankswitching on that one is a nightmare...

[Xan]

That's very different technology compared to Neo Geo hardware
DS games don't even use ROM

If you look at say SNES Everdrives, the oldest ones would connect a flash chip straight to the databus (or well, through a bunch of resistors). On the newer X5, the ROM is stored on a PSRAM chip which is only accessed through a CPLD or FPGA. So along with the ROM chips on original cartridges, you already have three different technologies of accessing a ROM.

I don't know if anyone ever bothered to check whether all are identical frame by frame in terms of loading speed. One thing about the X5 I noticed is that if pressing the reset button on the console the graphics will become garbled, which doesn't happen on the older v2.

[SavagePencil]

One would expect it to work as you said, but there is a report of DS games loading faster on a flash cart compared to the real cart. There is this, as well.

That's very different technology compared to Neo Geo hardware
DS games don't even use ROM

In general, the CPU issues a read and waits for the ROM to respond.

Source?
I'm not a CPU designer, but from my knowledge, the CPU sends the address to read from, and assumes the data is on the data bus when it reads it. Look at the pinout for a ROM IC. There's no signal to indicate the data being ready. I've also done it myself using bitbanging while debugging an arcade PCB to check if the needed data was correct.

Without linking to CPU docs, the Z-80 and 6502 have lines explicitly for this (/WAIT and RDY, respectively) to indicate this.

UPDATE: gonna reverse myself here; looks like most consoles only used these for DMA coordination and not for slow ROM reads, which some early computers did. So you’re right; systems expected ROM to respond in a tight timing window. Mea culpa!

The DS, if I remember correctly, has to load from the cart into RAM to execute, so if read speeds are slow then there will be a delay before it can run.

[Sumez]

Plaion's catch phrases implying it's better than FPGA are bollocks

I'd agree with as much. Having a custom made ASIC makes it a lot *cooler* I think, but not objectively "better".
People tend to both overestimate FPGA ("it's not emulation") and underestimate it ("it's just like software emulation")
An FPGA with sufficient capabilities, programmed correctly, should work exactly like the IC it's replicating. There's no overhead outside of the time it takes to program it.

It's pretty common for "modern" electronics to rely on FPGAs where custom designed proprietary ICs would be too expensive to produce. The ASIC would be less complex obviously, but FPGAs are mass produced to a much larger market. Cave's CV-1000 PCBs (every PCB they made since Mushihimesama) have an FPGA onboard for example, and a small rom with the program for the FPGA. Is it emulating itself?

Will this AES+ only get the (minor) issues currently known for Mister's core and will we all agree that it's good enough?

What are the issues? Probably depends on the source of those issues.
For all I know, it might not be related to the design of the console IC itself, but could be something in regards to how cartridges are emulated?

[neorichieb1971]

I don't really get the FPGA vs OG vs emulation hardware argument. I've ran games on all sorts of hardware and I just look at if its visually appealing, works correctly to the ears, eyes, hands and is costing what i'm willing to pay.

If you have to buy measuring equipment to see there is 0.06% lag or whatever, that is something I do not care one little bit.

If you consider that 100 brands made blu ray players, that they all conform to the same standard of operation, there are still differences between players. That is why for the past 50 years the media reviews products. If they were all identical there would be no need to review anything.

When the argument gets to that point of nit picking, nobody is buying this to play the games. They are buying or not buying based being inclusive of arguments on forums. Usually with 1 side saying its awesome, the other side protecting the OG and the freeloaders on emulation feeling like kings of the world who for the most part don't play neo geo games at all but belittle everyone else anyway.

Rest assured, Plaion engineers will likely have to find compromise. Almost 40 years has passed since the OG hardware, although I have heard that insiders did deliver full Neo Geo schematics from 1989. So it should be a close replica at least in RGB mode. I recently saw an MVS cabinet in a retro game shop on a LCD screen, it looked awful. No scanlines, no CRT filtering, just clean as a whistle. That is what I am waiting to see, because if that is the result of the NG+ its not worth $10 to me, let alone $200. I refuse to own more CRT's my last one went bang a few years ago and was quite scary. Sizzling noises, BOOM! then a plume of smoke filled my living room.

[orange808]

Speaking of emulation, you can run finished high quality Midway software emulation from Mame with almost no latency using GroovyMiSTer and GroovyMame without a paywall. Mame devs don't paywall their work.

FPGA bypasses the software emulation's bottleneck: the OS and drivers.

[Josh128]

When the argument gets to that point of nit picking, nobody is buying this to play the games. They are buying or not buying based being inclusive of arguments on forums. Usually with 1 side saying its awesome, the other side protecting the OG and the freeloaders on emulation feeling like kings of the world who for the most part don't play neo geo games at all but belittle everyone else anyway.

Nobody is buying this to play games. They might be buying it to play their already owned authentic game cartridges, because it looks cool, for the controllers, or because its a collectors item, but rest assured, every single person here, to a man, can play all the Neo Geo games they want for free, using MAME, Final Burn, or NeoRage X (the memories!).

[Sumez]

FPGA bypasses the software emulation's bottleneck: the OS and drivers.

That, and sequential logic. No if/then, it's all simulated logic gates. For some aspects of emulation this makes a really massive difference when it comes to accuracy, allowing emulation on a much lower level

[Konsolkongen]

Can a 100% accurately built FPGA also match all signal timings of the original designs perfectly?

Even if the FPGA logic is perfect could there still be some very small timing differences, that potentially could cause very minor differences in some cases? Is it possible to account for this when designing FPGA logic?

[Sumez]

Wouldn't that be controlled entirely by the clock speed?

[orange808]

FPGA bypasses the software emulation's bottleneck: the OS and drivers.

That, and sequential logic. No if/then, it's all simulated logic gates. For some aspects of emulation this makes a really massive difference when it comes to accuracy, allowing emulation on a much lower level

The two things that make 'massive' impacts on our ability to emulate are Moore's Law and the amount of free time devs have to research/develop the emus. That's true on every possible platform. In a perfect world with infinite time, a commited dev could make identical high quality emulators of a legacy machine in multiple ways. Every method will have strengths and weaknesses.

I'm glad I've been on the internet for a long time, because I sound like a LLM...

[Bassa-Bassa]

What are the issues? Probably depends on the source of those issues.
For all I know, it might not be related to the design of the console IC itself, but could be something in regards to how cartridges are emulated?

For something like this, I guess it could be. Stuff like this definitely seems it could not. These matters are usually discussed on Discord and I don't go there, but seems the author doesn't consider his work finished yet despite how well it runs basically everything. Extensive speed tests against the real thing are still due, as far as I'm aware.

[Konsolkongen]

Wouldn't that be controlled entirely by the clock speed?

No it’s a lot more complicated than that for sure. Different ICs will have different propergation delay and rise and fall times of signals.
This doesn’t necessarily make a difference, but I wonder if it is possible to design FPGA logic to accommodate for this.

[FinalBaton]

I'm really interested in it since it has analog video out.

Did anyone out there tested if it has correct video levels and clean picture(comparable to that of good rgb signals from the retro consoles that had them)?

[fernan1234]

Did anyone out there tested if it has correct video levels and clean picture(comparable to that of good rgb signals from the retro consoles that had them)?

Nobody has tested anything. It's not even known what the back of the console looks like, what the analog video connector looks like, and whether it only outputs composite video or other types like RGB, etc.

Edit: Jotego has conformed RGB output: https://retrorgb.com/jotego-confirms-ne ... tures.html

[D]

To my knowledge that has already been cleared up.
The back has an hdmi out and the regular multi av out with composite and RGB and of course a power input.
Someone was able to get a picture, weird angle.

[Restart_Point]

.
Glad to finally see some more information from a reliable source

Thanks to RetroRGB.com for highlighting this new video interview where Jotego says a lot of interesting stuff about AES+ (will need to turn on subtitles for non-Spanish speakers). He begins by saying that Plaion have now "allowed" him to say more for this interview.

He confirms that the ASICs are based on the MiSTer core, using his and Furrtek's work on that core, he says he believes lag will be as minimal as possible. He confirms RGB output. He says the carts will use flash memory to begin with, as ROM is only feasible in very large production runs, hinting that different methods could be used later if future cartridge demand allows. He says that the Neo Geo chipset is being reduced to 2 main ASIC chips. He vouches for Plaion's build-quality claims RE console and joysticks. He talks about the sound DAC and how the AES+ audio will differ from the MiSTer core....a must-watch

I wish that Plaion themselves were confirming more in-depth stuff like this on their website though...

LINK: https://www.youtube.com/watch?v=rgHGL5TSR-s



.
.