I'm back again and tried things with your MZ800 emulator.
Now the SDL oddity is solved (thanks), I investigated the behaviour of the CMT and the monitor
program, when it enters the file loading routines.
I am in MZ800 mode.
First thing I recognized is that there is no screen output of PLAY (or RECORD.PLAY) after the
monitor loading command L is hit.
(Likewise, in BASIC, there is also no output of PLAY.)
I think this should happen, as is with the original device.
The loading with and without CMT hack works, of course, but I look for as best similarity with the
original behaviour as possible...
I disassembled the monitor ROM with IDApro.
It seems that the following ROM code is not executed as expected:
ROM:069F ; =============== S U B R O U T I N E =======================================
ROM:069F
ROM:069F
ROM:069F sub_69F: ; CODE XREF: sub_436+11↑p
ROM:069F ; sub_4D8:loc_4E6↑p ...
ROM:069F C5 push bc
ROM:06A0 D5 push de
ROM:06A1 E5 push hl
ROM:06A2 06 0A ld b, 0Ah
ROM:06A4
ROM:06A4 loc_6A4: ; CODE XREF: sub_69F+22↓j
ROM:06A4 3A 02 E0 ld a, (byte_E002) # in MZ700 mode addr of PIO8255 port
C (sound,CMT,timer,CRT)
ROM:06A7 E6 10 and 10h # in port PC4, Checks the cassette motor
ROM:06A9 28 0E jr z, loc_6B9 #-->PLAY or RECORD.PLAY
ROM:06AB
ROM:06AB loc_6AB: ; CODE XREF: sub_69F+3E↓j
ROM:06AB 06 FF ld b, 0FFh
ROM:06AD
ROM:06AD loc_6AD: ; CODE XREF: sub_69F:loc_6B4↓j
ROM:06AD CD 96 09 call sub_996
ROM:06B0 18 02 jr loc_6B4
ROM:06B2 ; ---------------------------------------------------------------------------
ROM:06B2 18 EB jr sub_69F
ROM:06B4 ; ---------------------------------------------------------------------------
ROM:06B4
ROM:06B4 loc_6B4: ; CODE XREF: sub_69F+11↑j
ROM:06B4 10 F7 djnz loc_6AD
ROM:06B6 AF xor a
ROM:06B7
ROM:06B7 loc_6B7: ; CODE XREF: sub_69F+46↓j
ROM:06B7 18 E2 jr loc_69B
ROM:06B9 ; ---------------------------------------------------------------------------
ROM:06B9
ROM:06B9 loc_6B9: ; CODE XREF: sub_69F+A↑j
ROM:06B9 3E 06 ld a, 6
ROM:06BB 21 03 E0 ld hl, 0E003h # in MZ700 mode addr of PIO8255 port
D (Control port)
ROM:06BE 77 ld (hl), a
ROM:06BF 3C inc a
ROM:06C0 77 ld (hl), a
ROM:06C1 10 E1 djnz loc_6A4
ROM:06C3 CD 09 00 call sub_9
ROM:06C6 7A ld a, d
ROM:06C7 FE D7 cp 0D7h
ROM:06C9 28 05 jr z, loc_6D0
ROM:06CB 11 FB 03 ld de, 3FBh # + PLAY
ROM:06CE 18 07 jr loc_6D7
ROM:06D0 ; ---------------------------------------------------------------------------
ROM:06D0
ROM:06D0 loc_6D0: ; CODE XREF: sub_69F+2A↑j
ROM:06D0 11 02 04 ld de, 402h # + RECORD
ROM:06D3 DF rst 18h
ROM:06D4 11 FD 03 ld de, 3FDh # PLAY
ROM:06D7
ROM:06D7 loc_6D7: ; CODE XREF: sub_69F+2F↑j
ROM:06D7 DF rst 18h
ROM:06D8
ROM:06D8 loc_6D8: ; CODE XREF: sub_69F+43↓j
ROM:06D8 3A 02 E0 ld a, (byte_E002)
ROM:06DB E6 10 and 10h
ROM:06DD 20 CC jr nz, loc_6AB
ROM:06DF CD 32 0A call sub_A32
ROM:06E2 20 F4 jr nz, loc_6D8
ROM:06E4 37 scf
ROM:06E5 18 D0 jr loc_6B7
ROM:06E5 ; End of function sub_69F
It looks like as if something with the mapped address 0xE002 is not right, where the 8255
Programmable Peripheral Interface port C is mapped.
A memdump shows that after startup, the address reads typically as 0x15, i.e. input port PC4 (checks
the cassette motor) is 1.
So the emulator thinks the motor is already running and therefore PLAY is never displayed??
Unfortunately, I was not able to figure out how and what is different in the C code of pio8255.c,
cmt.c or mz800.c.
Maybe you have an idea?
Again, I really enjou your program, and I would be happy if my report helps you improving the emulator.
Thank you and kind regards,
Guntram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this behavior that you describe is a special (hack) feature that may that might deserve a little better solution.
Signal state of CMT motor is in MZ-800 presented in PC4 gate of 8255.
Hardware MZ-821 has intergrated controllable casette tape recorder. Motor state is presented as 0 or 1 on PC4 of 8255.
Hardware MZ-811 using only external CMT and PC4 is permanently bypassed in "motor running state".
Both behavior can be easily emulated, but first versions of mz800emu emulator had integrated only fast cmt hack method with default MZ-811 bypas cause a jam during load of few less known games.
Therefore is now motor state of PC4 on 8255 changed in special
changing mode. The behavior simply favors poorly written programs and we have emulated strange combination of MZ811 and MZ821.
I am playing with your new release (revision 218), and enjoy again the world of MZ800.
Meanwhile I have found the bug in pio8255.c, that troubled me (see my post from February 2021).
The problem is, that for CMT, there is neither a "PLAY" nor a "RECORD PLAY" displayed on sreen upon file load or record.
Now, a closer look into pio8255.c, line 228, reveals the reason.
Line 228 is:
g_pio8255.signal_pc03 = value & 0x01;
but should be:
g_pio8255.signal_pc03 = ( value >> 3 ) & 0x01;
If one changes line 228 accordingly, the ROM code (e-g. monitor command L) as well as the BASIC interpreter (LOAD) now show
the "arrow down symbol, followed by PLAY", or in case of the BASIC command SAVE, "arrow down, followed by RECORD.PLAY", as it should.
One should change line 218 in the samde way:
pio8255_set_pc01 ( value & 0x01 );
should become
pio8255_set_pc01 ( (value >> 1) & 0x01 );
(compare with line 167, where it is correct.)
Probably also line 222, which is
g_pio8255.signal_pc02 = value & 0x01;
should be
g_pio8255.signal_pc02 = (value >> 2) & 0x01;
But I do not have a test case for that, and also not enough insight here.
Maybe you can give it a try?
Another question is, how the record function in the Virtual CMT can write files, e.g. when you type the BASIC command SAVE "TEST123".
The file name is not determined by the BASIC line.
Kind regards,
Guntram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please read my answer from 2021-02-17 - emulated signal of CMT engine status has intentionally different behavior. This behavior caters for a some bad writen MZ-800 programs at the expense of HW emulation accuracy.
Your pio8255 patch may have some side effect to which the ROM responds by displaying "PLAY", but definitely is not in accordance with pio8255 documentation:
bit 7 - value 0 activate Bit SET/RESET mode
bit 6 downto 4 - is not used in this mode
bit 3 downto 1 - bit number for operation SET/RESET
bit 0 - operation 0: RESET, 1: SET
To your second question - Virtual CMT supports write only into WAV:
1) open virtual CMT
2) click to red button (Open file for recording)
3) into text input field write name of your new WAV file and click to Open - CMT is now recording
4) make SAVE from MZ-800 and when is done so click to Stop button in Virtual CMT
Your new WAV file is now created and may be readed back, or converted to MZF by any external tool.
If your WAV contains the standard MZ-800 format at any speed, you can use for example my CMTTOOL program to convert to MZF - https://www.ordoz.com/sharp/cmttool/v1.0/
RAR file is precompiled windows binary and TGZ contains source.
Best regards, Michal
Last edit: Michal Hucik 2021-12-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to update code and carefully abide the difference between virtual CMT mode and CMT hack mode. Now is in virtual CMT implemented CMT engine control via i8255.
Improvements are currently only available in SVN (since revision 222).
Dear Michal,
I'm back again and tried things with your MZ800 emulator.
Now the SDL oddity is solved (thanks), I investigated the behaviour of the CMT and the monitor
program, when it enters the file loading routines.
I am in MZ800 mode.
First thing I recognized is that there is no screen output of PLAY (or RECORD.PLAY) after the
monitor loading command L is hit.
(Likewise, in BASIC, there is also no output of PLAY.)
I think this should happen, as is with the original device.
The loading with and without CMT hack works, of course, but I look for as best similarity with the
original behaviour as possible...
I disassembled the monitor ROM with IDApro.
It seems that the following ROM code is not executed as expected:
...
ROM:03FB 7F 20 50 4C+aPlay: .ascii ' PLAY\r'
ROM:0402 7F 20 52 45+aRecord: .ascii ' RECORD.\r'
...
ROM:069F ; =============== S U B R O U T I N E =======================================
ROM:069F
ROM:069F
ROM:069F sub_69F: ; CODE XREF: sub_436+11↑p
ROM:069F ; sub_4D8:loc_4E6↑p ...
ROM:069F C5 push bc
ROM:06A0 D5 push de
ROM:06A1 E5 push hl
ROM:06A2 06 0A ld b, 0Ah
ROM:06A4
ROM:06A4 loc_6A4: ; CODE XREF: sub_69F+22↓j
ROM:06A4 3A 02 E0 ld a, (byte_E002) # in MZ700 mode addr of PIO8255 port
C (sound,CMT,timer,CRT)
ROM:06A7 E6 10 and 10h # in port PC4, Checks the cassette motor
ROM:06A9 28 0E jr z, loc_6B9 #-->PLAY or RECORD.PLAY
ROM:06AB
ROM:06AB loc_6AB: ; CODE XREF: sub_69F+3E↓j
ROM:06AB 06 FF ld b, 0FFh
ROM:06AD
ROM:06AD loc_6AD: ; CODE XREF: sub_69F:loc_6B4↓j
ROM:06AD CD 96 09 call sub_996
ROM:06B0 18 02 jr loc_6B4
ROM:06B2 ; ---------------------------------------------------------------------------
ROM:06B2 18 EB jr sub_69F
ROM:06B4 ; ---------------------------------------------------------------------------
ROM:06B4
ROM:06B4 loc_6B4: ; CODE XREF: sub_69F+11↑j
ROM:06B4 10 F7 djnz loc_6AD
ROM:06B6 AF xor a
ROM:06B7
ROM:06B7 loc_6B7: ; CODE XREF: sub_69F+46↓j
ROM:06B7 18 E2 jr loc_69B
ROM:06B9 ; ---------------------------------------------------------------------------
ROM:06B9
ROM:06B9 loc_6B9: ; CODE XREF: sub_69F+A↑j
ROM:06B9 3E 06 ld a, 6
ROM:06BB 21 03 E0 ld hl, 0E003h # in MZ700 mode addr of PIO8255 port
D (Control port)
ROM:06BE 77 ld (hl), a
ROM:06BF 3C inc a
ROM:06C0 77 ld (hl), a
ROM:06C1 10 E1 djnz loc_6A4
ROM:06C3 CD 09 00 call sub_9
ROM:06C6 7A ld a, d
ROM:06C7 FE D7 cp 0D7h
ROM:06C9 28 05 jr z, loc_6D0
ROM:06CB 11 FB 03 ld de, 3FBh # + PLAY
ROM:06CE 18 07 jr loc_6D7
ROM:06D0 ; ---------------------------------------------------------------------------
ROM:06D0
ROM:06D0 loc_6D0: ; CODE XREF: sub_69F+2A↑j
ROM:06D0 11 02 04 ld de, 402h # + RECORD
ROM:06D3 DF rst 18h
ROM:06D4 11 FD 03 ld de, 3FDh # PLAY
ROM:06D7
ROM:06D7 loc_6D7: ; CODE XREF: sub_69F+2F↑j
ROM:06D7 DF rst 18h
ROM:06D8
ROM:06D8 loc_6D8: ; CODE XREF: sub_69F+43↓j
ROM:06D8 3A 02 E0 ld a, (byte_E002)
ROM:06DB E6 10 and 10h
ROM:06DD 20 CC jr nz, loc_6AB
ROM:06DF CD 32 0A call sub_A32
ROM:06E2 20 F4 jr nz, loc_6D8
ROM:06E4 37 scf
ROM:06E5 18 D0 jr loc_6B7
ROM:06E5 ; End of function sub_69F
It looks like as if something with the mapped address 0xE002 is not right, where the 8255
Programmable Peripheral Interface port C is mapped.
A memdump shows that after startup, the address reads typically as 0x15, i.e. input port PC4 (checks
the cassette motor) is 1.
So the emulator thinks the motor is already running and therefore PLAY is never displayed??
Unfortunately, I was not able to figure out how and what is different in the C code of pio8255.c,
cmt.c or mz800.c.
Maybe you have an idea?
Again, I really enjou your program, and I would be happy if my report helps you improving the emulator.
Thank you and kind regards,
Guntram
Hi Guntram,
this behavior that you describe is a special (hack) feature that may that might deserve a little better solution.
Signal state of CMT motor is in MZ-800 presented in PC4 gate of 8255.
Hardware MZ-821 has intergrated controllable casette tape recorder. Motor state is presented as 0 or 1 on PC4 of 8255.
Hardware MZ-811 using only external CMT and PC4 is permanently bypassed in "motor running state".
Both behavior can be easily emulated, but first versions of mz800emu emulator had integrated only fast cmt hack method with default MZ-811 bypas cause a jam during load of few less known games.
Therefore is now motor state of PC4 on 8255 changed in special
changing mode. The behavior simply favors poorly written programs and we have emulated strange combination of MZ811 and MZ821.
State of PC4 is changed here:
https://sourceforge.net/p/mz800emu/code/HEAD/tree/trunk/src/pio8255/pio8255.c#l179
...or here:
https://sourceforge.net/p/mz800emu/code/HEAD/tree/trunk/src/pio8255/pio8255.c#l228
And read is here:
https://sourceforge.net/p/mz800emu/code/HEAD/tree/trunk/src/pio8255/pio8255.c#l494
Regards, Michal
Dear Michal,
I am playing with your new release (revision 218), and enjoy again the world of MZ800.
Meanwhile I have found the bug in pio8255.c, that troubled me (see my post from February 2021).
The problem is, that for CMT, there is neither a "PLAY" nor a "RECORD PLAY" displayed on sreen upon file load or record.
Now, a closer look into pio8255.c, line 228, reveals the reason.
Line 228 is:
g_pio8255.signal_pc03 = value & 0x01;
but should be:
g_pio8255.signal_pc03 = ( value >> 3 ) & 0x01;
If one changes line 228 accordingly, the ROM code (e-g. monitor command L) as well as the BASIC interpreter (LOAD) now show
the "arrow down symbol, followed by PLAY", or in case of the BASIC command SAVE, "arrow down, followed by RECORD.PLAY", as it should.
One should change line 218 in the samde way:
pio8255_set_pc01 ( value & 0x01 );
should become
pio8255_set_pc01 ( (value >> 1) & 0x01 );
(compare with line 167, where it is correct.)
Probably also line 222, which is
g_pio8255.signal_pc02 = value & 0x01;
should be
g_pio8255.signal_pc02 = (value >> 2) & 0x01;
But I do not have a test case for that, and also not enough insight here.
Maybe you can give it a try?
Another question is, how the record function in the Virtual CMT can write files, e.g. when you type the BASIC command SAVE "TEST123".
The file name is not determined by the BASIC line.
Kind regards,
Guntram
Hi Guntram,
please read my answer from 2021-02-17 - emulated signal of CMT engine status has intentionally different behavior. This behavior caters for a some bad writen MZ-800 programs at the expense of HW emulation accuracy.
Your pio8255 patch may have some side effect to which the ROM responds by displaying "PLAY", but definitely is not in accordance with pio8255 documentation:
bit 7 - value 0 activate Bit SET/RESET mode
bit 6 downto 4 - is not used in this mode
bit 3 downto 1 - bit number for operation SET/RESET
bit 0 - operation 0: RESET, 1: SET
To your second question - Virtual CMT supports write only into WAV:
1) open virtual CMT
2) click to red button (Open file for recording)
3) into text input field write name of your new WAV file and click to Open - CMT is now recording
4) make SAVE from MZ-800 and when is done so click to Stop button in Virtual CMT
Your new WAV file is now created and may be readed back, or converted to MZF by any external tool.
If your WAV contains the standard MZ-800 format at any speed, you can use for example my CMTTOOL program to convert to MZF - https://www.ordoz.com/sharp/cmttool/v1.0/
RAR file is precompiled windows binary and TGZ contains source.
Best regards, Michal
Last edit: Michal Hucik 2021-12-29
Hello,
I tried to update code and carefully abide the difference between virtual CMT mode and CMT hack mode. Now is in virtual CMT implemented CMT engine control via i8255.
Improvements are currently only available in SVN (since revision 222).
You can try to download the compiled snapshot of revision 222 - https://www.ordoz.com/mz800emu/snapshot/2022-02-09_rev222/
Michal