JP2004154421A

JP2004154421A - Malfunction detector for rom

Info

Publication number: JP2004154421A
Application number: JP2002324184A
Authority: JP
Inventors: Takaaki Ichihara; 高明市原; Shigeki Inaba; 重貴稲葉; Kazunari Tanaka; 一成田中; Kenichi Eguchi; 健一江口
Original assignee: Daiman Co Ltd
Current assignee: Daiman Co Ltd
Priority date: 2002-11-07
Filing date: 2002-11-07
Publication date: 2004-06-03

Abstract

<P>PROBLEM TO BE SOLVED: To provide a game machine detecting malfunction in the contents of ROM when there is the malfunction in the contents of the ROM in a time except turning on the power. <P>SOLUTION: A control device repeats superiority/inferiority determination process in a processing routine except for a processing routine executed in turning on the power (B05). <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、制御装置が、遊技機に配備されたＲＯＭの記憶内容のサムチェックを行って前記ＲＯＭの良／不良を判定する良否判定処理を行うＲＯＭの異常検知装置に関する。
【０００２】
【従来の技術】
遊技機に配備されている遊技制御装置のＲＯＭにはＣＰＵが実行するための各種遊技制御プログラムが格納されている。また、遊技機に配設されている液晶表示装置等からなる図柄表示装置を表示制御する表示制御装置においては、表示制御プログラムが格納されているＲＯＭや表示のための各種画像データが格納されているキャラクタＲＯＭが設けられている。これらＲＯＭに正常に各種制御プログラム或いは各種データが格納されているか否かのチェック検査は、遊技機の出荷時に、ＲＯＭサムのチェックを行ってＲＯＭサムが正常であるか否かによって行っており、遊技機が出荷された後は、ＲＯＭサムのチェックは行われていない。
【０００３】
しかしながら、遊技機の出荷後、例えば、ＲＯＭの内容が異常な状態であるにもかかわらず、異常と判断できない場合もある。例えば、ＲＯＭの書き込み不良のように、所謂書き込みが浅く不安定な状態であって、チェック当初は正常と判定されても、熱等の要因により不特定時期に安定な状態に移行した結果、書き込んだはずのデータとは異なる値に安定化することがある。こうした場合には、表示される画像の色や形が意図しないものになるが、従来は異常と判定されないため意図しない画像が表示され続けることになる。
【０００４】
なお、電源投入時に、遊技機のメイン基板に配備されたＣＰＵが、システムチェック処理において、ＲＯＭに格納された遊技制御プログラムのサムチェック及び画像制御プログラムのサムチェックを行い、システムチェック結果（適／不適）を画像表示装置に表示する遊技機が提案されている（例えば、特許文献１参照）。
【０００５】
しかしながら、従来の遊技機においては、ＲＯＭサムのチェックを電源投入時にのみ行っているため、営業時間中にＲＯＭの内容に異常が発生した場合に、検知することができず、遊技中に不具合を起こす可能性がある。
【０００６】
【特許文献１】
特開平８−３２２９８０号公報（第１２頁段落０１００−同頁段落０１０３、図３２）
【０００７】
【発明が解決しようとする課題】
本発明の目的は、電源投入時以外の時、例えば、営業時間中に、ＲＯＭの内容に異常が発生した場合でも、ＲＯＭの内容の異常を検知することができる遊技機を提供することにある。
【０００８】
【課題を解決するための手段】
請求項１に記載のＲＯＭの異常検知装置は、制御装置が、遊技機に配備されたＲＯＭの記憶内容のサムチェックを行って前記ＲＯＭの良／不良を判定する良否判定処理を行うものであって、上記課題を解決するために、前記制御装置は、電源投入時に実行する処理ルーチン以外の処理ルーチンにおいて、前記良否判定処理を繰り返すものであることを特徴とする。
【０００９】
請求項１に記載のＲＯＭの異常検知装置において、次のように構成することがある。前記制御装置は、該制御装置が実行する処理の残余時間に、前記良否判定処理を開始する一方、前記ＲＯＭの良／不良を判定する前に、前記残余時間が満了した場合には、前記良否判定処理を中断し、再度、前記処理の残余時間に、前記良否判定処理を継続して再開し、前記ＲＯＭの良／不良を判定するものとすることがある。この構成によると、例えば、営業時間中に、ＲＯＭの内容に異常が発生した場合でも、ＲＯＭの内容の異常を検知することができる。
【００１０】
また、制御装置が、遊技機に配備されたＲＯＭの記憶内容のサムチェックを行って前記ＲＯＭの良／不良を判定する良否判定処理を行うものであって、当該遊技機の稼動状態／非稼動状態を判定する稼動状態判定手段を設け、前記制御装置は、前記稼動状態判定手段が非稼動状態であると判定した場合に、前記良否判定処理を開始する一方、前記ＲＯＭの良／不良を判定する前に、前記稼動発射状態判定手段が稼動状態であると判定した場合には、前記良否判定処理を中断し、再度、前記稼動状態判定手段が非稼動状態であると判定した場合に、前記良否判定処理を継続して再開し、前記ＲＯＭの良／不良を判定するものとすることがある。この構成によると、例えば、営業時間中に、ＲＯＭの内容に異常が発生した場合でも、ＲＯＭの内容の異常を検知することができる。また、遊技機が稼動状態である場合に比べて、制御装置の処理負担が軽い遊技機が非稼動状態である場合にＲＯＭの良否判定処理を行うため、効率よく良否判定処理を行える。
【００１１】
さらに、上記のものにおいて、前記制御装置が、前記ＲＯＭの内容を複数ブロックに分け、ブロック毎にサムチェックを行って前記ＲＯＭの良／不良を判定するものとすることができる。この構成によれば、そのブロックの内容に異常がある場合に不適と判定するので、ＲＯＭのサムチェックを最後まで行わなくともＲＯＭの内容が不適であることを発見できるため、ＲＯＭの内容の異常を早く発見でき、その異常箇所も異常が発見されたブロックという形で特定することができる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。図１は、本実施形態のパチンコ遊技機に配備された制御系統の要部ブロック図である。電源装置１は、ＡＣ２４Ｖから、メイン制御装置２、サブ制御装置３、表示制御装置４、賞球制御装置５、発射制御装置６、液晶表示装置７の他、払出モータ８、発射モータ９、大入賞口ソレノイド１０、ランプ１１、スピーカ１２等の作動電源を生成して供給するものである。
【００１３】
本実施形態のパチンコ遊技機には、パチンコ遊技の総括的な制御を行うメイン制御装置２と、メイン制御装置２から送信された情報（コマンド）に基いて、ランプ（装飾ランプ、装飾ＬＥＤ、表示ランプ、表示ＬＥＤ等）１１の点灯、点滅等の表示制御及びスピーカ１２から音を出す音声制御を実行するサブ制御装置３と、メイン制御装置２からサブ制御装置３を経由して送信されたコマンドを受けて液晶表示装置７に図柄及び各種の遊技情報の表示を行う表示制御装置４と、メイン制御装置２から送信された情報（賞球コマンド）に基いて払出モータ８を駆動することで賞球の払出制御を行う賞球制御装置５と、タッチセンサ１３の検出信号を条件として、図示しない遊技盤面に向けて遊技球を発射する打球発射装置（図示せず）の発射モータ９の動作制御を行う発射制御装置６とが配備される。
【００１４】
メイン制御装置２（主制御部）は図示しないメイン制御基板に配備される。メイン制御装置２は、パチンコ遊技に関わる総括的な制御を行うための処理実行手段としてのメインＣＰＵと、メインＣＰＵが実行するためのパチンコ遊技全体に関わる遊技制御プログラムや遊技制御プログラムの実行に必要となる予め定めた設定データが格納されているＲＯＭと、随時読み出しおよび書き込みが可能なＲＡＭと、各種入賞検出手段から送られた検出信号を受け付けてメインＣＰＵに入力可能とする一方、メインＣＰＵから外部装置に対して制御出力を可能とするための入出力インタフェースと、メインＣＰＵが周辺機器との間でデータ通信を行うための通信インタフェース等を含んで構成されている。なお、メイン制御装置２の具体的な構成については図示を省略する。
【００１５】
前記各種入賞検出手段としては、例えば、図示しない遊技盤面に設けられた始動口（図柄始動口）へ入賞した遊技球を検出する始動口入賞検出スイッチ（始動口センサともいう）、前記遊技盤面に設定されたゲート（図示せず）への遊技球の通過を検出するゲートセンサ、遊技盤面に設けられた電動役物装置（図示せず）に配備された大入賞口に入賞した遊技球を検出する大入賞口センサ（図示せず）、前記大入賞口内に設けられた特定領域へ入賞した遊技球を検出する特定領域センサ等がある。なお、図１においては各種入賞検出手段を入賞検出器１４として記載している。また、前記外部装置としては、前記大入賞口を開放させるための大入賞口ソレノイド１０等がある。なお、賞球制御装置５及び発射制御装置６については周知であって、本発明の要旨とは直接に関連しないため、具体的な構成の図示や説明等を省略する。
【００１６】
メイン制御装置２とサブ制御装置３とは、メイン制御装置２からサブ制御装置３への一方向通信のみ可能に接続されている。サブ制御装置３は、ランプの点灯／点滅等の制御、音声制御、メイン制御装置２から送信されるコマンド受信及び表示制御装置４に対するコマンド送信を行うための処理実行手段としてのサブＣＰＵと、サブＣＰＵが実行するためのランプ点灯／点滅に関わる制御プログラム、音声発生に関わる制御プログラム、コマンド受信に関わる制御プログラム及びコマンド送信に関わる制御プログラム、これらの各種制御プログラムの実行に必要となる予め定めた設定データ（ランプの点灯パターン等や音データ）が格納されているＲＯＭと、随時読み出しおよび書き込みが可能なＲＡＭと、サブＣＰＵからの制御出力を可能とするための出力インタフェースと、サブＣＰＵがメイン制御装置２及び表示制御装置４との間でデータ通信を行うための通信インタフェース等を含んで構成されている。なお、サブ制御装置３の具体的な構成については図示を省略する。
【００１７】
サブ制御装置３にはランプ１１やスピーカ１２が接続されている。サブ制御装置３はメイン制御装置２から送信されるコマンド指令に従ってランプ１１を点灯駆動すると共にスピーカ１２より効果音や警報を発生する。また、サブ制御装置３は、メイン制御装置２から送信されたコマンドを受信すると、受信したコマンドが自己の行う制御に関係するコマンドの場合には、このコマンドを記憶すると共に表示制御装置４に送信する一方、受信したコマンドが自己の行う制御に関係しないコマンドの場合には、このコマンドをそのまま表示制御装置４に送信する。
【００１８】
表示制御装置４は、サブ制御装置３から送信されたコマンドに応じて液晶表示装置７の表示画面に、特別図柄、装飾図柄、静止画や動画（キャラクタ等）、遊技進行に伴って変化する遊技情報（例えば、始動入賞に関わる保留状態や大当り遊技中のラウンド数等）を各々表示制御するものである。
【００１９】
図２は、表示制御装置４の構成を示すブロック図である。図２に示すように、本実施形態に係る表示制御装置４は、表示用ＣＰＵ１５を中心として、制御ＲＯＭ１６、キャラクタＲＯＭ１７、ＶＲＡＭ１８、カラーパレットＲＡＭ１９、ビデオ・ディスプレイ・プロセッサ（以下、単にＶＤＰという）２０、Ｄ／Ａコンバータ２１から構成される。表示用ＣＰＵ１５は、サブ制御装置３に接続される。この表示用ＣＰＵ１５は、サブ制御装置３から送信出力されたコマンドデータを受け、制御ＲＯＭ１６に格納されている制御プログラムに従ってＶＤＰ２０に制御信号を出力する処理を行う。具体的には、サブ制御装置３から出力されたコマンドデータによって指定される変動パターンデータ（スケジューラデータ）を制御ＲＯＭ１６から読み出し、読み出したスケジューラデータを順次解読して、ＶＤＰ２０で取扱うことが可能な制御信号に変換し、その変換した制御信号をＶＤＰ２０に出力する処理を行う。ここで、スケジューラデータとは、液晶表示装置７に表示される一連の画像の時間的なスケジュール（例えぱ、特別図柄の停止タイミング等）を規定するデータである。
【００２０】
ＶＤＰ２０は、ラインバッファ方式の公知のＶＤＰであり、表示用ＣＰＵ１５から出力された制御信号を受け、キャラクタＲＯＭ１７、カラーパレットＲＡＭ１９、ＶＲＡＭ１８に格納された各データから表示用データを生成し、生成した表示用データを、Ｄ／Ａコンバータ２１を介して液晶表示装置７に出力する処理を行う。具体的には、キャラクタＲＯＭ１７には、表示キャラクタ（特別図柄を構成する数字、アニメーション、背景等）を液晶表示装置７に表示するための表示用データ（ｎ×ｎの各ドットの色を指定するカラー番号で構成される）が格納されている。カラーパレットＲＡＭ１９には、カラー番号毎にカラーデータが格納されている。ＶＲＡＭ１８には、画像作成エリアに設定された複数の領域にどのキャラクタ番号の表示用データを配置するかを指定するデータが格納されている。
【００２１】
そして、ＶＤＰ２０は、表示用ＣＰＵ１５から出力された制御信号が入力すると、その制御信号にしたがって次の処理を行う。すなわち、ＶＤＰ２０は、ＶＲＡＭ１８に格納されているデータに基いて画像作成エリアを構成する各領域に、キャラクタＲＯＭ１７に格納されている表示用データを配置する。次いで、ＶＤＰ２０は、表示用データが配置された画像作成エリアから１本の走査線を取出し、各走査線を構成する表示用データ（カラー番号）をカラーパレットＲＡＭ１９のデータを用いてカラーデータに変換する。そして、作成された１本の走査線の表示用データが、順にＤ／Ａコンバータ２１を介して液晶表示装置７に出力する。なお、ＶＤＰ２０は、作成した表示用データの出力に同期してクロック信号を液晶表示装置７に出力する。
【００２２】
液晶表示装置７は、液晶表示器２２（ｎ×ｍドット）と、液晶表示器２２を駆動するＬＣＤドライバ回路２３で構成される。ＬＣＤドライバ回路２３は、上述のＶＤＰ２０と接続され、ＶＤＰ２０から出力される画像データ及びクロック信号が入力されるようになっている。また、ＬＣＤドライバ回路２３には、液晶表示器２２が接続され、ＬＣＤドライバ回路２３から駆動信号が液晶表示器２２に出力されるようになっている。かかる構成において、ＬＣＤドライバ回路２３は、ＶＤＰ２０から出力されるクロック信号をカウントすることで、入力する画像データが何番目の走査線の何番目の画像データであるかを判断する。したがって、ＬＣＤドライバ回路２３に画像データが順に入力すると、その入力する画像データについて、クロック信号からどの走査線に係る画像データかを判断すると同時に、ＶＤＰ２０から出力される１走査線分の画像データのうち何番目の画像データであるかを判断する。そして、入力する画像データに基づいて液晶表示器２２の該当する走査線の１番目のドットに画像を表示する。以後、画像データが入力する毎に、その入力した画像データによって順々に次のドットの画像を表示する。そして、液晶表示器２２の表示エリアに応じた１走査線分の画像データにより画像を表示すると、次の走査線の画像データが入力するまでその状態で待機する。そして、上記の処理が全ての走査線について行われることで液晶表示器２２に１つの画像が表示される。
【００２３】
以上のように構成された実施形態の遊技機におけるＲＯＭの異常検知装置について説明する。本実施形態においては、請求項１乃至３に記載される制御装置は、表示制御装置４が相当する。また、請求項１乃至３に記載されるＲＯＭは、表示制御装置４に配備されたキャラクタＲＯＭ１７が相当する。
【００２４】
ＲＯＭの異常検知装置の第１実施形態について説明する。第１実施形態のＲＯＭの異常検知装置は、表示制御装置４が実行するメインルーチン処理の残余時間に、キャラクタＲＯＭ１７の記憶内容のサムチェックを行ってキャラクタＲＯＭ１７の良／不良を判定する良否判定処理を開始する一方、キャラクタＲＯＭ１７の良／不良を判定する前に、残余時間が満了した場合には、良否判定処理を中断し、再度、メイン処理の残余時間に、良否判定処理を継続して再開し、キャラクタＲＯＭ１７の良／不良を判定するものである。なお、実施形態では、請求項１に記載される良否判定処理は、ステップＢ０５のＲＯＭのサムチェック処理（後述）が相当する。
【００２５】
図３は表示制御装置４に配備された表示用ＣＰＵ１５（以下、表示用ＣＰＵという）が実行する処理のメインルーチンを示すフローチャートである。また、図４は、表示用ＣＰＵが、ＶＤＰ２０から送信される１画像表示の完了信号によって発生するＩＮＴ１割込時に実行するＩＮＴ１割込処理のフローチャートである。さらに、図５は、表示用ＣＰＵが、サブ制御装置３から各種コマンドの送信と共に送信されるＣＥ信号によって発生するＩＮＴ２割込時に実行するＩＮＴ２割込処理のフローチャートである。
【００２６】
図３のメインルーチンにおいて、電源投入時、表示用ＣＰＵはステップＢ０１の初期化処理を行い、以下の処理に必要な各フラグ類やレジスタの初期化を行う。なお、本実施形態では、前記初期化処理が電源投入時に実行する処理ルーチンに相当する。次いで、表示用ＣＰＵは、割込フラグがセットされているか否かを判別する（ステップＢ０２）。なお、割込フラグの値は、ステップＢ０１の初期化処理により「０（クリア）」とされている。表示用ＣＰＵは、ステップＢ０２を偽と判別してステップＢ０５のＲＯＭのサムチェック処理に進む。表示用ＣＰＵは、今回処理のＲＯＭのサムチェック処理を抜けると、ステップＢ０２に戻り、再度、割込フラグがセットされているか否かを判別する。従って、表示用ＣＰＵは、割込フラグがセットされるまでの間、ステップＢ０２を偽、ステップＢ０５のＲＯＭのサムチェック処理を繰り返し実行する。このように、本発明は、電源投入時に実行する処理ルーチン以外の処理ルーチンにおいて、ＲＯＭのサムチェック処理を実行する構成としてある。
【００２７】
ＶＤＰ２０は、液晶表示装置７の表示画面に１画面全体の表示が可能な状態となると（ＶＤＰ２０が１画面全体を表示するのにほぼ１６ｍｓを要する）、表示用ＣＰＵに対して１画像表示の完了信号を送信する。この完了信号は、表示用ＣＰＵのＩＮＴ１端子に入力される。この結果、表示用ＣＰＵにおいてＩＮＴ１割込が発生し、図４のＩＮＴ１割込処理が実行される。なお、ＶＤＰ２０は、ほぼ１６ｍｓ毎の間隔で１画像表示の完了信号を表示用ＣＰＵに送信する。従って、表示用ＣＰＵにおいてＩＮＴ１割込がほぼ１６ｍｓ毎に発生する。表示用ＣＰＵは、ＩＮＴ１割込処理を開始すると、割込フラグをセットし（ステップＢ０６）、メインルーチンに戻る（詳細に言えば、割込が発生した時に実行していたプログラムアドレスの次のアドレスに戻る）。
【００２８】
また、サブ制御装置３は、表示用ＣＰＵに対して各種コマンドの送信と共にＣＥ信号を送信する。このＣＥ信号は、表示用ＣＰＵのＩＮＴ２端子に入力される。この結果、表示用ＣＰＵにおいてＩＮＴ２割込が発生し、図５のＩＮＴ２割込処理が実行される。表示用ＣＰＵは、ＩＮＴ２割込処理を開始すると、サブ制御装置３から送信されたコマンドを受信し（ステップＢ０７）、受信したコマンドがどのようなコマンドであるかを解析し、解析結果に応じた各種フラグのセットを行い（ステップＢ０８）、メインルーチンに戻る（詳細に言えば、割込が発生した時に実行していたプログラムアドレスの次のアドレスに戻る）。
【００２９】
ＩＮＴ１割込が発生すると割込フラグがセットされる結果、表示用ＣＰＵは、ステップＢ０２を真と判別し、ステップＢ０３のメイン処理にて、サブ制御装置３からコマンド形式で指定された表示指令に応じた画像表示のために必要な各種データをセット処理やセットした各種データをＶＤＰ２０に出力する処理を行う。表示用ＣＰＵは、メイン処理を抜けると、割込フラグを０クリアし（ステップＢ０４）、ステップＢ０２に戻り、割込フラグがセットされているか否かを判別し（ステップＢ０２）、再度、割込フラグがセットされるまでの間、ステップＢ０２を偽、ステップＢ０５のＲＯＭのサムチェック処理を繰り返し実行する。
【００３０】
以上の説明から理解されるように、ステップＢ０３のメイン処理及びステップＢ０４の割込フラグを０クリアする処理は、ＩＮＴ１割込により割込フラグがセットされる毎に実行される。ＩＮＴ１割込がほぼ１６ｍｓ毎に発生することから、ＩＮＴ１割込と次のＩＮＴ１割込までのほぼ１６ｍｓから、表示用ＣＰＵが、ステップＢ０３のメイン処理及びステップＢ０４の割込フラグの０クリアする処理を実行するのに要した所要時間（この所要時間は、表示用ＣＰＵがメイン処理を実行するのに要する所要時間の長短によって変化する）を差し引いた時間が、処理上の空時間（残余時間）となる。本発明は、この空時間を用いてステップＢ０５のＲＯＭのサムチェック処理を行うものである。
【００３１】
図６は、表示用ＣＰＵが実行するＲＯＭのサムチェック処理のサブルーチンを示すフローチャートである。なお、この処理にて、表示用ＣＰＵはキャラクタＲＯＭ１７の内容（画像の基データ）のサムチェックを行う。表示用ＣＰＵは、まず、開始フラグが０であるか否かを判別する（ステップＡ１１）。なお、開始フラグは、表示用ＣＰＵがＲＯＭのサムチェック処理を新規に開始するのか否かを識別するためのフラグであり、初期値は、ステップＢ０１の初期化処理により「０（新規）」とされている。
【００３２】
表示用ＣＰＵは、ステップＡ１１を真と判別し、開始フラグに１をセットしてＲＯＭのサムチェック処理の新規開始を記憶し（ステップＡ１２）、ＲＡＭに設定されているＲＯＭサム記憶エリアを０クリアし（ステップＡ１３）、ＲＡＭに設定されているＲＯＭ参照アドレス記憶エリアを０クリアし（ステップＡ１４）、ステップＡ１５に進む。
【００３３】
ステップＡ１５に進むと、表示用ＣＰＵは、ＲＯＭ参照アドレスのＲＯＭデータ（キャラクタＲＯＭのデータ）をＲＯＭサムに加算記憶し（ステップＡ１５）、ＲＯＭ参照アドレスを次のアドレスに更新し（例えば、１バイト単位の読み出しであるならば、参照アドレスを＋１する）（ステップＡ１６）、更新したＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えたか否かを判別する（ステップＡ１７）。表示用ＣＰＵは、更新したＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えていなければ、ステップＡ１７を偽と判別し、今回のＲＯＭのサムチェック処理を抜けてメインルーチンに戻る。メインルーチンに戻ると、表示用ＣＰＵは、割込フラグが０である（割込フラグがクリアされている）結果、ステップＢ０２を偽と判別し、再び、ステップＢ０５のＲＯＭのサムチェック処理を実行する。
【００３４】
表示用ＣＰＵがＲＯＭのサムチェック処理を新規に開始した後では、開始フラグに１がセットされている結果、表示用ＣＰＵは、ステップＡ１１を偽と判別してステップＡ１５に進む。表示用ＣＰＵは、更新したＲＯＭ参照アドレスに基いてステップＡ１５を行い、再び、ステップＡ１６にてＲＯＭ参照アドレスを次のアドレスに更新し、更新したＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えたか否かを判別し（ステップＡ１７）、ＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えていなければ、今回のＲＯＭのサムチェック処理を抜けてメインルーチンに戻る。
【００３５】
このように、表示用ＣＰＵは、ＲＯＭのサムチェック処理においては、ＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えなければ、ステップＡ１１を偽、ステップＡ１５、ステップＡ１６、ステップＡ１７を偽と判別する処理ルーチンを繰り返す。従って、キャラクタＲＯＭ１７のＲＯＭサムが上記処理ルーチンを行う毎に加算されることになる。そして、上記処理ルーチンを実行しているうちに、ＩＮＴ１割込が発生することになる。ＩＮＴ１割込が発生すると、表示用ＣＰＵは、処理を中断してＩＮＴ１割込処理を実行する。なお、割込が発生した時に実行していたプログラムアドレスが記憶され、ＩＮＴ１割込処理の終了時に次のアドレスに戻り、処理を続けて再開する。そして、ＩＮＴ１割込処理の実行により割込フラグがセットされることに応じて、ステップＢ０３のメイン処理及びステップＢ０４の割込フラグの０クリアする処理を実行し、ステップＢ０２を偽と判別し、再度、ＲＯＭのサムチェック処理を続けて再開する。
【００３６】
このようにして、表示用ＣＰＵが、ステップＡ１１を偽、ステップＡ１５、ステップＡ１６、ステップＡ１７を偽と判別する処理ルーチンを繰り返すうちに、ＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えることになる。ＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えると、表示用ＣＰＵは、ステップＡ１７を真と判別し、ＲＯＭサムがＲＯＭ判定用サムと一致するか否かを判別する（ステップＡ１８）。ＲＯＭサムがＲＯＭ判定用サムと一致する場合には、キャラクタＲＯＭ１７の内容が正常であると判定し、ステップＡ１８を真と判別し、開始フラグを０クリアし（ステップＡ１９）、ＲＯＭのサムチェック処理を終えてメインルーチンに戻る。
【００３７】
一方、ＲＯＭサムがＲＯＭ判定用サムと一致しない場合には、キャラクタＲＯＭ１７の内容が異常であると判定し、ステップＡ１８を偽と判別し、エラーを報知する（ステップＡ２０）。また、即エラー報知するのではなく、繰り返して判定を行って、例えば、２度異常と判定したら報知するようにしてもよい。このようにすると判定の信頼性を上げることができる。なお、エラーの報知は、液晶表示装置７の画面の隅にエラーを目視によって識別できるような標識を表示させたり、外部出力端子から管理コンピュータ（図示せず）に対してエラー情報を出力する等によって行う。
【００３８】
以上により、１回目のＲＯＭのサムチェック処理が終了することになる。開始フラグが０クリアされた結果、次回のＲＯＭのサムチェック処理においては、ステップＡ１１の判別結果が真となるため、表示用ＣＰＵは、再度、ＲＯＭのサムチェック処理を新規に開始することになる。以上の説明から理解されるように、本発明は、電源投入時に実行する処理ルーチン以外の処理ルーチンにおいて、ＲＯＭのサムチェック処理を行い、ＲＯＭの良／不良の判定を繰り返すものである。
【００３９】
キャラクタＲＯＭ１７のように画像の基データ等を格納記憶する目的で使用されるデータＲＯＭでは、ＲＯＭの内容が異常である場合であっても、制御プログラムが正常に動作することが多く、ＲＯＭの内容が異常であるにもかかわらず、異常と判断できない場合が多い。しかしながら、キャラクタＲＯＭ１７のように画像の基データ等が異常であると、例えば、大当り図柄（確率変動に移行させる大当り図柄と通常確率のままの大当り図柄との２種類がある）の表示色が異常な色で表示されてしまうようなことが起りかねない。具体的には、表示されている大当り図柄は通常確率のままとなる大当り図柄であるのに、この大当り図柄の表示色が確変図柄を意味する「赤」で表示されてしまう（本来は、通常確率のままとなる大当り図柄は「青」で表示されていなければならない）ことが起こりかねない。
【００４０】
本実施形態のＲＯＭの異常検知装置は、上述のようにメインルーチン処理の空時間（残余時間）を用いてステップＢ０５のＲＯＭのサムチェック処理を行うものである。そして、ＲＯＭのサムチェック処理によってキャラクタＲＯＭ１７の内容に異常がある場合、キャラクタＲＯＭ１７の異常として検知できる。従って、電源投入時以外の時、例えば、営業時間中に、キャラクタＲＯＭの内容に異常が発生した場合でも、キャラクタＲＯＭの内容の異常を検知することができる。なお、キャラクタＲＯＭの内容の異常が検知された場合、異常の度合いが遊技に絶大な影響を与える異常であるのか、ほとんど遊技に影響を与えることがない異常であるのかは、不明であるので、本実施形態ではエラー報知をして遊技そのものは一応続行させるようにしている。
【００４１】
次に、ＲＯＭの異常検知装置の第２実施形態について説明する。第２実施形態のＲＯＭの異常検知装置は、上述した第１実施形態のＲＯＭの異常検知装置において、ＲＯＭの内容を複数ブロックに分け、ブロック毎にサムチェックを行ってＲＯＭの良／不良を判定するものである。図１２は、キャラクタＲＯＭ１７の内容について、アドレス毎のブロック分けと各ブロック毎のサム値の一例を模式的に示す図である。図１２に示す例では、アドレス「００００番地」〜「０００３番地」が第１ブロック（ＲＯＭブロック番号「１」）で、そのサム値が「ａ」、アドレス「０００４番地」〜「０００７番地」が第２ブロック（ＲＯＭブロック番号「２」）で、そのサム値が「ｂ」、…というように設定されている。
【００４２】
図７乃至図８は、表示用ＣＰＵが実行する第２実施形態のＲＯＭのサムチェック処理のサブルーチンを示すフローチャートである。表示用ＣＰＵは、まず、開始フラグが０であるか否かを判別する（ステップＡ３１）。なお、開始フラグは、表示用ＣＰＵがＲＯＭのサムチェック処理を新規に開始するのか否かを識別するためのフラグであり、初期値は、ステップＢ０１の初期化処理により「０（新規）」とされている。
【００４３】
表示用ＣＰＵは、ステップＡ３１を真と判別し、開始フラグに１をセットしてＲＯＭのサムチェック処理の新規開始を記憶する（ステップＡ３２）。次いで、表示用ＣＰＵは、ＲＡＭに設定されているＲＯＭブロック番号記憶エリア（ＲＢＮＯ）にＲＯＭブロック番号の初期値「１」をセットし（ステップＡ３３）、ステップＡ３４に進む。
【００４４】
ステップＡ３４に進むと、表示用ＣＰＵは、ＲＢＮＯ（ＲＯＭブロック番号）に対応するＲＯＭ先頭アドレスをＲＡＭに設定されているＲＯＭ参照アドレス記憶エリアにセットし（ステップＡ３４）、ＲＢＮＯ（ＲＯＭブロック番号）に対応するＲＯＭ最終アドレスをＲＡＭに設定されているＲＯＭ最終アドレス記憶エリアにセットし（ステップＡ３５）、ＲＢＮＯ（ＲＯＭブロック番号）に対応するＲＯＭサムをＲＡＭに設定されているＲＯＭ判定用サムにセットし（ステップＡ３６）、ＲＡＭに設定されているＲＯＭサム記憶エリアを０クリアし（ステップＡ３７）、条件設定フラグを０クリアし（ステップＡ３８）、ステップＡ３９に進む。なお、条件設定フラグは、表示用ＣＰＵがステップＡ３４〜ステップＡ３７のブロックに関する条件の設定を行うか否かを判別するためのフラグであり、「０」で「行わない」、「１」で「行う」を意味するフラグである。
【００４５】
なお、ステップＡ３４〜ステップＡ３６による具体的な設定の一例を挙げると、ＲＯＭブロック番号「２」である場合には、ＲＯＭ先頭アドレス「０００４」をＲＯＭ参照アドレスにセットし、ＲＯＭ最終アドレス「０００７」をＲＯＭ最終アドレスにセットし、ＲＯＭサム「ｂ」をＲＯＭ判定用サムにセットする。
【００４６】
ステップＡ３９に進むと、表示用ＣＰＵは、ＲＯＭ参照アドレスのＲＯＭデータをＲＯＭサムに加算記憶し（ステップＡ３９）、ＲＯＭ参照アドレスを次のアドレスに更新し（例えば、１バイト単位の読み出しであるならば、参照アドレスを＋１する）（ステップＡ４０）、更新したＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えたか否かを判別する（ステップＡ４１）。表示用ＣＰＵは、更新したＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えていなければ、ステップＡ４１を偽と判別し、今回のＲＯＭのサムチェック処理を抜けてメインルーチンに戻る。メインルーチンに戻ると、表示用ＣＰＵは、割込フラグが０である（割込フラグがクリアされている）結果、ステップＢ０２を偽と判別し、再び、ステップＢ０５のＲＯＭのサムチェック処理を実行する（図３参照）。
【００４７】
表示用ＣＰＵがＲＯＭのサムチェック処理を新規に開始した後では、開始フラグに１がセットされている結果、表示用ＣＰＵは、ステップＡ３１を偽と判別してステップＡ４２に進む。表示用ＣＰＵは、条件設定フラグが「１」（ブロックに関する条件の設定を行うか否か）であるか否かを判別するが、ブロックに関する条件の設定を既に行っている場合ステップＡ３８にて条件設定フラグが０クリアされているため、ステップＡ４２を偽と判別してステップＡ３９に進む。
【００４８】
表示用ＣＰＵは、更新したＲＯＭ参照アドレスに基いてステップＡ３９を行い、再び、ステップＡ４０にてＲＯＭ参照アドレスを次のアドレスに更新し、更新したＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えたか否かを判別し（ステップＡ４１）、ＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えていなければ、今回のＲＯＭのサムチェック処理を抜けてメインルーチンに戻る。
【００４９】
このように、表示用ＣＰＵは、ＲＯＭのサムチェック処理においては、ＲＯＭ参照アドレスがＲＯＭ最終アドレスを超えなければ、ステップＡ３１を偽、ステップＡ４２を偽、ステップＡ３９、ステップＡ４０、ステップＡ４１を偽と判別する処理ルーチンを繰り返す。従って、キャラクタＲＯＭ１７のＲＢＮＯで指定されているＲＯＭサムが上記処理ルーチンを行う毎に加算されることになる。そして、上記処理ルーチンを実行しているうちに、ＩＮＴ１割込の発生がなければ、ＲＯＭ参照アドレスがＲＯＭ最終アドレス（当該ブロックの最終アドレス）を超えることになる。表示用ＣＰＵは、ステップＡ４１を真と判別し、ＲＯＭサムがＲＯＭ判定用サム（当該ブロックの判定用サム）と一致するか否かを判別する（ステップＡ４３）。ＲＯＭサムがＲＯＭ判定用サムと一致する場合には、キャラクタＲＯＭ１７の当該ブロック番号の内容が正常であると判定し、ステップＡ４３を真と判別し、ステップＡ４５に進む。
【００５０】
ステップＡ４５に進むと、表示用ＣＰＵは、ＲＯＭブロック番号ＲＢＮＯを＋１し（ステップＡ４５）、更新したＲＯＭブロック番号ＲＢＮＯが最終ＲＯＭブロック番号を超えているか否かを判別する（ステップＡ４６）。更新したＲＯＭブロック番号ＲＢＮＯが最終ＲＯＭブロック番号を超えていなければ、条件設定フラグに１をセットし（ステップＡ４７）、今回のＲＯＭのサムチェック処理を抜けてメインルーチンに戻る。
【００５１】
次回のＲＯＭのサムチェック処理では、ステップＡ３１を偽と判別し、条件設定フラグに１がセットされている結果、表示用ＣＰＵは、ステップＡ４２を真と判別してステップＡ３４に進むため、表示用ＣＰＵは、次のブロック番号で指定されるブロックに関する条件の設定を行い（ステップＡ３４〜ステップＡ３６）、ＲＯＭサムを０クリアし（ステップＡ３７）、条件設定フラグを０クリアし（ステップＡ３８）、ステップＡ３９に進む。従って、次のブロック番号で指定されるブロックについて、ＲＯＭのサムチェック処理を開始することになる。
【００５２】
なお、上記処理ルーチンを実行しているうちにＩＮＴ１割込が発生する場合には、表示用ＣＰＵは、処理を中断してＩＮＴ１割込処理を実行する。なお、割込が発生した時に実行していたプログラムアドレスが記憶され、ＩＮＴ１割込処理の終了時に次のアドレスに戻り、処理を続けて再開する。そして、ＩＮＴ１割込処理の実行により割込フラグがセットされることに応じて、ステップＢ０３のメイン処理及びステップＢ０４の割込フラグの０クリアする処理を実行し、ステップＢ０２を偽と判別し、再度、ＲＯＭのサムチェック処理を続けて再開する。
【００５３】
なお、ステップＡ４３にて、ＲＯＭサムがＲＯＭ判定用サム（当該ブロックの判定用サム）と一致しない場合には、キャラクタＲＯＭ１７の当該ブロックの内容が異常であると判定し、ステップＡ４３を偽と判別し、エラーを報知する（ステップＡ４４）。
【００５４】
また、ステップＡ４６にて、更新したＲＯＭブロック番号ＲＢＮＯが最終ＲＯＭブロック番号を超えている場合には、１回目のＲＯＭのサムチェック処理が終了したことになり、表示用ＣＰＵは、ステップＡ４７を真と判別し、開始フラグを０クリアし（ステップＡ４８）、ＲＯＭのサムチェック処理を終えてメインルーチンに戻る。開始フラグが０クリアされた結果、次回のＲＯＭのサムチェック処理においては、ステップＡ３１の判別結果が真となるため、表示用ＣＰＵは、再度、ＲＯＭのサムチェック処理を新規に開始することになる。
【００５５】
前述した第１実施形態では、ＲＯＭのサムチェック処理において、ＲＯＭの内容を最終アドレスまでＲＯＭサムを加算してＲＯＭサムを判定しているが、上述の第２実施形態では、ＲＯＭのサムチェック処理において、ＲＯＭの内容を複数ブロックに分け、ブロック毎にサムチェックを行ってＲＯＭの良／不良を判定するので、ＲＯＭの内容に異常が存在する場合には、異常が存在するブロックにて異常が検知できるので、早期にＲＯＭの異常を検知することができる。
【００５６】
次に、ＲＯＭの異常検知装置の第３実施形態について説明する。第３実施形態のＲＯＭの異常検知装置は、当該遊技機の非稼動状態／稼動状態に応じてＲＯＭのサムチェック処理の実行／中断を行うものである。なお、明細書における当該遊技機の非稼動状態／稼動状態とは、遊技機の電源オフ状態／電源オン状態を意味するものではない。当該遊技機の稼動状態とは、当該遊技機において実際に遊技が行われている状態を意味し、当該遊技機の非稼動状態とは、所定時間の間、当該遊技機において遊技が行われていない状態を意味する。なお、本実施形態において、当該遊技機の非稼動状態／稼動状態の判定は、入賞検出が所定時間（一例として、５分）に亘ってない場合に遊技機の非稼動状態とし、入賞検出が所定時間（一例として、５分）に１回でもある場合に当該遊技機の稼動状態として扱う。
【００５７】
図９は、メイン制御装置２に配備されたＣＰＵ（以下、メインＣＰＵという）が実行する入賞チェック処理のサブルーチンを示すフローチャートである。メインＣＰＵは、入賞チェック処理を開始すると、まず、入賞検出があるか否かを判別する（ステップＳ１１）。なお、入賞検出器１４（図１参照）による検出信号があれば、入賞検出があることになる。電源投入直後は入賞検出なしであるので、メインＣＰＵはステップＳ１１を偽と判別し、ステップＳ１２に進み、タイマが０であるか否かを判別する（ステップＳ１２）。なお、このタイマは、入賞検出が所定時間に亘ってあるか否かを監視するための監視時間（例えば、５分）がセットされるタイマである。電源投入直後は、初期化されており、タイマ値が０とされている。メインＣＰＵは、ステップＳ１２を真と判別し、サブ制御装置３に対して送信するチェック実行コマンドをセットし（ステップＳ１３）、送信済フラグに１（送信済）をセットし（ステップＳ１４）、ステップＳ１５に進み、タイマに入賞検出に関わる監視時間（例えば、５分）をセットし（ステップＳ１５）、今回の入賞チェック処理を抜けて図示しないメインルーチンに戻る。なお、タイマにセットされたタイマ値は、図示しないタイマ減算処理にて所定周期毎に減算される。また、ステップＳ１４にてセットされたチェック実行コマンドは、図示しないコマンド出力処理にてサブ制御装置３に対して送信される。
【００５８】
次周期以降の入賞チェック処理において、上記監視時間（５分）の間、入賞検出がなければ、メインＣＰＵは、ステップＳ１１を偽、ステップＳ１２を偽と判別する処理ルーチンを繰り返す。そして、監視時間（５分）が経過すると、ステップＳ１２にてタイマの値が０であることが検出され、ステップＳ１２を真と判定し、再度、ステップＳ１３、ステップＳ１４、ステップＳ１５を行って、今回の入賞チェック処理を抜けて図示しないメインルーチンに戻る。
【００５９】
一方、上記監視時間が経過する前に、即ち、タイマにセットされているタイマ値が０となる前に、入賞検出があった場合には、表示用ＣＰＵは、ステップＳ１１を真と判別し、ステップＳ１２に進み、送信済フラグの値が１であるか否かを判別する（ステップＳ１２）。送信済フラグは、サブ制御装置３に対してチェック実行コマンド（後述）を送信したか否かを識別するためのフラグであり、初期値は「０」である。メインＣＰＵは、送信済フラグに１がセットされている結果、ステップＳ１２を真と判定する。表示用ＣＰＵは、サブ制御装置３に対して送信するチェック中断コマンドをセットし（ステップＳ１７）、送信済フラグを０クリアし（ステップＳ１８）、ステップＳ１５に進み、タイマに入賞検出に関わる監視時間（例えば、５分）をセットし（ステップＳ１５）、今回の入賞チェック処理を抜けて図示しないメインルーチンに戻る。なお、ステップＳ１７にてセットされたチェック中断コマンドは、図示しないコマンド出力処理にてサブ制御装置３に対して送信される。
【００６０】
次周期以降の入賞チェック処理において、チェック中断コマンドを送信してから上記監視時間（５分）の間、入賞検出がなければ、メインＣＰＵは、ステップＳ１１を偽、ステップＳ１２を偽と判別する処理ルーチンを繰り返す。そして、監視時間（５分）が経過すると、ステップＳ１２にてタイマの値が０であることが検出され、ステップＳ１２を真と判定し、再度、サブ制御装置３に対して送信するチェック実行コマンドをセットし（ステップＳ１３）、送信済フラグに１（送信済）をセットし（ステップＳ１４）、ステップＳ１５に進み、タイマに入賞検出に関わる監視時間（例えば、５分）をセットし（ステップＳ１５）、今回の入賞チェック処理を抜けて図示しないメインルーチンに戻る。従って、チェック中断コマンドを送信してから上記監視時間（５分）の間に入賞検出がなければ、サブ制御装置３に対してチェック実行コマンドが送信される。
【００６１】
一方、次周期以降の入賞チェック処理において、チェック中断コマンドを送信してから上記監視時間（５分）の間に入賞検出がある場合、表示用ＣＰＵは、ステップＳ１１を真と判別し、送信済フラグが０クリアされている結果、ステップＳ１６を偽と判別し、ステップＳ１５に進み、新たに、タイマに入賞検出に関わる監視時間（例えば、５分）をセットし（ステップＳ１５）、今回の入賞チェック処理を抜けて図示しないメインルーチンに戻る。従って、上記監視時間（５分）の間に入賞検出がある毎に、上記監視時間（５分）がタイマに更新セットされることになるため、上記監視時間（５分）の間に入賞検出があり続ける限り、タイマがタイムアップすることはない。従って、チェック中断コマンドを送信してから上記監視時間（５分）の間に入賞検出があり続ける限り、サブ制御装置３に対してチェック実行コマンドが送信されることはない。
【００６２】
メイン制御装置２から送信されたチェック実行コマンド並びにチェック中断コマンドは、サブ制御装置３に一旦受信され、サブ制御装置３によって受信したコマンドが自己の行う制御に関係しないコマンドと判断され、このコマンドをそのまま表示制御装置４に送信する。
【００６３】
次に、サブ制御装置３を経由して送信されたチェック実行コマンド及びチェック中断コマンドに応じた表示制御装置４のＲＯＭのサムチェック処理について説明する。チェック実行コマンド及びチェック中断コマンドが表示制御装置４に送信されると、表示用ＣＰＵにＩＮＴ２割込が発生する。表示用ＣＰＵは、ＩＮＴ２割込処理に進み、コマンド受信処理にてコマンドを受信し（ステップＢ０７）、コマンド解析処理において受信したコマンドを解析し、解析結果に応じた各種フラグのセットを行い（ステップＢ０８）、メインルーチンに戻る（図５参照）。
【００６４】
図１０は、表示用ＣＰＵが実行するコマンド解析処理のサブルーチンの一部を示すフローチャートである。表示用ＣＰＵは、受信したコマンドを解析する中で、受信コマンドがチェック実行コマンドであるか否かを判別する（ステップＡ５１）。受信コマンドがチェック実行コマンドである場合、ＲＯＭのサムチェック処理に関する実行フラグＦ１に１をセットし（ステップＡ５２）、コマンド解析処理を抜ける。一方、受信コマンドがチェック実行コマンドでない場合、受信コマンドがチェック中断コマンドであるか否かを判別する（ステップＡ５３）。表示用ＣＰＵは、受信コマンドがチェック中断コマンドである場合、ＲＯＭのサムチェック処理に関する実行フラグＦ１を０クリアし（ステップＡ５４）、コマンド解析処理を抜ける。なお、受信コマンドがチェック実行コマンドでなく、チェック中断コマンドでもない場合には、ＲＯＭのサムチェック処理に関する実行フラグＦ１についての処理は行わないため、実行フラグＦ１の値は現在のままとなる。
【００６５】
図１１は、ＲＯＭの異常検知装置の第３実施形態における表示用ＣＰＵが実行する処理のメインルーチンを示すフローチャートである。第３実施形態のＲＯＭの異常検知装置の表示用ＣＰＵが実行する処理のメインルーチンが、第１実施形態のＲＯＭの異常検知装置の表示用ＣＰＵが実行する処理のメインルーチンと異なる点は、実行フラグＦ１のセット状態に応じてＲＯＭのサムチェック処理を行う点のみが異なり、他の点は、第１実施形態と同じである。
【００６６】
表示用ＣＰＵは、ステップＢ０２で割込フラグがセットされていないと判別すると、実行フラグＦ１がセットされているか否かを判別する（ステップＢ１０）。表示用ＣＰＵは、実行フラグＦ１がセットされている場合、ＲＯＭのサムチェック処理を行ってステップＢ０２に戻る一方、実行フラグＦ１がセットされていない場合、ＲＯＭのサムチェック処理を行わずにそのままステップＢ０２に戻る。なお、ＲＯＭのサムチェック処理自体は、図６に示す第１実施形態或いは図７乃至図８に示す第２実施形態の何れでもよい。
【００６７】
以上に述べたように、第３実施形態のＲＯＭの異常検知装置は、入賞検出が所定時間（一例として、５分）に亘ってないことを契機として、ＲＯＭのサムチェック処理を実行する。また、ＲＯＭのサムチェック処理の実行中、入賞検出が所定時間（一例として、５分）に１回でもあることを契機として、ＲＯＭのサムチェック処理の実行を中断する。さらに、入賞検出が所定時間（一例として、５分）に亘ってないことを契機として、ＲＯＭのサムチェック処理を実行する。なお、ＲＯＭのサムチェック処理の実行を中断していた場合には、ＲＯＭのサムチェック処理の実行再開となる。
【００６８】
表示用ＣＰＵにおいて、上記のような入賞検出が所定時間（一例として、５分）に亘ってない状態は、例えば、デモ画面のように、アニメーションによる動画は少なく静止画像を表示する状況である。このため、図１１のステップＢ０３のメイン処理における所要時間が短くなるため、他の遊技状況に比べてメインルーチンの残余時間が長くなる。従って、この残余時間中に行うＲＯＭのサムチェック処理の繰り返し回数が他の遊技状況に比べて増えるため、効率よくＲＯＭのサムチェック処理を行うことができる。
【００６９】
以上に述べた第３実施形態では、入賞検出が所定時間（一例として、５分）に亘ってないことを契機として、ＲＯＭのサムチェック処理を実行するようにしているが、ＲＯＭのサムチェック処理を実行する契機は、入賞検出に限られない。例えば、賞球制御基板に接続されると共に、実際に排出された賞球を検出する賞球検出器の検出状況を契機としてもよい。この場合、賞球制御装置（図１参照）５が賞球検出器の球検出を監視し、球検出が所定時間に亘ってないことを検出すると（タイマのタイムアップ）、表示制御装置４にチェック実行コマンドを送信し、表示制御装置４がこれを受けてＲＯＭのサムチェック処理を実行する構成とする。この構成によれば、メイン制御装置２が入賞検出を監視する第３実施形態のものに比べてメイン制御装置２の処理負担を軽減できる。
【００７０】
以上、本発明の実施形態について説明したが、ＲＯＭの異常を検知した場合のエラー報知について、重度な異常と軽度な異常とを区別して報知するようにしてもよい。例えば、第２実施形態で述べたように、特定のブロックで異常を検知した場合は、遊技者にも何らかの異常が生じたことが分かるように報知する。すなわち、異常を検知したブロック番号で、重度な異常か軽度な異常かを判別するようにする。軽度な異常の場合、遊技盤の専用のランプ等を点灯させる程度にし、できるだけ遊戯者に気づかれず、ホールの店員のみが気付く程度に報知することが望ましい。なお、店員が異常に気付いた場合、営業終了以降に制御装置の入れ替え等の処置をするようにすれば、遊技者の迷惑とはならない。また、重度な異常であった場合は、遊技者に分かるように、例えば、液晶表示画面の全面に異常報知画面を表示して報知する。なお、軽度な異常とは、例えば、背景の一部の色が意図しない色で表示されるような状態であって、要するに、遊技を行う上で支障のない状態を指すものである。一方、重度な異常とは、例えば、前述の特別図柄の色が、確率変動図柄、非確率変動図柄の区別なく同じ色となったり、背景の色と混同して特別図柄自体が識別し難くなるような状態であって、要するに、遊技の継続に支障が生じるような状態を指す。
【００７１】
【発明の効果】
請求項１に記載の構成によれば、制御装置は、電源投入時に実行する処理ルーチン以外の処理ルーチンにおいて、遊技機に配備されたＲＯＭの記憶内容のサムチェックを行って前記ＲＯＭの良／不良を判定する良否判定処理を繰り返すので、電源投入時以外の時、例えば、営業時間中に、ＲＯＭの内容に異常が発生した場合でも、ＲＯＭの内容の異常を検知することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るパチンコ遊技機に配備された制御系統の要部ブロック図
【図２】同上の実施形態の表示制御装置の構成を示すブロック図
【図３】本発明の第１実施形態に係る表示制御装置に配備された表示用ＣＰＵが実行する処理のメインルーチンを示すフローチャート
【図４】同上の第１実施形態に係る表示用ＣＰＵが、ＶＤＰから送信される１画像表示の完了信号によって発生するＩＮＴ１割込時に実行するＩＮＴ１割込処理のフローチャート
【図５】同上の表示用ＣＰＵが、サブ制御装置から各種コマンドの送信と共に送信されるＣＥ信号によって発生するＩＮＴ２割込時に実行するＩＮＴ２割込処理のフローチャート
【図６】同上の表示用ＣＰＵが実行する第１実施形態のＲＯＭのサムチェック処理のサブルーチンを示すフローチャート
【図７】表示用ＣＰＵが実行する第２実施形態のＲＯＭのサムチェック処理のサブルーチンを示すフローチャート
【図８】図７のフローチャートのつづき
【図９】本発明の第３実施形態に係るメイン制御装置に配備されたＣＰＵ（が実行する入賞チェック処理のサブルーチンを示すフローチャート
【図１０】第３実施形態に係る表示用ＣＰＵが実行するコマンド解析処理のサブルーチンの一部を示すフローチャート
【図１１】第３実施形態における表示用ＣＰＵが実行する処理のメインルーチンを示すフローチャート
【図１２】キャラクタＲＯＭの内容について、アドレス毎のブロック分けと各ブロック毎のサム値の一例を模式的に示す図
【符号の説明】
１電源装置
２メイン制御装置
３サブ制御装置
４表示制御装置
５賞球制御装置
６発射制御装置
７液晶表示装置
８払出モータ
９発射モータ
１０大入賞口ソレノイド
１１ランプ
１２スピーカ
１３タッチセンサ
１４入賞検出器
１５表示用ＣＰＵ
１６制御ＲＯＭ
１７キャラクタＲＯＭ
１８ＶＲＡＭ
１９カラーパレットＲＡＭ
２０ビデオ・ディスプレイ・プロセッサ（ＶＤＰ）
２１Ｄ／Ａコンバータ
２２液晶表示器
２３ＬＣＤドライバ回路[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a ROM abnormality detection device in which a control device performs a sum check of storage contents of a ROM provided in a gaming machine and performs a pass / fail judgment process for judging pass / fail of the ROM.
[0002]
[Prior art]
Various game control programs to be executed by the CPU are stored in the ROM of the game control device provided in the game machine. Further, in a display control device for controlling display of a symbol display device such as a liquid crystal display device provided in a game machine, a ROM in which a display control program is stored and various image data for display are stored. Character ROM is provided. The check of whether or not various control programs or various data are normally stored in the ROM is performed by checking the ROM sum and checking whether the ROM sum is normal when the gaming machine is shipped. After the gaming machine is shipped, the ROM sum is not checked.
[0003]
However, after the gaming machine is shipped, for example, it may not be possible to determine that the content is abnormal even though the contents of the ROM are abnormal. For example, a so-called shallow and unstable state, such as a defective write in a ROM, is determined to be normal at the beginning of the check, but the state is changed to a stable state at an unspecified time due to factors such as heat. May stabilize to a different value than the expected data. In such a case, the color or shape of the displayed image is unintended, but the unintended image continues to be displayed because it is not conventionally determined to be abnormal.
[0004]
When the power is turned on, the CPU arranged on the main board of the gaming machine performs a sum check of the game control program stored in the ROM and a sum check of the image control program in the system check processing, and a system check result (appropriate / There has been proposed a gaming machine that displays (unsuitable) on an image display device (for example, see Patent Document 1).
[0005]
However, in a conventional gaming machine, the ROM sum is checked only when the power is turned on. Therefore, if an abnormality occurs in the contents of the ROM during business hours, it cannot be detected, and a malfunction occurs during the game. May cause.
[0006]
[Patent Document 1]
JP-A-8-322980 (page 12, paragraph 0100-page 0103, FIG. 32)
[0007]
[Problems to be solved by the invention]
An object of the present invention is to provide a gaming machine capable of detecting an abnormality in the contents of a ROM even when the contents of the ROM occur during a time other than when the power is turned on, for example, during business hours. .
[0008]
[Means for Solving the Problems]
In the ROM abnormality detection device according to the first aspect, the control device performs a good / bad determination process of performing a sum check of the storage content of the ROM provided in the game machine to determine whether the ROM is good or bad. In order to solve the above problem, the control device repeats the pass / fail determination processing in a processing routine other than a processing routine executed when power is turned on.
[0009]
The ROM abnormality detection device according to claim 1 may be configured as follows. The control device starts the pass / fail judgment process in the remaining time of the process executed by the control device. On the other hand, if the remaining time expires before judging the pass / fail of the ROM, the pass / fail judgment is made. In some cases, the determination process is interrupted, and the pass / fail determination process is continued and restarted again in the remaining time of the process to determine the pass / fail of the ROM. According to this configuration, for example, even if an abnormality occurs in the contents of the ROM during business hours, an abnormality in the contents of the ROM can be detected.
[0010]
In addition, the control device performs a good / bad determination process for determining the good / bad of the ROM by performing a sum check of the storage content of the ROM provided in the gaming machine, wherein the operating state / non-operation of the gaming machine is determined. Operating state determining means for determining a state; wherein the control device starts the pass / fail determination processing when the operating state determining means determines that the operating state is not in operation; Before the operation, if the active firing state determination unit determines that the operating state, is to suspend the pass / fail determination process, again, if the operating state determination unit determines that the non-operating state, In some cases, the pass / fail judgment processing is continued and restarted to judge pass / fail of the ROM. According to this configuration, for example, even if an abnormality occurs in the contents of the ROM during business hours, an abnormality in the contents of the ROM can be detected. In addition, when the gaming machine, which has a light processing load on the control device, is in the non-operation state as compared with the case where the gaming machine is in the operation state, the quality determination processing of the ROM is performed, so that the quality determination processing can be performed efficiently.
[0011]
Further, in the above, the control device may divide the content of the ROM into a plurality of blocks and perform a sum check for each block to determine whether the ROM is good or defective. According to this configuration, if there is an abnormality in the contents of the block, it is determined that the contents are inappropriate. Therefore, it is possible to discover that the contents of the ROM are inappropriate without performing the checksum of the ROM to the end. Can be found quickly, and its abnormal location can be specified in the form of a block in which the abnormality is found.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram of a main part of a control system provided in the pachinko gaming machine of the present embodiment. The power supply device 1 is provided with a main control device 2, a sub control device 3, a display control device 4, a prize ball control device 5, a launch control device 6, a liquid crystal display device 7, a payout motor 8, a launch motor 9, This is for generating and supplying operating power for the winning opening solenoid 10, the lamp 11, the speaker 12, and the like.
[0013]
The pachinko gaming machine according to the present embodiment includes a main control device 2 that performs overall control of the pachinko game, and a lamp (decorative lamp, decorative LED, display) based on information (command) transmitted from the main control device 2. A sub-controller 3 that performs display control such as lighting and blinking of a lamp 11 and a display LED, and voice control that emits a sound from a speaker 12, and a command transmitted from the main control device 2 via the sub-controller 3. In response to this, the display control device 4 that displays symbols and various game information on the liquid crystal display device 7, and the prize by driving the payout motor 8 based on the information (prize ball command) transmitted from the main control device 2. A prize ball control device 5 that performs a payout control of a ball, and a launching module of a hit ball launching device (not shown) that launches a game ball toward a game board surface (not shown) on condition of a detection signal of the touch sensor 13. A firing control unit 6 is deployed for controlling the operation of the motor 9.
[0014]
The main control device 2 (main control unit) is provided on a main control board (not shown). The main control device 2 is a main CPU serving as a processing execution unit for performing overall control related to the pachinko game, and necessary for executing a game control program and a game control program related to the entire pachinko game to be executed by the main CPU. A ROM in which predetermined setting data is stored, a RAM that can be read and written at any time, and a detection signal sent from various winning detection means can be received and input to the main CPU. It includes an input / output interface for enabling control output to an external device, a communication interface for the main CPU to perform data communication with peripheral devices, and the like. The illustration of the specific configuration of the main control device 2 is omitted.
[0015]
As the various winning detection means, for example, a starting opening winning detection switch (also referred to as a starting opening sensor) for detecting a game ball winning a starting opening (symbol starting opening) provided on a game board surface (not shown), A gate sensor that detects the passage of a game ball to a set gate (not shown), and detects a game ball that has won a big winning opening provided in an electric accessory device (not shown) provided on a game board surface. A special winning opening sensor (not shown), a specific area sensor for detecting a game ball that has won a specific area provided in the special winning opening, and the like. In FIG. 1, various winning detection means are described as a winning detector 14. The external device includes a special winning opening solenoid 10 for opening the special winning opening. Note that the prize ball control device 5 and the launch control device 6 are well known, and are not directly related to the gist of the present invention, so that illustration and description of a specific configuration are omitted.
[0016]
The main control device 2 and the sub control device 3 are connected so that only one-way communication from the main control device 2 to the sub control device 3 is possible. The sub-control device 3 includes a sub-CPU as a process execution unit for performing control such as lighting / flashing of a lamp, voice control, receiving a command transmitted from the main control device 2, and transmitting a command to the display control device 4. A control program related to lamp lighting / flashing, a control program related to sound generation, a control program related to command reception and a control program related to command transmission, and a predetermined program required to execute these various control programs to be executed by the CPU. A ROM in which setting data (lamp lighting pattern and sound data) is stored, a RAM that can be read and written as needed, an output interface for enabling control output from the sub CPU, and a sub CPU. Communication for performing data communication between the control device 2 and the display control device 4; It is configured to include an interface and the like. In addition, illustration of a specific configuration of the sub control device 3 is omitted.
[0017]
A lamp 11 and a speaker 12 are connected to the sub control device 3. The sub-controller 3 drives the lamp 11 in accordance with a command transmitted from the main controller 2 and generates a sound effect and an alarm from the speaker 12. When receiving the command transmitted from the main control device 2, if the received command is a command related to the control performed by itself, the sub control device 3 stores the command and transmits the command to the display control device 4. On the other hand, if the received command is not related to the control performed by itself, this command is transmitted to the display control device 4 as it is.
[0018]
The display control device 4 displays a special design, a decorative design, a still image or a moving image (such as a character) on the display screen of the liquid crystal display device 7 in response to a command transmitted from the sub-control device 3, and a game that changes with the progress of the game. Information (for example, a hold state related to a start winning prize, the number of rounds during a big hit game, etc.) is displayed and controlled.
[0019]
FIG. 2 is a block diagram illustrating a configuration of the display control device 4. As shown in FIG. 2, the display control device 4 according to the present embodiment mainly includes a display CPU 15, a control ROM 16, a character ROM 17, a VRAM 18, a color palette RAM 19, a video display processor (hereinafter simply referred to as VDP) 20. , D / A converter 21. The display CPU 15 is connected to the sub-control device 3. The display CPU 15 receives command data transmitted and output from the sub control device 3 and performs a process of outputting a control signal to the VDP 20 according to a control program stored in the control ROM 16. More specifically, control is performed by reading variation pattern data (scheduler data) specified by the command data output from the sub-control device 3 from the control ROM 16, sequentially decoding the read scheduler data, and handling the scheduler data by the VDP 20. A process of converting the control signal into a signal and outputting the converted control signal to the VDP 20 is performed. Here, the scheduler data is data that defines a temporal schedule of a series of images displayed on the liquid crystal display device 7 (for example, a special symbol stop timing and the like).
[0020]
The VDP 20 is a known VDP of a line buffer system, receives a control signal output from the display CPU 15, generates display data from data stored in the character ROM 17, the color pallet RAM 19, and the VRAM 18, and generates the generated display. The processing for outputting the data for use to the liquid crystal display device 7 via the D / A converter 21 is performed. Specifically, the character ROM 17 specifies display data (the colors of each dot of n × n) for displaying the display characters (numbers, animations, backgrounds, and the like constituting the special symbols) on the liquid crystal display device 7. (Consisting of a color number). The color palette RAM 19 stores color data for each color number. The VRAM 18 stores data specifying which character number display data is to be arranged in a plurality of areas set in the image creation area.
[0021]
When the control signal output from the display CPU 15 is input, the VDP 20 performs the following processing according to the control signal. That is, the VDP 20 arranges the display data stored in the character ROM 17 in each area constituting the image creation area based on the data stored in the VRAM 18. Next, the VDP 20 extracts one scanning line from the image creation area where the display data is arranged, and converts the display data (color number) constituting each scanning line into color data using the data of the color pallet RAM 19. I do. Then, the created display data of one scanning line is sequentially output to the liquid crystal display device 7 via the D / A converter 21. The VDP 20 outputs a clock signal to the liquid crystal display device 7 in synchronization with the output of the created display data.
[0022]
The liquid crystal display device 7 includes a liquid crystal display 22 (n × m dots) and an LCD driver circuit 23 for driving the liquid crystal display 22. The LCD driver circuit 23 is connected to the above-described VDP 20, and receives image data and a clock signal output from the VDP 20. A liquid crystal display 22 is connected to the LCD driver circuit 23, and a drive signal is output from the LCD driver circuit 23 to the liquid crystal display 22. In such a configuration, the LCD driver circuit 23 counts the clock signal output from the VDP 20 to determine the number of the scanning line and the number of the image data to be input. Therefore, when the image data is sequentially input to the LCD driver circuit 23, the input image data is determined based on the clock signal as to which scan line the image data is, and at the same time, the image data of one scan line output from the VDP 20 is output. The order of the image data is determined. Then, an image is displayed on the first dot of the corresponding scanning line of the liquid crystal display 22 based on the input image data. Thereafter, each time image data is input, an image of the next dot is displayed in order based on the input image data. Then, when an image is displayed by the image data of one scanning line corresponding to the display area of the liquid crystal display 22, the apparatus stands by in that state until image data of the next scanning line is input. Then, one image is displayed on the liquid crystal display 22 by performing the above processing for all the scanning lines.
[0023]
A description will be given of a ROM abnormality detection device in the gaming machine of the embodiment configured as described above. In the present embodiment, the display control device 4 corresponds to the control device described in claims 1 to 3. Further, the ROM described in claims 1 to 3 corresponds to the character ROM 17 provided in the display control device 4.
[0024]
A first embodiment of the ROM abnormality detection device will be described. The abnormality detection device for the ROM of the first embodiment performs a sum check of the stored contents of the character ROM 17 in the remaining time of the main routine process executed by the display control device 4 to determine whether the character ROM 17 is good or bad. On the other hand, if the remaining time has expired before judging whether the character ROM 17 is good or bad, the good / bad judgment processing is interrupted, and the good / bad judgment processing is continued and resumed again in the remaining time of the main processing. Then, the quality / defectiveness of the character ROM 17 is determined. In the embodiment, the pass / fail determination processing described in claim 1 corresponds to the ROM checksum processing (described later) in step B05.
[0025]
FIG. 3 is a flowchart illustrating a main routine of a process executed by the display CPU 15 (hereinafter, referred to as a display CPU) provided in the display control device 4. FIG. 4 is a flowchart of an INT1 interrupt process executed by the display CPU at the time of an INT1 interrupt generated by a one-image display completion signal transmitted from the VDP 20. FIG. 5 is a flowchart of an INT2 interrupt process executed by the display CPU at the time of an INT2 interrupt generated by a CE signal transmitted together with transmission of various commands from the sub-control device 3.
[0026]
In the main routine of FIG. 3, when the power is turned on, the display CPU performs an initialization process in step B01, and initializes flags and registers necessary for the following processes. In the present embodiment, the initialization corresponds to a processing routine executed when the power is turned on. Next, the display CPU determines whether or not the interrupt flag is set (step B02). Note that the value of the interrupt flag has been set to “0 (clear)” by the initialization processing in step B01. The display CPU determines that step B02 is false, and proceeds to the ROM checksum process of step B05. When the display CPU exits the ROM sum check process of the current process, the process returns to step B02, and determines again whether or not the interrupt flag is set. Therefore, the display CPU repeatedly performs step B02 and repeats the ROM checksum process of step B05 until the interrupt flag is set. As described above, the present invention is configured to execute the ROM checksum processing in a processing routine other than the processing routine executed when the power is turned on.
[0027]
When the VDP 20 is ready to display the entire screen on the display screen of the liquid crystal display device 7 (it takes approximately 16 ms for the VDP 20 to display the entire screen), the display CPU completes displaying one image. Send a signal. This completion signal is input to the INT1 terminal of the display CPU. As a result, an INT1 interrupt occurs in the display CPU, and the INT1 interrupt processing of FIG. 4 is executed. The VDP 20 transmits a completion signal for displaying one image to the display CPU at intervals of approximately 16 ms. Therefore, the INT1 interrupt occurs approximately every 16 ms in the display CPU. When the display CPU starts the INT1 interrupt processing, it sets an interrupt flag (step B06) and returns to the main routine (specifically, the next address of the program address that was being executed when the interrupt occurred). Back to).
[0028]
The sub-control device 3 transmits a CE signal to the display CPU together with various commands. This CE signal is input to the INT2 terminal of the display CPU. As a result, an INT2 interrupt occurs in the display CPU, and the INT2 interrupt processing of FIG. 5 is executed. When the display CPU starts the INT2 interrupt processing, the display CPU receives the command transmitted from the sub-control device 3 (step B07), analyzes what the received command is, and responds to the analysis result. Various flags are set (step B08), and the process returns to the main routine (specifically, returns to the address next to the program address being executed when the interrupt occurred).
[0029]
When the INT1 interrupt occurs, the interrupt flag is set. As a result, the display CPU determines that step B02 is true, and in the main process of step B03, the display CPU responds to the display command specified by the command format from the sub control device 3. A process for setting various data necessary for displaying the corresponding image and a process for outputting the set various data to the VDP 20 are performed. After exiting the main processing, the display CPU clears the interrupt flag to 0 (step B04), returns to step B02, determines whether or not the interrupt flag is set (step B02), and interrupts again. Until the flag is set, step B02 is false, and the ROM checksum process of step B05 is repeatedly executed.
[0030]
As understood from the above description, the main processing of step B03 and the processing of clearing the interrupt flag to 0 in step B04 are executed every time the interrupt flag is set by the INT1 interrupt. Since the INT1 interrupt occurs approximately every 16 ms, the display CPU clears the interrupt flag in step B03 from the main process in step B03 and the interrupt flag in step B04 from approximately 16 ms between the INT1 interrupt and the next INT1 interrupt. (The required time varies depending on the length of time required for the display CPU to execute the main processing) is the idle time (remaining time) in the processing. . In the present invention, the sum check process of the ROM in step B05 is performed using the idle time.
[0031]
FIG. 6 is a flowchart showing a subroutine of a ROM checksum process executed by the display CPU. In this process, the display CPU performs a checksum of the contents of the character ROM 17 (base data of the image). The display CPU first determines whether or not the start flag is 0 (step A11). The start flag is a flag for identifying whether or not the display CPU newly starts the ROM sum check processing. The initial value is set to “0 (new)” by the initialization processing in step B01. Have been.
[0032]
The display CPU determines that step A11 is true, sets the start flag to 1 and stores the new start of the ROM sum check processing (step A12), and clears the ROM sum storage area set in the RAM to 0. (Step A13), the ROM reference address storage area set in the RAM is cleared to 0 (Step A14), and the process proceeds to Step A15.
[0033]
In step A15, the display CPU adds and stores the ROM data (character ROM data) of the ROM reference address to the ROM sum (step A15), and updates the ROM reference address to the next address (for example, 1 byte). If the reading is in units, the reference address is incremented by 1 (step A16), and it is determined whether or not the updated ROM reference address has exceeded the ROM final address (step A17). If the updated ROM reference address does not exceed the ROM final address, the display CPU determines that step A17 is false, exits the current ROM checksum process, and returns to the main routine. When returning to the main routine, the display CPU determines that step B02 is false as a result of the interrupt flag being 0 (clearing the interrupt flag), and executes the ROM checksum process of step B05 again. I do.
[0034]
After the display CPU newly starts the ROM checksum processing, the start flag is set to 1 and as a result, the display CPU determines that step A11 is false and proceeds to step A15. The display CPU performs step A15 based on the updated ROM reference address, updates the ROM reference address to the next address again in step A16, and determines whether the updated ROM reference address has exceeded the ROM final address. If it is determined (step A17) that the ROM reference address does not exceed the ROM final address, the process exits the current ROM checksum process and returns to the main routine.
[0035]
As described above, in the ROM checksum processing, if the ROM reference address does not exceed the ROM final address, the display CPU performs a processing routine for determining false in step A11 and false in steps A15, A16, and A17. repeat. Therefore, the ROM sum of the character ROM 17 is added every time the above processing routine is performed. Then, while the above processing routine is being executed, an INT1 interrupt occurs. When the INT1 interrupt occurs, the display CPU interrupts the process and executes the INT1 interrupt process. The program address that was being executed when the interrupt occurred is stored, and when the INT1 interrupt process ends, the program returns to the next address and the process is continued and resumed. Then, in response to the interrupt flag being set by the execution of the INT1 interrupt process, the main process of step B03 and the process of clearing the interrupt flag to 0 in step B04 are executed, and step B02 is determined to be false. Again, the ROM checksum processing is continued and restarted.
[0036]
In this way, the ROM reference address exceeds the ROM final address while the display CPU repeats the processing routine of determining false in step A11 and false in steps A15, A16, and A17. When the ROM reference address exceeds the ROM final address, the display CPU determines that step A17 is true and determines whether the ROM sum matches the ROM determination sum (step A18). If the ROM sum matches the ROM determination sum, it is determined that the contents of the character ROM 17 are normal, step A18 is determined to be true, the start flag is cleared to 0 (step A19), and the ROM checksum processing is performed. And returns to the main routine.
[0037]
On the other hand, if the ROM sum does not match the ROM determination sum, it is determined that the contents of the character ROM 17 are abnormal, step A18 is determined to be false, and an error is notified (step A20). Further, instead of immediately notifying the error, the determination may be repeatedly performed. For example, the notification may be performed if the abnormality is determined twice. By doing so, the reliability of the determination can be increased. The error is reported by displaying a sign at the corner of the screen of the liquid crystal display device 7 so that the error can be visually identified, outputting error information from an external output terminal to a management computer (not shown), or the like. Done by
[0038]
Thus, the first ROM sum check processing is completed. As a result of the start flag being cleared to 0, in the next ROM checksum processing, the determination result of step A11 becomes true, and the display CPU newly starts the ROM checksum processing again. . As understood from the above description, in the present invention, in the processing routine other than the processing routine executed when the power is turned on, the checksum of the ROM is performed, and the determination of the good / bad of the ROM is repeated.
[0039]
In a data ROM such as the character ROM 17 used for storing and storing basic data of an image, the control program often operates normally even when the contents of the ROM are abnormal, and the contents of the ROM are often used. Despite being abnormal, it is often not possible to determine that it is abnormal. However, if the basic data of the image is abnormal as in the character ROM 17, for example, the display color of the big hit symbol (there are two types, a big hit symbol that shifts to probability variation and a big hit symbol with the normal probability) is abnormal. It may happen that the image is displayed in a different color. Specifically, although the displayed big hit symbol is a big hit symbol that normally has the probability, the display color of this big hit symbol is displayed in “red” meaning a probable change symbol (originally, the normal big hit symbol) The big hit symbol that remains the probability must be displayed in "blue").
[0040]
The ROM abnormality detection device of the present embodiment performs the ROM checksum process in step B05 using the idle time (remaining time) of the main routine process as described above. If the content of the character ROM 17 is abnormal due to the ROM checksum process, the character ROM 17 can be detected as abnormal. Therefore, even when the content of the character ROM is abnormal at times other than when the power is turned on, for example, during business hours, the abnormality of the content of the character ROM can be detected. When an abnormality in the contents of the character ROM is detected, it is unknown whether the degree of the abnormality is an abnormality that has a great effect on the game or an abnormality that hardly affects the game, In the present embodiment, an error is notified and the game itself is temporarily continued.
[0041]
Next, a second embodiment of the ROM abnormality detection device will be described. The ROM abnormality detection device according to the second embodiment is different from the ROM abnormality detection device according to the first embodiment in that the content of the ROM is divided into a plurality of blocks and a sum check is performed for each block to determine whether the ROM is good or defective. Is what you do. FIG. 12 is a diagram schematically showing an example of the contents of the character ROM 17 divided into blocks for each address and a sum value for each block. In the example shown in FIG. 12, addresses “0000” to “0003” are the first block (ROM block number “1”), the sum value of which is “a”, and addresses “0004” to “0007”. In the second block (ROM block number “2”), the sum value is set as “b”,.
[0042]
FIGS. 7 and 8 are flowcharts showing a subroutine of the ROM sum check process of the second embodiment executed by the display CPU. The display CPU first determines whether or not the start flag is 0 (step A31). The start flag is a flag for identifying whether or not the display CPU newly starts the ROM sum check processing. The initial value is set to “0 (new)” by the initialization processing in step B01. Have been.
[0043]
The display CPU determines that step A31 is true, sets 1 to the start flag, and stores the new start of the ROM sum check process (step A32). Next, the display CPU sets the initial value of the ROM block number “1” in the ROM block number storage area (RBNO) set in the RAM (step A33), and proceeds to step A34.
[0044]
In step A34, the display CPU sets the ROM start address corresponding to RBNO (ROM block number) in the ROM reference address storage area set in RAM (step A34), and sets the RBNO (ROM block number). The corresponding ROM final address is set in the ROM final address storage area set in the RAM (step A35), and the ROM sum corresponding to RBNO (ROM block number) is set in the ROM determination sum set in the RAM. (Step A36), the ROM sum storage area set in the RAM is cleared to 0 (Step A37), the condition setting flag is cleared to 0 (Step A38), and the process proceeds to Step A39. Note that the condition setting flag is a flag for determining whether or not the display CPU sets the conditions for the blocks in steps A34 to A37, and is “0” for “not performed” and “1” for “1”. This is a flag that means "do."
[0045]
In addition, as an example of a specific setting in steps A34 to A36, when the ROM block number is “2”, the ROM start address “0004” is set as the ROM reference address, and the ROM end address “0007” is set. Is set to the ROM final address, and the ROM sum "b" is set to the ROM determination sum.
[0046]
In step A39, the display CPU adds the ROM data of the ROM reference address to the ROM sum and stores it (step A39), and updates the ROM reference address to the next address (for example, if reading is performed in units of 1 byte). For example, the reference address is incremented by 1) (step A40), and it is determined whether or not the updated ROM reference address has exceeded the ROM final address (step A41). If the updated ROM reference address does not exceed the ROM final address, the display CPU determines that step A41 is false, exits the current ROM sum check process, and returns to the main routine. When returning to the main routine, the display CPU determines that step B02 is false as a result of the interrupt flag being 0 (clearing the interrupt flag), and executes the ROM checksum process of step B05 again. (See FIG. 3).
[0047]
After the display CPU newly starts the ROM checksum processing, the start flag is set to 1 and as a result, the display CPU determines that step A31 is false and proceeds to step A42. The display CPU determines whether or not the condition setting flag is “1” (whether or not to set the condition for the block). If the condition for the block has already been set, the condition is set in step A38. Since the setting flag has been cleared to 0, step A42 is determined to be false and the process proceeds to step A39.
[0048]
The display CPU performs step A39 based on the updated ROM reference address, updates the ROM reference address to the next address again in step A40, and determines whether the updated ROM reference address has exceeded the ROM final address. If it is determined (step A41) that the ROM reference address does not exceed the ROM final address, the process exits the current ROM checksum process and returns to the main routine.
[0049]
As described above, in the ROM sum check process, if the ROM reference address does not exceed the ROM final address, the step A31 is false, the step A42 is false, and the steps A39, A40, and A41 are false. The processing routine for determining is repeated. Therefore, the ROM sum specified by RBNO of the character ROM 17 is added every time the above processing routine is performed. If the INT1 interrupt does not occur during the execution of the above processing routine, the ROM reference address exceeds the ROM final address (the final address of the block). The display CPU determines that step A41 is true, and determines whether the ROM sum matches the ROM determination sum (the determination sum of the block) (step A43). If the ROM sum matches the ROM determination sum, it is determined that the contents of the block number in the character ROM 17 are normal, step A43 is determined to be true, and the process proceeds to step A45.
[0050]
In step A45, the display CPU increments the ROM block number RBNO by 1 (step A45), and determines whether or not the updated ROM block number RBNO exceeds the final ROM block number (step A46). If the updated ROM block number RBNO does not exceed the final ROM block number, the condition setting flag is set to 1 (step A47), and the process exits the current ROM sum check process and returns to the main routine.
[0051]
In the next ROM sum check process, the display CPU determines that the step A31 is false and the condition setting flag is set to 1. As a result, the display CPU determines that the step A42 is true and proceeds to the step A34. The CPU sets conditions for the block designated by the next block number (steps A34 to A36), clears the ROM sum to 0 (step A37), clears the condition setting flag to 0 (step A38), and Proceed to A39. Accordingly, the ROM checksum processing is started for the block specified by the next block number.
[0052]
If an INT1 interrupt occurs during execution of the above processing routine, the display CPU interrupts the process and executes the INT1 interrupt process. The program address that was being executed when the interrupt occurred is stored, and when the INT1 interrupt process ends, the program returns to the next address and the process is continued and resumed. Then, in response to the interrupt flag being set by the execution of the INT1 interrupt process, the main process of step B03 and the process of clearing the interrupt flag to 0 in step B04 are executed, and step B02 is determined to be false. Again, the ROM checksum processing is continued and restarted.
[0053]
If the ROM sum does not match the ROM determination sum (the determination sum of the block) in step A43, it is determined that the content of the block in the character ROM 17 is abnormal, and step A43 is determined to be false. Then, an error is notified (step A44).
[0054]
If the updated ROM block number RBNO exceeds the final ROM block number in step A46, this means that the first ROM sum check process has been completed, and the display CPU sets step A47 to true. Is determined, the start flag is cleared to 0 (step A48), the ROM checksum process is completed, and the process returns to the main routine. As a result of clearing the start flag to 0, in the next ROM checksum processing, the result of the determination in step A31 becomes true, so that the display CPU newly starts the ROM checksum processing again. .
[0055]
In the above-described first embodiment, in the ROM sum check processing, the ROM sum is added to the final address of the contents of the ROM to determine the ROM sum. In the second embodiment, the ROM sum check processing is performed. In the above method, the content of the ROM is divided into a plurality of blocks, and a sum check is performed for each block to determine whether the ROM is good or bad. Since the detection can be performed, the abnormality of the ROM can be detected at an early stage.
[0056]
Next, a third embodiment of the ROM abnormality detection device will be described. The ROM abnormality detection device according to the third embodiment executes / interrupts the ROM checksum processing in accordance with the non-operation state / operation state of the gaming machine. The non-operational state / operating state of the gaming machine in the specification does not mean the power-off state / power-on state of the gaming machine. The operating state of the gaming machine means a state in which the gaming machine is actually playing a game, and the non-operating state of the gaming machine means that the gaming machine is playing a game for a predetermined time. No state means. In the present embodiment, the non-operating state / operating state of the gaming machine is determined when the winning detection is not performed for a predetermined period of time (for example, 5 minutes), and the non-operating state of the gaming machine is determined. If it is at least once in a predetermined time (for example, 5 minutes), it is treated as the operating state of the gaming machine.
[0057]
FIG. 9 is a flowchart illustrating a subroutine of a winning check process executed by a CPU (hereinafter, referred to as a main CPU) provided in the main control device 2. When the winning check process is started, the main CPU first determines whether or not a winning is detected (step S11). If there is a detection signal from the winning detector 14 (see FIG. 1), it means that winning is detected. Since there is no winning detection immediately after power-on, the main CPU determines that step S11 is false, proceeds to step S12, and determines whether or not the timer is 0 (step S12). This timer is a timer for setting a monitoring time (for example, 5 minutes) for monitoring whether or not winning detection has been performed for a predetermined time. Immediately after power-on, the timer is initialized and the timer value is set to 0. The main CPU determines that step S12 is true, sets a check execution command to be transmitted to the sub-control device 3 (step S13), and sets 1 (transmitted) to the transmitted flag (step S14). The process proceeds to S15, in which a monitoring time (for example, 5 minutes) related to winning detection is set in a timer (step S15), and the process exits the current winning check process and returns to a main routine (not shown). The timer value set in the timer is decremented at predetermined intervals by a timer decrement process (not shown). The check execution command set in step S14 is transmitted to the sub-control device 3 by a command output process (not shown).
[0058]
In the prize check processing in the next cycle and thereafter, if no prize is detected during the monitoring time (5 minutes), the main CPU repeats the processing routine of determining step S11 to be false and step S12 to be false. Then, when the monitoring time (5 minutes) elapses, it is detected that the value of the timer is 0 in step S12, it is determined that step S12 is true, and steps S13, S14, and S15 are performed again. The process returns from the winning check process to a main routine (not shown).
[0059]
On the other hand, if the winning detection is performed before the monitoring time elapses, that is, before the timer value set in the timer becomes 0, the display CPU determines that step S11 is true, Proceeding to step S12, it is determined whether or not the value of the transmitted flag is 1 (step S12). The transmitted flag is a flag for identifying whether or not a check execution command (described later) has been transmitted to the sub-control device 3, and its initial value is “0”. As a result of the transmission flag being set to 1, the main CPU determines that step S12 is true. The display CPU sets a check interruption command to be transmitted to the sub-control device 3 (step S17), clears the transmitted flag to 0 (step S18), and proceeds to step S15. (For example, 5 minutes) is set (step S15), and the process exits the current winning check process and returns to the main routine (not shown). The check suspension command set in step S17 is transmitted to the sub control device 3 by a command output process (not shown).
[0060]
In the prize check process in the next cycle and thereafter, if no prize is detected during the monitoring time (5 minutes) after transmitting the check interruption command, the main CPU determines that step S11 is false and step S12 is false. Repeat the routine. When the monitoring time (5 minutes) has elapsed, it is detected in step S12 that the value of the timer is 0, the step S12 is determined to be true, and the check execution command transmitted to the sub-control device 3 again. Is set (step S13), the transmitted flag is set to 1 (transmitted) (step S14), the process proceeds to step S15, and a monitoring time (for example, 5 minutes) related to winning detection is set in a timer (step S15). ), And returns to the main routine (not shown) through the current winning check processing. Therefore, if there is no winning detection during the monitoring time (5 minutes) after transmitting the check interruption command, a check execution command is transmitted to the sub-control device 3.
[0061]
On the other hand, in the prize check processing in the next cycle and thereafter, if a prize is detected during the monitoring time (5 minutes) after the transmission of the check interruption command, the display CPU determines that step S11 is true, and the transmitted CPU has been transmitted. As a result of the flag being cleared to 0, step S16 is determined to be false, the process proceeds to step S15, and a new monitoring time (for example, 5 minutes) related to winning detection is set in the timer (step S15). After the checking process, the process returns to the main routine (not shown). Therefore, every time there is a winning detection during the monitoring time (5 minutes), the monitoring time (5 minutes) is updated and set in the timer, so that the winning detection is performed during the monitoring time (5 minutes). As long as there is, the timer will not expire. Therefore, as long as winning detection continues during the monitoring time (5 minutes) after transmitting the check interruption command, the check execution command is not transmitted to the sub-control device 3.
[0062]
The check execution command and the check interruption command transmitted from the main control device 2 are temporarily received by the sub-control device 3, and the command received by the sub-control device 3 is determined as a command not related to the control performed by the sub-control device 3, and the command is determined. It is transmitted to the display control device 4 as it is.
[0063]
Next, the sum check processing of the ROM of the display control device 4 according to the check execution command and the check suspension command transmitted via the sub control device 3 will be described. When the check execution command and the check interruption command are transmitted to the display control device 4, an INT2 interrupt occurs in the display CPU. The display CPU proceeds to the INT2 interrupt processing, receives a command in the command reception processing (step B07), analyzes the received command in the command analysis processing, and sets various flags according to the analysis result (step B07). B08), and returns to the main routine (see FIG. 5).
[0064]
FIG. 10 is a flowchart illustrating a part of a subroutine of a command analysis process executed by the display CPU. While analyzing the received command, the display CPU determines whether the received command is a check execution command (step A51). If the received command is a check execution command, the execution flag F1 relating to the sum check processing of the ROM is set to 1 (step A52), and the process exits the command analysis processing. On the other hand, if the received command is not the check execution command, it is determined whether or not the received command is a check interruption command (step A53). When the received command is the check interruption command, the display CPU clears the execution flag F1 relating to the sum check processing of the ROM to 0 (step A54) and exits the command analysis processing. If the received command is neither a check execution command nor a check interruption command, the processing of the execution flag F1 relating to the ROM sum check processing is not performed, and the value of the execution flag F1 remains as it is.
[0065]
FIG. 11 is a flowchart illustrating a main routine of a process executed by the display CPU in the third embodiment of the ROM abnormality detection device. The difference between the main routine of the process executed by the display CPU of the ROM abnormality detection device of the third embodiment and the process executed by the display CPU of the ROM abnormality detection device of the first embodiment is that The only difference is that the ROM checksum processing is performed according to the set state of the flag F1, and the other points are the same as in the first embodiment.
[0066]
When determining that the interrupt flag has not been set in step B02, the display CPU determines whether or not the execution flag F1 has been set (step B10). When the execution flag F1 is set, the display CPU performs the ROM sum check process and returns to step B02. When the execution flag F1 is not set, the display CPU does not perform the ROM sum check process and proceeds to step B02. Return to B02. Note that the ROM sum check processing itself may be either the first embodiment shown in FIG. 6 or the second embodiment shown in FIGS.
[0067]
As described above, the ROM abnormality detection device according to the third embodiment executes the ROM checksum process when the winning detection is not performed for a predetermined time (for example, 5 minutes). Further, during execution of the ROM sum check processing, the execution of the ROM sum check processing is interrupted when the winning detection is performed once even in a predetermined time (for example, 5 minutes). Further, when the winning detection is not performed for a predetermined time (for example, 5 minutes), the ROM checksum processing is executed. When the execution of the ROM checksum is interrupted, the execution of the ROM checksum is restarted.
[0068]
In the display CPU, a state in which the above-described winning detection is not performed for a predetermined time (for example, 5 minutes) is a situation in which, as in the case of a demo screen, there are few moving images based on animation, and still images are displayed. Therefore, the required time in the main process of step B03 in FIG. 11 is reduced, and the remaining time of the main routine is longer than in other game situations. Therefore, the number of repetitions of the ROM checksum performed during the remaining time is increased as compared with other game situations, so that the ROM checksum can be performed efficiently.
[0069]
In the third embodiment described above, when the winning detection is not performed for a predetermined time (for example, 5 minutes), the ROM sum check processing is executed. Is not limited to winning detection. For example, it may be triggered by a detection state of a prize ball detector that is connected to the prize ball control board and detects an actually discharged prize ball. In this case, the prize ball control device (see FIG. 1) 5 monitors the ball detection of the prize ball detector, and when it detects that the ball detection has not been performed for a predetermined time (time-up of the timer), the display control device 4 A check execution command is transmitted, and the display control device 4 receives the command and executes a ROM checksum process. According to this configuration, the processing load on the main control device 2 can be reduced as compared with the third embodiment in which the main control device 2 monitors winning detection.
[0070]
As described above, the embodiment of the present invention has been described. However, regarding the error notification when the abnormality of the ROM is detected, the error may be notified while distinguishing between the severe abnormality and the mild abnormality. For example, as described in the second embodiment, when an abnormality is detected in a specific block, the player is notified so as to know that some abnormality has occurred. That is, it is determined whether the abnormality is a serious abnormality or a minor abnormality based on the block number at which the abnormality is detected. In the case of a minor abnormality, it is desirable to turn on a dedicated lamp or the like of the game board, and to notify the player as little as possible without notice of the player as much as possible. In addition, if the store clerk notices an abnormality, if a countermeasure such as replacement of the control device is performed after the business is over, the player is not inconvenienced. In addition, when a serious abnormality is detected, an abnormality notification screen is displayed and displayed on the entire surface of the liquid crystal display screen, for example, so that the player can understand. Note that the mild abnormality is, for example, a state in which a part of the background is displayed in an unintended color, that is, a state in which there is no problem in playing a game. On the other hand, a severe abnormality means, for example, that the color of the above-mentioned special symbol is the same color without distinction between the probability-varying symbol and the non-probability-varying symbol, or it is difficult to identify the special symbol itself by being confused with the background color. In short, it refers to a state in which the continuation of the game is hindered.
[0071]
【The invention's effect】
According to the configuration of the first aspect, the control device checks the stored contents of the ROM provided in the gaming machine in a processing routine other than the processing routine executed when the power is turned on, and determines whether the ROM is good or defective. Is repeated, so that an abnormality in the contents of the ROM can be detected even when an abnormality occurs in the contents of the ROM other than when the power is turned on, for example, during business hours.
[Brief description of the drawings]
FIG. 1 is a block diagram of a main part of a control system provided in a pachinko gaming machine according to an embodiment of the present invention.
FIG. 2 is a block diagram showing a configuration of a display control device according to the embodiment.
FIG. 3 is a flowchart showing a main routine of a process executed by a display CPU provided in the display control device according to the first embodiment of the present invention;
FIG. 4 is a flowchart of an INT1 interrupt processing executed by the display CPU according to the first embodiment at the time of an INT1 interrupt generated by a one-image display completion signal transmitted from the VDP.
FIG. 5 is a flowchart of an INT2 interrupt process executed by the display CPU at the time of an INT2 interrupt generated by a CE signal transmitted along with transmission of various commands from the sub-control device.
FIG. 6 is a flowchart showing a subroutine of a sum check process of the ROM of the first embodiment executed by the display CPU;
FIG. 7 is a flowchart showing a subroutine of a ROM checksum process of the second embodiment executed by the display CPU;
8 is a continuation of the flowchart of FIG. 7;
FIG. 9 is a flowchart showing a subroutine of a prize check process executed by a CPU provided in a main control device according to a third embodiment of the present invention;
FIG. 10 is a flowchart showing a part of a subroutine of a command analysis process executed by a display CPU according to a third embodiment;
FIG. 11 is a flowchart illustrating a main routine of a process executed by a display CPU according to a third embodiment.
FIG. 12 is a diagram schematically showing an example of a block division for each address and a sum value for each block with respect to the contents of a character ROM;
[Explanation of symbols]
1 power supply
2 Main controller
3 Sub-control device
4 Display control device
5 Award ball control device
6 Launch control device
7 Liquid crystal display
8 Dispensing motor
9 Launch motor
10 Big Winner Solenoid
11 lamp
12 speakers
13 Touch sensor
14 Winning Detector
15 Display CPU
16 Control ROM
17 Character ROM
18 VRAM
19 Color Palette RAM
20 Video Display Processor (VDP)
21 D / A converter
22 Liquid crystal display
23 LCD driver circuit

Claims

In the ROM abnormality detection device, in which a control device performs a good / bad determination process to determine whether the ROM is good or defective by performing a sum check of a storage content of a ROM provided in the gaming machine, the control device is configured to execute at power-on. An abnormality detection device for a ROM that repeats the pass / fail judgment processing in a processing routine other than the processing routine to perform the determination.