Testing on a PE+ Machine

Here is a small update on the new game code I am writing for the PE+ platform.

I finally got around to burning the code on a chip and putting it in my real machine. The results were amazingly good. I was worried about the watchdog timer, but the code I put in place to support it works just fine.

I discovered some interesting details about the machine as I tried to enable certain features within my game.

The coin comparator turns on the coin-lockout feature by default. This means that any coins put into the machine are immediately rejected and come out in the little coin reject tray. I added code to turn off the coin-lockout and any coins inserted after that pass through the ABC optics and into the hopper. I have code in place to check for the proper ABC sequence and any coin-in timeouts before accepting the coin. These functions appear to be completely working.

Next was attempting to payout a coin from the hopper (the area that holds all the coins inside the machine). In order to successfully do this, you must enable both Hopper 1 and Hopper 2 outputs. This makes the hopper motor spin which in turn drives coins up a bar and out of the machine. At the end of the payout chute is a sensor that is triggered as the coin is leaving the machine. By creating code to enable the motor and count the number of coins passing through the sensor, I was able to acurately dispense any number of coins.

There is also support for testing when the hopper is empty, or a coin-out timeout condition occurs. And I added code to turn on the diverter when the hopper is full. This is just a simple gate that diverts coins into an overflow bucket when the hopper cannot hold anymore coins.

With this greater understanding of the hopper/payout process, I was able to fix a bug in the MAME driver that currently has issues with the hopper empty and coin-out timeout conditions. I will be submitting the fix for the next update.

Technically I believe I have most aspects of the machine covered that I will need to finish my game. There are some additional pieces I may add once the game is solid, but they are somewhat optional. This list of extra features would include:

• EEPROM Support to backup the battery-backed RAM
• Music Option (The game currently uses tones only)
• Dollar Bill Validator support (I would need to buy one for testing)
• Progressive Jackpot Feature (May need partial DUART support)
• Card Animation
• Attract Mode Animation (Blinking Play 5 Coins)
• Double Up Feature
• Soft Meters (Keeps track of coin counts etc)
• Joker Feature (Optional but would reduce paytables)

There is plenty of testing and coding to do, but I believe my knowledge of the machine is growing and will allow me to further solidify the current MAME driver over time.

3 Card Poker Diversion

Looks like my MAME adventure has changed course slightly for the time being. After learning so much about the PE+ hardware and emulating it, I decided to try my hand at creating a new romset for this platform from scratch!

The results so far are the many pictures posted here. I decided to create a game that is not currently found on this platform, and chose to go with a 3-card poker game.

The rules of the game are fairly straight-forward. You and the dealer are dealt 3 cards each and you must obtain a higher hand than the dealer. It is classic stud poker, where you don't discard and draw.

Besides the normal "ante" wager. You can place a bonus wager on the final value of your hand dealt. This "Pair Plus" wager pays even if you end up losing the hand. The bonus wager only pays if your hand is a pair or better. A paytable determines the payout for each of the bonus hands.

Once you receive your hand you can decide to either play or fold. If you play, you must place a second wager that matches your original ante. If you fold, you lose your ante wager, but can still receive your bonus payoff if you have a pair or better.

If you decide to play, the dealers cards are revealed and you are paid even money for your ante wager if you have a higher hand than the dealer. If the dealer hand qualifies (Queen high or better), your play wager also pays even money, otherwise its a push. If a tie occurs, you push both bets.

I'm developing the application using SDCC and compiling for the i8052 platform. Once compiled I convert the .HEX file to a .BIN file and test it under MAME. So far I have the video, inputs and sound mostly working. Its interesting to code from the other side of the platform. Things as simple as random number generators (which is done), etc. can be a pain to figure out, but once I am done, I will have a solid SDK for building other games.

I have been trying to create a game in the same style as IGT and therefore I have been adding support for the multiple operator screens that are used to setup the machine.

I will eventually burn the game onto a chip and test it in my real machine. But I want to make sure I have most of the bugs worked out first in MAME. Burning chips and disassembling the machine to pop in the chip takes too much time, but will need to be done sometime in the future to make sure I didn't miss something in the code (like the watchdog timer which the MAME driver ignores).

There is still plenty of code required to finish the game, but I am learning a lot about this machine as I go. And I currently have a lot of useful code for my PE+ SDK.

