CPCEC a new emulator from cngsoft

Started by Arnaud, 09:14, 16 March 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

pelrun

GPL does not concern itself with embedded assets if they're not executable. Those files are covered by their own licenses, which of course you must follow just as you follow the GPL for the code itself.

BTW the GPL is explicitly not a contract, as contract law and copyright law are distinct in various jurisdictions.

cngsoft

#276
The legality of third-party data of any kind is indeed a problem: the default CPCEC package is already an impure compromise that mixes GPL source files and documentation, precompiled binaries for Windows and third-party firmware files. Ideally, the package should include the sources and docs, nothing else; it would be the user's task to compile the binaries and to bring his own firmware files.

In comparison, the Debian version of the Spectrum family emulator FUSE does it right: the "fuse-emulator-common" package doesn't include any firmwares on its own, and its only firmware-based dependency is "opense-basic", an open-source software replacement. The suggested packages include "spectrum-roms", unavailable on purpose from the main Debian repositories: Sinclair, Amstrad et al. may allow the distribution of the unmodified firmware files, but that doesn't make these files OSS-compliant, and the main Debian repositories cannot accept anything but pure OSS. You must go to the non-free repositories instead to fetch this particular package.

An important negative consequence is that as long as there aren't any OSS replacements of the CPC firmwares (or C64, now that I emulate it) CPCEC and CSFEC (as well as all CPC and C64 emulators in general) will be unacceptable in 100% pure open-source software environments.
(if you can't see the banner right now my server is currently offline)

AmatCoder

Thanks for answers.

So package (source tarball) could contain the ROM files but they cannot be embedded (firmware also is executable code after all...)
It's a pity because it would have been more comfortable for the end user :( .

By the way (and getting back on topic) I want report a possible bug:
The game "007 The Living Daylights" is flickering with last versions of CPCEC (with CRT type 1).

TotO

Quote from: cngsoft on 23:33, 11 August 22Ideally, the package should include the sources and docs, nothing else; it would be the user's task to compile the binaries and to bring his own firmware files.
And nobody will use it.

The problem is to have mixed the CPC/ZX/C64 emulators into your CPC emulator.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

cngsoft

#279
Quote from: AmatCoder on 19:54, 13 August 22So package (source tarball) could contain the ROM files but they cannot be embedded (firmware also is executable code after all...)
It's a pity because it would have been more comfortable for the end user :(
Making the job easy for the end users debases pure OSS into tainted freeware with undesired consequences; keeping it pure means all end users either have to install C compilers and learn to use them, or give up altogether as TotO says. Damned if we do, damned if we don't.

QuoteBy the way (and getting back on topic) I want report a possible bug:
The game "007 The Living Daylights" is flickering with last versions of CPCEC (with CRT type 1).
That's expected, the game doesn't setup its split screen properly (the debugger shows a clue of possible CRTC trouble: the screen is 512x304 pixels instead of the normal 512x312): launch that game on Winape or CPCEPower with CRTC1 and see what happens. It even looks like this game should also fail on PLUS ASIC hardware!
(if you can't see the banner right now my server is currently offline)

TotO

#280
It is a problem for you to split them?

- CPCEC (binary + ROMs)
- SPCEC
- C64EC

It is not possible to have a common open source base "EC" used by each CPC, SPC, C64 projects?
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Longshot

#281
QuoteThat's expected, the game doesn't setup its split screen properly (the debugger shows a clue of possible CRTC trouble: the screen is 512x304 pixels instead of the normal 512x312): launch that game on Winape or CPCEPower with CRTC1 and see what happens.

Launching the game on another emulator is not a guarantee.
Just that they all emulate badly.
Only the test on the real machine is important.

The game works fine without flicking on a real machine with CRTC 1.

The problem comes from a bad update of R52 when a request to reset the counter occurs exactly on the last microsecond of the HSYNC. In general, R52 is incremented on C0=R2+R3-1. But the reset request on this same position is taken into account after the incrementation.

So, on the C0 position of the OUT, R52 goes to 0 and is incremented to 1, instead of being incremented and zeroed. (this takes place at 130F during the game for information). This causes interrupts to be shifted one line earlier, and since the game handles all of its ruptures under interrupt, this has consequences. CRTC 0 and 2 are not impacted since the R4 update falls on the last line (this is only a problem for CRTC 1 whose counter C4 goes into overflow, and then encounters the value of R7 by triggering a VSYNC).

A priori, this game already used multiple ruptures in 1987. :o

It must have been developed on CRTC 0 or 2, because there is another bug in the game inherent in the operation of CRTC 1. The absence of text (or the repetition of the score during the game) in the lower part of the screen is linked to the characteristic of the CRTC 1 to take into account the update of R12/R13 as long as C4=0. In other words, this operation occurs too early and the author would have seen it if he had worked on a CRTC 1.

QuoteIt even looks like this game should also fail on PLUS ASIC hardware!
There's no reason it shouldn't work because it's not a CRTC issue. It works on CRTC 4.
Rhaaaaaa

cpcitor

> The problem comes from a bad update of R52 when a request to reset the counter occurs exactly on the last microsecond of the HSYNC. (...)

Now that's a deep knowledge of all the CRTC and their quirks... to each and every microsecond!  :o  :)
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

Powered by SMFPacks Menu Editor Mod