Scali wrote:

No, I think it is. Because 8051s are off-the-shelf parts, only the firmware is proprietary, and once you have extracted the firm […]
Show full quote

derSammler wrote:

That's the point, isn't it? It's completely irrelevant *why* it's proprietary.

No, I think it is.
Because 8051s are off-the-shelf parts, only the firmware is proprietary, and once you have extracted the firmware (which people have), you can flash it into other off-the-shelf 8051s (or make a clean-room reimplementation).
The PAS is different, as it has its own ASICs. They are not standard chips with firmware in them. They are custom chips.
So you'd have to reverse-engineer the whole ASICs and reimplement them in whatever technology is suitable (perhaps FPGA). That's an entirely different ballgame. Software vs hardware.

Not to say that cloning a PAS isn't possible, just saying it's not comparable to cloning an SB. It's more complicated.

Yep

Tiido wrote:

there's a dump available of some SB clone's MCU content

Scali wrote:

People have extracted the firmware from the SB DSPs

Wait a min...
What firmware is currently available?
From some genuine SB? From some clone? Or both?

Grzyb wrote:

What firmware is currently available?
From some genuine SB? From some clone? Or both?

I think both.
That is, some clones didn't have the protect bit set, so they could easily be read back.
People have also decapped real SB DSPs to expose the mask, which could be read that way. I believe these ROMs may be out there somewhere, but hidden from Creative's sight 😀
See here on the MAME forum for example: https://forums.bannister.org/ubbthreads.php?u … er=95562&page=4
This presentation on the Snark Barker explains how he read the actual ROM from a masked SB DSP (some Chinese clone? The firmware has Creative copyrights anyway, so either it's a weird real chip, or it's an exact copy of a real SB DSP):
https://hardwear.io/usa-2019/presentations/So … io-usa-2019.pdf

Scali wrote:

No, I think it is. Because 8051s are off-the-shelf parts, only the firmware is proprietary, and once you have extracted the firm […]
Show full quote

derSammler wrote:

That's the point, isn't it? It's completely irrelevant *why* it's proprietary.

No, I think it is.
Because 8051s are off-the-shelf parts, only the firmware is proprietary, and once you have extracted the firmware (which people have), you can flash it into other off-the-shelf 8051s (or make a clean-room reimplementation).
The PAS is different, as it has its own ASICs. They are not standard chips with firmware in them. They are custom chips.
So you'd have to reverse-engineer the whole ASICs and reimplement them in whatever technology is suitable (perhaps FPGA). That's an entirely different ballgame. Software vs hardware.

Not to say that cloning a PAS isn't possible, just saying it's not comparable to cloning an SB. It's more complicated.

^ this.

Plus - contrary to people in many YouTube videos say (I'm not going to point fingers here) - I don't highly regard FPGA. To me it's not true hardware (even if technically it is - it's not period correct - more like hardware emulation of hardware). It's like putting LS6 into '69 Camaro and detuning it to original engine's specs in hopes to emulate the original experience... crazy.

Really great discussions ! I wish it were possible to re-make a new PAS16 today but agree that it would be near impossible to do even emulated properly let alone as true original clone smd chips

HanJammer wrote:

Scali wrote:

No, I think it is. Because 8051s are off-the-shelf parts, only the firmware is proprietary, and once you have extracted the firm […]
Show full quote

derSammler wrote:

That's the point, isn't it? It's completely irrelevant *why* it's proprietary.

No, I think it is.
Because 8051s are off-the-shelf parts, only the firmware is proprietary, and once you have extracted the firmware (which people have), you can flash it into other off-the-shelf 8051s (or make a clean-room reimplementation).
The PAS is different, as it has its own ASICs. They are not standard chips with firmware in them. They are custom chips.
So you'd have to reverse-engineer the whole ASICs and reimplement them in whatever technology is suitable (perhaps FPGA). That's an entirely different ballgame. Software vs hardware.

Not to say that cloning a PAS isn't possible, just saying it's not comparable to cloning an SB. It's more complicated.

^ this.

Plus - contrary to people in many YouTube videos say (I'm not going to point fingers here) - I don't highly regard FPGA. To me it's not true hardware (even if technically it is - it's not period correct - more like hardware emulation of hardware). It's like putting LS6 into '69 Camaro and detuning it to original engine's specs in hopes to emulate the original experience... crazy.

