Skip to content

Commit

Permalink
Bibliographic references.
Browse files Browse the repository at this point in the history
  • Loading branch information
@redcode
redcode committed Jan 13, 2025
1 parent dbc0778 commit ad14805
Show file tree
Hide file tree
Showing 2 changed files with 56 additions and 56 deletions.
40 changes: 20 additions & 20 deletions THANKS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,22 +5,22 @@ Many thanks to the following individuals (in alphabetical order):
* azesmbog
1. For validating tests on real hardware [1.1].
2. For discovering the unstable behavior of the `ccf/scf` instructions.
3. For testing the `ccf/scf` instructions on real hardware [2,3].
3. For testing the `ccf/scf` instructions on real hardware [2, 3].
4. For his invaluable help.
* Banks, David (hoglet)
1. For deciphering the additional flag changes of the block instructions
[4.1,4.2,5].
2. For his research on the `ccf/scf` instructions [5,6].
[4.1, 4.2, 5].
2. For his research on the `ccf/scf` instructions [5, 6].
* Beliansky, Anatoly (Tolik_Trek)
For validating tests on real hardware [1.2].
* Bobrowski, Jan
For fixing the "Z80 Full Instruction Set Exerciser for Spectrum" [7].
* boo_boo
For deciphering the behavior of MEMPTR [8,9,10,11].
For deciphering the behavior of MEMPTR [8, 9, 10, 11].
* Brady, Stuart
For his research on the `ccf/scf` instructions [12].
* Brewer, Tony
1. For his research on the special RESET [4.3,13].
1. For his research on the special RESET [4.3, 13].
2. For helping to decipher the additional flag changes of the block
instructions [4].
3. For conducting low-level tests on real hardware [4].
Expand All @@ -31,7 +31,7 @@ Many thanks to the following individuals (in alphabetical order):
1. For his corrections to the documentation.
2. For validating tests on real hardware [14].
* Chunin, Roman (CHRV)
For testing the behavior of MEMPTR on real hardware [8,9,10,11].
For testing the behavior of MEMPTR on real hardware [8, 9, 10, 11].
* Conway, Simon (BadBeard)
For validating the "Z80 Test Suite" on several Z80 clones [15].
* Cooke, Simon
Expand All @@ -49,38 +49,38 @@ Many thanks to the following individuals (in alphabetical order):
For his article on Z80 interrupts [19].
* Gimeno Fortea, Pedro
1. For his research work [20].
2. For writing the first-ever ZX Spectrum emulator [21,22].
2. For writing the first-ever ZX Spectrum emulator [21, 22].
* goodboy
For testing the behavior of MEMPTR on real hardware [8,9,10,11].
For testing the behavior of MEMPTR on real hardware [8, 9, 10, 11].
* Greenway, Ian
For testing the `ccf/scf` instructions on real hardware [12,23].
For testing the `ccf/scf` instructions on real hardware [12, 23].
* Harston, Jonathan Graham
1. For his research work.
2. For his technical documents about the Zilog Z80 [24,25,26].
2. For his technical documents about the Zilog Z80 [24, 25, 26].
3. For porting the "Z80 Instruction Set Exerciser" to the ZX Spectrum [27].
* Helcmanovsky, Peter (Ped7g)
1. For helping me to write the "IN-MEMPTR" test.
2. For writing the "Z80 Block Flags Test" [1,28].
2. For writing the "Z80 Block Flags Test" [1, 28].
3. For writing the "Z80 CCF SCF Outcome Stability" test [28].
4. For writing the "Z80 INT Skip" test [28].
5. For his research on the unstable behavior of the `ccf/scf` instructions.
6. For his invaluable help.
* Iborra Debón, Víctor (Eremus)
For validating tests on real hardware.
* icebear
For testing the behavior of MEMPTR on real hardware [8,9,10,11].
For testing the behavior of MEMPTR on real hardware [8, 9, 10, 11].
* ICEknight
For validating tests on real hardware.
* Kladov, Vladimir
For deciphering the behavior of MEMPTR [8,9,10,11].
For deciphering the behavior of MEMPTR [8, 9, 10, 11].
* Krook, Magnus
For validating tests on real hardware [1.3].
* London, Matthew (mattinx)
For validating tests on real hardware.
* Martínez Cantero, Ricardo (Kyp)
For validating tests on real hardware.
* Molodtsov, Aleksandr
For testing the behavior of MEMPTR on real hardware [8,9,10,11].
For testing the behavior of MEMPTR on real hardware [8, 9, 10, 11].
* Nair, Arjun
For validating tests on real hardware [1].
* Nicolás-González, César
Expand All @@ -95,8 +95,8 @@ Many thanks to the following individuals (in alphabetical order):
For his research on the state of the registers after POWER-ON [29].
* Rak, Patrik
1. For improving the "Z80 Instruction Set Exerciser for Spectrum" [30].
2. For deciphering the behavior of the `ccf/scf` instructions [15,30].
3. For writing the "Zilog Z80 CPU Test Suite" [30,31].
2. For deciphering the behavior of the `ccf/scf` instructions [15, 30].
3. For writing the "Zilog Z80 CPU Test Suite" [30, 31].
4. For his research on the unstable behavior of the `ccf/scf` instructions.
* Rodríguez Jódar, Miguel Ángel (mcleod_ideafix)
For his research on the state of the registers after POWER-ON/RESET [32].
Expand All @@ -105,14 +105,14 @@ Many thanks to the following individuals (in alphabetical order):
* Sainz de Baranda y Romero, Manuel
For teaching me programming and giving me my first computer.
* Sánchez Ordiñana, José Ismael (Vaporatorius)
For validating tests on real hardware [31.1,33].
For validating tests on real hardware [31.1, 33].
* Sevillano Mancilla, Marta (TheMartian)
For validating tests on real hardware [14.1].
* Stevenson, Dave
1. For testing the special RESET on real hardware [13].
2. For conducting low-level tests on real hardware [4.4].
* Titov, Andrey (Titus)
For his research on the `ccf/scf` instructions [2,3].
For his research on the `ccf/scf` instructions [2, 3].
* Vučenović, Zoran
For writing the Pascal binding.
* Weissflog, Andre (Floh)
Expand All @@ -122,7 +122,7 @@ Many thanks to the following individuals (in alphabetical order):
* Wilkinson, Oli (evolutional)
For validating tests on real hardware [1].
* Wlodek
For testing the behavior of MEMPTR on real hardware [8,9,10,11].
For testing the behavior of MEMPTR on real hardware [8, 9, 10, 11].
* Woodmass, Mark (Woody)
1. For his invaluable contributions to the emuscene.
2. For writing the "Z80 Test Suite" [15].
Expand All @@ -131,7 +131,7 @@ Many thanks to the following individuals (in alphabetical order):
5. For writing the "EIHALT" test.
* Young, Sean
1. For his research work.
2. For his technical documents about the Zilog Z80 [20,29,37].
2. For his technical documents about the Zilog Z80 [20, 29, 37].
* ZXGuesser
For validating tests on real hardware.