Superboard, Keno and Slots

The PE+ machine has at least two varieties of motherboards. The basic board I have been emulating and the superboard version. The superboard has an additional socket on it for "game data". The superboard is backwards compatable with most or all of the non-superboard games (those that begin with PP or PS etc). The superboard specific games generally are in the format of XPnnnnnn or XSnnnnnn with game data roms in a format of XnnnnnnP or XnnnnnnS. (P for poker and S for Slots)

Internally, the super board maps the game data rom in all the external addresses the non-superboard had not used. After tracing the schematics, I determined the addresses are $1000, $3000, $5000, $7000, $9000, $B000, $D000 and $F000. So even though the game rom is stored on a 64k chip, only every other page actually can contain data. This essentually adds 32K of information to the superboard romsets.

With these changes added to the driver, I can now support the rather large list of superboard roms too. The slot pictured above is the Triple Triple Diamond Video Slot (XS000006) romset for the superboard. The slot driver uncovered some additional issues with video processing that I had not encountered before. Once I figured out the issue, the slot reels lined up nicely and the gameplay was correct.

Another romset now supported is the Deuces Wild Video Poker (XP000019). It is similar to many of the video poker romsets but has a few different graphics and gameplay with 2's being wild.

Lastly, I added support for a non-superboard version of Keno (KE1012). The romset I have has a bad dump of the CG files so there is some residue on the screen on some of the larger letters. The game uses a lightpen for input, so I had to add lightpen support, but it seems to be working just fine now.

At this point I am finding some small issues with the coin hopper timing when the machine tries to payout coins. I sometimes get a hopper empty or coin-out timeout message. It appears I will need to do something similar as the ABC optics for the coin-in mechanism, but not as complex. Some initial code appears to work on the non-superboard romsets.

EEPROM Support and Blackjack

Since the last time I posted, I worked on adding I2C EEPROM support to the driver. Initially I spent a bunch of time creating the code I needed from a couple different sources I found in the MAME code base. Once I got the code working, I began to test the driver and things looked pretty good. A couple of days later, another MAME developer (smf) produced a much better library then the one I had cobbled together and helped me hook it into my driver and replace the I2C code I had already in place. The newer I2C driver worked great too and is now part of the MAME core.

Now that the I2C code is in the driver, a lot of hacks have been removed. The following is the sequence of events that take place when you load a game for the first time.

1. The first time in, the CMOS (battery-backed RAM) and the EEPROM will both be empty. You will get a "Call Attendant - CMOS Data" screen, and when you open the door and press the Self-Test button, it will attempt to load values from the EEPROM to the CMOS.
2. The next time you start the game, you will get a "Call Attendant - EEPROM Data" screen. When you open the door and press the Self-Test button, it will attempt to load the EEPROM with default data found in the game code.
3. At this point, both the CMOS and EEPROM contain some default values and you must enter operator mode to fill in any missing values such as denomination.
4. From that point on, all restarts of the game will react properly and the game will display.

I have found a few games that are having issues when using the 8052 specific Timer 2. These games do not let you proceed past step 1 as of yet. I'm thinking the I8051 driver in MAME may not be working for this scenario, or I am missing some other piece in my driver.

Finally, as you can see from the picture above, I have included in the driver support for a new fully working clone (PEBE0014) which is the IGT Blackjack program that also runs on the PE+ platform.

The ABC's of Coin Optics

After a bunch of research and trial and error, I finally got the coin-in functionality to work.

This type of IGT machine uses an ABC coin optic detector translator. Basically what happens is the coin is dropped into the coin slot and passes through 3 different optics (A, B & C). As the coin passes through each optic, the optic's state changes from zero to one for a short period of time. This sequence is important to the game program and must be in the following order:
A->AB->ABC->BC->C

So first the A Optic is triggered, then the B Optic is triggered (while A is still active) and finally the C Optic is triggered (while A & B still active). From there the optics begin to shut off starting with A, then B, then C.

The reason for such complexity is to prevent "coin stringing". Where someone attaches a coin to a string and tries to pull it back out of the slot. In this scenario, the optics would be triggered correctly on the way down, but would start to trigger again on the way up and screw up the sequence expected. Once the sequence is broken, the coin either produces a "Jam" error message or "Coin Sequence" error.

