libretro/mame2003-plus-libretro
1
0
Fork 0
mirror of https://github.com/libretro/mame2003-plus-libretro.git synced 2024-11-23 00:09:44 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

normalize line endings (#1010)

Browse Source 
* normalize line endings

* line endings
This commit is contained in:
markwkidd 2021-04-05 12:19:09 -04:00 committed by GitHub
parent 1eeb9c935c
commit 85d13aa3dc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 281935 additions and 281935 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1384
CHANGELOG.md
View File

File diff suppressed because it is too large Load Diff

214
LICENSE.md
View File

@ -1,107 +1,107 @@
# MAME 2003-Plus License
#### MAME - Multiple Arcade Machine Emulator
Copyright (C) 1997-2003 by Nicola Salmoria and The MAME Team, Copyright (C)2003-2018 by the Libretro MAME 2003 Team and Copyright (C)2017-2018 by the Libretro MAME 2003-Plus Team. Backports from other versions of MAME are as noted in individual source files.
Many people have helped with this project--directly, or by releasing the source code for the drivers they have written. We are not trying to take credit that isn't ours. See the **Acknowledgments** section for a list of contributors. Please note, however, that the list is incomplete. Also see the comments in the source code to see the people who contributed to specific drivers. That list, too, may be incomplete. We apologize for any omission.
MAME 2003-Plus is licensed under the classic MAME Non-Commercial license and specifically the license of MAME 0.78 unless specifically stated otherwise by individual source files.
All trademarks cited in this document are property of their respective owners.
## MAME 0.78 Usage and Distribution License
### I. Purpose
MAME is strictly a non-profit project. Its main purpose is to be a reference to the inner workings of the emulated arcade machines. This is done for educational purposes and to prevent many historical games from sinking into oblivion once the hardware they run on stops working. Of course to preserve the games, you must also be able to actually play them; you can consider that a nice side effect.
It is not our intention to infringe on any copyrights or patents on the original games. All of MAME's source code is either our own or freely available. To operate, the emulator requires images of the original ROMs from the arcade machines, which must be provided by the user. No portions of the original ROM codes are included in the executable.
-------------------------
### II. Cost
MAME is free. Its source code is free. Selling either is not allowed.
-------------------------
### III. ROM Images
ROM images are copyrighted material. Most of them cannot be distributed freely. Distribution of MAME on the same physical medium as illegal copies of ROM images is strictly forbidden.
You are not allowed to distribute MAME in any form if you sell, advertise, or publicize CD-ROMs or other media containing illegal copies of ROM images. This restriction applies even if you don't make money, directly or indirectly, from those activities. You are allowed to make ROMs and MAME available for download on the same website, but only if you warn users about the ROMs's copyright status, and make it clear that users must not download ROMs unless they are legally entitled to do so.
-------------------------
### IV. Source Code Distribution
If you distribute the binary (compiled) version of MAME, you should also distribute the source code. If you can't do that, you must provide a link to a site where the source can be obtained.
-------------------------
### V. Distribution Integrity
This chapter applies to the official MAME distribution. See below for limitations on the distribution of derivative works. MAME must be distributed only in the original archives. You are not allowed to distribute a modified version, nor to remove and/or add files to the archive.
-------------------------
### VI. Reuse of Source Code
This chapter might not apply to specific portions of MAME (e.g. CPU emulators) which bear different copyright notices. The source code cannot be used in a commercial product without the written authorization of the authors. Use in non-commercial products is allowed, and indeed encouraged. If you use portions of the MAME source code in your program, however, you must make the full source code freely available as well.
Usage of the _information_ contained in the source code is free for any use. However, given the amount of time and energy it took to collect this information, if you find new information we would appreciate if you made it freely available as well.
-------------------------
### VII. Derivative Works
Derivative works are allowed, provided their source code is freely available. However, these works are discouraged. MAME is a continuously-evolving project. It is in your best interests to submit your contributions to the MAME development team, so they may be integrated into the main distribution.
There are some specific modifications to the source code which go against the spirit of the project. They are NOT considered a derivative work, and distribution of executables containing them is strictly forbidden. Such modifications include, but are not limited to:
- enabling games that are disabled
- changing the ROM verification commands so that they report missing games
- removing the startup information screens
If you make a derivative work, you are not allowed to call it MAME. You must use a different name to make clear that it is a MAME derivative, not an official distribution from the MAME team. Simply calling it MAME followed or preceded by a punctuation mark (e.g. MAME+) is not sufficient. The name must be clearly distinct (e.g. REMAME). The version number must also match the number of the official MAME version from which you derived your version.
-------------------------
## MAME 0.78 Acknowledgments
First of all, thanks to Allard van der Bas (avdbas@wi.leidenuniv.nl) for starting the Arcade Emulation Programming Repository at http://valhalla.ph.tn.tudelft.nl/emul8
Without the Repository, I would never have even tried to write an emulator. Unfortunately, the original Repository is now closed, but its spirit lives on in MAME.
* Z80 emulator Copyright (c) 1998 Juergen Buchmueller, all rights reserved.
* M6502 emulator Copyright (c) 1998 Juergen Buchmueller, all rights reserved.
* Hu6280 Copyright (c) 1999 Bryan McPhail, mish@tendril.force9.net
* I86 emulator by David Hedley, modified by Fabrice Frances (frances@ensica.fr)
* M6809 emulator by John Butler, based on L.C. Benschop's 6809 Simulator V09.
* M6808 based on L.C. Benschop's 6809 Simulator V09.
* M68000 emulator Copyright 1999 Karl Stenerud. All rights reserved.
* 80x86 M68000 emulator Copyright 1998, Mike Coates, Darren Olafson.
* 8039 emulator by Mirko Buffoni, based on 8048 emulator by Dan Boris.
* T-11 emulator Copyright (C) Aaron Giles 1998
* TMS34010 emulator by Alex Pasadyn and Zsolt Vasvari.
* TMS9900 emulator by Andy Jones, based on original code by Ton Brouwer.
* Cinematronics CPU emulator by Jeff Mitchell, Zonn Moore, Neil Bradley.
* Atari AVG/DVG emulation based on VECSIM by Hedley Rainnie, Eric Smith and Al Kossow.
* TMS5220 emulator by Frank Palazzolo.
* AY-3-8910 emulation based on various code snippets by Ville Hallik, Michael Cuddy, Tatsuyuki Satoh, Fabrice Frances, Nicola Salmoria.
* YM-2203, YM-2151, YM3812 emulation by Tatsuyuki Satoh.
* POKEY emulator by Ron Fries.
* Many thanks to Eric Smith, Hedley Rainnie and Sean Trowbridge for information on the Pokey random number generator.
* NES sound hardware info by Matthew Conte.
* YM2610 emulation by Hiromitsu Shioya.
* Background art by Peter Hirschberg (PeterH@cronuscom.com).
* Allegro library by Shawn Hargreaves, 1994/97
* SEAL Synthetic Audio Library API Interface Copyright (C) 1995, 1996 Carlos Hasan. All Rights Reserved.
* Video modes created using Tweak 1.6b by Robert Schmidt, who also wrote TwkUser.c.
* "inflate" code for zip file support by Mark Adler.
* DOS executable compressed with UPX by Markus F.X.J. Oberhumer & Laszlo Molnar, http://upx.sourceforge.net/
* Big thanks to Gary Walton (garyw@excels-w.demon.co.uk) for too many things to mention.
* Thanks to Brian Deuel, Neil Bradley, and the Retrocade dev team for allowing us to use Retrocade's game history database.
* Thanks to Richard Bush for info on several games.
* Thanks to Dave (www.finalburn.com) for info on After Burner.
and thanks to everyone else I forgot.
# MAME 2003-Plus License
#### MAME - Multiple Arcade Machine Emulator
Copyright (C) 1997-2003 by Nicola Salmoria and The MAME Team, Copyright (C)2003-2018 by the Libretro MAME 2003 Team and Copyright (C)2017-2018 by the Libretro MAME 2003-Plus Team. Backports from other versions of MAME are as noted in individual source files.
Many people have helped with this project--directly, or by releasing the source code for the drivers they have written. We are not trying to take credit that isn't ours. See the **Acknowledgments** section for a list of contributors. Please note, however, that the list is incomplete. Also see the comments in the source code to see the people who contributed to specific drivers. That list, too, may be incomplete. We apologize for any omission.
MAME 2003-Plus is licensed under the classic MAME Non-Commercial license and specifically the license of MAME 0.78 unless specifically stated otherwise by individual source files.
All trademarks cited in this document are property of their respective owners.
## MAME 0.78 Usage and Distribution License
### I. Purpose
MAME is strictly a non-profit project. Its main purpose is to be a reference to the inner workings of the emulated arcade machines. This is done for educational purposes and to prevent many historical games from sinking into oblivion once the hardware they run on stops working. Of course to preserve the games, you must also be able to actually play them; you can consider that a nice side effect.
It is not our intention to infringe on any copyrights or patents on the original games. All of MAME's source code is either our own or freely available. To operate, the emulator requires images of the original ROMs from the arcade machines, which must be provided by the user. No portions of the original ROM codes are included in the executable.
-------------------------
### II. Cost
MAME is free. Its source code is free. Selling either is not allowed.
-------------------------
### III. ROM Images
ROM images are copyrighted material. Most of them cannot be distributed freely. Distribution of MAME on the same physical medium as illegal copies of ROM images is strictly forbidden.
You are not allowed to distribute MAME in any form if you sell, advertise, or publicize CD-ROMs or other media containing illegal copies of ROM images. This restriction applies even if you don't make money, directly or indirectly, from those activities. You are allowed to make ROMs and MAME available for download on the same website, but only if you warn users about the ROMs's copyright status, and make it clear that users must not download ROMs unless they are legally entitled to do so.
-------------------------
### IV. Source Code Distribution
If you distribute the binary (compiled) version of MAME, you should also distribute the source code. If you can't do that, you must provide a link to a site where the source can be obtained.
-------------------------
### V. Distribution Integrity
This chapter applies to the official MAME distribution. See below for limitations on the distribution of derivative works. MAME must be distributed only in the original archives. You are not allowed to distribute a modified version, nor to remove and/or add files to the archive.
-------------------------
### VI. Reuse of Source Code
This chapter might not apply to specific portions of MAME (e.g. CPU emulators) which bear different copyright notices. The source code cannot be used in a commercial product without the written authorization of the authors. Use in non-commercial products is allowed, and indeed encouraged. If you use portions of the MAME source code in your program, however, you must make the full source code freely available as well.
Usage of the _information_ contained in the source code is free for any use. However, given the amount of time and energy it took to collect this information, if you find new information we would appreciate if you made it freely available as well.
-------------------------
### VII. Derivative Works
Derivative works are allowed, provided their source code is freely available. However, these works are discouraged. MAME is a continuously-evolving project. It is in your best interests to submit your contributions to the MAME development team, so they may be integrated into the main distribution.
There are some specific modifications to the source code which go against the spirit of the project. They are NOT considered a derivative work, and distribution of executables containing them is strictly forbidden. Such modifications include, but are not limited to:
- enabling games that are disabled
- changing the ROM verification commands so that they report missing games
- removing the startup information screens
If you make a derivative work, you are not allowed to call it MAME. You must use a different name to make clear that it is a MAME derivative, not an official distribution from the MAME team. Simply calling it MAME followed or preceded by a punctuation mark (e.g. MAME+) is not sufficient. The name must be clearly distinct (e.g. REMAME). The version number must also match the number of the official MAME version from which you derived your version.
-------------------------
## MAME 0.78 Acknowledgments
First of all, thanks to Allard van der Bas (avdbas@wi.leidenuniv.nl) for starting the Arcade Emulation Programming Repository at http://valhalla.ph.tn.tudelft.nl/emul8
Without the Repository, I would never have even tried to write an emulator. Unfortunately, the original Repository is now closed, but its spirit lives on in MAME.
* Z80 emulator Copyright (c) 1998 Juergen Buchmueller, all rights reserved.
* M6502 emulator Copyright (c) 1998 Juergen Buchmueller, all rights reserved.
* Hu6280 Copyright (c) 1999 Bryan McPhail, mish@tendril.force9.net
* I86 emulator by David Hedley, modified by Fabrice Frances (frances@ensica.fr)
* M6809 emulator by John Butler, based on L.C. Benschop's 6809 Simulator V09.
* M6808 based on L.C. Benschop's 6809 Simulator V09.
* M68000 emulator Copyright 1999 Karl Stenerud. All rights reserved.
* 80x86 M68000 emulator Copyright 1998, Mike Coates, Darren Olafson.
* 8039 emulator by Mirko Buffoni, based on 8048 emulator by Dan Boris.
* T-11 emulator Copyright (C) Aaron Giles 1998
* TMS34010 emulator by Alex Pasadyn and Zsolt Vasvari.
* TMS9900 emulator by Andy Jones, based on original code by Ton Brouwer.
* Cinematronics CPU emulator by Jeff Mitchell, Zonn Moore, Neil Bradley.
* Atari AVG/DVG emulation based on VECSIM by Hedley Rainnie, Eric Smith and Al Kossow.
* TMS5220 emulator by Frank Palazzolo.
* AY-3-8910 emulation based on various code snippets by Ville Hallik, Michael Cuddy, Tatsuyuki Satoh, Fabrice Frances, Nicola Salmoria.
* YM-2203, YM-2151, YM3812 emulation by Tatsuyuki Satoh.
* POKEY emulator by Ron Fries.
* Many thanks to Eric Smith, Hedley Rainnie and Sean Trowbridge for information on the Pokey random number generator.
* NES sound hardware info by Matthew Conte.
* YM2610 emulation by Hiromitsu Shioya.
* Background art by Peter Hirschberg (PeterH@cronuscom.com).
* Allegro library by Shawn Hargreaves, 1994/97
* SEAL Synthetic Audio Library API Interface Copyright (C) 1995, 1996 Carlos Hasan. All Rights Reserved.
* Video modes created using Tweak 1.6b by Robert Schmidt, who also wrote TwkUser.c.
* "inflate" code for zip file support by Mark Adler.
* DOS executable compressed with UPX by Markus F.X.J. Oberhumer & Laszlo Molnar, http://upx.sourceforge.net/
* Big thanks to Gary Walton (garyw@excels-w.demon.co.uk) for too many things to mention.
* Thanks to Brian Deuel, Neil Bradley, and the Retrocade dev team for allowing us to use Retrocade's game history database.
* Thanks to Richard Bush for info on several games.
* Thanks to Dave (www.finalburn.com) for info on After Burner.
and thanks to everyone else I forgot.

559660
metadata/history.dat
View File

File diff suppressed because it is too large Load Diff

222
src/cpu/i86/i86.txt
View File

@ -1,111 +1,111 @@
intel 8086 and compatibles
--------------------------
this info is here,
to list and give some remarks on all 8086 compatible processors
excellent info in Hamarsoft's 86BUGS list
(also distributed in ralf browns interrupt list)
8086/8088
---------
20 bit adress bus, 16 bit data bus and registers
many 8080 assembler sources should be compilable/reusable
8086
----
6 bytes prefetch queue
8088
----
8086 with 8 bit data bus,
prefetch queue only 4 byte, and refilled when 1 byte empty
early 8086/8088 revisions bug
-----------------------------
(copyright 1978 on package)
mov sreg, doesnot disable until next operation is executed
8086/8088
---------
"mov cs, " causes unconditional jump!
80C86/80C88
-----------
"mov cs, " ignored
80186/80188
-----------
integrated pic8259, pit8253, dma8253 (but not at standard pc addresses)
additional instructions
"mov cs, " ?
shift count anded with 0x1f
80188
-----
8bit data bus
NEC series
----------
80186 instruction set, additional nec instructions
although it is based on 80186 instruction set, some behaviours follow 8086
8080 emulation mode
"mov cs, " ignored
shift count not anded (acts like 8086)
NEC 70116 (V30)
---------------
8086 pin compatible
NEC 70108 (V20)
---------------
8088 pinout
NEC V30MX
---------
on die ems hardware
24 bit address but for ems memory!?
no 8080 emulation mode
NEC V40
-------
pinout, integrated peripherals as 80186
NEC V50
-------
pinout, integrated peripherals as 80188
NEC V33?
--------
speed optimized V30?
NEC V25/V35?
------------
NEC V25+/V35+?
--------------
NEC V60/V70
-----------
risc (misc/delux) like instruction set
v30? emulation mode (without 8080 emulation mode)
80286
-----
80186 with additional instructions
24 bit address bus,
protected mode
80386 and later
---------------
not covered here
8087/80287/80387/80387sx
------------------------
mathematical coprocessors
weitek, iit variants
in 80486 coprocessor integrated
(except 80486sx and several clones)
80487: 80486 with other pinout
intel 8086 and compatibles
--------------------------
this info is here,
to list and give some remarks on all 8086 compatible processors
excellent info in Hamarsoft's 86BUGS list
(also distributed in ralf browns interrupt list)
8086/8088
---------
20 bit adress bus, 16 bit data bus and registers
many 8080 assembler sources should be compilable/reusable
8086
----
6 bytes prefetch queue
8088
----
8086 with 8 bit data bus,
prefetch queue only 4 byte, and refilled when 1 byte empty
early 8086/8088 revisions bug
-----------------------------
(copyright 1978 on package)
mov sreg, doesnot disable until next operation is executed
8086/8088
---------
"mov cs, " causes unconditional jump!
80C86/80C88
-----------
"mov cs, " ignored
80186/80188
-----------
integrated pic8259, pit8253, dma8253 (but not at standard pc addresses)
additional instructions
"mov cs, " ?
shift count anded with 0x1f
80188
-----
8bit data bus
NEC series
----------
80186 instruction set, additional nec instructions
although it is based on 80186 instruction set, some behaviours follow 8086
8080 emulation mode
"mov cs, " ignored
shift count not anded (acts like 8086)
NEC 70116 (V30)
---------------
8086 pin compatible
NEC 70108 (V20)
---------------
8088 pinout
NEC V30MX
---------
on die ems hardware
24 bit address but for ems memory!?
no 8080 emulation mode
NEC V40
-------
pinout, integrated peripherals as 80186
NEC V50
-------
pinout, integrated peripherals as 80188
NEC V33?
--------
speed optimized V30?
NEC V25/V35?
------------
NEC V25+/V35+?
--------------
NEC V60/V70
-----------
risc (misc/delux) like instruction set
v30? emulation mode (without 8080 emulation mode)
80286
-----
80186 with additional instructions
24 bit address bus,
protected mode
80386 and later
---------------
not covered here
8087/80287/80387/80387sx
------------------------
mathematical coprocessors
weitek, iit variants
in 80486 coprocessor integrated
(except 80486sx and several clones)
80487: 80486 with other pinout

326
src/cpu/m6502/m6502.txt
View File

@ -1,163 +1,163 @@
mos metal oxid semiconductor
bought by cbm
licence to produce chips
rockwell
transistor, logic gate designs:
NMOS (M65xx)
CMOS (M65Cxx)
HMOS (M75xx) hyper? MOS, used in early c16/plus4 series
H2MOS (M85xx) hyper2 MOS, used in C128, later c16/plus4, late C64
?SCMOS (M65SCxx) Super? CMOS
?CE (M65CExx, M45xx) CMOS Enhanced?, used in not released C65
HMOS, H2MOS CPUs have the same core as the NMOS series
6500 / 6501
mask programable microcontroller
32 io ports (2 interruptable)
timer
64 byte ram
8 kbyte rom
6502 (used in many designs)
b-flag always 1! (only pushed as 0 when break executed!)
memory changing opcodes accesses memory: read, write data, write modified data
6504
only 12 address pins a11..a0
6508
8 io pins (p0 bis p7)
6509
1 megabyte memory management
(lda,sta (zeropage),y modified, uses 2nd address extension register)
6510/8500 (used in some designs)
6 io pins (p0 bis p5)
6510T/8503? (used in commodore C1551 floppy)
8 io pins
integrated clock generation?
7501/8501 (c16, c116, c232, c264, plus4, c364)
7 io pins (no p5)
no nmi
8502 (c128)
7 io pins (no p7)
the above series is opcode compatible (including illegal opcodes)
n2a03 (some arcades, NES)
-------------------------
(nintendo variant)
NMOS based!
illegal opcodes
$6c jump indirect low byte overrun problem as in 6502
no decimal mode
integrated sound hardware
65c02 (used in some designs)
----------------------------
fixed jmp ind opcode
memory changing opcodes accesses memory: read, read, write
no illegal opcodes from the above series
so not full compatible to 6502 series
b flag always 1 as in NMOS Series is not known?
additional commands
several other CMOS variants
65sc02 (where used?)
--------------------
65c02 compatible
additional commands
atari lynx bastian schicks bll
integrated m65sc02 cpu core
no bbr bbs instructions, else m65c02 compatible
watara supervision
integrated m65c02 cpu core (or m65sc02 or m65ce02?)
gte65816 (nintendo snes)
------------------------
65802 upgrade cpu (c64 and c128 upgrade cpu)
16 bit wide registers
24 bit address space
65c02? compatible mode
additional commands
spc700
------
(snes sound processor)
same register layout?
same addressing modes?
heavily modified opcodes
YA could be combined for 16 bit operations?
huc6280 (nec pcengine)
----------------------
65sc02 compatible?
8 memory registers
(highest 3 bits select memory register, these build a22..a13)
(so 2 Megabyte address room!)
additional commands?
several additional integrated features
65ce02 (c65 prototype)
----------------------
(scan of documentation available, also use
c65 m4510 documentation)
(cpu core to be used in asics)
65sc02 compatible
z register
(65c02 zeropage indexed addressing is now (zeropage),z)
b bank register, highbyte of all zerozape addressing
register for stack high byte
additional command (some from the 65816)
m4510 (Commodore C65 CPU)
-------------------------
(scan of documentation (in c65 documentation) available)
65ce02 compatible
integrated 20 bit memory management (map)
(aug opcode changed to map opcode)
2 cia6526 integrated
1 uart integrated
mitsubishi 740 series
---------------------
(data book in electronic form available)
(M507xx, M509xx, M374xx, M38xxx, M375xx)
NMOS based
additional operation mode
(arithmetic instruction not performing on akku (a=a operation addressing mode)
but on zeropage ([x]=[x] operation addressing mode))
additional instructions LDM, MUL, DIV, TST, COM, RRF, CLT, SET, WIT, STP, CLP
BRK 1 byte only?
BRA CMOS compatible
BBC, BBR different opcode as CMOS, and also akku addressing
different TRB, TSB
no CMOS STZ, JMP ind,x
STP not in all variants
MUL, DIV not in all variants
Set Overflow Pin
----------------
in 6502 and pin compatibles (65C02 65SC02 65SC802 65CE02), M6509
no SO pin 6510/7501/8500/8501/8502/65sc816
6510T ?
mos metal oxid semiconductor
bought by cbm
licence to produce chips
rockwell
transistor, logic gate designs:
NMOS (M65xx)
CMOS (M65Cxx)
HMOS (M75xx) hyper? MOS, used in early c16/plus4 series
H2MOS (M85xx) hyper2 MOS, used in C128, later c16/plus4, late C64
?SCMOS (M65SCxx) Super? CMOS
?CE (M65CExx, M45xx) CMOS Enhanced?, used in not released C65
HMOS, H2MOS CPUs have the same core as the NMOS series
6500 / 6501
mask programable microcontroller
32 io ports (2 interruptable)
timer
64 byte ram
8 kbyte rom
6502 (used in many designs)
b-flag always 1! (only pushed as 0 when break executed!)
memory changing opcodes accesses memory: read, write data, write modified data
6504
only 12 address pins a11..a0
6508
8 io pins (p0 bis p7)
6509
1 megabyte memory management
(lda,sta (zeropage),y modified, uses 2nd address extension register)
6510/8500 (used in some designs)
6 io pins (p0 bis p5)
6510T/8503? (used in commodore C1551 floppy)
8 io pins
integrated clock generation?
7501/8501 (c16, c116, c232, c264, plus4, c364)
7 io pins (no p5)
no nmi
8502 (c128)
7 io pins (no p7)
the above series is opcode compatible (including illegal opcodes)
n2a03 (some arcades, NES)
-------------------------
(nintendo variant)
NMOS based!
illegal opcodes
$6c jump indirect low byte overrun problem as in 6502
no decimal mode
integrated sound hardware
65c02 (used in some designs)
----------------------------
fixed jmp ind opcode
memory changing opcodes accesses memory: read, read, write
no illegal opcodes from the above series
so not full compatible to 6502 series
b flag always 1 as in NMOS Series is not known?
additional commands
several other CMOS variants
65sc02 (where used?)
--------------------
65c02 compatible
additional commands
atari lynx bastian schicks bll
integrated m65sc02 cpu core
no bbr bbs instructions, else m65c02 compatible
watara supervision
integrated m65c02 cpu core (or m65sc02 or m65ce02?)
gte65816 (nintendo snes)
------------------------
65802 upgrade cpu (c64 and c128 upgrade cpu)
16 bit wide registers
24 bit address space
65c02? compatible mode
additional commands
spc700
------
(snes sound processor)
same register layout?
same addressing modes?
heavily modified opcodes
YA could be combined for 16 bit operations?
huc6280 (nec pcengine)
----------------------
65sc02 compatible?
8 memory registers
(highest 3 bits select memory register, these build a22..a13)
(so 2 Megabyte address room!)
additional commands?
several additional integrated features
65ce02 (c65 prototype)
----------------------
(scan of documentation available, also use
c65 m4510 documentation)
(cpu core to be used in asics)
65sc02 compatible
z register
(65c02 zeropage indexed addressing is now (zeropage),z)
b bank register, highbyte of all zerozape addressing
register for stack high byte
additional command (some from the 65816)
m4510 (Commodore C65 CPU)
-------------------------
(scan of documentation (in c65 documentation) available)
65ce02 compatible
integrated 20 bit memory management (map)
(aug opcode changed to map opcode)
2 cia6526 integrated
1 uart integrated
mitsubishi 740 series
---------------------
(data book in electronic form available)
(M507xx, M509xx, M374xx, M38xxx, M375xx)
NMOS based
additional operation mode
(arithmetic instruction not performing on akku (a=a operation addressing mode)
but on zeropage ([x]=[x] operation addressing mode))
additional instructions LDM, MUL, DIV, TST, COM, RRF, CLT, SET, WIT, STP, CLP
BRK 1 byte only?
BRA CMOS compatible
BBC, BBR different opcode as CMOS, and also akku addressing
different TRB, TSB
no CMOS STZ, JMP ind,x
STP not in all variants
MUL, DIV not in all variants
Set Overflow Pin
----------------
in 6502 and pin compatibles (65C02 65SC02 65SC802 65CE02), M6509
no SO pin 6510/7501/8500/8501/8502/65sc816
6510T ?

4
src/cpu/mips/dismips.mak
View File

@ -1,2 +1,2 @@
dismips.exe: dismips.c mipsdasm.c
gcc -O3 -I../../windows dismips.c -o../../../dismips
dismips.exe: dismips.c mipsdasm.c
gcc -O3 -I../../windows dismips.c -o../../../dismips

12
src/cpu/mips/dismips32.mak
View File

@ -1,6 +1,6 @@
CFLAGS=$(CFLAGS) -DSTANDALONE= -I../../win32
dismips.exe: dismips.obj
link $**
dismips.obj: dismips.c mipsdasm.c
CFLAGS=$(CFLAGS) -DSTANDALONE= -I../../win32
dismips.exe: dismips.obj
link $**
dismips.obj: dismips.c mipsdasm.c

10
src/cpu/tms34010/makefile
View File

@ -1,5 +1,5 @@
dis34010.exe : dis34010.o -lalleg
gcc -m486 -O3 -ffast-math -fomit-frame-pointer -finline-functions dis34010.o -lalleg -o dis34010.exe
dis34010.o : dis34010.c 34010dsm.c
gcc -c -m486 -O3 -ffast-math -fomit-frame-pointer -finline-functions -I/mame/src -I/mame/src/msdos dis34010.c
dis34010.exe : dis34010.o -lalleg
gcc -m486 -O3 -ffast-math -fomit-frame-pointer -finline-functions dis34010.o -lalleg -o dis34010.exe
dis34010.o : dis34010.c 34010dsm.c
gcc -c -m486 -O3 -ffast-math -fomit-frame-pointer -finline-functions -I/mame/src -I/mame/src/msdos dis34010.c

912
src/mame2003/mame2003.h
View File

@ -1,456 +1,456 @@
#ifndef MAME2003_H
#define MAME2003_H
#include <stdio.h>
#include <libretro.h>
#include <file/file_path.h>
#include <compat/posix_string.h>
#include "osd_cpu.h"
#include "inptport.h"
/*
* we can't #include <retro_miscellaneous.h> to bring in PATH_MAX_LENGTH due to namespace conflicts
* involing the DWORD define so we'll include only some useful bits for now
*/
#include <retro_inline.h>
#if defined(__CELLOS_LV2__)
#include <sys/fs_external.h>
#endif
#include <limits.h>
#ifndef PATH_MAX_LENGTH
#if defined(__CELLOS_LV2__)
#define PATH_MAX_LENGTH CELL_FS_MAX_FS_PATH_LENGTH
#elif defined(_XBOX1) || defined(_3DS) || defined(PSP) || defined(PS2) || defined(GEKKO) || defined(WIIU) || defined(ORBIS)
#define PATH_MAX_LENGTH 512
#else
#define PATH_MAX_LENGTH 4096
#endif
#endif
/*
* end of retro_miscellaneous.h bits
*/
#ifdef __cplusplus
extern "C" {
#endif
/* The Win32 port requires this constant for variable arg routines. */
#ifndef CLIB_DECL
#define CLIB_DECL
#endif
#ifdef __LP64__
#define FPTR unsigned long /* 64bit: sizeof(void *) is sizeof(long) */
#else
#define FPTR unsigned int
#endif
/***************************************************************************
Parameters
***************************************************************************/
#define APPNAME "mame2003-plus"
#define FRAMES_PER_FPS_UPDATE 12
#define MAX_GFX_ELEMENTS 32
#define MAX_MEMORY_REGIONS 32
#define NORMALIZED_ANALOG_THRESHOLD 64
enum
{
X_AXIS = 0,
Y_AXIS,
Z_AXIS,
PEDAL_AXIS,
MAX_ANALOG_AXES
};
enum
{
IDX_CLASSIC = 0,
IDX_MODERN,
IDX_8BUTTON,
IDX_6BUTTON,
IDX_NUMBER_OF_INPUT_TYPES
};
enum /* the "display numbers" for each player, as opposed to their array index */
{
DISP_PLAYER1 = 1,
DISP_PLAYER2,
DISP_PLAYER3,
DISP_PLAYER4,
DISP_PLAYER5,
DISP_PLAYER6
};
#define MAX_PLAYER_COUNT DISP_PLAYER6 /* We currently support a maximum of six simultaneous players */
/******************************************************************************
The following is a set of OS joystick codes (also including buttons and controls
on mice, lightguns, etc). In MAME 2003+, the libretro API takes the role of the
MAME OSD and these codes are used to represent the full range of input states
that can exist among any of the libretro API abstractions that can be used.
The names for elements of the enum reflect the fact that these codes parallel
input codes in libretro.h; because each of the libretro input abstractions uses
independent, overlapping code ranges, we cannot simply reuse the libretro codes.
******************************************************************************/
enum
{
OSD_JOYPAD_B = 0,
OSD_JOYPAD_Y,
OSD_JOYPAD_SELECT,
OSD_JOYPAD_START,
OSD_JOYPAD_UP,
OSD_JOYPAD_DOWN,
OSD_JOYPAD_LEFT,
OSD_JOYPAD_RIGHT,
OSD_JOYPAD_A,
OSD_JOYPAD_X,
OSD_JOYPAD_L,
OSD_JOYPAD_R,
OSD_JOYPAD_L2,
OSD_JOYPAD_R2,
OSD_JOYPAD_L3,
OSD_JOYPAD_R3,
OSD_MOUSE_LEFT_CLICK,
OSD_MOUSE_RIGHT_CLICK,
OSD_MOUSE_MIDDLE_CLICK,
OSD_ANALOG_LEFT_NEGATIVE_X,
OSD_ANALOG_LEFT_POSITIVE_X,
OSD_ANALOG_LEFT_NEGATIVE_Y,
OSD_ANALOG_LEFT_POSITIVE_Y,
OSD_ANALOG_RIGHT_NEGATIVE_X,
OSD_ANALOG_RIGHT_POSITIVE_X,
OSD_ANALOG_RIGHT_NEGATIVE_Y,
OSD_ANALOG_RIGHT_POSITIVE_Y,
OSD_INPUT_CODES_PER_PLAYER
};
/******************************************************************************
Shared libretro log interface
set in mame2003.c
******************************************************************************/
extern retro_log_printf_t log_cb;
/******************************************************************************
frontend message interface
implemented in mame2003.c
******************************************************************************/
extern void frontend_message_cb(const char *message_string, unsigned frames_to_display);
/******************************************************************************
Core options
******************************************************************************/
/******************************************************************************
* retro_variable_default contains the default value for a libretro core option
*
*****************************************************************************/
struct retro_variable_default
{
const char *key;
const char *defaults_string;
};
/******************************************************************************
Display
******************************************************************************/
/* mame_bitmap used to be declared here, but has moved to common.c */
/* sadly, the include order requires that at least this forward declaration is here */
struct mame_bitmap;
struct mame_display;
struct performance_info;
struct rectangle;
struct rom_load_data;
/* these are the parameters passed into osd_create_display */
struct osd_create_params
{
int width, height; /* width and height */
int aspect_x, aspect_y; /* aspect ratio X:Y */
int depth; /* depth, either 16(palette), 15(RGB) or 32(RGB) */
int colors; /* colors in the palette (including UI) */
float fps; /* frame rate */
int video_attributes; /* video flags from driver */
int orientation; /* orientation requested by the user */
};
/*
Create a display screen, or window, of the given dimensions (or larger). It is
acceptable to create a smaller display if necessary, in that case the user must
have a way to move the visibility window around.
The params contains all the information the
Attributes are the ones defined in driver.h, they can be used to perform
optimizations, e.g. dirty rectangle handling if the game supports it, or faster
blitting routines with fixed palette if the game doesn't change the palette at
run time. The VIDEO_PIXEL_ASPECT_RATIO flags should be honored to produce a
display of correct proportions.
Orientation is the screen orientation (as defined in driver.h) which will be done
by the core. This can be used to select thinner screen modes for vertical games
(ORIENTATION_SWAP_XY set), or even to ask the user to rotate the monitor if it's
a pivot model. Note that the OS dependent code must NOT perform any rotation,
this is done entirely in the core.
Depth can be 8 or 16 for palettized modes, meaning that the core will store in the
bitmaps logical pens which will have to be remapped through a palette at blit time,
and 15 or 32 for direct mapped modes, meaning that the bitmaps will contain RGB
triplets (555 or 888). For direct mapped modes, the VIDEO_RGB_DIRECT flag is set
in the attributes field.
Returns 0 on success.
*/
int osd_create_display(const struct osd_create_params *params, UINT32 *rgb_components);
/* osd_close_display is implemented in video.c */
void osd_close_display(void);
/*
osd_skip_this_frame() must return 0 if the current frame will be displayed.
This can be used by drivers to skip cpu intensive processing for skipped
frames, so the function must return a consistent result throughout the
current frame. The function MUST NOT check timers and dynamically determine
whether to display the frame: such calculations must be done in
osd_update_video_and_audio(), and they must affect the FOLLOWING frames, not
the current one. At the end of osd_update_video_and_audio(), the code must
already know exactly whether the next frame will be skipped or not.
*/
int osd_skip_this_frame(void);
/*
Update video and audio. game_bitmap contains the game display, while
debug_bitmap an image of the debugger window (if the debugger is active; NULL
otherwise). They can be shown one at a time, or in two separate windows,
depending on the OS limitations. If only one is shown, the user must be able
to toggle between the two by pressing IPT_UI_TOGGLE_DEBUG; moreover,
osd_debugger_focus() will be used by the core to force the display of a
specific bitmap, e.g. the debugger one when the debugger becomes active.
leds_status is a bitmask of lit LEDs, usually player start lamps. They can be
simulated using the keyboard LEDs, or in other ways e.g. by placing graphics
on the window title bar.
*/
void osd_update_video_and_audio(struct mame_display *display);
/******************************************************************************
Sound
******************************************************************************/
/*
osd_start_audio_stream() is called at the start of the emulation to initialize
the output stream, then osd_update_audio_stream() is called every frame to
feed new data. osd_stop_audio_stream() is called when the emulation is stopped.
The sample rate is fixed at Machine->sample_rate. Samples are 16-bit, signed.
When the stream is stereo, left and right samples are alternated in the
stream.
osd_start_audio_stream() and osd_update_audio_stream() must return the number
of samples (or couples of samples, when using stereo) required for next frame.
This will be around Machine->sample_rate / Machine->drv->frames_per_second,
the code may adjust it by SMALL AMOUNTS to keep timing accurate and to
maintain audio and video in sync when using vsync. Note that sound emulation,
especially when DACs are involved, greatly depends on the number of samples
per frame to be roughly constant, so the returned value must always stay close
to the reference value of Machine->sample_rate / Machine->drv->frames_per_second.
Of course that value is not necessarily an integer so at least a +/- 1
adjustment is necessary to avoid drifting over time.
*/
int osd_start_audio_stream(int stereo);
int osd_update_audio_stream(INT16 *buffer);
void osd_stop_audio_stream(void);
/******************************************************************************
Keyboard
******************************************************************************/
/*
return a list of all available keys (see input.h)
*/
const struct KeyboardInfo *osd_get_key_list(void);
/*
tell whether the specified key is pressed or not. keycode is the OS dependent
code specified in the list returned by osd_get_key_list().
*/
int osd_is_key_pressed(int keycode);
/*
Return the Unicode value of the most recently pressed key. This
function is used only by text-entry routines in the user interface and should
not be used by drivers. The value returned is in the range of the first 256
bytes of Unicode, e.g. ISO-8859-1. A return value of 0 indicates no key down.
Set flush to 1 to clear the buffer before entering text. This will avoid
having prior UI and game keys leak into the text entry.
*/
int osd_readkey_unicode(int flush);
/******************************************************************************
Joystick
******************************************************************************/
/*
return a list of all available joystick inputs (see input.h)
*/
const struct JoystickInfo *osd_get_joy_list(void);
/*
tell whether the specified joystick direction/button is pressed or not.
joycode is the OS dependent code specified in the list returned by
osd_get_joy_list().
*/
int osd_is_joy_pressed(int joycode);
/* added for building joystick seq for analog inputs */
int osd_is_joystick_axis_code(int joycode);
/* osd_analogjoy_read returns in the range -128 .. 128 (yes, 128, not 127) */
void osd_analogjoy_read( int player,
int analog_axis[MAX_ANALOG_AXES],
InputCode analogjoy_input[MAX_ANALOG_AXES] );
/******************************************************************************
*
* Legacy joystick calibration functions
*
* As of March 2021: these MAME functions should not actually be used and will not be invoked
* as long as needs_calibration always returns 0. The libretro frontend is reponsible for
* providing calibrated position data.
******************************************************************************/
/* Joystick calibration routines BW 19981216 */
int osd_joystick_needs_calibration(void);
/* Preprocessing for joystick calibration. Returns 0 on success */
void osd_joystick_start_calibration(void);
/* Prepare the next calibration step. Return a description of this step. */
/* (e.g. "move to upper left") */
const char *osd_joystick_calibrate_next(void);
/* Get the actual joystick calibration data for the current position */
void osd_joystick_calibrate(void);
/* Postprocessing (e.g. saving joystick data to config) */
void osd_joystick_end_calibration(void);
/******************************************************************************
Trackball, Spinner, Mouse
******************************************************************************/
/* osd_track_read expects the OSD to return the relative change in mouse or trackball
* coordinates since the last reading. If the user has set their mouse type to
* `pointer` in the core options, its coordinates are translated from absolute to
* relative coordinates before being stored in `mouse_x[]`.
*/
void osd_trak_read(int player, int *deltax, int *deltay);
/******************************************************************************
Lightgun
******************************************************************************/
/******************************************************************************
The osd_lightgun_read call should return the delta from the middle of the screen
when the gun is fired (not the absolute pixel value), and 0 when the gun is
inactive.
When osd_lightgun_read returns 0, control passes through to the analog joystick,
and mouse, in that order. In other words, when osd_lightgun_read returns a
value it overrides both mouse & analog joystick.
The value returned by the OSD layer should be -128 to 128, same as analog
joysticks. (yes, 128, not 127).
*******************************************************************************/
void osd_lightgun_read(int player, int *deltax, int *deltay);
/******************************************************************************
Utility functions
******************************************************************************/
/* inptport.c defines general purpose defaults for key and joystick bindings which
* may be further adjusted by the OS dependent code to better match the available
* keyboard, e.g. one could map pause to the Pause key instead of P, or snapshot
* to PrtScr instead of F12. Of course the user can further change the settings
* to anything they like.
*
* osd_customize_inputport_defaults is called on startup, before reading the
* configuration from disk. Scan the list, and change the keys/joysticks you want.
*/
void osd_customize_inputport_defaults(struct ipd *defaults);
/******************************************************************************
Timing
As of March 2021, these functions are not implemented in the libretro port.
******************************************************************************/
typedef INT64 cycles_t;
/* return the current number of cycles, or some other high-resolution timer */
cycles_t osd_cycles(void);
/* return the number of cycles per second */
cycles_t osd_cycles_per_second(void);
/* return the current number of cycles, or some other high-resolution timer.
This call must be the fastest possible because it is called by the profiler;
it isn't necessary to know the number of ticks per seconds. */
cycles_t osd_profiling_ticks(void);
#ifdef __cplusplus
}
#endif
#endif /* MAME2003_H */
#ifndef MAME2003_H
#define MAME2003_H
#include <stdio.h>
#include <libretro.h>
#include <file/file_path.h>
#include <compat/posix_string.h>
#include "osd_cpu.h"
#include "inptport.h"
/*
* we can't #include <retro_miscellaneous.h> to bring in PATH_MAX_LENGTH due to namespace conflicts
* involing the DWORD define so we'll include only some useful bits for now
*/
#include <retro_inline.h>
#if defined(__CELLOS_LV2__)
#include <sys/fs_external.h>
#endif
#include <limits.h>
#ifndef PATH_MAX_LENGTH
#if defined(__CELLOS_LV2__)
#define PATH_MAX_LENGTH CELL_FS_MAX_FS_PATH_LENGTH
#elif defined(_XBOX1) || defined(_3DS) || defined(PSP) || defined(PS2) || defined(GEKKO) || defined(WIIU) || defined(ORBIS)
#define PATH_MAX_LENGTH 512
#else
#define PATH_MAX_LENGTH 4096
#endif
#endif
/*
* end of retro_miscellaneous.h bits
*/
#ifdef __cplusplus
extern "C" {
#endif
/* The Win32 port requires this constant for variable arg routines. */
#ifndef CLIB_DECL
#define CLIB_DECL
#endif
#ifdef __LP64__
#define FPTR unsigned long /* 64bit: sizeof(void *) is sizeof(long) */
#else
#define FPTR unsigned int
#endif
/***************************************************************************
Parameters
***************************************************************************/
#define APPNAME "mame2003-plus"
#define FRAMES_PER_FPS_UPDATE 12
#define MAX_GFX_ELEMENTS 32
#define MAX_MEMORY_REGIONS 32
#define NORMALIZED_ANALOG_THRESHOLD 64
enum
{
X_AXIS = 0,
Y_AXIS,
Z_AXIS,
PEDAL_AXIS,
MAX_ANALOG_AXES
};
enum
{
IDX_CLASSIC = 0,
IDX_MODERN,
IDX_8BUTTON,
IDX_6BUTTON,
IDX_NUMBER_OF_INPUT_TYPES
};
enum /* the "display numbers" for each player, as opposed to their array index */
{
DISP_PLAYER1 = 1,
DISP_PLAYER2,
DISP_PLAYER3,
DISP_PLAYER4,
DISP_PLAYER5,
DISP_PLAYER6
};
#define MAX_PLAYER_COUNT DISP_PLAYER6 /* We currently support a maximum of six simultaneous players */
/******************************************************************************
The following is a set of OS joystick codes (also including buttons and controls
on mice, lightguns, etc). In MAME 2003+, the libretro API takes the role of the
MAME OSD and these codes are used to represent the full range of input states
that can exist among any of the libretro API abstractions that can be used.
The names for elements of the enum reflect the fact that these codes parallel
input codes in libretro.h; because each of the libretro input abstractions uses
independent, overlapping code ranges, we cannot simply reuse the libretro codes.
******************************************************************************/
enum
{
OSD_JOYPAD_B = 0,
OSD_JOYPAD_Y,
OSD_JOYPAD_SELECT,
OSD_JOYPAD_START,
OSD_JOYPAD_UP,
OSD_JOYPAD_DOWN,
OSD_JOYPAD_LEFT,
OSD_JOYPAD_RIGHT,
OSD_JOYPAD_A,
OSD_JOYPAD_X,
OSD_JOYPAD_L,
OSD_JOYPAD_R,
OSD_JOYPAD_L2,
OSD_JOYPAD_R2,
OSD_JOYPAD_L3,
OSD_JOYPAD_R3,
OSD_MOUSE_LEFT_CLICK,
OSD_MOUSE_RIGHT_CLICK,
OSD_MOUSE_MIDDLE_CLICK,
OSD_ANALOG_LEFT_NEGATIVE_X,
OSD_ANALOG_LEFT_POSITIVE_X,
OSD_ANALOG_LEFT_NEGATIVE_Y,
OSD_ANALOG_LEFT_POSITIVE_Y,
OSD_ANALOG_RIGHT_NEGATIVE_X,
OSD_ANALOG_RIGHT_POSITIVE_X,
OSD_ANALOG_RIGHT_NEGATIVE_Y,
OSD_ANALOG_RIGHT_POSITIVE_Y,
OSD_INPUT_CODES_PER_PLAYER
};
/******************************************************************************
Shared libretro log interface
set in mame2003.c
******************************************************************************/
extern retro_log_printf_t log_cb;
/******************************************************************************
frontend message interface
implemented in mame2003.c
******************************************************************************/
extern void frontend_message_cb(const char *message_string, unsigned frames_to_display);
/******************************************************************************
Core options
******************************************************************************/
/******************************************************************************
* retro_variable_default contains the default value for a libretro core option
*
*****************************************************************************/
struct retro_variable_default
{
const char *key;
const char *defaults_string;
};
/******************************************************************************
Display
******************************************************************************/
/* mame_bitmap used to be declared here, but has moved to common.c */
/* sadly, the include order requires that at least this forward declaration is here */
struct mame_bitmap;
struct mame_display;
struct performance_info;
struct rectangle;
struct rom_load_data;
/* these are the parameters passed into osd_create_display */
struct osd_create_params
{
int width, height; /* width and height */
int aspect_x, aspect_y; /* aspect ratio X:Y */
int depth; /* depth, either 16(palette), 15(RGB) or 32(RGB) */
int colors; /* colors in the palette (including UI) */
float fps; /* frame rate */
int video_attributes; /* video flags from driver */
int orientation; /* orientation requested by the user */
};
/*
Create a display screen, or window, of the given dimensions (or larger). It is
acceptable to create a smaller display if necessary, in that case the user must
have a way to move the visibility window around.
The params contains all the information the
Attributes are the ones defined in driver.h, they can be used to perform
optimizations, e.g. dirty rectangle handling if the game supports it, or faster
blitting routines with fixed palette if the game doesn't change the palette at
run time. The VIDEO_PIXEL_ASPECT_RATIO flags should be honored to produce a
display of correct proportions.
Orientation is the screen orientation (as defined in driver.h) which will be done
by the core. This can be used to select thinner screen modes for vertical games
(ORIENTATION_SWAP_XY set), or even to ask the user to rotate the monitor if it's
a pivot model. Note that the OS dependent code must NOT perform any rotation,
this is done entirely in the core.
Depth can be 8 or 16 for palettized modes, meaning that the core will store in the
bitmaps logical pens which will have to be remapped through a palette at blit time,
and 15 or 32 for direct mapped modes, meaning that the bitmaps will contain RGB
triplets (555 or 888). For direct mapped modes, the VIDEO_RGB_DIRECT flag is set
in the attributes field.
Returns 0 on success.
*/
int osd_create_display(const struct osd_create_params *params, UINT32 *rgb_components);
/* osd_close_display is implemented in video.c */
void osd_close_display(void);
/*
osd_skip_this_frame() must return 0 if the current frame will be displayed.
This can be used by drivers to skip cpu intensive processing for skipped
frames, so the function must return a consistent result throughout the
current frame. The function MUST NOT check timers and dynamically determine
whether to display the frame: such calculations must be done in
osd_update_video_and_audio(), and they must affect the FOLLOWING frames, not
the current one. At the end of osd_update_video_and_audio(), the code must
already know exactly whether the next frame will be skipped or not.
*/
int osd_skip_this_frame(void);
/*
Update video and audio. game_bitmap contains the game display, while
debug_bitmap an image of the debugger window (if the debugger is active; NULL
otherwise). They can be shown one at a time, or in two separate windows,
depending on the OS limitations. If only one is shown, the user must be able
to toggle between the two by pressing IPT_UI_TOGGLE_DEBUG; moreover,
osd_debugger_focus() will be used by the core to force the display of a
specific bitmap, e.g. the debugger one when the debugger becomes active.
leds_status is a bitmask of lit LEDs, usually player start lamps. They can be
simulated using the keyboard LEDs, or in other ways e.g. by placing graphics
on the window title bar.
*/
void osd_update_video_and_audio(struct mame_display *display);
/******************************************************************************
Sound
******************************************************************************/
/*
osd_start_audio_stream() is called at the start of the emulation to initialize
the output stream, then osd_update_audio_stream() is called every frame to
feed new data. osd_stop_audio_stream() is called when the emulation is stopped.
The sample rate is fixed at Machine->sample_rate. Samples are 16-bit, signed.
When the stream is stereo, left and right samples are alternated in the
stream.
osd_start_audio_stream() and osd_update_audio_stream() must return the number
of samples (or couples of samples, when using stereo) required for next frame.
This will be around Machine->sample_rate / Machine->drv->frames_per_second,
the code may adjust it by SMALL AMOUNTS to keep timing accurate and to
maintain audio and video in sync when using vsync. Note that sound emulation,
especially when DACs are involved, greatly depends on the number of samples
per frame to be roughly constant, so the returned value must always stay close
to the reference value of Machine->sample_rate / Machine->drv->frames_per_second.
Of course that value is not necessarily an integer so at least a +/- 1
adjustment is necessary to avoid drifting over time.
*/
int osd_start_audio_stream(int stereo);
int osd_update_audio_stream(INT16 *buffer);
void osd_stop_audio_stream(void);
/******************************************************************************
Keyboard
******************************************************************************/
/*
return a list of all available keys (see input.h)
*/
const struct KeyboardInfo *osd_get_key_list(void);
/*
tell whether the specified key is pressed or not. keycode is the OS dependent
code specified in the list returned by osd_get_key_list().
*/
int osd_is_key_pressed(int keycode);
/*
Return the Unicode value of the most recently pressed key. This
function is used only by text-entry routines in the user interface and should
not be used by drivers. The value returned is in the range of the first 256
bytes of Unicode, e.g. ISO-8859-1. A return value of 0 indicates no key down.
Set flush to 1 to clear the buffer before entering text. This will avoid
having prior UI and game keys leak into the text entry.
*/
int osd_readkey_unicode(int flush);
/******************************************************************************
Joystick
******************************************************************************/
/*
return a list of all available joystick inputs (see input.h)
*/
const struct JoystickInfo *osd_get_joy_list(void);
/*
tell whether the specified joystick direction/button is pressed or not.
joycode is the OS dependent code specified in the list returned by
osd_get_joy_list().
*/
int osd_is_joy_pressed(int joycode);
/* added for building joystick seq for analog inputs */
int osd_is_joystick_axis_code(int joycode);
/* osd_analogjoy_read returns in the range -128 .. 128 (yes, 128, not 127) */
void osd_analogjoy_read( int player,
int analog_axis[MAX_ANALOG_AXES],
InputCode analogjoy_input[MAX_ANALOG_AXES] );
/******************************************************************************
*
* Legacy joystick calibration functions
*
* As of March 2021: these MAME functions should not actually be used and will not be invoked
* as long as needs_calibration always returns 0. The libretro frontend is reponsible for
* providing calibrated position data.
******************************************************************************/
/* Joystick calibration routines BW 19981216 */
int osd_joystick_needs_calibration(void);
/* Preprocessing for joystick calibration. Returns 0 on success */
void osd_joystick_start_calibration(void);
/* Prepare the next calibration step. Return a description of this step. */
/* (e.g. "move to upper left") */
const char *osd_joystick_calibrate_next(void);
/* Get the actual joystick calibration data for the current position */
void osd_joystick_calibrate(void);
/* Postprocessing (e.g. saving joystick data to config) */
void osd_joystick_end_calibration(void);
/******************************************************************************
Trackball, Spinner, Mouse
******************************************************************************/
/* osd_track_read expects the OSD to return the relative change in mouse or trackball
* coordinates since the last reading. If the user has set their mouse type to
* `pointer` in the core options, its coordinates are translated from absolute to
* relative coordinates before being stored in `mouse_x[]`.
*/
void osd_trak_read(int player, int *deltax, int *deltay);
/******************************************************************************
Lightgun
******************************************************************************/
/******************************************************************************
The osd_lightgun_read call should return the delta from the middle of the screen
when the gun is fired (not the absolute pixel value), and 0 when the gun is
inactive.
When osd_lightgun_read returns 0, control passes through to the analog joystick,
and mouse, in that order. In other words, when osd_lightgun_read returns a
value it overrides both mouse & analog joystick.
The value returned by the OSD layer should be -128 to 128, same as analog
joysticks. (yes, 128, not 127).
*******************************************************************************/
void osd_lightgun_read(int player, int *deltax, int *deltay);
/******************************************************************************
Utility functions
******************************************************************************/
/* inptport.c defines general purpose defaults for key and joystick bindings which
* may be further adjusted by the OS dependent code to better match the available
* keyboard, e.g. one could map pause to the Pause key instead of P, or snapshot
* to PrtScr instead of F12. Of course the user can further change the settings
* to anything they like.
*
* osd_customize_inputport_defaults is called on startup, before reading the
* configuration from disk. Scan the list, and change the keys/joysticks you want.
*/
void osd_customize_inputport_defaults(struct ipd *defaults);
/******************************************************************************
Timing
As of March 2021, these functions are not implemented in the libretro port.
******************************************************************************/
typedef INT64 cycles_t;
/* return the current number of cycles, or some other high-resolution timer */
cycles_t osd_cycles(void);
/* return the number of cycles per second */
cycles_t osd_cycles_per_second(void);
/* return the current number of cycles, or some other high-resolution timer.
This call must be the fastest possible because it is called by the profiler;
it isn't necessary to know the number of ticks per seconds. */
cycles_t osd_profiling_ticks(void);
#ifdef __cplusplus
}
#endif
#endif /* MAME2003_H */

638
src/sound/pokey.txt
View File

@ -1,319 +1,319 @@
Atari POKEY Chip Emulator V2.0
==============================
by Ron Fries
31 Jan 97
The PokeySound Chip Emulator is designed to emulate the functionality of the
Atari POKEY Chip Hardware through 'C' Sourcecode. The emulator is able to
produce sounds which are essentially identical to the original POKEY chip,
including the exact distortions and pitches.
The emulator is designed to run in a 32-bit environment. Though it can be
compiled and run in a 16-bit environment, it is slow.
I would like to give special thanks to Neil Bradley. He provided excellent
testing support and was also the driving force behind the multiple POKEY
emulation.
New Features:
-------------
Version 2.0 of the 'PokeySound' adds the following features:
1) Support for multiple POKEY chips. The maximum supported is configured
at compile time.
2) An adjustable gain. The previous releases had a built-in gain of 64.
3) A clipping option. Depending on the number of chips emulated and the
configured gain, it is possible for the output to exceed 8-bits.
Clipping can be enabled to prevent this, though it does increase the
processing time.
Standard Features:
------------------
The 'PokeySound' emulator supports the following functions:
1) All polynomial sound generators:
a) 4-bit poly - actual bit pattern determined from sampled sound
b) 5-bit poly - actual bit pattern determined from sampled sound
c) 17-bit poly - simulated random bit pattern
d) 9-bit poly - derived from simulated 17-bit poly
2) Full support of all 'Divide by N' counter clocks:
a) 1.79 MHz (high limited to playback sample rate)
b) 64 KHz (high limited to playback sample rate)
c) 15 KHz
3) Full support of all 'Divide by N' resolutions:
a) 8-bit - single channel
b) 16-bit - double channel
4) Full support of all distortions
a) 5-bit poly, then 17-bit poly
b) 5-bit poly only
c) 5-bit poly, then 4-bit poly
d) 17-bit poly only
e) no poly counters (pure tone)
f) 5-bit poly only
5) Full support of volume control
6) Full support of all pitches - distortions will vary exactly as the
original Atari based on different pitches
7) Accurate pitch generation
8) Support of any playback sample rate (e.g. 22050)
The 'PokeySound' emulator does not currently support the following functions:
1) High pass filters
Though I don't believe adding support for the High-Pass filters is very
complicated, I decided not to add support right now because I don't
believe this feature is used much. I'm also not sure how much impact it
would have on performance. Let me know if you find an application that
uses it.
In the 2.0 release, I've removed the non-optimized vrersion. It was only
left in for reference. If you would still like to see the non-optimized
version, it's available in the 1.2 release.
One of the unique features of the emulator is that the processing time varies
based on the frequency. Since the routine only calculates new output values
when a change is sensed, the lower frequencies (which change less frequently)
will require less processing time.
Differences Between the Emulator and the Actual POKEY Chip:
-----------------------------------------------------------
The biggest difference between the emulator and the original hardware is
that the emulator emulates an 'ideal' POKEY chip. All output from the
emulator is a based on a precise square wave, whereas the output from the
original chip has decay. Though the output is slightly different, I
don't believe this difference is easily discernible.
Another slight difference is the 17-bit/9-bit poly. Since the polynomial
is large (2^17 bits), I choose to create the sample using a random number
generator rather than a table. I don't believe this difference is
significant.
There are also a few differences which are introduced by aliasing. This is
a direct result of using an output sampling rate which is not identical to
the original sound rate. It is most evident with high frequencies.
A final difference is the lack of support for the High-Pass Filter
functionality. I plan to add this in a future release if necessary.
Sample/Test Application:
------------------------
The test program I've distributed is a 16-bit DOS application created with
the Borland 'C' compiler. The only reason I used 16-bit was because I
already had a set of working SB drivers in 16-bit. Since the test system
is dedicated to generating sounds, the performance in 16-bit is more than
adequate.
POKEY.C
=======
The POKEY.C file is the heart of the PokeySound Emulation program.
Although the routines in the file must work together, no other files are
modules are required for operation. A header file, 'POKEY.H', has
been included for use in other modules, and provides the necessary
function prototypes. I've attempted to make the routines as portable as
possible, so the file should compile on almost any compiler with little
or no modification.
I have made some attempts at optimizing the routines, though I am sure
more optimization can be done. They are currently only available in 'C'.
I'll be happy to convert them to assembly language if desired. Please feel
free to send me e-mail at rfries@tcmail.frco.com.
The routines are easy to use. Detailed descriptions on the function calls
are listed below.
The POKEY.C module can be compiled in a 32-bit or 16-bit environment.
Since these routines are optimized for 32-bit use, the code will default
to 32-bit. To compile in 16-bits, use a command line option to define
the variable COMP16.
GENERAL OVERVIEW
----------------
On start-up of the system, a single call should be made to Pokey_sound_init.
This routine will prepare the structures for sound output. This routine
can be called again if necessary during warm-start or other reset.
Once in the main loop, there are two other functions that will be used.
Whenever the system needs to write to either the AUDC or AUDF values,
a call should be made to the Update_pokey_sound routine. This routine will
take care of updating the internal registers. It will pre-calculate several
values to help with optimization.
The only other routine that is called is the Pokey_process function. This
function will fill a audio buffer with a specified number of bytes. This
function should be called whenever a new audio buffer is required.
For best results, I recommend using at least two output buffers. Using this
scheme, the sound card can be playing one buffer while the system is filling
the other.
DETAILED FUNCTION DESCRIPTIONS
------------------------------
Pokey_sound_init(uint32 freq17, uint16 playback_freq, uint8 num_pokeys)
-----------------------------------------------------------------------
This function initializes the structures used by the PokeySound routines.
This function takes three parameters: the main clock frequency, the
playback frequency and the number of POKEY chips to emulate.
The maximum number of POKEY chips emulated is configured at compile time.
Though the maximum number of chips can be configured as one, the PokeySound
1.2 routines are recommended if only a single chip is to be emulated since
they have will provide better performance.
The main clock frequency is the frequency of the 1.79MHz source clock.
To provide exact results, freq17 should be set equal to 1789790 Hz. As an
alternative, freq17 can be set to an approximate frequency of 1787520 Hz.
Using this approximate frequency will reduce aliasing and thus produce a
clearer output signal.
A constant has been defined for both of these values for your convenience.
The names are FREQ_17_EXACT and FREQ_17_APPROX.
The playback frequency is the frequency of the sound playback (the frequency
used by the sound card). For best results, the playback frequency should
be an even division of the main clock frequency. Since most of the sounds
will be generated using the 64kHz clock, I also recommend making the
playback frequency an even division of the 64kHz clock.
The 64kHz clock is exactly equal to the main clock divided by 28. For
the playback frequency, I recommend one of the following values:
1) FREQ_17_APPROX / (28*1), which is equal to 63840. Of course, most sound
cards can't reproduce this frequency.
2) FREQ_17_APPROX / (28*2), which is equal to 31920. All of the newer cards
will support this frequency.
3) FREQ_17_APPROX / (28*3), which is equal to 21280. All of the SB
compatibles should support this frequency.
4) FREQ_17_APPROX / (28*4), which is equal to 15960. This may be the
best choice, as it offers good sound reproduction with good performance.
Of course, these options also assume you are using the approximate
frequency for the main clock as well. Any of these choices will offer the
best results when the main 64kHz clock is used, reasonable results when the
15kHz clock is selected, and marginal results when the 1.79MHz clock is
selected (the only way to produce good results in all cases is to set the
playback frequency to 1.79MHz!)
Feel free to experiment to find other alternatives as well.
This function has no return value (void).
Update_pokey_sound (uint16 addr, uint8 val, uint8 chip, uint8 gain)
-------------------------------------------------------------------
This function should be called each time an AUDC, AUDF or AUDCTL value
changes. This function takes four parameters: the address to change,
the new value, the chip to be updated, and the gain to be used.
The lower four bits of the address should be one of the following values:
Addr Description
------ -----------
0x00 AUDF1
0x01 AUDC1
0x02 AUDF2
0x03 AUDC2
0x04 AUDF3
0x05 AUDC3
0x06 AUDF4
0x07 AUDC4
0x08 AUDCTL
In order to support multiple POKEY chips, only the lower four bits of
the address are used. Note that this routine can no longer be called with
any address as it will affect the operation of the specified chip.
The routine pre-calculates several values that are needed by the
processing function. This is done to optimize performance.
The output will be amplified (multiplied) by gain/16 (previous releases had
a built in multiplier of 4, which calculates to a gain value of 64). If the
output exceeds the maximum value after then gain and clipping is enabled,
the output will be limited to reduce distortion.
The best value for the gain depends on the number of POKEYs emulated and
the maximum volume used. The maximum possible output for each channel is 15,
making the maximum possible output for a single chip to be 60. Assuming all
four channels on the chip are used at full volume, a gain of 64 can be used
without distortion. If 4 POKEY chips are emulated and all 16 channels are
used at full volume, the gain must be no more than 16 to prevent distortion.
Of course, if only a few of the 16 channels are used or not all channels are
used at full volume, a larger gain can be used.
To enable clipping, define the logical CLIP before compiling. This is the
default mode of operation as it has already been included in the POKEY.H file.
Note that this is only recommended if clipping is necessary since it will
impact the performance.
This function has no return value (void).
Pokey_process (uint8 *buffer, uint16 n)
---------------------------------------
This function calculates and fills a buffer with unsigned 8-bit mono audio.
This function takes two parameters: a pointer to the buffer to fill and
the size of the buffer (limited to 65535). This function fills the
buffer based on the requested size and returns. It automatically
updates the pointers for the next call, so subsequent calls to this function
will provide a continuous stream of data.
The size of the buffer that is needed depends on the playback frequency.
It is best to keep the buffer as small as possible to maximize response time
to changes in the sound. Of course, the minimum size is dependent on
system and emulator performance.
Selecting the correct buffer size is a careful balance. Selecting a buffer
size that is too small will produce noticeable clicks in the output, though
selecting a size that is too large will cause a poor response time and
possible delays in the system when the new buffer is filled.
This function has no return value (void).
License Information and Copyright Notice
========================================
PokeySound is Copyright(c) 1996-1997 by Ron Fries
This library is free software; you can redistribute it and/or modify it under
the terms of version 2 of the GNU Library General Public License as published
by the Free Software Foundation.
This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more
details.
To obtain a copy of the GNU Library General Public License, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Any permitted reproduction of these routines, in whole or in part, must bear
this legend.
Atari POKEY Chip Emulator V2.0
==============================
by Ron Fries
31 Jan 97
The PokeySound Chip Emulator is designed to emulate the functionality of the
Atari POKEY Chip Hardware through 'C' Sourcecode. The emulator is able to
produce sounds which are essentially identical to the original POKEY chip,
including the exact distortions and pitches.
The emulator is designed to run in a 32-bit environment. Though it can be
compiled and run in a 16-bit environment, it is slow.
I would like to give special thanks to Neil Bradley. He provided excellent
testing support and was also the driving force behind the multiple POKEY
emulation.
New Features:
-------------
Version 2.0 of the 'PokeySound' adds the following features:
1) Support for multiple POKEY chips. The maximum supported is configured
at compile time.
2) An adjustable gain. The previous releases had a built-in gain of 64.
3) A clipping option. Depending on the number of chips emulated and the
configured gain, it is possible for the output to exceed 8-bits.
Clipping can be enabled to prevent this, though it does increase the
processing time.
Standard Features:
------------------
The 'PokeySound' emulator supports the following functions:
1) All polynomial sound generators:
a) 4-bit poly - actual bit pattern determined from sampled sound
b) 5-bit poly - actual bit pattern determined from sampled sound
c) 17-bit poly - simulated random bit pattern
d) 9-bit poly - derived from simulated 17-bit poly
2) Full support of all 'Divide by N' counter clocks:
a) 1.79 MHz (high limited to playback sample rate)
b) 64 KHz (high limited to playback sample rate)
c) 15 KHz
3) Full support of all 'Divide by N' resolutions:
a) 8-bit - single channel
b) 16-bit - double channel
4) Full support of all distortions
a) 5-bit poly, then 17-bit poly
b) 5-bit poly only
c) 5-bit poly, then 4-bit poly
d) 17-bit poly only
e) no poly counters (pure tone)
f) 5-bit poly only
5) Full support of volume control
6) Full support of all pitches - distortions will vary exactly as the
original Atari based on different pitches
7) Accurate pitch generation
8) Support of any playback sample rate (e.g. 22050)
The 'PokeySound' emulator does not currently support the following functions:
1) High pass filters
Though I don't believe adding support for the High-Pass filters is very
complicated, I decided not to add support right now because I don't
believe this feature is used much. I'm also not sure how much impact it
would have on performance. Let me know if you find an application that
uses it.
In the 2.0 release, I've removed the non-optimized vrersion. It was only
left in for reference. If you would still like to see the non-optimized
version, it's available in the 1.2 release.
One of the unique features of the emulator is that the processing time varies
based on the frequency. Since the routine only calculates new output values
when a change is sensed, the lower frequencies (which change less frequently)
will require less processing time.
Differences Between the Emulator and the Actual POKEY Chip:
-----------------------------------------------------------
The biggest difference between the emulator and the original hardware is
that the emulator emulates an 'ideal' POKEY chip. All output from the
emulator is a based on a precise square wave, whereas the output from the
original chip has decay. Though the output is slightly different, I
don't believe this difference is easily discernible.
Another slight difference is the 17-bit/9-bit poly. Since the polynomial
is large (2^17 bits), I choose to create the sample using a random number
generator rather than a table. I don't believe this difference is
significant.
There are also a few differences which are introduced by aliasing. This is
a direct result of using an output sampling rate which is not identical to
the original sound rate. It is most evident with high frequencies.
A final difference is the lack of support for the High-Pass Filter
functionality. I plan to add this in a future release if necessary.
Sample/Test Application:
------------------------
The test program I've distributed is a 16-bit DOS application created with
the Borland 'C' compiler. The only reason I used 16-bit was because I
already had a set of working SB drivers in 16-bit. Since the test system
is dedicated to generating sounds, the performance in 16-bit is more than
adequate.
POKEY.C
=======
The POKEY.C file is the heart of the PokeySound Emulation program.
Although the routines in the file must work together, no other files are
modules are required for operation. A header file, 'POKEY.H', has
been included for use in other modules, and provides the necessary
function prototypes. I've attempted to make the routines as portable as
possible, so the file should compile on almost any compiler with little
or no modification.
I have made some attempts at optimizing the routines, though I am sure
more optimization can be done. They are currently only available in 'C'.
I'll be happy to convert them to assembly language if desired. Please feel
free to send me e-mail at rfries@tcmail.frco.com.
The routines are easy to use. Detailed descriptions on the function calls
are listed below.
The POKEY.C module can be compiled in a 32-bit or 16-bit environment.
Since these routines are optimized for 32-bit use, the code will default
to 32-bit. To compile in 16-bits, use a command line option to define
the variable COMP16.
GENERAL OVERVIEW
----------------
On start-up of the system, a single call should be made to Pokey_sound_init.
This routine will prepare the structures for sound output. This routine
can be called again if necessary during warm-start or other reset.
Once in the main loop, there are two other functions that will be used.
Whenever the system needs to write to either the AUDC or AUDF values,
a call should be made to the Update_pokey_sound routine. This routine will
take care of updating the internal registers. It will pre-calculate several
values to help with optimization.
The only other routine that is called is the Pokey_process function. This
function will fill a audio buffer with a specified number of bytes. This
function should be called whenever a new audio buffer is required.
For best results, I recommend using at least two output buffers. Using this
scheme, the sound card can be playing one buffer while the system is filling
the other.
DETAILED FUNCTION DESCRIPTIONS
------------------------------
Pokey_sound_init(uint32 freq17, uint16 playback_freq, uint8 num_pokeys)
-----------------------------------------------------------------------
This function initializes the structures used by the PokeySound routines.
This function takes three parameters: the main clock frequency, the
playback frequency and the number of POKEY chips to emulate.
The maximum number of POKEY chips emulated is configured at compile time.
Though the maximum number of chips can be configured as one, the PokeySound
1.2 routines are recommended if only a single chip is to be emulated since
they have will provide better performance.
The main clock frequency is the frequency of the 1.79MHz source clock.
To provide exact results, freq17 should be set equal to 1789790 Hz. As an
alternative, freq17 can be set to an approximate frequency of 1787520 Hz.
Using this approximate frequency will reduce aliasing and thus produce a
clearer output signal.
A constant has been defined for both of these values for your convenience.
The names are FREQ_17_EXACT and FREQ_17_APPROX.
The playback frequency is the frequency of the sound playback (the frequency
used by the sound card). For best results, the playback frequency should
be an even division of the main clock frequency. Since most of the sounds
will be generated using the 64kHz clock, I also recommend making the
playback frequency an even division of the 64kHz clock.
The 64kHz clock is exactly equal to the main clock divided by 28. For
the playback frequency, I recommend one of the following values:
1) FREQ_17_APPROX / (28*1), which is equal to 63840. Of course, most sound
cards can't reproduce this frequency.
2) FREQ_17_APPROX / (28*2), which is equal to 31920. All of the newer cards
will support this frequency.
3) FREQ_17_APPROX / (28*3), which is equal to 21280. All of the SB
compatibles should support this frequency.
4) FREQ_17_APPROX / (28*4), which is equal to 15960. This may be the
best choice, as it offers good sound reproduction with good performance.
Of course, these options also assume you are using the approximate
frequency for the main clock as well. Any of these choices will offer the
best results when the main 64kHz clock is used, reasonable results when the
15kHz clock is selected, and marginal results when the 1.79MHz clock is
selected (the only way to produce good results in all cases is to set the
playback frequency to 1.79MHz!)
Feel free to experiment to find other alternatives as well.
This function has no return value (void).
Update_pokey_sound (uint16 addr, uint8 val, uint8 chip, uint8 gain)
-------------------------------------------------------------------
This function should be called each time an AUDC, AUDF or AUDCTL value
changes. This function takes four parameters: the address to change,
the new value, the chip to be updated, and the gain to be used.
The lower four bits of the address should be one of the following values:
Addr Description
------ -----------
0x00 AUDF1
0x01 AUDC1
0x02 AUDF2
0x03 AUDC2
0x04 AUDF3
0x05 AUDC3
0x06 AUDF4
0x07 AUDC4
0x08 AUDCTL
In order to support multiple POKEY chips, only the lower four bits of
the address are used. Note that this routine can no longer be called with
any address as it will affect the operation of the specified chip.
The routine pre-calculates several values that are needed by the
processing function. This is done to optimize performance.
The output will be amplified (multiplied) by gain/16 (previous releases had
a built in multiplier of 4, which calculates to a gain value of 64). If the
output exceeds the maximum value after then gain and clipping is enabled,
the output will be limited to reduce distortion.
The best value for the gain depends on the number of POKEYs emulated and
the maximum volume used. The maximum possible output for each channel is 15,
making the maximum possible output for a single chip to be 60. Assuming all
four channels on the chip are used at full volume, a gain of 64 can be used
without distortion. If 4 POKEY chips are emulated and all 16 channels are
used at full volume, the gain must be no more than 16 to prevent distortion.
Of course, if only a few of the 16 channels are used or not all channels are
used at full volume, a larger gain can be used.
To enable clipping, define the logical CLIP before compiling. This is the
default mode of operation as it has already been included in the POKEY.H file.
Note that this is only recommended if clipping is necessary since it will
impact the performance.
This function has no return value (void).
Pokey_process (uint8 *buffer, uint16 n)
---------------------------------------
This function calculates and fills a buffer with unsigned 8-bit mono audio.
This function takes two parameters: a pointer to the buffer to fill and
the size of the buffer (limited to 65535). This function fills the
buffer based on the requested size and returns. It automatically
updates the pointers for the next call, so subsequent calls to this function
will provide a continuous stream of data.
The size of the buffer that is needed depends on the playback frequency.
It is best to keep the buffer as small as possible to maximize response time
to changes in the sound. Of course, the minimum size is dependent on
system and emulator performance.
Selecting the correct buffer size is a careful balance. Selecting a buffer
size that is too small will produce noticeable clicks in the output, though
selecting a size that is too large will cause a poor response time and
possible delays in the system when the new buffer is filled.
This function has no return value (void).
License Information and Copyright Notice
========================================
PokeySound is Copyright(c) 1996-1997 by Ron Fries
This library is free software; you can redistribute it and/or modify it under
the terms of version 2 of the GNU Library General Public License as published
by the Free Software Foundation.
This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more
details.
To obtain a copy of the GNU Library General Public License, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Any permitted reproduction of these routines, in whole or in part, must bear
this legend.