Expand Down
72 changes: 36 additions & 36 deletions sources/Z80.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1525,7 +1525,7 @@ INSN(neg)
| `ccf` and `scf` are the only instructions in which Q affects the flags. |
| Patrik Rak cracked the behavior of YF and XF in 2012, confirming that they |
| are taken, respectively, from bits 5 and 3 of the result of `(Q ^ F) | A` |
| [1,2]. This applies to all Zilog Z80 models, both NMOS and CMOS. In 2018, |
| [1, 2]. This applies to all Zilog Z80 models, both NMOS and CMOS. In 2018, |
| David Banks (AKA hoglet) discovered that at least some ST CMOS models do |
| not set XF according to this formula and instead take this flag from bit 3 |
| of A, whereas NEC NMOS models take both flags from A [3]. |
Expand Down Expand Up @@ -1994,19 +1994,19 @@ INSN(out_vBYTE_a)
}


/*----------------------------------------------------------------------------.
| The `out (c),0` instruction behaves as `out (c),255` on the Zilog Z80 CMOS. |
| This was first discovered by Simon Cooke, who reported it on Usenet in 1996 |
| [1,2]. Later, in 2004, Colin Piggot rediscovered it with his SAM Coupé when |
| running a demo for SCPDU 6, coincidentally written by Simon Cooke [1]. In |
| 2008, this was once again rediscovered by the MSX community [1,3]. |
| |
| References: |
| 1. https://sinclair.wiki.zxnet.co.uk/wiki/Z80 |
| 2. https://groups.google.com/g/comp.os.cpm/c/HfSTFpaIkuU/m/KotvMWu3bZoJ |
| 3. https://msx.org/forum/development/msx-development/bug-z80-emulation-or- |
| tr-hw |
'============================================================================*/
/*-----------------------------------------------------------------------------.
| The `out (c),0` instruction behaves as `out (c),255` on the Zilog Z80 CMOS. |
| This was first discovered by Simon Cooke, who reported it on Usenet in 1996 |
| [1, 2]. Later, in 2004, Colin Piggot rediscovered it with his SAM Coupé when |
| running a demo for SCPDU 6, coincidentally written by Simon Cooke [1]. In |
| 2008, this was once again rediscovered by the MSX community [1, 3]. |
| |
| References: |
| 1. https://sinclair.wiki.zxnet.co.uk/wiki/Z80 |
| 2. https://groups.google.com/g/comp.os.cpm/c/HfSTFpaIkuU/m/KotvMWu3bZoJ |
| 3. https://msx.org/forum/development/msx-development/bug-z80-emulation-or-tr |
| -hw |
'=============================================================================*/