By adding code to the driver to simulate a correct sequence of the optics, I am now able to press a key to insert coins, and the game shows a coin in.

Door Closure

Well I finally got the code mostly working for the door closure problems I was having. It seems the door optics like to pulse on and off when in a closed state. The game now starts with the door closed and I can press a key to simulate opening the door. However, I cannot yet get back to a closed door without restarting.

Still this is important, since it allows me to test the coin-in optics now. The machine tends to bypass the coin detection when the door is open, so having it closed now will help in debugging.

The door closure also allowed me to see for the first time the "attract mode" animation on the cards. As you can see in the picture, the face cards animate when the game is idle, assuming you have the option set to do so in the operator setup.

Time to figure out the coin-in sequence now. Its obviously an important feature to implement.

Minor Update

Not much new to report today. I updated the driver to support a new romset, PP0188 - Standard Draw Poker. A screenshot of it is pictured here with the paytable option on. This rom also has an AutoHold feature, but was disabled. It has been suggested that depending on a casino's location and policies, that they will sometimes enable or disable this feature.

I had to apply the same code hacks as the PP0516 driver to make it work. But it does work as far as the others go.

I just updated my driver against the MAME .120 source and submitted it again. Hopefully the next revision will have some of the changes and bug fixes I made to the 8051 core.

Timers, Dip Switches and I/O

Well, it looks like I figured out why I could play credits, see the card backs but then the deal-draw button would cause the game to hang. The game code was in an endless loop waiting for an interrupt to set a variable to allow it to continue.

I proceeded to trace why the interrupt wasn't firing and found out the code was using "split timer" mode for Timer 0. I start looking at the 8051 core code and find out that it was never implemented! So, the only thing to do is wait for someone else to do it, or add it myself. I went for the later. After adding the code to support split timers, I discovered the 8051 core had some more bugs in the way it determined what timer mode was to be used. This bug (mistake) was repeated in the serial transmit part of the code, so I fixed it there too.

After these changes my driver started to work a lot better. The timing still seemed a bit wrong so I went back to the 8051 core looking for other bugs. Upon searching I also found that there were several opcodes with the wrong cycle counts. I update the code for that too.

I'm thinking the 8051 core may still have other issues to be found, but I have progressed enough to play credits to the end game. In other words, I can bet credits, hold cards, draw cards and obtain a payout. In between I am able to double up when the option is enabled.

I found out my game supports an "Autohold" feature which is really nice. The only way to enable it is to set one byte in the program code and adjust the checksum, but I may end up doing that for my real machine.

A couple of other misc thing I did was to add support for I/O addresses and the dip switches are now working.

At this point, some open issues are:

• Door Closure
• Sensing Coin-In
• EEPROM support
• Timing

I expect there will be more 8051 core to look at to determine the timing issues. The other open issues are just a matter of time.

Layout with Lamps

I've done a bunch of things since the last post. I mapped all the output devices to either lamps or output calls. With that I then created a layout file for displaying some of the lamps while playing. The little red square in the upper right corner is the change request light. Overall, these new lamps should help debug some areas a little better.

I found some problems with the way I did paged mode addressing to external ram. With those changes my memory model cleaned up considerably. All cmos data is now in one block #000-fff.

With the cmos memory now organized properly, I was able to load it on driver init with preset values. This let me populate the machine with things like max coins in, current denomination, background color, music choice, game type, drop door, bill acceptor, double up, animation, paytable and deal speed. I noticed I started getting the little "RESTART" and "GAME OVER" text on screen now. This is a good sign. That area of screen was not painting before, and usually tells the operator what has happened recently.

I was able to remove one code hack that was testing cmos memory but failing. That code now runs without errors.

Finally, I created a child driver for the rom set "Set038" that I was testing with earlier. This new driver is called "peset038", but still contained in the same file "peplus.c".



I am still having trouble debugging the door sensors, and I believe I will need to tackle the eeprom soon. There are still areas of game code that need hacks removed, and they relate to the eeprom.

More Progress

After a few game code hacks to bypass error codes, I was able to get the game to produce a "Out of Service" screen. From this screen I could get into the operator mode and setup all the game settings for denomination, sound, double-up etc. Basically, all operator mode screens became available.

