CPCEC a new emulator from cngsoft

[cngsoft]

I released a couple of bugfixes during the past days:
* 20200503 -- minor patch improving the behavior of the Z80 operations INI, IND, INIR, INDR, OUTI, OUTD, OTIR and OTIR: the 2012 RAXOFT tests (Z80CCF, Z80FULL and Z80MEMPTR) score zero errors. Slightly more precise automatic frameskip.
* 20200505 -- minor patch focused on the SDL2 toolkit: fixed a bug when confirming overwriting files, and improved file browsing across directories by pointing by default to the previous directory.

Here are some tests you can do to see if the emulation is accurate:

- Install XDDOS 2.10 ROM and see if the system starts u
- Install FutureOS and copy from disc to disc (disc or file, check both)
- "" Use OS-Infos Tool to see if the expansion RAM can be detected

FutureOS succeeded at making a copy of the ZEXALL disc from drive A: to drive B: as seen in the screenshots:




FutureOS crashed when I tried opening the ramdisk at drive M: ; the same happens on WinAPE when inserting the same cartridge (English)+AMSDOS+FW3.15+WithoutMenu.cpr and examining the ramdisk.

[GUNHED]

Thanks for testing. I'll have a look what's the problem with M regarding real CPC and emulators.
Your FDC routines (and others) seem to be very faithful. Great work!!! 

EDIT: The crash when DIRectory of M seems to depend on the data in RAM &CC. It's not a problem of the emulation, more a problem in sorting the DIR which is not used. Will fix that.

[cpcitor]

TL;DR:
(1) Congratulations cngsoft for this extraordinary work!
(2) I can offer contribution in convenience feature (telling from command line to run something, and exit when CPC resets).

I tested the emulator on Ubuntu 20.04 (actually Xubuntu). It compiles easily, runs smoothly with low CPU consumption.   

  CPCEC is on a good way to replace caprice32 as my test-run emulator and debug emulator. 

I usually test-run my prods with caprice32.