Even if compared to software emulation would still result in a whole indipendent (without an os, drivers etc..) much better solution beside still depending on the quality of the code development itself. To fpga lately, at least in the console "emulation/simulation" subject, I'd prefer those old style ASIC redesign of hardware that still may be perfect or a disaster but has it looks like even more specific and lower level than fpga.
For example there were quite good "Genesis-on-a-chip" asic in the past and others bad. Last newer official solution went for the usual ARM/linux emulation road and that's the reason I didn't buy newer "mini" retro game console.

Well, spinning a new ASIC is only a few hundred grand...

gdjacobs wrote:

Well, spinning a new ASIC is only a few hundred grand...

Does it? (question)
I'd imagine considering the classic glued type of ASIC directly on the PCB for these kind of platforms I would not be surprised if prices for a company would be lower considering how many of these console asic were built for low end cheap unknown chinese products.
I remember products like the C64DTV having similar solution, most of the Genesis clones of these years had this solution, most of them sold for much lower prices and sometimes having quite good results.
But maybe I've just never been a fan of software emulation.

EDIT: just to specify the C64DTV was not a chinese product; I was just thinking of that kind of pcb/asic board.

386SX wrote:

I remember products like the C64DTV having similar solution

The C64DTV is not a copy of the original C64 chips though.
It was originally developed by Jeri Ellsworth as the C-One, using FPGA technology.
Once the FPGA was mature enough, they basically 'froze it in time' by converting it to ASIC (like a readonly-version of the FPGA circuit). Effectively it still runs like an FPGA (the ASIC is clocked at 32 MHz and basically emulates the C64 'in software').

So it's not really a good example.
I don't know about the Chinese clones, but I wouldn't be surprised if they took a similar approach: clone the hardware in an FPGA first, and then 'bake' it into an ASIC for mass-production.
I think the market for the C64DTV, clones of Sega/Nintendo/Atari/etc consoles is far larger than that of some PAS clone though, so whether it's economically viable to go the ASIC route for a PAS clone, is up for debate.

Making a new ASIC is very expensive regardless of who you turn to, 100k is about right if everything goes right the first time, but if there's a bug or something you spend another 100k for the revision that fixes it. Majority of the cost is tooling to set up the machines to produce your design and creation of all the unique things necessary for making your design.
And in the end you use the same sort of HDL to create the ASIC as you do with an FPGA or a CPLD so there will not be any sort of functional (or moral) difference between them (apart from ability to usually include analog blocks into an ASIC, something you cannot do with an FPGA).

Some info about ASIC costs:
https://www.sigenics.com/page/ASICs-c

As you can see, example values range from 22K to 850K USD

Those low numbers in the end were also for very simple devices. Summing the low ends of each step described before was 57k, and that's still probably for a very simple device. The quotations for something comparable in complexity to what a sound card chipset would be have been in the 100k range from a few places, and that is for using non cutting edge processes etc.

EDIT: I used their cost estimator and it gave me 850k for something that would be single chip sound card solution... If I took out all the analog stuff (i.e use external DAC, ADC and mixer) the cost reduced to 480k...

Scali wrote:

The C64DTV is not a copy of the original C64 chips though. It was originally developed by Jeri Ellsworth as the C-One, using FPG […]
Show full quote

386SX wrote:

I remember products like the C64DTV having similar solution

The C64DTV is not a copy of the original C64 chips though.
It was originally developed by Jeri Ellsworth as the C-One, using FPGA technology.
Once the FPGA was mature enough, they basically 'froze it in time' by converting it to ASIC (like a readonly-version of the FPGA circuit). Effectively it still runs like an FPGA (the ASIC is clocked at 32 MHz and basically emulates the C64 'in software').

So it's not really a good example.
I don't know about the Chinese clones, but I wouldn't be surprised if they took a similar approach: clone the hardware in an FPGA first, and then 'bake' it into an ASIC for mass-production.
I think the market for the C64DTV, clones of Sega/Nintendo/Atari/etc consoles is far larger than that of some PAS clone though, so whether it's economically viable to go the ASIC route for a PAS clone, is up for debate.