After going through that setup I was able to get the normal game screen to appear with it showing cards from the last hand. With that screen I pressed "Play Credit" and it deducted credits and displayed 5 card backs like the picture shown here. I also re-ran the test with the "Max Credits" button and it peeled off 5 credits in a row like it should. I setup the ram to have 20,000 credits to start with in order to play.

Unfortunately, the "Deal-Spin-Start" button did not reveal the cards in my hand to allow me to press the Hold buttons. My theory at this point is the door sensors are still not 100%. I think they may pulse on/off instead of stay in a constant state. Either way, this is a major milestone.

Obviously I need to go back and find out what I need to do to remove the game code hacks, but being able to get this deep into the game is really helping document memory locations.

Set and Clear

Well I finally dumped and disassembled the Set038 chip that is used to setup a PE+ machine that has had a battery replaced or just a bad data image.

This fairly simple program is also used to setup a denomination and choose if you have a bill acceptor attached.

I've been using this program to better understand what goes into the battery-backed ram and how the cmos is accessed.

After a lot of investigation in the code, I found that the cmos is attached to address #9000 using an I2C bus as a communication mechanism. It appears that #9000 is a write only address to affect (wc, scl and sda). Further analysis seems to point to #8000 bit 7 as the read bit for data and acks. The #8000 address is normally used for Output Bank A, but bit 7 is not documented in the operator screen as being used.

Based on schematics, and a visual look-over, I have a X2404P cmos which can hold 512 bytes (4K-bits) of information.

I found some code that tests the integrity of the cmos etc and commented it out in order to see what would happen. The screen above is the result. I am able to fully run the Set038 chip program in the emulator and simulate saving data to battery-backed ram. The program fails if I don't comment out the block of code that tests the device. Tracing this particular dump has really helped me understand the inner workings of the cmos communication.

My next step is to make it work without commenting out the section of code that verifies the cmos etc. This will require driver changes to simulate a 24c04 eeprom.

Call Attendant

Now that things are mostly working I decided I wanted to see if I can figure out how to get a coin into the machine so I can play.

At this point the system comes up with a single screen that just says "CALL ATTENDANT". If I open the door and press the "Self Test" button. The screen to the right is shown. It appears there is some missing data in my external RAM.

The RAM is usually kept via a battery attached to the motherboard. If you replace the battery or pull the RAM chip, you will lose all the contents inside. This is where the coin counts and settings are stored. I have been playing with those values for a while, but now may be at a point where I need to see what a valid RAM looks like.

I will be dumping a "Set and Clear" ROM that is used in real life to fix such an issue. I will need to disassemble that source of that and figure out what it is doing in order to make my RAM match what a real machine would have.

Background Color

The screen that lets you change the background color wasn't working before. It would let you select and change red, green and blue values, but it never refreshed the screen.

I found that the code writes to location #6000 whenever the value changes. With a change to my driver to update the internal palettes whenever #6000 is updated, I was able to make it work!

I don't have code to load the palettes upon startup with a predefined value yet, but I know the background is saved in memory for when you power off the machine. This is something I will have to add later. For right now, it will boot up with the default background in the color prom.

Current Game Display Part II

As you can see I got the current game display showing cards!

The problem was actually quite big. Up to this point the screens I had been viewing only used graphic characters found in the roms at locations between 0x00 and 0xFF. The card graphics are located beyond the 8-bit boundary of 0xFF and needed a 16-bit address in order to find them.

I found that the Port 1 actually stores the upper address I needed. It also stores the palette number. Up to this point, the palette had alway been zero, but once I got the value from P1 I had all I needed to display characters in higher addresses.

Another problem is the 8052 driver didn't seem to have a way for me to fetch the value of P1, so I had to add a new function to allow me access to internal ram values. Yet another change to the 8052 core that I will need to go back and document.

Current Game Display

I finally figured out how to advance to the next screen. It seems the "Current Denomination" and "Maximum Coins" need to be populated before you can go on. It has to do with showing coin counts for each grouping like "with 1 coin in", "with 2 coins in" etc.

