redbags

@HongKong Phooey Not sure how I missed this but I've got a few methods for extracting the various data structures from the T7 games. If this is still of interest / use let me know and I'll share the python + powershell code I use for various stages. For machine_logic.barc - it uses both encryption and zlib compression. And then once the data is out there is a tonne of work to do to assemble the reels.

I'm curious how the display turns out / what the options are. The default T7 exec wants 2 x 1280 x 1024 or something like that so reasonably big. Perhaps the options might include scaling it down or screen 2 just being a dummy output/not used which wouldn't impair too many ganes albeit not ideal. Build looks great though. Look forward to seeing more.

My suspicion is the underlying logic is there in the game assets but might take some work to enable. I know for a fact that Rainbow Riches Pure Gold has the big stake logic i.e. reel strips, payouts etc n the game logic file so there is hope

The discussion was less about how good the game is but more focused on what may or may not run from an emulation point of view as an emulator comes into view. The consensus appears to be it's T8 or above only so unlikely to be available from an emulation point of view from the outset.

Here is the config file from the game itself. Something I never noticed before (because I never looked too closely at T8) is that videobet appears to start coming into view as there are various config breadcrumbs laying around. On the question of what is different between T7 and T8 - it 'might' be the case that T8 switched to using Direct3D instead of OpenGL for graphics rendering. In this case it looks like it's still on the older OpenGL.

The author states they are working on T7 emulation. This means no raging rhino. But. I don't really see the difference (from my limited technical view) between T7 and T8 so you should assume that at some point it will come into view. The T8 era really has some of the all time greats so the future looks bright.

Thanks for confirming re: HASP. Re: big bet logic - take a look at 'pure gold' as an example but obviously in a time far away from now when you're less busy. Cheers

Something else I'm curious about is - I believe the 'big bet' game logic is present in the T7/T8 games. From a personal point of view - this is FOBT mecca as far as I'm concerned. But the hope is that we should be able to bring that functionality back at some point

I'd always assumed videobet (and associated content) would be offlimits. Your post suggests that might not be the case. I've never seen the videobet architecture so no idea what to expect. Likewise I've never seen a T8 architecture in action, however, I've explored an image and assume it's mostly the same if not entirely as the T7. This makes me believe that if you emulate T7 then T8 emulation is implied. I'm curious how these guys are going to get around the game encryption from an emulation point of view. I always understood that the game executables (and content) were encrypted and the HASP was necessary to decrypt. It's actually possible to emulate the HASP so the physical device is not present but I doubt that's their approach. Maybe they'll just inject some vertex type license at runtime to make ot work. Not sure but certainly curious.

Doesn't videobet mean that standalone is no longer a thing i.e. the machines always need to be connected to a server? And why would that mean vertex prices drop? @HongKong Phooey Great work. Look forward to seeing a beta.

This was one of the arcade machines in our local swimming pool. Played and watched it being played for hours on end as a kid. Had the NES port and spent even more hours clocking it again and again and again. Fantastic game.

Rat Race is my earliest memory of gambling. Must be 40+ yrs ago in a seaside arcade in Haylin Island (not sure I spelt that correctly). Will download and take a look.

Maybe but not sure how accurate that is. I don't know anything about the systems that came before this but perhaps they didn't use HASP i.e. rio cabinets and it's leftover code. As far as I can tell barboot only deals with installing the HASP software - it doesn't actually communicate with the HASP.

The RAM disk is strange and I can only assume it was intended to host ephemeral data hence they carved a bit out of RAM. Never seen one used on a production system before. The PE bar7.tmp sounds suspiciously like the real barboot so I think you are on the right track. You might also notice they have a tendency to name exe stuff .tmp i.e. devcon, ftpserver etc. The developer.txt file is simply a check for the presence of the file - there is nothing of significance in it from what I could tell. So just go ahead and add the file and barboot will display text informing you it's running in developer mode. Barboot also has some check for the presence of pressing of left alt key - again - not especially clear what it's intended for. There is another check for c:\settings\settings.ini which is quite important to be present so make sure you copy it if moving to another system. Ge.exe is some sort of packed version of the real executive which is called executive.exe. If you don't have the ram drive configured then just create a small V:\ drive and the real executive will be copied there and launched. If all goes well you will get the executive running and then be greeted by an alarm telling you that the cabinet dongle is missing. And then you're stuck. Re: elvis20. I believe you have the game but it's in an encrypted form. I think it gets unencrypted via the licence on the HASP which is why when you poke it - it all looks like junk. Re: hasp - I did read there are some which allow freeplay. Maybe expired or something. Otherwise I think you will need to get one. Trying to work around it without having one is going to be a serious undertaking. I would say I've been looking at this system on/off for around one year and I probably haven't scratched the surface. It's very complex with a lot of moving parts. Be prepared to burn a lot of hours/days/weeks looking at raw computer data

I went into the tank on this one. Based on where I've gotten so far I still maintain that there is NO physical dependency on the ATI graphics card - it's all configuration. Here is how graphics work in the exec:- Exec --> SDL --> OpenGL (windows) --> OpenGL (device driver) In the above - the exec is using certain functions which are not exposed directly through the Windows XP OpenGL library as it's basically a very old/small version of openGL (v1.1 I believe). Instead, the Windows OpenGL library is forwarding those to the device driver through a function pointer. The functions appear to be OpenGL 1.2 or higher. What I believe this means is as long as the installed video card implements OpenGL 1.2 or higher than you're good to go. The caveat here is that it's possible further along the line some hardware specific dependency comes into play but this seems unlikely as the video card manufacturers generally played quite well with aligning with the API specs. The fact that the T8 uses another graphics card from another manufacturer supports this idea as well i.e. they'll be doing spec driven code.