I remember it and still have it and like all its story/development 😉.
I was thinking to it an example for the similar pcb implementation when the core is soldered directly into a simple dual layer pcb and doesn't need a packaging and I suppose with much less costs than a real mass-market oriented product, often used into old low end 90's eletronic toys; nothing bad about it at all, if it helps to reduce costs anyway.
I've been quite interested for some time readings of the 'Genesis/Mega Drive on a chip' with good and bad results depending on the model, but I'm not entirely convinced that "basically emulates it in software". Are those ASIC having the same kind of "gate" logic as the FPGA works? It'd be interesting to see if a modern ASIC having let's say a Z80 into it to work, when seen with x-ray or whatever just looks like a real Z80 and/or works exactly like it even in the most sensitive timing logics. Could it be that these asic may need a 32Mhz crystal to be divided into its system bus for each its own real frequency just for costs reasons but could have had different freq crystals for each internal parts?
I'm not that expert but I would not be surprised to see real "cpu" be designed into such ASIC without being "just" an a fpga translation. I suppose most asic are developed through softwares simulation project maybe even FPGA before getting into a real test silicon. Aren't those real hardware "implementation"?

Tiido wrote:

Making a new ASIC is very expensive regardless of who you turn to, 100k is about right if everything goes right the first time, but if there's a bug or something you spend another 100k for the revision that fixes it. Majority of the cost is tooling to set up the machines to produce your design and creation of all the unique things necessary for making your design.
And in the end you use the same sort of HDL to create the ASIC as you do with an FPGA or a CPLD so there will not be any sort of functional (or moral) difference between them (apart from ability to usually include analog blocks into an ASIC, something you cannot do with an FPGA).

But compared to a "arm/software emulation" road when I suppose the costs of buying licenses, softwares developments hours for the o.s., drivers, testing, buying the required numbers of the mobile ARM soc themself (beside mostly low-medium end smartphone level), could we ask ourself if a company choosing this solution will spend quite a lot maybe similar to built a product of the same level?

386SX wrote:

but I'm not entirely convinced that "basically emulates it in software". Are those ASIC having the same kind of "gate" logic as the FPGA works?

Well, I was talking about the C64DTV, where this is true.
You basically program the FPGA with HDL, so in a way you write the logic in 'software' (not the same as normal software for regular computers of course).
And the FPGA basically 'emulates' the logic circuit according to that software, using its hardware tables and things.
When you convert it to ASIC, you still base it on the same HDL code and therefore it still works like an FPGA, not like a 'real' chip, with direct hardwired logic. Which is why the ASIC in a C64DTV runs at 32 MHz, not at 1 MHz like a real C64.

Scali wrote:

Well, I was talking about the C64DTV, where this is true. You basically program the FPGA with HDL, so in a way you write the log […]
Show full quote

386SX wrote:

but I'm not entirely convinced that "basically emulates it in software". Are those ASIC having the same kind of "gate" logic as the FPGA works?

Well, I was talking about the C64DTV, where this is true.
You basically program the FPGA with HDL, so in a way you write the logic in 'software' (not the same as normal software for regular computers of course).
And the FPGA basically 'emulates' the logic circuit according to that software, using its hardware tables and things.
When you convert it to ASIC, you still base it on the same HDL code and therefore it still works like an FPGA, not like a 'real' chip, with direct hardwired logic. Which is why the ASIC in a C64DTV runs at 32 MHz, not at 1 MHz like a real C64.

But staying generic, the fact it has a 32 Mhz oscillator doesn't seem a contradiction to me for a possible "perfect system asic replica". The Commodore 64 had an oscillator @ around 14.3MHz this didn't mean the system "as a whole" was running @ that frequency obviously. An ASIC may have such high freq oscillator and still divide perfectly in hardware the 1Mhz of the MOS cpu and the other freqs required by others components just like most real hardwares always did. I agree something on a FPGA development board may sounds "sort of fake" hardware but as soon it's fixed into an asic without all the complexity of the entire original FPGA used/unused logics/pcb factory design/ide enviroment/eeproms/ram, I can't understand why an indipendent final ASIC couldn't be called a "rough" (in some case even bad for some genesis on a chip) approximated real cpu,gpu,sound chip, hardwired anyway...in a single chip like all the smartphone SOC nowdays or the various APU around.

