Jump to content

SomeRandomGuy

  • Posts

    54
  • Joined

  • Last visited

  • Days Won

    1

SomeRandomGuy last won the day on October 7 2022

SomeRandomGuy had the most liked content!

Retained

  • Where did you find out about this site ?
    YouTube

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

SomeRandomGuy's Achievements

Νεοσύλλεκτος

Νεοσύλλεκτος (2/13)

  • One Year In
  • Very Popular
  • One Month Later
  • Dedicated 2 Weeks
  • Week One Done

Recent Badges

151

Reputation

  1. Haven't posted in a while, just checking in here. Haven't abandoned this place or anything, just been hella busy with work stuff, school stuff, and much of the non-busy time has gone to other reversing projects. Very cool to see progress @johnparker007 as always , great to hear you're feeling better as well! IDA is a very very useful program, I've been using it for all my fruit machine RE in fact, and many other things too. Z80 code it can handle just fine (Bonus Talker has one) plus so far I've also dealt with MC6800, TMS9900 and Intel 8048 on the fruities. The last 2 don't have processor modules in IDA so I had to make my own, with these simple 8-bitters you can get away with quickly hacking something together in Python though . There's also Ghidra that's aimed at the same things IDA does, it's main advantages are that you don't need to pirate it, and that it can decompile assembly into C for theoretically every CPU that's supported. Though in practice trying to decompile handwritten 8-bit assembly such as here breaks down quick, and the overall quality of the decompiler isn't as good as IDA, which has been worked on for longer but only does certain architectures, though Ghidra will probably get closer as time goes on. I use IDA myself since Ghidra didn't exist as far as the general public was concerned when I was first getting into all this stuff, and IDA works better for certain niche applications like 16-bit x86 code if you're into that type of thing. Had a look at the PROCONN stuff, threw in one of the Bullseye ROMs and it looks fine in IDA as far as a quick glance goes at least. One thing that IDA kinda sucks at is dealing with banked memory, where there can be different parts out of the entire ROM code visible in memory depending on what's selected, you see this on the SNES for example. Doesn't seem to be the case with PROCONN on this game at least. The memory map is simple, total size of the ROM chip is 64K, in Z80 memory 0000-EFFF is the first 60K of the ROM, then 2K of RAM at F000-F7FF, and then the last 2K of ROM at F800-FFFF. Dunno if that last 2K of ROM can be switched in some way, but that part is empty for this game anyway so doesn't matter. What can be confusing though is all sorts of tricks that programmers used back in the olden days of handwritten assembly, for example there's this code here: It looks like it's jumping to the middle of another instruction, which definitely shouldn't happen. But if you look inside the function at DA04 that's called right before the sketchy code and look at what it's doing, you can see that it reads 2 bytes following the call instruction to DA04, does something with them, then continues to the code after them. So what it should actually look like is this: Here's another one with code that doesn't disassemble at first: Much better after fixing: That's just one example, but you can see many different kinds of this strangeness, depending on how 'clever' the programmer was feeling that day. Jump tables are pretty common for Z80 as well, usually a jp (hl) instruction that has a list of addresses close by that go to different parts of code. With enough experience you eventually develop a feeling for this sort of stuff, but at the same time you never really run out of new ways of being clever. It can get especially bad if the programmer was focused on intentionally making the code hard to follow, but that's more of a thing for stuff like copy protection on home computer games, shouldn't be much to worry about as far as fruit machines go at least. Anyway, good luck with the reversing!
  2. Ooh, anything to do with MAME integration is always nice to see . I was about to mention -video none for hiding the window but it looks like you've already got that one figured out . Worth talking to MAMEdevs about this stuff at some point anyway, I don't think MAME used as a background component is a use case which has been explored that much, and Vas & others know a lot more about this stuff than I do. Quite the clown show is all I'm going to say about that situation. @johnparker007 has already said everything important that you need to know about Mr. Unity CEO here anyway Some emulation updates too - in the MAME thread I planned to look at Summit Coin 8035 mechanical hardware and Cleartone's Bonus Talker hardware. So I've done some looking now, took Bonus Talker's code apart and started gradually doing the same for Summit games too. No work on the MAME side yet. Bonus Talker should definitely be doable, as long as I can get the Digitalker sound chip that's doing the speech hooked up right, which is really the main draw of the machine anyway. There are some things that need guessing though, such as some additional sound hardware that's there in addition to the speech. There's a 555 timer on the board with some oddly-valued resistors close by that reminds me a lot of a tone generator with similar hardware used on Black Box. Problem here is there are no videos of this thing, so how it sounds has to be a complete guess. Some clocks need to be guessed as well, which means it'll run a bit too fast or too slow. No schematics to help here unfortunately, there's a manual that's very helpful but it only has a boardview in it. Anyway, it should definitely be possible to make it playable, but some parts won't be quite right. Summit games should also be doable, one thing that kinda sucks though is that there's ROMs for a Dutch machine called Supershot, but compared to the regular UK games it also has an extra sound card on it. That card unfortunately has a ROM on it that's not dumped . The guy who has/had the machine actually dumped the game ROMs himself and is on the Mecca, only problem though is that his last post was made more than 10 years ago
  3. MPU2 is now in! That one went waaay smoother, wasn't quite as much stuff this time around, but I've also learned a bit since the last time. Next thing to look at I haven't quite decided on yet, but it'll probably be Summit Coin 8035 hardware, or taking a look at Cleartone Bonus Talker, the first fruit machine with sampled sound. Not many machines to add for either choice so should go quicker overall, but I've also got university and work coming back soon, so less time for working on fruits there, but we'll see how things go.
  4. That's quite interesting... on that first example the text looks somewhat funny and the numbers on the squares are screwed, but considering the source material this thing is working with, the parts that work look pretty good. Interesting stuff! Got an MPU2 update as well - two VFS games went in, Triple Chance and Fruitopoly, the latter actually got dumped only slightly more than a month ago, so thank you EddieC on the Mecca! You don't see new dumps of machines that old very often, so that's always nice to see. These two and some Barcrest test ROM that I added are the last of the ROMs that I found, so now it's on to cleaning up and testing. Most of the way there for the next pull request now
  5. Well, well, well, it took a damn while, but the first part of Black Box is now officially in MAME. At some point I'll deal with the stepper reel games too, but for now it's done. Haven't posted here in a while too, and as far as my free time for fruit emulation stuff goes, I'm still somewhat busy . University stuff I took care of for the summer, but then came an internship right after that. Fortunately though I'm very nearly done with it and will finally have some more time available very soon. I didn't sit idle for the last few months though, in fact I got work done on bits of MPU2 here and there as time allowed. The few Barcrest usual suspects that are dumped such as Spot Light and Rock On run, plus a couple Dutch machines too. Right now I'm dealing with this weird thing from Leisure Games. One of the Dutch games is kinda interesting - the ROM that was uploaded was called Silver Star, but it's actually Super Star, which seems to be one of Barcrest's very first MPU1/2 releases ever. There's a list of old Barcrest machines with their release dates floating around and it's the first game on that list, I was wondering the whole time what it was, but seems that mystery is now solved. Here's the flyer: At first I thought it was also Barcrest's very first CPU-based fruity ever, but that honor seems to go to a machine called Top Twenty, which looks like this: Also saw what @johnparker007's been cooking, OASIS looks promising. The whole Arcade Sim-as-a-prototype thing makes sense, starting over takes longer for sure, but doing things more properly and learning from the first time definitely helps in the long run, plus it being open source is also very nice. Excited to see the converted layouts in MAME once that day comes , together with all the other arcade stuff too of course. Get well soon!
  6. They used Z8 and PIC microcontrollers, PICs can be decapped, don't know much about Z8's. MPU5 is still a ways off though, need to get MPU4 done first That was a fun read, I've seen similar stories about the J2ME development experience . Shame about the shafting, even their Wikipedia article mentions sketchy dealings going on. Seems to me like overall handhelds & mobile weren't seen as much by the industry back then, especially compared to the things it's up to nowadays. As to dumping phones, I think by the 2000s they got complex enough that you can extract most things through software, plus there's been quite a bit archived already for some of the manufacturers. Would be interesting to see somebody make an emulator for an actual phone as opposed to just the OS.
  7. Wow, didn't expect that, that's cool! Maybe one day GridRacer 3D will be added to the J2ME software list, once that becomes a thing . BTW if you still happen to have any Nokia SDKs and such laying around somewhere then it would be cool if they ended up on archive.org if not already there, don't want that stuff to be lost to time . Yep there's quite a few techs using microcontrollers that would be really nice to have dumped. Though most of the time whatever the MCU does can probably be simulated without a dump, but in some cases it might not be 100% accurate. MPU5 for example has a load of them: there's the main processor, then there's the reel controller, mux board controller, program card PIC and finally the audio DSP . Fortunately there's also techs which don't have extra MCUs on them, or for sp.ACE the reel controllers are already dumped (one from ACE and one from PCP, seems there's multiple versions of the ACE one, though it shouldn't be a big deal for a tech that old).
  8. That's part of what MAME is all about nowadays, anything with a CPU in it is fair game Off the top of my head there's dumps for a digital scale, DVD players, some old Nokias (3310 included), bus ticket validators, a heart monitor, a bomb disposal robot, the list goes on and on...
  9. Got the Black Box pull request submitted, almost there now... These new layouts look great! I had to do some full builds to make sure my code worked, did one now with the limit at 200 and one at 150 because why not, they're both attached Yeah there can sometimes be a commit in the latest git that breaks the build, though that error looks a bit weird. Could be worth doing another pull, the builds sure aren't quick though mame200.zip mame150.zip
  10. Aww, that's a shame Could be worth asking about it though, I don't think people running MAME on Pi's or whatever make much use of drivers with artwork or anything else that has a lot of textures (and most of the time they're not running anywhere near modern MAME in the first place). Some of the layouts having the older style would be no big deal IMO, and I guess manual intervention like making all the arrows on that layout the same size could also be done, but that defeats the purpose of the automated process in the first place. Regardless of there being fancy looking lamps or not, great work as always!
  11. Had a lack of time this week once again, but I'm back to doing fruit stuff now. Golden Spin is finally working, which should be all the EM games covered! Now I need to get everything ready for submitting. Won't be quick as I first need to get the latest MAME code into my development branch (currently a couple months behind) and then do some other stuff. Real close to MAME officially getting the first part of Black Box now Niiice stuff! I attached the current build, all ROMs should be there if any are still missing I actually disassembled a bit of the code myself . Got it attached along with an untouched one in case I got something wrong. I tried to get all the addresses labeled, didn't comment the code itself much. TMS1000 has a whole bunch of early 70s CPU weirdness going on, definitely not like your usual modern day microcontroller. They used a LFSR instead of a regular counter for the program counter, that's why the addresses look all weird . One important part of the TMS1000 is that to write to the O port it doesn't directly write to it, rather it writes to a 5-bit PLA which in turn generates the outputs. There's another ROM file for that PLA in the same folder (BTW I transcribed the bits wrong in the one I uploaded first, so get the new one), which is actually a text file. There's a line for each PLA term and only 8 of them are used, one for each output bit. The speaker outputs for example are lines 11 and 12 (O6 and O7). When playing a tune the code just increments the PLA register from 0x10 to 0x1F over and over. The code is unusual but there's not that much to reverse engineer, most of it is just instructions that load the tune data into memory. mame.zip mp0027a.zip
  12. Nice progress as always, cool to see SRU in action . Talking to David about it is definitely the way to go here, some of the drivers were last updated a long while ago, so things are bound to be out of date. Haven't had much time the last few days to work on things, but finally managed to find some. Looking at Golden Spin now and seems it does just about everything slightly differently compared to the usual games, though that might have been the case for Bellfruit's original club machines as well. The code not being easy to follow in places doesn't help much either. Slowly figuring things out now, made some good progress but I still haven't found where the start button is
  13. Honestly no idea right now, Black Box is not quite done yet as I need to take care of that remaining machine, then clean the code up to get it to a state ready for submitting, then clean it some more once I get feedback on it. As far as MPU3 goes though, now that the MPU4 cleanup is finally in I can see Haze looking at it since the two are similar, there was already a bit of MPU3 characteriser stuff done. Well the dumped chip and the one in the real machine are both MP0027A's, and I doubt they would have silently changed the code without giving it a new part number, that's what the A is probably already there for. The note data in the TMS1000 code does seem to correspond to what the emulator plays, I don't think it can pull any alternate data out of somewhere either. With help from Hap's doorbell code I did find a bug now that caused the tempo to be slightly wrong, but that still doesn't explain where the extra notes come from. I'm gonna say this is good enough for now A DX of a doorbell, truly the new era of fruit machine emulation has arrived!
  14. It's kinda weird, doesn't seem like it's repeating it to me... (edit: the audio player doesn't seem to work here, files are in a zip now) The Black Box side has a line that controls whether the tunes play at normal or fast speed, and I set the normal speed after how fast Oranges & Lemons is supposed to be, so changing it would be right for only one of them. Even with a slower speed the tune still doesn't sound 100% right, strange issue... tunes.zip
  15. @Altharic@johnparker007@wolf676 For some reason the tune after you collect a gamble is shorter than the real one, it's almost like it plays less notes. Other than that it's done now, thanks a lot to everybody who contributed! 2-3 weeks ago I stumbled across this thing, and now it's emulated Now I'm back to dealing with Golden Spin I guess, getting close... Build is attached if anybody wants to give it a go mame.zip
×
×
  • Create New...