Now that I made it to the current game display I figured I would see some cards on screen. Either the current game data values are corrupt (since I don't have any game history), or I am looking up the wrong graphic characters.

Machine Counts

Well now that the inputs and door sensors are working, I thought I would look at the machine counts screens.

It seems that I will need to map the memory locations for each of the amounts, but most appear to have zeros in them.

The values are stored in a 4 byte BCD format and support values from 0 to 99999999.

I can't seem to get past a certain screen and advance to the current game display screen. I need to figure out what is blocking me from going forward.

Sound of Music

Well, the music now works! At first the speed was really slow, so I had to finally determine the speed of the 80c32 CPU and the Sound chip.

It turns out that the cpu is exactly 7.3728 MHz or (2 x 3.6864) and the sound chip is 1.6666 MHz or (20.000/12). These values line up nicely with the crystals found on the motherboard (3.6864 and 20.000).

I found there are 5 tones and 9 songs. The 9th song is not played during operator mode, but is used I think when paying out credits or coins. Its just a song where the notes keep getting higher and higher. This seems to match how the payout process works.

Sound

After tracing the game code, I found that the sound chip is accessed via external ram at #4000. Specifically, #4000 is the control port, and #4004 is the write port.



I setup the driver to map to these and navigate to the output test screen and fire off the sound test. It works! I hear a 'ping' sound just like my original hardware. Its not exact, but I'm sure its due to the improper frequency I setup for the cpu.



I know that I can mess with the sound settings in operator mode in a page further down, so I advance the pages but cannot get to the sound screen. There is probably a variable in memory that needs to be set in order to let it know that that page is available.

Outputs

I fought with the inputs for a long while trying to get it to advance to the next page (outputs), but it kept resetting every time I pressed the "Self Test" button.

I finally narrowed it down to the door sensors. There are two sensors to deal with, the upper door and lower door. It seems the door wasn't open or something and the code just resets itself.

Now that I can get to the next page, I can mess with the outputs. Since I won't be using any outputs for now, I just tried triggering the sound effects button. Nothing happened. Looks like sound is next!

Inputs

I had to hack the game code to jump to the operator mode. The only way to normally get to this screen is to open the door and press the "Self Test" button. Since I don't have inputs yet, I force the code to jump there.

This allows me to see what happens when messing with the inputs via the keyboard.

After a lot of digging I found that the Inputs seem to address external ram at #A000. There is also inputs at #8000.

After fuzzing around with the values, I found that the #A000 region is split into 2 banks. The high nibble stores 8 inputs and the low nibble the other 8. This covers banks B and C.

The #8000 region seems to handle the bank A but since these are not buttons, they need to be treated differently. This area is gonna need help eventually. But for now I have all 3 banks working but not the dip switches.

In Living Color

Horray! The colors are perfect. I had to figure out how the bitplane stuff is setup in the driver properly and now you can see its working great!

The colors match my real hardware exactly, except for the background color. I know you can change the background color when in operator mode, so my guess is this is the default color that ships with the color prom.

Now that I have a working visual, I need to figure out how to get inputs to work.

Better Video

As you can see I figured out the issue with the video. Looks like the transparent addressing mode automatically advances the cursor to the right (basically incrementing the current address after displaying).

Once I added the code to do this, things cleared up considerably. I still need to mess with the color palette, but that shouldn't be a problem.

I see something!

Its not pretty, but there is definitely structure there. I can tell where the "Open Door" text and "COINS IN" text are. And the colors are all bad.

Looks like I need to review the documentation on the video processor and see if there is something I missed.

8052 core

Well after looking at the source code to the 8052 core, I found there is no way to currently do what I need to do when dealing with "paged mode" addressing. I need Port 2 (P2) to be the high byte of the address when reading external ram, and it appears the 8052 driver has a place for a callback function but was commented out and doesn't appear to work anyways.



I had to hack the 8052 driver to include P2 as the upper byte when accessing external RAM. I will have to revisit the cpu driver later and include a way to make the callback work. For now I just hard-coded what I need. I'm desperate to see some output soon!

Accessing Memory

I'm finding that the game code addresses some external memory using "paged mode". Basically, Port2 (P2) holds the High Byte address while an 8-bit register like R0 holds the Low Byte of the address. This allows for a 16-bit pseudo-address by combining P2 and R0.

Whenever graphics are addressed in the game code, they seem to be using a value of 0x20 for P2. Which tells me they are addressing a range of 0x2000 to 0x20FF.

I found that in other drivers using the CRC6845, they generally look at 2 memory locations to get it to work. One for the registers and another for the address. I found some video code that places values at 0x2080, 0x2081 and 0x2083. One too many addresses, but I can tell that the 0x2083 value always holds the address to the graphics character in it. Since its using "Transparent Mode Addressing", I'm gonna need all three.

Video Processor

I think I have resolved the issues with the memory and started to try and find out how the video is handled in the game code. After a ton of research I find out the video system appears to be using a special method called "Transparent Mode Addressing". The MAME driver for the CRTC6845 doesn't seem to be coded to handle this yet. I'm gonna try to go without the driver and hack my own implementation for now. I'd really like to see some kind of visuals show up on screen. If I get anything to show up I will go back and see about adding the features to the CRTC6845 driver at a later date.



My first challenge is to find out where in memory the video is updated. The game code is getting more and more commented, but there is some areas that are unexplored. Time to flesh out the game code some more.

Driver problems

Well, this driver is not gonna be a slam-dunk in any means. There is a lot to learn about how MAME drivers work. I found a few games that use 8051/8052 cpus and others with AY-8912 sound and others with SY6545 type video processors. With that I cobbled together a basic driver that displays a startup screen!

I didn't confirm the proper cpu speeds but can do that once things start to partially work. I just used values other people did so the timing is somewhat correct. I noticed 2 different crystals on the motherboard, one marked 20.000 and the other marked 3.684. They probably correspond to the cpu and sound chips but could also be used in the timing of the serial port (which I think is used to relay progressive jackpot information).

Well the driver doesn't work past the title page. It bombs out a lot with memory violations. I'm gonna need to figure out a lot more on how memory is divided in the cpu.

Starting a MAME driver

I think I have enough information on hand to at least being a basic MAME driver. I know the processor is a 8052 equivalent (which there is a CPU emulator for in MAME). Looking at my motherboard I also see a AY-3-8912 sound generator, and a 6545 video processor. I have game code, graphics and color prom dumps. At this point I would love to see what I can get up and running in MAME.



I downloaded the MAME source code and setup my development environment. I then compiled it and tried one of the free roms (Robby) found on the MAME website. At this point my system is ready to go.

More Game Code

The game code has some data embedded in it for processing strings such as "COINS IN", or "ROYAL FLUSH". Using the offsets I discovered in the graphics files, I was able to come up with a chart of letters that correspond to data found in the game. With this information I then added comments to the source code wherever I found a string being used.



The more strings I find, the more the code starts to document itself. I am finding the same subroutines being called after loading the strings, which makes me think its routines for painting to the screen. Time to dig around in the code.

Game Code

The processor on the my PE+ board is an Intel 80c32. It pre-dates the 8051/8052, which is a more common version of the chip.

I used a program called DIS8051 to disassemble the game code and it appears to be unprotected. I found that strange for a system that is used for gambling, but was quite happy to see it!

Time to dig into the code and see if I can start mapping interesting things. I'm using 8052.com as a reference site. They have a ton of information on this processor. Once I get comfortable with the code, I will begin creating a driver in MAME.

Graphics

Well I've figured out how the graphics are stored on the CG chips. Basically, they are using 4 bit planes to represent the colors, meaning this is a 256 color system.

I wrote a little C++ program to open the graphic roms and organize them a little better on screen so I could see them grouped properly. The colors are guessed at this point and I know there are 16 palettes to be used, so I just picked common colors and used 1 palette for this. Thats why the spades and clubs are red. The palette gets switched when the game is displaying cards.

I'm considering making this a real graphics editor sometime. It would be nice to change the card backs and animation pictures, etc. and burn new chips to put in my real machine. But for now I won't be adding any other features to this viewer.

And so it begins!

I've been kicking around the idea of making a MAME port for the IGT PE+ Poker machines for a long time. I know the hardware shares many similarities with arcade machines, and the MAME team has developed quite a few libraries for CPUs etc.

I personally own an IGT PE+ Poker Bar Top model show here.

My first step was to dump the roms in order to view the them in a binary format.

This was a fairly straight forward process using my trusty USB programmer. I ended up dumping 5 chips this way. The game program (pp0516) in my case, and the 4 CG chips for the character graphics (MRO, MRG, MRB, and MRX). The color prom (CAP 740) is a special little bugger that I could not dump by normal methods. I ended up resorting to putting it on a breadboard and reading the 256 bytes by hand with a bunch of LEDs. This took a while, but is accurate.

So now its time to look at the binaries and see what I can find.