I'M ALMOST OFFENDED... almost...

naw Just kidding.

I can defiantly understand if you're only into late 90s PC games then a 286 wouldn't be much use to YOU.

But those of us who play (and love to play with) games & computers from the 80s 286 are fairly awesome. Father than a 4.77mhz 8088.

games like Silpheed come to mind for games with Adlib & Gameblaster music, CGA/ EGA graphics that run a little slow on an 8088, but great on a 286.

my collection consists of 8088 XT and 286 AT class machines that I use almost every day! even when doing something simple like formatting floppy diskettes for use on other systems I will often fire up my Turbo XT clone.

something about the feeling of the older machines, the sounds that they make and the speed of everything is lost on 90s machines.

386SX wrote:

But staying generic, the fact it has a 32 Mhz oscillator doesn't seem a contradiction to me for a possible "perfect system asic replica". The Commodore 64 had an oscillator @ around 14.3MHz this didn't mean the system "as a whole" was running @ that frequency obviously.

I didn't say it has a 32 MHz oscillator, I said it ran at 32 MHz.
And yes, in theory it could be a perfect clone of a C64. But it isn't.
The most obvious difference is that the SID is not fully implemented, filters are missing.

That's the thing: It's *not* a clone of the real hardware, it's not even a gate-for-gate equivalent reimplementation in FPGA technology.
It's just an approximation.

pinkdonut666 wrote:

https://i.imgur.com/rfkVjgTl.jpg […]
Show full quote

I'M ALMOST OFFENDED... almost...

naw Just kidding.

I can defiantly understand if you're only into late 90s PC games then a 286 wouldn't be much use to YOU.

But those of us who play (and love to play with) games & computers from the 80s 286 are fairly awesome. Father than a 4.77mhz 8088.

games like Silpheed come to mind for games with Adlib & Gameblaster music, CGA/ EGA graphics that run a little slow on an 8088, but great on a 286.

my collection consists of 8088 XT and 286 AT class machines that I use almost every day! even when doing something simple like formatting floppy diskettes for use on other systems I will often fire up my Turbo XT clone.

something about the feeling of the older machines, the sounds that they make and the speed of everything is lost on 90s machines.

is one of those a 5162? or just a couple of 8088s lurking over there?

Scali wrote:

I didn't say it has a 32 MHz oscillator, I said it ran at 32 MHz. And yes, in theory it could be a perfect clone of a C64. But i […]
Show full quote

386SX wrote:

But staying generic, the fact it has a 32 Mhz oscillator doesn't seem a contradiction to me for a possible "perfect system asic replica". The Commodore 64 had an oscillator @ around 14.3MHz this didn't mean the system "as a whole" was running @ that frequency obviously.

I didn't say it has a 32 MHz oscillator, I said it ran at 32 MHz.
And yes, in theory it could be a perfect clone of a C64. But it isn't.
The most obvious difference is that the SID is not fully implemented, filters are missing.

That's the thing: It's *not* a clone of the real hardware, it's not even a gate-for-gate equivalent reimplementation in FPGA technology.
It's just an approximation.

I understand and remember it wasn't a "clone". I think to remember in some ways (color palette maybe) it was even better than the C64, other things like you said were missing. I remember to have tested it with various original C64 tech demos and it resulted obviously in different both gfx and sound problems while it had its own demo community with great gfx effects.
I have the doubt some of similar project (like some Genesis-on-a-chip running on various last decade Genesis "replica" (officially licensed) having an asic with a separated memory with many full original games that had a 28Mhz crystal) use that clock to generate the internal specific ones inside the ASIC not to run the ASIC as a 28Mhz chip emulating a 7Mhz 68000.. I'm not sure of the word "emulation" is right here with hardware oscillator divided into real perfect different internal clocks.
But I may be wrong. Anyway, having some ghz quad core armv7 soc with full opengl gpu, running a sort of "droid" linux with drivers, usb controller, a gui, an emulator app that run at last the game still always sounds the worst solution and not much sure if cheaper as I was asking above.