I don't believe it's been reverse engineered but that's probably because nobody has looked too closely at it. Because the system/games are unpacked at rest it's not reallly much of a barrier to anything.

It's Windows XP embedded. The application software is all just standard windows x86 32bit. Hardware wise - I know the graphics card is an Radeon X1300. In terms of all the other hardware - not exactly sure as I no longer have the physical unit. Opinions tend to vary but I'm not convinced there is physical dependencies on the underlying PC hardware except for the fact that Windows XP embedded needs to be able to boot + install the necessary drivers. PC hardware aside there are two key peripheral dependencies when considering the PC environment. One is the MPU - this is a proprietory piece of hardware connected via USB which manages all the cabinet hardware i.e. note acceptors, hoppers, led lamps etc. The other is the Sentinel HASP - this essentially serves to provide the encryption/protection of some of the software + individual games. If your goal here was to get the system up and running on something other than the OEM hardware - MPU/HASP and all that other stuff aside - I'm pretty sure that is possible. If your goal was can I run these games via some sort of emulation or on hardware that eliminates the need for the proprietory hardware - what I can say is that you will need very strong reverse engineering skills and the appetite to take on a huge task. There is probably somewhere in the region of 50Mb+ of code before you even get anywhere near a game. For anyone not versed in reverse engineering - 50Mb is massive. 10s of thousands of lines of code and some very complex code I might add.

Never say never but this just seems very unlikely to me. For starters the driver used to support the graphics is stock AMD. And modifying the BIOS of a commercial graphics hard is both a.) technically challenging and b.) something almost certainly off limits from AMDs perspective. If you look at the behaviour outlined by slots magic - sticking in any old graphics card doesn't break it - the output just comes out incorrectly. And I'm sure that's a gfx card configuration vs something more technical. The exec in T7 land is drawing to a single canvas and managing offsets etc to know where to draw to recreate the 'multiple' display effects. But the graphics card and driver has the job of sending half of that canvas to one monitor over one port and the other half to the other monitor over the other port. Things change in T8 because of the addition of an additional screen but in T7 that's how it works. I suspect that if you were to connect a single screen which supports the resolution of 2546 x 1200 (typing off hand here but it's something like that) to any graphics card it would work as expected. And final thought - keeping the graphics card uniform makes a lot of sense when you look at at the setup of these systems and how locked down/controlled they are. Fewer hardware types = less management overhead. So I think it's less about custom graphics vs a tightly controlled system where introducing new hardware becomes a headache. Now someone can come along and say.....I did all this via the OS on a T7 and it still didn't work to prove me wrong. But installing and configuring a graphics without somehow interacting with the OS - it's hard to know what you actually did.

I suppose my wider point is that I'm pretty sure they haven't done anything as low level like creating custom silicone, drivers or firmware and such such like on the gfx. I think that's a bit of a myth / something mired in mystery. I suspect any replacement card you got working either shared the same driver or that default driver setting came with the required settings. Out of interest - did you ever tinker with the graphics setup in the actual operating system?

Too bad none of us have a T7 to test it on. But I suspect the issue is one of graphics card setup + configuration vs underlying code issue. The API at that time did not support multiple displays as draw canvases so it was left to the developer to treat them as two screens but managed via a single desktop resolution. Apparently horizontal span mode needs to be configured at the driver level vs extended mode or some variation on that. And looking at the code there are some fairly strong indicators it is drawing to a single resolution and doing a bunch of operations on that to make sure things are drawn to the correct viewport. So if someone out there has a broken T7 graphics card and is willing to tinker then I think it's possible to get any card working so long as it supports the relevant API and required resolution. I'm only going on registry settings but it's something like 2560x1024.

Well that sounds more like a configuration thing vs graphics card not working. I don't suppose you tried but if you bombed out of the exec and reverted to the OS i guess they were working. I was looking at the driver install earlier so will go and take a look again. There are a lot of settings

Out of curiosity - when you say suitable - what was the criteria and where did you land? I was looking at the T7 spec and I can see it's a AMD Radeon X1300. What happens if/when you stick another non-X1300 gfx card in? Black screens?

I double checked and the exec uses OpenGL for the API and another set of libraries called SDL to abstract out some of the graphical operations. I'll dig deeper and see if I can find out where the hard dependency on this is coming from.

From memory the exec is based on a fairly old Open GL spec - I'll take a look later and confirm. Generally speaking it's less about the emulation and more about the API spec. I think what is probably unique about those graphics cards (for those times) is they probably had larger memory to deal with the resolution across two screens and multiple output ports. I'm reasonably sure a modern virtual graphics card could do the lifting of a 20+ yr old graphics card. It's also possible to use GPU pass through these days if not (I've seen this for LLM workloads but not gaming but assume it's the same).

I suspect you need to go after the exec as opposed to the individual games. I've never seen the individual game code because it's encrypted at rest and I got rid of my working system before poking around in that. But I think the exec is still doing quite a bit of the heavy lifting. HASP is the bigger blocker though. I do think getting T7/T8 games running on any PC will happen at some point once someone with the right level of skills and determination puts their mind to it. It's the skills part holding me back