INSN(out_vc_0)
{
Expand Down Expand Up @@ -2286,21 +2286,21 @@ INSN(hook)

/* MARK: - Public Functions */

/*----------------------------------------------------------------------.
| On POWER-ON, the CPU zeroes PC, I and R, sets SP, IX, IY, AF, BC, DE, |
| HL, AF', BC', DE' and HL' to FFFFh [1,2], resets the interrupt enable |
| flip-flops (IFF1 and IFF2) and selects interrupt mode 0 [3]. On Zilog |
| NMOS models, F is sometimes set to FDh (NF reset) [1]. |
| |
| There is no information about the initial state of MEMPTR and Q, so |
| they are assumed to be 0. |
| |
| References: |
| 1. https://baltazarstudios.com/webshare/Z80-undocumented-behavior.htm |
| 2. https://worldofspectrum.org/forums/discussion/34574 |
| 3. Young, Sean (2005-09-18). "Undocumented Z80 Documented, The" |
| v0.91, p. 20. |
'======================================================================*/
/*-----------------------------------------------------------------------.
| On POWER-ON, the CPU zeroes PC, I and R, sets SP, IX, IY, AF, BC, DE, |
| HL, AF', BC', DE' and HL' to FFFFh [1, 2], resets the interrupt enable |
| flip-flops (IFF1 and IFF2) and selects interrupt mode 0 [3]. On Zilog |
| NMOS models, F is sometimes set to FDh (NF reset) [1]. |
| |
| There is no information about the initial state of MEMPTR and Q, so |
| they are assumed to be 0. |
| |
| References: |
| 1. https://baltazarstudios.com/webshare/Z80-undocumented-behavior.htm |
| 2. https://worldofspectrum.org/forums/discussion/34574 |
| 3. Young, Sean (2005-09-18). "Undocumented Z80 Documented, The" v0.91, |
| p. 20. |
'=======================================================================*/

Z80_API void z80_power(Z80 *self, zboolean state)
{
Expand All @@ -2313,9 +2313,9 @@ Z80_API void z80_power(Z80 *self, zboolean state)


/*-------------------------------------------------------------------------.
| The normal RESET zeroes PC, I, and R [1,2,3,4,5,6], resets the interrupt |
| enable flip-flops (IFF1 and IFF2) [1,2,3,4,5] and selects interrupt mode |
| 0 [1,2,3,4,7]. |
| The normal RESET zeroes PC, I, and R [1, 2, 3, 4, 5, 6], resets the |
| interrupt enable flip-flops (IFF1 and IFF2) [1, 2, 3, 4, 5] and selects |
| interrupt mode 0 [1, 2, 3, 4, 7]. |
| |
| References: |
| 1. Zilog (2016-09). "Z80 CPU User Manual" rev. 11, p. 6. |
Expand Down Expand Up @@ -2512,7 +2512,7 @@ Z80_API zusize z80_run(Z80 *self, zusize cycles)
| simulations [3]. |
| |
| In 2022, Manuel Sainz de Baranda y Goñi discovered that the CPU does not |
| accept a second NMI during the NMI response [4,5]. Therefore, it is not |
| accept a second NMI during the NMI response [4, 5]. Therefore, it is not |
| possible to chain two NMI responses in a row without executing at least |
| one instruction between them [3]. |
| |
Expand Down Expand Up @@ -2562,7 +2562,7 @@ Z80_API zusize z80_run(Z80 *self, zusize cycles)
| not accept the maskable interrupt if IFF1 and IFF2 do not have the same |
| state prior to the execution of the instruction, which can only be |
| caused by an earlier NMI response [1]. This behavior was rediscovered in |
| 2022 by Manuel Sainz de Baranda y Goñi [2,3]. |
| 2022 by Manuel Sainz de Baranda y Goñi [2, 3]. |
| |
| References: |
| 1. Weissflog, Andre (2021-12-17). "New Cycle-Stepped Z80 Emulator, A". |
Expand Down Expand Up @@ -2637,10 +2637,10 @@ Z80_API zusize z80_run(Z80 *self, zusize cycles)
| the instruction is fetched [1]. Each INTA M-cycle takes as many T-states |
| as its normal M1 counterpart (the opcode fetch M-cycle) plus the 2 wait |
| T-states mentioned above [1]. Subsequent bytes of the instruction are |
| fetched by using normal memory read M-cycles [1,2], during which the |
| fetched by using normal memory read M-cycles [1, 2], during which the |
| interrupting I/O device must still supply the data [2]. The PC register, |
| however, remains at its pre-interrupt state, not being incremented as a |
| result of the instruction fetch [1,2]. |
| result of the instruction fetch [1, 2]. |
| |
| References: |
| 1. Checked with "Visual Z80 Remix". |
Expand Down

0 comments on commit ad14805

Please sign in to comment.