Pros: caprice32 is open-source with public history, lightweight, easy to build, has menus, can be instructed from command line to run some command and exit on next CPC reset since I contributed some code to that effect (Scriptable wait point command-line option CAP32_WAITBREAK · Issue #110 · ColinPitrat/caprice32).
Cons: imperfect fullscreen handling, ageing dependency (SDL 1), emulation probably imperfect (yet sufficient so far for my needs).

I usually debug with arnoldemu.

Pros: arnoldemu is open-source, has some powerful debugging facilities (several windows, context menu, loading external symbols).
Cons: has become difficult to build (dependency on old wxwidget) and has some annoyances, like consuming 100% CPU whenever the debugger is active, no code history and no release visible since May 13, 2017.

(Most other emulators do not fit because they are not open-source, heavyweight or only work on Windows. https://floooh.github.io/tiny8bit/ is interesting: extremely accurate, easy yet heavyweight build, can run in web pages like https://gourichon.org/cpcitor/bydate/2020/2020-05-03/ .)

CPCEC may replace both

Pros: like caprice32 CPCEC is open-source with public history (I created a git history from your zips to share on github, with proper commit messages and fixing some issues like corrupted rom in one commit), lightweight, easy to build, has menus.
Cons: imperfect fullscreen handling, can not yet be instructed from command line to run some command and exit on next CPC reset. I can contribute as I did for caprice32. Also, debugging is not as luxurious as in arnoldemu. Interestingly, tiny8bit allows to use any window resolution for status and debugging, could provide inspiration.

All in all, congrats for cpcec!

[cpcitor]

Hi again!

You did a very good job of isolating the operating-system-dependent parts and making a SDL2 variant.
CPCEC works very well on Linux, and consumes little CPU on my machine!

I guess you will update http://cngsoft.no-ip.org/cpcec.htm

Turning this

CPCEC requires a Microsoft Windows 2000 operating system or later.

Into something like this?

CPCEC can run on Windows and SDL2-supported platforms including Linux desktop.
The Windows variant of CPCEC requires a Microsoft Windows 2000 operating system or later.

[cpcitor]

It's really nice that we start to have choices of emulators.

I love the ability to dump part of the CPC memory to a host file, to check for non-corruption.

Cpce really nicely fits the "simple, accurate, and convenient" type of emulator, which is a perfect niche to run and develop.

By comparison, RetroVirtualMachine complexity of UI makes it less practical to use (especially the debugging features), but on the plus side; its outstanding graphical realism (including rotating cassette reels) and capability to hear the tape signal while the CPC decodes it, are really nice when checking a tape loader being developed really works as intended.

Congrats to all of you, you rock!

[cpcitor]

Ah, I found some drawback in CPCEC: sound is mono. 

So, when checking music and do not need a debugger I use caprice32 again.

From looking at the source code it looks like CPCEC is mono on all platforms.

As expected, setting

Code: [Select]

#define AUDIO_CHANNELS 2

in cpcec-ox.h is not enough to get stereo sound. 

Still, huge congrats to CNGSoft. I used CPCEC debugger a number of times.

[XeNoMoRPH]

20200603 -- seventeenth public release. Added stereo sound. Fixed a bug in the CPC PIO (the read-only mode of port A allowed writing), another bug in the tape analysis (CPCEC: the algorithm for TITUS caused trouble in "The Blues Brothers"; ZXSEC: Speedlock5 didn't recognize the heading noise; both systems add patches to shorten the initial delays), another one in the loading of CPC snapshots (a snapshot saved on PLUS hardware without the "CPC+" block showed a completely black palette), another one in the Z80 debugger (the command 'P0 could generate an infinite disassembly), another one on tape handling (reading a WAV file must use >128 as reference instead of >=128) and some problems in Win32 (the screen stopped updating after pausing, switching windows in and out) and SDL2 (boot message errors weren't shown; the filename sorting algorithm was slow).

[cngsoft]

It took a long while, but CPCEC 20201010 is out. Big changes in the CRTC logic ("Chapelle Sixteen" runs at last!), new support for Dandanator cartridges (now you can play "Sword of Ianna"), partial Playcity support (enough for Targhan and Toto's teasers to work), more disc protections that run, new debugging functions (looking at graphics, following a timer, skipping scanlines and frames, etc), improvements in the user interface...





I need a rest, but I still want to make a game for the CPC Retrodev 2020 compo, so the next three weeks are going to be busy, a race against the deadline...

[Targhan]

Wow, great job!

I need a rest, but I still want to make a game for the CPC Retrodev 2020 compo

Great, but think about your health (mental and physical) first. Take care .

[cngsoft]

Small update: CPCEC 20201012 adds mouse support for SDL2. Keyboard usage stays the same, the mouse support is built on top of it:
- the main menu appears when right-clicking on the window;
- navigating menus requires clicking on their captions;
- picking a menu item requires clicking on said item;
- scrolling a list requires clicking above it (or below it) once;
- choosing an item in a list requires clicking on it twice (first click selects it, second click confirms the choice);
- quitting menus and dialogs requires clicking outside their areas.

Closing widgets by clicking beyond their bounds should feel familiar: the user interface from Rainbird Software's "OCP Art Studio".


It was one of the goals for the 20201010 release but it was half cooked and I forgot to finish it beforehand.

[reidrac]

Would it be possible to include the source files in a directory inside the ZIP and that the filenames are all lowercase?

Is not really a big deal, but every time I uncompress the ZIP, is a bit messy in Linux

Thanks for the emulators (both, I use cpcec and zxsec in Linux).

[pelrun]

I never trust a zip file, I invariably go into a new dir before unpacking them. And there's an option to unzip to lowercase the filenames.
@cpcitor has been maintaining a git repo at https://github.com/cpcitor/cpcec as well, which has the benefit of the full history of the zipped releases. Although it's not quite been updated with the newest release yet.

[reidrac]

I never trust a zip file, I invariably go into a new dir before unpacking them. And there's an option to unzip to lowercase the filenames.
@cpcitor has been maintaining a git repo at https://github.com/cpcitor/cpcec as well, which has the benefit of the full history of the zipped releases. Although it's not quite been updated with the newest release yet.

Hah! Looks like the unzip version of Ubuntu has the lowercase option, but I don't think I saw it in thee Debian version

It may be me, just ignore me 

[cpcitor]

I never trust a zip file, I invariably go into a new dir before unpacking them. And there's an option to unzip to lowercase the filenames.
@cpcitor has been maintaining a git repo at https://github.com/cpcitor/cpcec as well, which has the benefit of the full history of the zipped releases. Although it's not quite been updated with the newest release yet.

Thanks @Pelrun. Indeed, and I'm planning to update the repo today.

[cpcitor]

@cpcitor has been maintaining a git repo at https://github.com/cpcitor/cpcec as well, which has the benefit of the full history of the zipped releases. Although it's not quite been updated with the newest release yet.

It is now up-to-date! You can get the benefits of git with:

git clone https://github.com/cpcitor/cpcec


For the record, this is made possible because @cngsoft does things rather tidy, which makes automation possible:

* the history is generated by a script that fetches the ZIPs from the official cpcec web page and extracts the messages from the changes in file `cpcec-e.txt`.
* from now on each commit message includes the names of the ZIP file that was used to generate the commit, see for example https://github.com/cpcitor/cpcec/commit/01b09339b25784d38e31afbceff2c3c82e6e910f "This commit corresponds to archive: cpcec-20201010.zip"

[cpcitor]

new debugging functions (looking at graphics, following a timer, skipping scanlines and frames, etc), improvements in the user interface...

I noticed, when debugging, the vertical dotted line on the emulated screen, which is very cool to "feel" the speed at which the picture is displayed while the Z80 does its best to compute.

I played with the "show graphics" (press W in the debugger). Would need some more explanation.
I'm still puzzled because even on my latest game JustGet9, knowing the address and width in bytes, I could not see my graphics.  ¯\_(ツ)_/¯

I figured out from the source https://github.com/cpcitor/cpcec/blob/master/cpcec-z8.h#L4267 those keys:
HOME/END increase/decrease "sprite width in bytes"?
LEFT/RIGHT move one byte left/right
UP/DOWN move one line up/down
PAGEUP/PAGEDOWN move 16 lines up/down

[Spirax]

Hello.I just create an account to say thanks to cngsoft for the dandanator support on CPCEC 
thanks a lot for make Sword of Ianna playable on another emulator.
I will follow it on futures releases as I am developing a new cardbridge game....For the moment I can only say it works fine after I modify my own code to make it compatible with the emulator  As per the dandanator specs, we can use FD+FD + ld (IY+x) , abc ,
A for the config,
B for 1st slot zone
and C for 2nd slot zone

On my code for the new game I map both slots at same time using this code

Code: [Select]

    ld iy, rombank
    defb #fd, #fd
    ld (iy+0), b
    defb #fd, #fd
    ld (iy+1), c
And it was not working properlyAfter a few debug sessions I was able to found that the emulator only manage (iy+0) as tigger and not (iy+1)

so I modify my code to:

Code: [Select]

    ld iy, rombank
    defb #fd, #fd
    ld (iy+0), b
    inc iy
    defb #fd, #fd
    ld (iy+0), c
and now my new game (WIP port to CPC not announced yet) is working as supposed on CPCEC too 
but I would like to report it as may be good for a future release for a better dandanator emulation fidelity if you can check to use only 4 bytes as tigger for FDFDFD70 ,FDFDFD71, FDFDFD77 instead of the actual 5 bytes as FDFDFD7000 ,FDFDFD7100, FDFDFD7700

thanks a lot fo all your work

[cngsoft]

Hello.I just create an account to say thanks to cngsoft for the dandanator support on CPCEC 
thanks a lot for make Sword of Ianna playable on another emulator.
I will follow it on futures releases as I am developing a new cardbridge game....For the moment I can only say it works fine after I modify my own code to make it compatible with the emulator  As per the dandanator specs, we can use FD+FD + ld (IY+x) , abc ,
A for the config,
B for 1st slot zone
and C for 2nd slot zone

On my code for the new game I map both slots at same time using this code

Code: [Select]

    ld iy, rombank
    defb #fd, #fd
    ld (iy+0), b
    defb #fd, #fd
    ld (iy+1), c
And it was not working properlyAfter a few debug sessions I was able to found that the emulator only manage (iy+0) as tigger and not (iy+1)

so I modify my code to:

Code: [Select]

    ld iy, rombank
    defb #fd, #fd
    ld (iy+0), b
    inc iy
    defb #fd, #fd
    ld (iy+0), c
and now my new game (WIP port to CPC not announced yet) is working as supposed on CPCEC too 
but I would like to report it as may be good for a future release for a better dandanator emulation fidelity if you can check to use only 4 bytes as tigger for FDFDFD70 ,FDFDFD71, FDFDFD77 instead of the actual 5 bytes as FDFDFD7000 ,FDFDFD7100, FDFDFD7700

thanks a lot fo all your work

Excellent bug report, thank you very much! Together with several few changes from the past days, it deserves a new release!


20201020 -- minor patch fixing a bug in the Dandanator support (the "LD (IY+n),A/B/C" operations must work with any "n" value, instead of just 0: thanks to Spirax for the report) and another one in the CRTC (counter HCC is 8 bits long: "Camembert Meeting 4 Demo" stops showing a line of garbage between the top and the middle panels), adding SDL2_DOUBLE_QUEUE as an optional SDL2 compilation flag (some systems need an audio buffer longer than the default 8 frames) and using a different pixel pattern when both X-Masking and Y-Masking are enabled.

I cannot wait to know more about your ongoing Dandanator-based project, and I hope that this new version will be fully compatible with it.

[cpcitor]

Excellent bug report, thank you very much! Together with several few changes from the past days, it deserves a new release!


20201020 -- minor patch fixing a bug in the Dandanator support (the "LD (IY+n),A/B/C" operations must work with any "n" value, instead of just 0: thanks to Spirax for the report) and another one in the CRTC (counter HCC is 8 bits long: "Camembert Meeting 4 Demo" stops showing a line of garbage between the top and the middle panels), adding SDL2_DOUBLE_QUEUE as an optional SDL2 compilation flag (some systems need an audio buffer longer than the default 8 frames) and using a different pixel pattern when both X-Masking and Y-Masking are enabled.

Hi!

Congrats cngqsoft for the new release!

For the people who prefer to get code and updates via git, I updated the repo on https://github.com/cpcitor/cpcec with the new release.

To get code first time:

Code: [Select]

git clone https://github.com/cpcitor/cpcec
To update:

Code: [Select]

git fetch ; git rebase

[Spirax]

Hello.
Thanks for the new vesrion, I have reverted my code to use ld (iy+1) as I save 4 bytes and some cicles on the routine. I have tested the new version and now is working properly with ld (iy+1), thanks

if I can sugest something for the TODO list.....
whe we released Sword Of Ianna a lot of user requested the posiblity to use snapshots for cardbridges as no any emulator support it.

I have done some test and appear as I can save a snap when I am running a dandanator cardbridge.
BUT in order to load it, you need to follow some procedure....
start the emulator
load the same dandanator cardbridge and start it
then load the snap.sna and on 95% of the cases you recover the game :

there is any posibility to link the snapshot saved to the cardbridge that was loaded when the snapshot was created?

please add this to a future future TODO list, I think someone will need to create a standard snapshot file for cardbridges or a new version of sna with cardbirdge options

on Ianna we only save on the Dandanator cardbridge the preferences, as user can redefine keys and the language selected, so on original CPC we can recover user preferences from dandanator.
on the new game I am looking to implement a quick status save, that will alow the user to save like a check point on the cardbridge on any moment on the game.
it will have passwords to access the different levels, but user can on any moment save the state or reload the previous saved status

After check the code with CPCEC I have added some protections to the routine to check if it was saved to the cardhbridge properly.
so if on real CPC it will report savestatus "Ok", and under emulators than don't support save (yet) it will report savestatus "Fail"
 
so thanks again for the emulator than allow us to test our code better 

Saludos
Spirax

[cngsoft]

Hello.
Thanks for the new vesrion, I have reverted my code to use ld (iy+1) as I save 4 bytes and some cicles on the routine. I have tested the new version and now is working properly with ld (iy+1), thanks

if I can sugest something for the TODO list.....
whe we released Sword Of Ianna a lot of user requested the posiblity to use snapshots for cardbridges as no any emulator support it.

I have done some test and appear as I can save a snap when I am running a dandanator cardbridge.
BUT in order to load it, you need to follow some procedure....
start the emulator
load the same dandanator cardbridge and start it
then load the snap.sna and on 95% of the cases you recover the game :

there is any posibility to link the snapshot saved to the cardbridge that was loaded when the snapshot was created?

please add this to a future future TODO list, I think someone will need to create a standard snapshot file for cardbridges or a new version of sna with cardbirdge options

on Ianna we only save on the Dandanator cardbridge the preferences, as user can redefine keys and the language selected, so on original CPC we can recover user preferences from dandanator.
on the new game I am looking to implement a quick status save, that will alow the user to save like a check point on the cardbridge on any moment on the game.
it will have passwords to access the different levels, but user can on any moment save the state or reload the previous saved status

After check the code with CPCEC I have added some protections to the routine to check if it was saved to the cardhbridge properly.
so if on real CPC it will report savestatus "Ok", and under emulators than don't support save (yet) it will report savestatus "Fail"
 
so thanks again for the emulator than allow us to test our code better 

Saludos
Spirax

What you say touches two topics. On one hand, CPCEC does use a small custom block for Dandanator status at the end of each snapshot, a small 16-byte chunk labelled "DNTR" that includes the last four bytes sent to the configuration ports, plus the last four bytes that are currently in use: the "RET mode" delays the activation of the new configuration bytes, so we need to keep the old ones somewhere. However, as you say, the user still needs to insert the appropriate Dandanator cartridge before loading the snapshot. If no cartridge is present, CPCEC automatically inserts the last known Dandanator cartridge; it isn't a great guess, but it let me play "Sword of Ianna" during several days on two machines (a desktop and a laptop) until I completed it. I'm wary of including paths and filenames within this custom block because nothing keeps the user from moving or renaming cartridges and snapshots, and thus making the included paths and filenames useless.

On the other hand, the Dandanator being able to save data on its own cartridges (Flash EEPROM, isn't it?) is a topic that the official documentation explains poorly and that, for fear of destroying data, I didn't implement; I'll wait for more explicit docs on the matter. The even poorer documentation on Spectrum (right now, all I know is that the ZX Dandanator monitors writes to the lowest 16k page; I have no idea on what those writes mean and do) is the reason why ZXSEC lacks Dandanator support, too.

So as you can see things are still limited and the CPC Dandanator support is restricted to read-only operation, not unlike the Playcity emulation that merely emulates plays and triggers NMIs because they're the only parts I could read about and test.

[Nich]

Is it just me, or has anyone else found a major problem with CPCEC, in that it doesn't save files to disc images?

To test this, reset the CPC, insert a DSK file into drive A, and type in a line in BASIC such as:

Code: [Select]

10 PRINT"Hello world"
Then save it to disc:

Code: [Select]

SAVE"hello"
No error messages like "disc is write protected" appear, and the status display at the bottom left of the screen flashes to indicate that there is disc drive activity.

Now try cataloguing the disc:

Code: [Select]

CAT
In my case, even though there were no error messages, the file has not been saved to the disc image!

cpcec-20201012_test.png
(2.05 kB, 768x536 - viewed 86 times)

I've tested it in both Windows and Linux (under Wine) and this bug occurs in the latest version (20201012) and several previous releases.

[cpcitor]

Is it just me, or has anyone else found a major problem with CPCEC, in that it doesn't save files to disc images?

I've observed this, too, and can reproduce with release 20201012.

Actually, when you press F7 to insert a disk, you can press TAB to show another menu with options "Read Only" and "Read/Write".

If you choose "Read/Write" (it is tricky to know which you actually choose), then you get the expected behavior.

That said, you're right. The default behavior (running cpcec diskimagefilename.dfk) is buggy (no write but no error), the UI is non-discoverable. CPCEC is work in progress, open source and you can contribute. :-)

[Dandare]

On the other hand, the Dandanator being able to save data on its own cartridges (Flash EEPROM, isn't it?) is a topic that the official documentation explains poorly and that, for fear of destroying data, I didn't implement; I'll wait for more explicit docs on the matter. The even poorer documentation on Spectrum (right now, all I know is that the ZX Dandanator monitors writes to the lowest 16k page; I have no idea on what those writes mean and do) is the reason why ZXSEC lacks Dandanator support, too.

Hi, Thanks for supporting the CPC Dandanator in your emulator.
CPC Dandanator documentation includes the Z80 assembler code for erasing a block and writing a block in flash memory. Further documentation on the expected commands can be found on the SST39SF040 datasheet, since the code simply follows the JEDEC commands as defined there. A quick preview of the code:

Code: [Select]

; ---------------------------------------------------------------------------------------- 
; CPC Dandanator! Mini HW v1.2/1.3 - Eeprom Write SST39SF040
;
; Typical Usage ->    LD A, SectN               ; Loop 128 sectors
;               CALL SSTSECTERASE         ;   |
;               LD A, SectN               ;   |
;               LD HL, RAMSOURCE4KBLOCK      ;   |
;               CALL SSTSECTPROG         ;   |
;               JP DDNTRRESET
;
; Dandare - May 2018
; ----------------------------------------------------------------------------------------     


; ----------------------------------------------------------------------------------------
; ERASE SECTOR
;     A  = Sector number (39SF040 has 128 4k sectors)
;
;    ****  MUST BE RUN FROM RAM, DI, AND WITH EXTERNAL EEPROM (ZONE0) PAGED IN in 0x0000
;   ****  NO OTHER ZONE PAGED IN, Commands Enabled
;   ****  Also Write Operations must be enabled and serial operations disabled
;
; ----------------------------------------------------------------------------------------
SSTSECERASE:PUSH AF                  ; Save Sector Number
         AND 3                  ; Get Sector within Page
         SLA A                  ; Move to A13,A12 in DE
.....


On the other hand, there is a specific ZX Dandanator document for emulator implementation that I wrote back in 2016 (Last updated in 2018) that I have distributed to anyone interested in supporting ZX Dandanator in his/her emulator.  This document explains pulse timings, commands types, and technical details on the implementation, focusing on the most relevant aspects to include in an emulator. I'll be happy to share it with you if you are interested.


A sample of this document (In Spanish) is shown below:

Code: [Select]

El ZX Dandanator! Mini recibe comandos de control a través de escrituras en el espacio ROM (0x0000-0x3FFF).
Sin embargo, por compatibilidad futura y soporte de ZesarUX, se le asignan las direcciones comprendidas entre 0x0000 y 0x0003.
 
Estos comandos, que pueden ser simples o múltiples/especiales (más detalle sobre esto luego)
están compuestos una serie de pulsos consecutivos generados por esas escrituras (ld (0x0001),a -  por ejemplo.
El valor de A es ignorado aunque se usa en el emulador ZesarUX).
El HW del Dandanator espera recibir pulsos separados por, al menos 7us y nunca más de 32us,
aunque se recomienda una separación nominal de entre 10 y 15us.
Para determinar el valor del comando enviado, el microcontrolador arranca un timer de 32us en el momento
de recibir cada pulso y, si recibe otro pulso antes de que el timer se complete, va sumando ese pulso a un contador.
Cuando se produce un “timeout”, es decir, cuando pasan 32us sin recibir otro pulso, se consideran los pulsos
contados como el comando recibido. En la imagen siguiente, el comando es “20”. (captura de analizador lógico)
...
Los comandos especiales están conformados por 3 comandos simples consecutivos más un pulso de confirmación.
Deben atender a unos criterios de temporización y direccionamiento estrictos de la siguiente manera:
 
·      Cada comando recibido está sujeto a las mismas normas explicadas con anterioridad sobre la distancia entre pulsos y el timeout.
·      De manera adicional, desde el momento de detección de cada comando (tras su timeout) se dispone de un máximo de 512us
para enviar el siguiente dato del comando especial. Si no se hace, se ignora el comando recibido.
 
·      Por compatibilidad con ZesarUX, el primer byte del comando debe enviarse a la dirección 0x0001,
el segundo a la dirección 0x0002, el tercero a la dirección 0x0003 y el pulso de confirmación,
con cualquier valor en el dato, a la dirección 0x0000.


....




Additionally, the full source code for the PIC microcontroller in the ZX Dandanator is available at the project's homepage, including the "commands.h" file describing all possible received commands.


An excerpt of this commands.h file:

Code: [Select]


// Special Command code to execute (all special commands are 4-steps: Command Code, Command Data 1, Command Data 2, Fast Execute)
// Command Code, Data 1 and Data 2
// Data1, Data2 and Fast Execute MUST be on next consecutive 512us windows to Command (4 windows total). Otherwise Special Command will be ignored
// All data must arrive in pulses separated by at least 8us and no more than 30us.
// Detecting a command is done by timing out the pulses. After 32us without a pulse, the command, consisting in the number of received pulses, is processed.


// COMMANDS :
//---------------------------------------------------------------------------------------
// Command 0    : Not implemented (can't be)
// Command 1-32 : Bank Switch to 0-31 (1-32 pulses)
// Command 33   : Bank Switch to Internal ROM (Internal is recognized as Bank 33)
#define CMD_INTERNALROM_DISABLECMD 34
// Command 34   : Bank Switch to Internal ROM & Disable further Commands
// Command 35   : Reserved
#define CMD_RESET 36
// Command 36   : Generate a Reset
#define CMD_NMI 37
// Command 37   : Generate a NMI
// Command 38   : Reserved
#define CMD_SET_RESETSLOT 39
// Command 39   : Set Reset Slot. Current Slot is selected in case of an Spectrum-Triggered Reset. Cleared on ANY reset (even PIC-Triggered resets).
//--------------------------------------------------------------
#define CMD_SP_FASTCHANGE 40
// Special Command 40   : Fast Change & Action
//                      : Data 1 : Bank Number (1-33,35) - 35 means previous bank   
//                      : Data 2 : Action to perform
//                               : bit 3 - Disable Commands
//                               : bit 2 - Lock Commands   
//                               : bit 1 - NMI
//                               : bit 0 - Reset
//                               : bits 4-7 - Reserved MUST be 0
//--------------------------------------------------------------


[cngsoft]

Is it just me, or has anyone else found a major problem with CPCEC, in that it doesn't save files to disc images?
To test this, reset the CPC, insert a DSK file into drive A, and type in a line in BASIC such as:

Code: [Select]

10 PRINT"Hello world"Then save it to disc:

Code: [Select]

SAVE"hello"No error messages like "disc is write protected" appear, and the status display at the bottom left of the screen flashes to indicate that there is disc drive activity.
Now try cataloguing the disc:

Code: [Select]

CATIn my case, even though there were no error messages, the file has not been saved to the disc image!

I've tested it in both Windows and Linux (under Wine) and this bug occurs in the latest version (20201012) and several previous releases.

I believed I had already answered this question to you in a past email, but I see that I never did. Ah well: CPCEC discards writes by default unless you ask CPCEC to create a disc from the menu, or you insert the disc with F7 (drive A) or Shift-F7 (drive B) and -depending on the Windows version- you disable the "read only" checkbox or you choose "open for writing" on the Open button submenu. Microsoft hid the file dialog options inside the "Open" button after Windows XP, but Wine's implementation keeps the options visible:



The SDL version, as @cpcitor states, provides these options through an extra menu that pops up when hitting TAB.

That being said, I should really consider dividing this dual behavior into three parts:
1.- explicit read-only, writing isn't allowed and triggers Write Protected errors;
2.- implicit read-only, writing isn't allowed but triggers nothing;
3.- explicit read-write, writing is allowed.
Cases 1 and 3 fit regular activity, while case 2 is ideal for protected discs that need the write protection off. I even spoke about it here in this same thread.