164
src/sound/tms5220.txt
View File

@ -1,82 +1,82 @@
*****************************
TI TMS5220 Emulator
(c) Frank Palazzolo
Updated by Raphael Nabet
*****************************
The TI TMS5220 Speech chip uses Linear-Predictive decoding scheme to produce
speech from very compact data. This scheme is very similar to the U.S.
Federal Standard LPC-10e coding system, which was developed soon after
this chip.
It is virtually identical to the chip used in the landmark "Speak 'N Spell"
toy produced in the '70s.
Acknowledgements:
-----------------
I would like to thank Larry Brantingham, the original designer of the chip,
for his technical help.
I would also like to thank Neill Cortlett, who first showed that this chip
could be emulated in real-time in his Multi-Gauntlet Emulator.
Theory of operation:
--------------------
The TI speech chip contains a 128-bit parallel-in, serial-out FIFO, a
10-pole digital lattice filter which models the vocal tract, and a D/A
converter. It was originally design to operate either with a microcomputer
interface, or with a serial speech ROM. The Speech ROM functionality is
now emulated, although no arcade games require it currently.
The input data is writen a byte at a time into the chip, and it is
decoded bitwise into variable length frames.
Possible Frame Types are as follows:
Energy RF Pitch K1 K2 K3 K4 K5 K6 K7 K8 K9 K10
-----------------------------------------------------------------
Silent 0000
Stop 1111
Repeat XXXX 1 XXXXXX
Unvoiced XXXX 0 000000 XXXXX XXXXX XXXX XXXX
Voiced XXXX 0 XXXXXX XXXXX XXXXX XXXX XXXX XXXX XXXX XXXX XXX XXX XXX
Stop Frame: Stops the current speech
Repeat Frame: Uses the digital filter coefficients from the previous frame,
with new Energy and Pitch values
Unvoiced Frame: Uses Noise generator to feed 4 pole digital filter
(All other coefficients are set to zero)
Voiced Frame: Uses Pulse Generator to feed 10 pole digital filter
All parameters (Energy, Pitch, K1-K10) are indexes into a lookup table for
actual values (see TMS5220R.c)
K1-K10 are reflection coefficients for the lattice filter.
Each frame is used to generate 200 samples, and 8 times during each frame,
(every 25 samples), these values are linearly interpolated to smooth out
frame transitions.
The Noise generator is based on a shift-register type random-bit generator.
The Pulse generator is based on a lookup table.
API:
----
TBD
More:
-----
For further technical info, the data sheet is floating around on the net.
(I believe the name is TMS.PDF) If you can't find a copy, email me and
I'll point you towards it. Feel free to contact me if you have a question.
Frank Palazzolo
palazzol@home.com
*****************************
TI TMS5220 Emulator
(c) Frank Palazzolo
Updated by Raphael Nabet
*****************************
The TI TMS5220 Speech chip uses Linear-Predictive decoding scheme to produce
speech from very compact data. This scheme is very similar to the U.S.
Federal Standard LPC-10e coding system, which was developed soon after
this chip.
It is virtually identical to the chip used in the landmark "Speak 'N Spell"
toy produced in the '70s.
Acknowledgements:
-----------------
I would like to thank Larry Brantingham, the original designer of the chip,
for his technical help.
I would also like to thank Neill Cortlett, who first showed that this chip
could be emulated in real-time in his Multi-Gauntlet Emulator.
Theory of operation:
--------------------
The TI speech chip contains a 128-bit parallel-in, serial-out FIFO, a
10-pole digital lattice filter which models the vocal tract, and a D/A
converter. It was originally design to operate either with a microcomputer
interface, or with a serial speech ROM. The Speech ROM functionality is
now emulated, although no arcade games require it currently.
The input data is writen a byte at a time into the chip, and it is
decoded bitwise into variable length frames.
Possible Frame Types are as follows:
Energy RF Pitch K1 K2 K3 K4 K5 K6 K7 K8 K9 K10
-----------------------------------------------------------------
Silent 0000
Stop 1111
Repeat XXXX 1 XXXXXX
Unvoiced XXXX 0 000000 XXXXX XXXXX XXXX XXXX
Voiced XXXX 0 XXXXXX XXXXX XXXXX XXXX XXXX XXXX XXXX XXXX XXX XXX XXX
Stop Frame: Stops the current speech
Repeat Frame: Uses the digital filter coefficients from the previous frame,
with new Energy and Pitch values
Unvoiced Frame: Uses Noise generator to feed 4 pole digital filter
(All other coefficients are set to zero)
Voiced Frame: Uses Pulse Generator to feed 10 pole digital filter
All parameters (Energy, Pitch, K1-K10) are indexes into a lookup table for
actual values (see TMS5220R.c)
K1-K10 are reflection coefficients for the lattice filter.
Each frame is used to generate 200 samples, and 8 times during each frame,
(every 25 samples), these values are linearly interpolated to smooth out
frame transitions.
The Noise generator is based on a shift-register type random-bit generator.
The Pulse generator is based on a lookup table.
API:
----
TBD
More:
-----
For further technical info, the data sheet is floating around on the net.
(I believe the name is TMS.PDF) If you can't find a copy, email me and
I'll point you towards it. Feel free to contact me if you have a question.
Frank Palazzolo
palazzol@home.com

