CPCEC a new emulator from cngsoft

[TotO]

The accuracy of your spellchecker isn't accurate, really.

I don't know if it is good, it wrote: "Touch your ass".

[WiltshireWizard]

z

[TotO]

I genuinely have no idea whether you are making some clever linguistic pun or not.

Please, return to your social networks were attacking people on their problems is a sport. Your post is not CPC related, just free wickedness. Thank you.

[abalore]

The accuracy of your spellchecker isn't accurate, really.

We are using a non-native language, it's a lack of education and very bad taste to make fun about it.

[eto]

The accuracy of your spellchecker isn't accurate, really.

don't drink and post.

[WiltshireWizard]

z

[Urusergi]

I think it's only a little joke
As a spanish speaker I've no problem if someone corrects me.

[Gryzor]

Dudes, tell me you haven't started drinking that early? 

Let's get back on topic. 

[Mage]

Great emulator !!! Congrats and thank you @cngsoft !
And also thank you to NoRecess for the Linux GTK port !

[cngsoft]

Thanks, @Mage. This is the feedback that makes this work worth taking :-)

And indeed, now that you mention @norecess' ports, and getting back on topic, what happened to @cpcitor's CPCEC repository? It got its last update back in January, half a year ago. Is Cpcitor alright?

[cpcitor]

what happened to @cpcitor's CPCEC repository? It got its last update back in January, half a year ago. Is Cpcitor alright?

Hi everyone! Thanks for citing me, the notification got my attention. As a result, I've just updated the repo, with updates from the 6 latest zip archives.

https://github.com/cpcitor/cpcec

If I'm alright? Thanks for asking. I've been busy "In Real Life"^(tm).  Also, slowly started to work on my next production(s). Considering one or two "tech demonstrators" (in the initial sense of a minimal thing that showcases one possibility, each could be fleshed out into a small actual intro/demo). They are meant as cumulative steps towards a somewhat ambitious game I have in mind, and will make real if time permits.

[cngsoft]

A new month, a new release.