324
src/sound/ym2151.txt
View File

@ -1,162 +1,162 @@
This is some very technical info I found during my experiments with real chip.
I hope someone will find it interesting.
YM2151 TIMING DIAGRAM
+-------------------------------------------------------------------------------------------------------------------------------|---------
Cycle no. | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 |11 |12 |13 |14 |15 |16 |17 |18 |19 |20 |21 |22 |23 |24 |25 |26 |27 |28 |29 |30 |31 | 0 | 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _
D/A clock |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| _______________________________ |
SH1 signal |_______________________________| |_______________________________________________________________|_________
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| _______________________________|
SH2 signal |_______________________________________________________________________________________________| |_________
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| | |
SO | x | x | x | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9| S0| S1| S2| x | x | x | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9| S0| S1| S2| x | x |
(D/A data) | | |
| R I G H T C H A N N E L | L E F T C H A N N E L |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
READ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
INTERNAL CH| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 |
DATA OP| C2| C2| C2| C2| C2| C2| C2| C2| M1| M1| M1| M1| M1| M1| M1| M1| M2| M2| M2| M2| M2| M2| M2| M2| C1| C1| C1| C1| C1| C1| C1| C1| C2| C2|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
operator #| 24| 25| 26| 27| 28| 29| 30| 31| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23| 24| 25|
+---------------------------------------------------------------|---------------------------------------------------------------|---------
Note:
-----
The SO (D/A data) is sequentially output to the YM3012 (stereo) or YM3014 (mono).
Formula to calculate sample from SO data is:
N = S2(2^2) + S1(2^1) + S0
where S2 = S1 = S0 = 0 - not allowed
SAMPLE = (-1+D9 + D8(2^-1) + D7(2^-2) + D6(2^-3) + ... + D0(2^-9) + 2^-10) * 2^-N
Anyway, important is that SO data is delayed by one sample compared to READ INTERNAL DATA.
This is logical since chip has to sum all channels' outputs before it will send SO data
(this is what the ACC (accumulator) does).
YM2151 Test register (0x01):
+----------+-----+------+-----+-----+------+------+------+-------+
| bit no. | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+----------+-----+------+-----+-----+------+------+------+-------+
| hex val. | 80 | 40 | 20 | 10 | 08 | 04 | 02 | 01 |
+----------+-----+------+-----+-----+------+------+------+-------+
| |LS/MS| RIen | HEG | NEG | HPGL | ILFO | HLFO | u_clk |
+----------+-----+------+-----+-----+------+------+------+-------+
bit 6 - RIen (Read Internal data Enable)
When set to 1, chip's internal data can be read via status register.
Simply set this bit and read data that will come out sequentially via the 8-bit
bus. Format of this data and the timing will be described later (diagram is above).
bit 7 - LS/MS (Least Significant or Most Significant 8 bits of internal data)
When 0 - chip's internal data read via status register is lower 8 bits (LSB),
When 1 - chip's internal data is upper 8 bits (MSB) (plus something I haven't figured out).
In other words: in order to read 8 LSB bits set this bit to 0, in order to read
8 MSB bits set this bit to 1.
bit 5 - HEG (Halt Envelope Generator)
When 1 - Envelope Generator gets halted.
This means that *Phase* Generator data can be read out when:
HEG bit is set to 1 (EG gets halted), and data coming out via the status register
will be pure sinus wave at the _CURRENT_ EG output.
This means you need to know _EXACTLY_ when to set this bit.
Simple workaround is to do the following:
- TL (Total Level) of the operator to minimum dB value (0x00) - it is max volume,
- AR (Attack Rate) of the operator to maximum speed (shortest time) (0x1f),
- D1L (Decay Level) of the operator to max (93 dB) (0xf0),
- D1R (Decay Rate) of the operator to zero (infinite time) speed (0x00),
- set KEYON of that operator,
- wait a while (long enough so Attack phase of the EG can be done),
- set HEG bit in the test register to 1,
and its done, since EG will be halted generating 0 (zero) dB level for
that operator (exactly speaking EG will stay in D1R phase) and, since 0 dB from EG
means no change on the sinus data stored inside of the chip's internal ROM,
you can read this ROM data.
Careful reader will notice that it may not be needed to use HEG bit to read the data
(bacause EG will be at 0dB anyway), but using this bit, one can make samples
of pure PHASE generator innerworking - that is how I obtained phaseinc_rom[].
bit 4 - NEG (Negate output data)
When 1 - output data sign will be simply inverted.
Worth noticing is that when this bit is 1 - also chip output data will be negated,
causing bad sound coming out of the speakers since the YM3012 (the D/A converter)
does not expect the negated data !!!
bit 3 - HPGL (Halt Phase Generator AND LFO amplitude modulation)
When 1 - Phase Generator is halted. Also amplitude modulation
(from LFO to Envelope Generator) is halted.
You can use this bit to analyse Envelope Generator work.
As it was in the case of HEG bit you need to know _EXACTLY_ when to set this bit.
Unfortunately, there is no _simple_ way. You will need to synchronise on the chip
output signals to know when to set it.
bit 2 - ILFO (Internal LFO related)
When 1 - LFO output (depends on selected waveform)
LFO outputs some internal signals...what are they ?
I did not test if this bit alters Phase Modulation in any way.
Also alters timer A somehow. At least it sounds like a restart.
bit 1 - HLFO (Halt LFO)
When 1 - LFO gets HALTED (at maximum amplitude in case of AM).
On the 1 to 0 transition LFO will be RESET to startup of the waveform
(phase of the LFO _only_).
bit 0 - u_clk (unknown, but probably internal clock related)
When 1 - Envelope Generator times are much shorter (faster envelopes).
I do not know if it alters Attacks parts of the envelope. I'm sure it
alters Decays times. Also timers are much (twice ?) faster than normally.
Perhaps this bit is disabling some internal clock divider.
FWIW, frequencies of the operators are NOT altered by setting this bit.
Jarek Burczynski
s0246@poczta.onet.pl
bujar@mame.net
This is some very technical info I found during my experiments with real chip.
I hope someone will find it interesting.
YM2151 TIMING DIAGRAM
+-------------------------------------------------------------------------------------------------------------------------------|---------
Cycle no. | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 |11 |12 |13 |14 |15 |16 |17 |18 |19 |20 |21 |22 |23 |24 |25 |26 |27 |28 |29 |30 |31 | 0 | 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _
D/A clock |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| _______________________________ |
SH1 signal |_______________________________| |_______________________________________________________________|_________
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| _______________________________|
SH2 signal |_______________________________________________________________________________________________| |_________
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
| | |
SO | x | x | x | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9| S0| S1| S2| x | x | x | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9| S0| S1| S2| x | x |
(D/A data) | | |
| R I G H T C H A N N E L | L E F T C H A N N E L |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|---+---+-
READ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
INTERNAL CH| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 |
DATA OP| C2| C2| C2| C2| C2| C2| C2| C2| M1| M1| M1| M1| M1| M1| M1| M1| M2| M2| M2| M2| M2| M2| M2| M2| C1| C1| C1| C1| C1| C1| C1| C1| C2| C2|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
operator #| 24| 25| 26| 27| 28| 29| 30| 31| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23| 24| 25|
+---------------------------------------------------------------|---------------------------------------------------------------|---------
Note:
-----
The SO (D/A data) is sequentially output to the YM3012 (stereo) or YM3014 (mono).
Formula to calculate sample from SO data is:
N = S2(2^2) + S1(2^1) + S0
where S2 = S1 = S0 = 0 - not allowed
SAMPLE = (-1+D9 + D8(2^-1) + D7(2^-2) + D6(2^-3) + ... + D0(2^-9) + 2^-10) * 2^-N
Anyway, important is that SO data is delayed by one sample compared to READ INTERNAL DATA.
This is logical since chip has to sum all channels' outputs before it will send SO data
(this is what the ACC (accumulator) does).
YM2151 Test register (0x01):
+----------+-----+------+-----+-----+------+------+------+-------+
| bit no. | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+----------+-----+------+-----+-----+------+------+------+-------+
| hex val. | 80 | 40 | 20 | 10 | 08 | 04 | 02 | 01 |
+----------+-----+------+-----+-----+------+------+------+-------+
| |LS/MS| RIen | HEG | NEG | HPGL | ILFO | HLFO | u_clk |
+----------+-----+------+-----+-----+------+------+------+-------+
bit 6 - RIen (Read Internal data Enable)
When set to 1, chip's internal data can be read via status register.
Simply set this bit and read data that will come out sequentially via the 8-bit
bus. Format of this data and the timing will be described later (diagram is above).
bit 7 - LS/MS (Least Significant or Most Significant 8 bits of internal data)
When 0 - chip's internal data read via status register is lower 8 bits (LSB),
When 1 - chip's internal data is upper 8 bits (MSB) (plus something I haven't figured out).
In other words: in order to read 8 LSB bits set this bit to 0, in order to read
8 MSB bits set this bit to 1.
bit 5 - HEG (Halt Envelope Generator)
When 1 - Envelope Generator gets halted.
This means that *Phase* Generator data can be read out when:
HEG bit is set to 1 (EG gets halted), and data coming out via the status register
will be pure sinus wave at the _CURRENT_ EG output.
This means you need to know _EXACTLY_ when to set this bit.
Simple workaround is to do the following:
- TL (Total Level) of the operator to minimum dB value (0x00) - it is max volume,
- AR (Attack Rate) of the operator to maximum speed (shortest time) (0x1f),
- D1L (Decay Level) of the operator to max (93 dB) (0xf0),
- D1R (Decay Rate) of the operator to zero (infinite time) speed (0x00),
- set KEYON of that operator,
- wait a while (long enough so Attack phase of the EG can be done),
- set HEG bit in the test register to 1,
and its done, since EG will be halted generating 0 (zero) dB level for
that operator (exactly speaking EG will stay in D1R phase) and, since 0 dB from EG
means no change on the sinus data stored inside of the chip's internal ROM,
you can read this ROM data.
Careful reader will notice that it may not be needed to use HEG bit to read the data
(bacause EG will be at 0dB anyway), but using this bit, one can make samples
of pure PHASE generator innerworking - that is how I obtained phaseinc_rom[].
bit 4 - NEG (Negate output data)
When 1 - output data sign will be simply inverted.
Worth noticing is that when this bit is 1 - also chip output data will be negated,
causing bad sound coming out of the speakers since the YM3012 (the D/A converter)
does not expect the negated data !!!
bit 3 - HPGL (Halt Phase Generator AND LFO amplitude modulation)
When 1 - Phase Generator is halted. Also amplitude modulation
(from LFO to Envelope Generator) is halted.
You can use this bit to analyse Envelope Generator work.
As it was in the case of HEG bit you need to know _EXACTLY_ when to set this bit.
Unfortunately, there is no _simple_ way. You will need to synchronise on the chip
output signals to know when to set it.
bit 2 - ILFO (Internal LFO related)
When 1 - LFO output (depends on selected waveform)
LFO outputs some internal signals...what are they ?
I did not test if this bit alters Phase Modulation in any way.
Also alters timer A somehow. At least it sounds like a restart.
bit 1 - HLFO (Halt LFO)
When 1 - LFO gets HALTED (at maximum amplitude in case of AM).
On the 1 to 0 transition LFO will be RESET to startup of the waveform
(phase of the LFO _only_).
bit 0 - u_clk (unknown, but probably internal clock related)
When 1 - Envelope Generator times are much shorter (faster envelopes).
I do not know if it alters Attacks parts of the envelope. I'm sure it
alters Decays times. Also timers are much (twice ?) faster than normally.
Perhaps this bit is disabling some internal clock divider.
FWIW, frequencies of the operators are NOT altered by setting this bit.
Jarek Burczynski
s0246@poczta.onet.pl
bujar@mame.net