20220806 -- minor patch fixing glitches in the VIC-II (the ending of "Creatures II" requires precise sprite priority), the CIA (the protection of "Druid 2" modifies and freezes the day-of-time clock, but "Island of Dr.Destructo" expects said clock to stay active after modifying it), the SID 6581 (Maniacs of Noise's "Echofied" scans channel 3 to generate a sampled echo), the C64 idle bus (the protection of "Barry McGuigan's Boxing" checks the $DE00-$DFFF area: reported by Neville) and the Z80 and MOS 6510 disassemblers. ZXSEC can save Dandanator information in SZX snapshots thanks to a new block type, "DNTR". The YM file generation is now in a new file, `cpcec-ym.h`. The SDL2 audio buffer is now the library's choice (suggested by Kawe). The keyboard shortcuts Alt+Up and Alt+Down zoom the window up and down. Enabling both X-masking and Y-masking shows a new dot matrix. Minor optimisations in XRF film logic.

@cpcitor, real life is indeed consuming. We look forward to your new tech demonstrations! (I certainly hope that CPCEC will run them as intended)

P.D.: CHIPNSFX and UZ80 got minor updates too, the former with similar audio buffer changes to CPCEC, the later with two new error checks.

[Carnivius]

A new month, a new release.



20220806 -- minor patch fixing glitches in the VIC-II (the ending of "Creatures II" requires precise sprite priority), the CIA (the protection of "Druid 2" modifies and freezes the day-of-time clock, but "Island of Dr.Destructo" expects said clock to stay active after modifying it), the SID 6581 (Maniacs of Noise's "Echofied" scans channel 3 to generate a sampled echo), the C64 idle bus (the protection of "Barry McGuigan's Boxing" checks the $DE00-$DFFF area: reported by Neville) and the Z80 and MOS 6510 disassemblers. ZXSEC can save Dandanator information in SZX snapshots thanks to a new block type, "DNTR". The YM file generation is now in a new file, `cpcec-ym.h`. The SDL2 audio buffer is now the library's choice (suggested by Kawe). The keyboard shortcuts Alt+Up and Alt+Down zoom the window up and down. Enabling both X-masking and Y-masking shows a new dot matrix. Minor optimisations in XRF film logic.

@cpcitor, real life is indeed consuming. We look forward to your new tech demonstrations! (I certainly hope that CPCEC will run them as intended)

P.D.: CHIPNSFX and UZ80 got minor updates too, the former with similar audio buffer changes to CPCEC, the later with two new error checks.

Very cool but could I ask if you could sort the files into folders, please?  I downloaded the zip and it appears all three emulators and their files are all in the same folder and it's a bit messy and I ain't sure how to split them into separates. There also appears to be scripts for the CPC one?  Is that what .H files are?

[cpcitor]

A new month, a new release.

Nearly everyone here knows the official URL for the emulator, yet it can be reminded: http://cngsoft.no-ip.org/cpcec.htm

I updated https://github.com/cpcitor/cpcec with the latest patch.

@cpcitor, real life is indeed consuming. We look forward to your new tech demonstrations! (I certainly hope that CPCEC will run them as intended)

I'm confident about the Z80 part (behavior appears to have been very well covered by emulators  -- timings, flags, hidden registers) and the video part, because I'm not too much into CRTC effects and stick to the fully-portable-between-all-real-machines subset of CRTC settings.

One of the thing I'm considering digging very deep in one of the anticipated project is the sound. Deep enough to probably break a number of current emulators. Why? The AY chip also appears to have been well analyzed yet I see two issues:
* I suspect many emulators don't have cycle-accurate emulation, which might be a problem when banging the registers at high frequency for specific effects or trying to break the limits of sampled audio
* because the output of the AY chip fundamentally operates at 125kHz which is not a multiple of 44100Hz or 48000Hz, it additionally requires some math and/or audio engineering knowledge for an emulator to produce clean audio (Arnoldemu and RetroVM fare better than other emulators as observed on https://www.cpcwiki.eu/forum/emulators/sound-emulation-survey/ ).

Don't hold your breath, things will take time. Cheers!

[cngsoft]

Very cool but could I ask if you could sort the files into folders, please?  I downloaded the zip and it appears all three emulators and their files are all in the same folder and it's a bit messy and I ain't sure how to split them into separates. There also appears to be scripts for the CPC one?  Is that what .H files are?

The source files end in .C (sources), .H (headers), .RC (Windows resources), .ICO (Windows icons) and .PNG (non-Windows icons); you can erase them all if you don't plan to compile anything. The essential files end in .EXE (Windows binaries) and .ROM (firmwares), while the .TXT files are the docs. You can always write a short BAT file, something like "DEL *.C *.H *.RC *.ICO *.PNG", to erase the source files on demand.

That being said, it's true that rearranging the package is a suggestion that I get every now; the most common request is to merge the ROM files within the compiled binaries. It would reduce the amount of visible files, but it would also make the project less OSS-friendly (embedding "blobs", sourceless binaries that cannot be replaced with sourced ones) and damage its customisation (compiling the emulators with the English blobs would hurt users relying on other blobs: French, Spanish, German...). There's nothing I can do as long as there isn't a consensus on the matter.

[Carnivius]

The source files end in .C (sources), .H (headers), .RC (Windows resources), .ICO (Windows icons) and .PNG (non-Windows icons); you can erase them all if you don't plan to compile anything. The essential files end in .EXE (Windows binaries) and .ROM (firmwares), while the .TXT files are the docs. You can always write a short BAT file, something like "DEL *.C *.H *.RC *.ICO *.PNG", to erase the source files on demand.

That being said, it's true that rearranging the package is a suggestion that I get every now; the most common request is to merge the ROM files within the compiled binaries. It would reduce the amount of visible files, but it would also make the project less OSS-friendly (embedding "blobs", sourceless binaries that cannot be replaced with sourced ones) and damage its customisation (compiling the emulators with the English blobs would hurt users relying on other blobs: French, Spanish, German...). There's nothing I can do as long as there isn't a consensus on the matter.

Ok cool but how do I separate them emulators into CPC, ZX and C64 folders neatly? 

[cngsoft]

Ok cool but how do I separate them emulators into CPC, ZX and C64 folders neatly? 

* CPC: CPCEC.EXE, CPC464.ROM, CPC664.ROM, CPC6128.ROM, CPCPLUS.ROM and CPCADOS.ROM;
* ZX: ZXSEC.EXE, SPECTRUM.ROM, SPEC128K.ROM, SPEC-P-2.ROM, SPEC-P-3.ROM and TRDOS.ROM;
* C64: CSFEC.EXE, C64EN.ROM and C1541.ROM.
The odd one out is XRF.EXE, the video conversion tool shared by the three emulators.

[Carnivius]

* CPC: CPCEC.EXE, CPC464.ROM, CPC664.ROM, CPC6128.ROM, CPCPLUS.ROM and CPCADOS.ROM;
* ZX: ZXSEC.EXE, SPECTRUM.ROM, SPEC128K.ROM, SPEC-P-2.ROM, SPEC-P-3.ROM and TRDOS.ROM;
* C64: CSFEC.EXE, C64EN.ROM and C1541.ROM.
The odd one out is XRF.EXE, the video conversion tool shared by the three emulators.

Thanks. 
Hm, when you list it like that it seems so obvious and I'm an idiot. 

[cngsoft]

It was more complicated in the past, when firmwares were inherited from extant projects that divided them into many small files and gave them arbitrary names. Typical C64 emulators cut the firmware into two 8K files and one 4K (KERNAL, BASIC and CHARGEN) and the Spectrum firmwares get often spliced into 16K files, leading to the 64K Spectrum Plus 3 firmware becoming PLUS3-0.ROM, PLUS3-1.ROM, PLUS3-2.ROM and PLUS3-3.ROM.

[GUNHED]

What this emulator really needs is a comfortable ROM selection option. like all modern emulators have.   Anything else... this one could be the killer app! 

[AmatCoder]

[...] the most common request is to merge the ROM files within the compiled binaries. It would reduce the amount of visible files, but it would also make the project less OSS-friendly (embedding "blobs", sourceless binaries that cannot be replaced with sourced ones) and damage its customisation (compiling the emulators with the English blobs would hurt users relying on other blobs: French, Spanish, German...)[...]

Hmm, I had not thought about this: Embedding Amstrad ROM files into executable could violate GPLv3 license.

And not just because they are "blobs" but also because, as far as I know,  Amstrad given permission for non-commercial purposes. This is not compatible with GPLv3.

Any thoughts? Am I wrong?


Ps.- I am asking this because I was writing a(nother) GTK port of the CPCEC emulator and I was embedding the Amstrad ROM files into executable

Ps2.- @cngsoft : Thanks you for your work, it's really great!

[andycadley]

Embedding the Amstrad ROM is probably not compatible with any version of the GPL and almost certainly not GPLv3. If you want to stay safely within the terms of the GPL you probably shouldn't be distributed the ROMs with it at all, since you don't have the rights to GPL them.

[pelrun]

I believe this is an incorrect interpretation. An emulator isn't linked against the ROM code, and doesn't require the ROM to have specific contents or functionality. The ROM is simply an input file read in by the emulator and acted upon - just because you load an image into the GIMP or a custom/commercial level into Chocolate DOOM doesn't make those files subject to the GPL either.

Embedding is not linking; executables can have embedded graphics and other files and that is considered an "aggregation" only.

[andycadley]

Embedding (or including) non-GPL'd assets, whether images or other things, is quite probably a violation of the GPL. It is, at the very least, something of a legal headache for either you or someone else down the line.

As with all things GPL though, it's ultimately just a license contract between you and your users. Unless you're actually planning on suing them, it doesn't actually matter at all.

[eto]

quite probably a violation of the GPL.

Of course you must not publish those components under the GPL, so those have to be excluded from the statement, that the emulator is under GPL. 


If I understand the GPL correctly, then it basically only makes sure, that work that is derived from work under GPL or uses GPL work, will also be under GPL. But if your GPL work is using non-GPL work or us bundled with it, that does not automagically make that work GPL too. That's, as far as I can see, not part of the GPL. But maybe I missed that part in the GPL.