SomeRandomGuy
-
Posts
54 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Posts posted by SomeRandomGuy
-
-
On 11/09/2023 at 23:13, johnparker007 said:
Done a little more hacky testing, this renders basic 2d reels, synced with the emulation. Kept MAME window visible so I can press keys in MAME for the moment to drive the emulation (play the machine). Ultimately MAME will be a hidden child process and Oasis will be passing inputs through:
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.
On 13/09/2023 at 10:41, johnparker007 said:I am keeping a very close eye on these new 'Unity Install Fee' developments, as they relate to Oasis. Currently the plan is to build Oasis on Unity, however they have recently announced an insanely greedy plan that will potentially kill off lots of small studios (especially ones that create 'free to play' games, like mobile games with IAPs). In a lot of cases (i.e: commercial free-to-play games), the model one tries to achieve is many millions of users, but a very small 'ARPU' (average revenue per user). If Unity want say $0.15 per user, and you only actually earn $0.10 per user, you've now gone from a profitable game, to one that in reality costs you more than you receive!
While this new 'Unity Install Fee' would not affect Oasis (since Oasis is free), I suspect this may signify the beginning of the end for the Unity game engine.
Viable yet unpreferable (for a bunch of technical reasons I don't want to get into right now) alternatives are Unreal Engine, and Godot Engine.
Unity is 'going public' soon (so people can buy shares in it on the stock market), and is also now being run by the a-hole who used to run EA, with all the lootboxes and other toxic cashgrab IAPs, so it's clear why they are driving this excellent game engine into the ground; ca$$$$h.
Ugh, the enshitification of yet another great product, thanks modern capitalism.
On the plus side, we already did the very 'game engine specific' proof of concept with the initial Arcade Simulator project (to prove we could run a massive arcade with 100s of machines on a modest spec PC)... so a lot of the upcoming near-term work in Oasis has to do with stuff that is fairly easy to port to another engine. Things like finishing up the MAME emulation IO, the Oasis Layout Editor project format, the 'safe screen scraper MFME extractor' system, the MAME layout export system, the machine+layout formats (for use in the new 2D and 3D Oasis modules like Arcade Sim v2, standalone machine player, etc) - these things are not so closely tied to Unity in the new Oasis project (they were very entwined with Unity in Arcade Sim, but the plan was already to decouple these formats with Oasis, so got a little lucky there).
So as and when I can do bits and bobs of work on Oasis, it will be in those areas... and we'll see how this whole thing plays out!
Here's a quick rough video a dev has made about this, I'm sure more will follow as this news (about Unity, not Oasis! ) goes mainstream:
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
-
2
-
-
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.
-
5
-
2
-
-
On 03/08/2023 at 18:36, johnparker007 said:
Had another play with this new simple process for enhancing low-res pixelated layouts... the idea is that one day, as part of the layout editor, it will be a easy to use built-in tool, with some tweakable settings...
This time was Super Hyper Viper at a whopping 16x upscale for an 8K layout, here's some before/after, using the simple fixed process (upscale, rebalance color, unsharp mask):
Before:
After:
Before:
After:
Before:
After:
Before:
After:
It's not all there yet by any means though:
Before (notice the text is actually much more legible):
After: (text is an unreadable mess)
I believe in future multimodal LLMs would be able to guess the correct text based on knowledge of the game though the MAME internal classic layouts, and fonts used on these machines, and then redo the text as fonts with layer effects... probably a long way off yet, purely due to these not being particularly in-demand generative AI skills, but it does seem feasible... will be a handy stopgap for those machines where no high res images are available, and no highres redraw has been done
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
-
2
-
-
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:
Spoiler
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:
Spoiler
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!
-
5
-
2
-
-
22 hours ago, Altharic said:
These are pretty cheap judging by ebay prices and mpu5 sadly if I bought these I would have no idea what to do to dump them I mean the reel board is under a tenner mux is £12.....
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
12 hours ago, johnparker007 said: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
I have a couple of old backups of the Gyrox source and perhaps biz emails on CDRW in the attic... It was a very long time ago, but I suspect I don't have any SDK downloads on there - hopefully they haven't been lost to time...
Compared to the other phone manufacturers in the early years, Nokia were a thing of beauty; they used to have a very active dev forum, whereas with say Sharp, they (at the time) used to have a top J2ME handset (in Europe) the GX10, but no documentation... and if you did a System.gc() at the wrong time/place, it would simply reset the entire handset
there were a bunch of gotchas like that at the time you could only really learn through testing, or if you were very lucky, an internet forum post.
It was a real wild west, depending on who had written the KVM, there was a pretty small crew of KVM writers back in the day, it was crazy. I remember SonyEriccson started off super terrible, it was infamously bad to try support..... then something happened (almost certainly a new freelance KVM coder, as they along with other manufacturers were slowly realizing that J2ME performance was a selling point, like megapixels, and just had a capex cost), and they went from the worst to rivalling/beating Nokia devices for J2ME performance. Motorola had a similar journey; they had crazily bad 'runtime stack management', so the memory fragmentation from the J2ME 'heap' memory would build up fast, so you could build a graphically rich game (but multiload) that'd run ok for one gameplay loop, but then it would die being unable to allocate memory (flat memory model worked, but didn't suit multiloads)... this was on the famous V3 aka RAZR, very sexy slim flip-phone, it was a very nice looking device compared to the clunkers of the day, I think the 'solution' in the end for those Motos was just to have very limited GFX RAM usage via hardly any gfx, so you'd delay the heap recycle limit crash for as long as possible, it was all so insanely mercurial back then lol, almost like the ZX Spectrum days (I was too young to be involved at the time, but have a 'fair' understanding now, though I realised it's a very limited number of people playing Speccy stuff these days, so I switched back to FME for hobby dev).
Typing this, I remember there were certain handsets recognised as 'reference' devices in the fledgling industry(obvs it/s worth many billions now, I didn't manage to cash in on the growth unfortunately lol), e.g: Nokia 3510i, Nokia 7210, Sharp GX10, SonyEricsson K800i, (these were very good for the time), Sharp GX20+, Motorola V3, Samsung D600... quite a few more, on a per manufacturer basis - so you'd make your game work on the ref devices, then pass over builds per handset family, and the content aggregators (that us indie devs released through, to get onto the WAP portals), would take those builds and have a compatibility list, of 'like' devices similarly/same screen resolution/KVM/softkey code. I should write this up somewhere, as I've seen hardly any mention of this in the modern day of the net, so it could end up lost - where I work now (Distinctive Games) after some N64 dalliances, went on to do some solid games initially in the monochrome J2ME era (before my time in the industry)... I spent (I think I can now say,. NDAs must've expired) a lot of time devving iterations of FIFA J"ME working with EA (yes that EA, the evil microtransaction guys now lol) - a great learning curve though; there were very specific optimisation strategies developed that only work for certain KVMs (which was another wild west, the majority of gaming handsets planet-wide ran J2ME KVMs written in the relevant assembler (it wasn't all nice AMR 7 back in those days!) by a very small (4-5) handful of people.
Man, I'm hungover, but that is a lot of text lol - I've got more tales like this, it was a smallish 'scene' globally... I failed to get rich out of it unfortunately, but definitely happy to have been involved (even earning probably at best min wages via my own game company!), having been too unknowledgeable to be involved with the earlier eras. But JP, I hear you cry, surely you made bank doing the original R-Type port for Irem via Elite (yes that Elite); nope, got pretty much robbed by Steve Wilcox, the original MD of Elite, a lot of people did around then and even back in the Speccy days; Elite's model was to pay devs far less than their dues after the source/binary was delivered, then threaten to sue on some aspect of abstract code delivery law upon request of payment. Sad but true...
This is a really long post ...but one more thought is that I have kept a box of old handsets from when I ran Gyrox (prob 30-40 devices).... the chips are probably very complex to extract (compared to say the TMS1000 doorbell) but I will continue to hold onto that box, and be happy to give them up for ripping once hobbyist chip extraction is at that level.
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.
-
1
-
-
3 hours ago, johnparker007 said:
Once they get up to Nokia 3510i, 7210 onwards, I will have to dig out the 'ROMs' of my old first mobile game 'GridRacer 3d'!
Some screenshots here (from a slightly later Nokia s60), clearly I did all the graphics by how crummy they are I did that perspective road effect on the title screen picture using Deluxe Paint on an Amiga emulator believe it or not, I think I stole the bike from an Gamecube XG3 screenshot and modified it... It was perhaps the first 3d game though...
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 .
3 hours ago, johnparker007 said:No it's all cool - I suspect in the future some other fruit machine boards/chips might come up need similar doing, thanks for the contribution!
3 hours ago, Altharic said:I think this will be one of them
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).
-
6 hours ago, johnparker007 said:
Oh for sure, it's all super cool - it's just such an abstract thing to end up in MAME haha, if you'd have told me MAME would've been emulating doorbells 10 years back, I would have been skeptical to say the least!
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...
-
3
-
-
Got the Black Box pull request submitted, almost there now...
On 12/10/2022 at 21:46, johnparker007 said:Glad to hear some might use them for other than debugging/testing!
Actually, while I should get git/MAME synced/building, I don't need to be able to compile it for ages yet, so if I could kick that can down the road
So if you could compile a new exe please, but with it doubled from the new value, so:
static constexpr int MAX_TEXTURE_SCALES = 200;...that would be super handy, thanks man
(As I'm sure 200 will be enough...)
This font in MAME needs some editing, I've not looked where it came from at all, but on scrolling through those WIP screenshots above, I noticed that consistently, the lower case i, and the lower case l (L), appear to be half the width they should be, so they are very narrow everywhere:
... where there's i or l, like in Bu lli on, etc... hopefully shouldn't be too bad to fix...
Ta again for the build, saves me a job, since I don't need to be set up building MAME over here until near the end of this little(ish) project
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
16 hours ago, Altharic said:Same result unfortunately same with the alternative linker I'll have another go if I get time later
Compiling resources generated/resource/mame_mame_vers.rc...
Linking mame.exe...
ld.lld: error: undefined symbol: driver_list::s_drivers_sorted
>>> referenced by libemu.a(emuopts.o):(.refptr._ZN11driver_list16s_drivers_sortedE)
>>> referenced by libemu.a(config.o)
>>> referenced by libemu.a(render.o)ld.lld: error: undefined symbol: driver_list::s_driver_count
>>> referenced by libemu.a(drivenum.o):(.refptr._ZN11driver_list14s_driver_countE)
>>> referenced by libfrontend.a(selgame.o)
>>> referenced by libfrontend.a(simpleselgame.o)
collect2.exe: error: ld returned 1 exit status
make[2]: *** [mame.make:271: ../../../../../mame.exe] Error 1
make[1]: *** [Makefile:1087: mame] Error 2
make: *** [makefile:1119: windows_x64] Error 2
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
-
5
-
1
-
1
-
-
15 hours ago, johnparker007 said:
Another slight show-stopper, is that due to how MAME's internal layout renderer works, my fancy new shaded, rounded corner lamps may have to go (sob, I spent ages getting them looking nice!)... I might look into working out the layouts that are likely to cause issues, to then make them fall back to the old minimal solid rectangles... not sure yet, as then the layouts would be randomly inconsistent on the lamp/button shading, which might be worse.
While the array size of this could be increased (in MAME source), I don't think Cauvas will be on board with that, due to the increased memory hit on constrained ports of MAME.
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!
-
1
-
-
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
On 06/10/2022 at 00:35, johnparker007 said:Already done the extracts for SRU - though I couldn't progress as I don't have the revised MAME romsets, same for Blackbox (though I suspect I have another rom ident issue to sort out like we saw with the MPU5 roms). Perhaps @SomeRandomGuy could hook me up with the new MAME roms for those two techs please?
Niiice stuff! I attached the current build, all ROMs should be there if any are still missing
6 hours ago, andrew96 said:Was the TMS1000 MP00027a rom dump made available to us minions? the reason I ask as it seems a very simple 4 bit microprocessor and would like to see if I can get a PIC chip to recreate it. cheers
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.
-
1
-
6
-
-
9 hours ago, johnparker007 said:
Does the fruit machine dat have muchother info per ROM, such as Manufacturer, Platform (MPU3/Scorpion 4/etc?)
For ones that are not emulated by MFME (ie in the legacy section as part of a working layout) this could be super useful, as the emulation bugs can be ultimately worked out in MAME to get them running (with exception of maybe some MPU6/Scorp 6 protection stuff).
For the ones with layouts, there's more that I can pull over (damn only realising now, I've got to doo all the scraper work for these per tech Config pages yet!):
Which are then useful for the MAME driver, e.g: for MPU4, these settings lead to which sub-driver they end up in, or inform setting up of 'traits'.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
-
2
-
1
-
-
20 hours ago, Altharic said:
I for one am delighted never thought I'd hear that tune again used to sometimes annoy me other times it reminded me i was at the seaside good memories.
What plans do you have after blackbox been looking at the current state of techs in mame and some are almost there as in they do more than the mame status suggest?
Eg spoof mpu3 seems to boot and go into attract mode but doesn't coin up
Yet its status is non working
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.
9 hours ago, johnparker007 said:I have a theory - wasn't there like MP0029, MP0029A etc...? Perhaps Texas Instruments released their standard 24 song chip, but then someone at TI realised they could make some of the beeper tunes sound a little better, and so started putting out v2 chips with some slight improvement tweaks to the note sequence data?
So the chip has the same inputs from the CPU (play song #3 and normal speed etc)... but now some of the songs have subtly different notes
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
1 hour ago, johnparker007 said:Yes, ta
it wouldn't be a hard DX to make - me having the time to put it in is all a long way off unfortunately with all the other high priority MAME layout/integration stuff at the mo But wouldn't rule it out if I get chance in the future!
A DX of a doorbell, truly the new era of fruit machine emulation has arrived!
-
1
-
1
-
-
4 hours ago, andrew96 said:
no the tune is the same length, it is repeated twice, it looks like the other sounds are just other tunes sped up which is easy to do as on the doorbell I had did have this fault! there was no feedback from one pin to another for note length
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...
-
@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
-
4
-
1
-
3
-
-
The TMS1000 is now dumped! Should have some time later today to look at it, if everything goes according to plan then it shouldn't take more than a couple days at most to hook the sound up. As far as other Black Box progress is going, looks like I'm on the last game now which is BWB's Golden Spin, seems to be a rebuild of some club machine. Though it won't be easy, it has even more unemulated hardware which is not surprising at this point and even better, a custom codebase that's different from all the Bellfruit stuff I've seen so far. Probably won't be quick, but getting closer to being able to finally wrap things up
-
2
-
4
-
-
10 hours ago, johnparker007 said:
Great news on the TMS1000 side project!
And also great progress on the Black Box driver I had a quick google - I wonder if they were going to add some kind of sound, but then didn't in the end (leaving an abandoned sound board connector)..?
There's two adverts for it, and neither mention the sound, which would've presumably been a marketing point at the time:Thanks, Sean said he should be able to do it this weekend
Looking at the code there are quite a few different sounds inside, I'd bet it's supposed to have it. A mute machine would have been weird by 1982
10 hours ago, Altharic said:Could be worth asking over the Mecca about this they remember stuff most of us never knew and many still have this kit
Excellent news about Blackbox
Problem is sulzerned seems to be the only one there who has that machine, which is the same one I was talking about. Can't really emulate sound without a reference of some sort
-
2
-
1
-
-
2 hours ago, johnparker007 said:
Implemented 'full' extracting of seven segment, previously I'd just been extracting the number and on color...
Then decided to set the data structures and screen grabs up for what I think are all the remaining ones:
This is the test layout containing the new components I am setting up (pretty sure I have them all after this pass is done):
Quite a bit more scraping still to set up, but making solid progress - the video screens will be quick as they've not many fields ...and then some other issue to sort out (too narrow layouts, and an old issue I'd forgotten; mfme font scraping bug which gives me problems between uppercase I (i) and lowercase l (L), and also the '£' character).
The aim at the end of it is so that I can run any layout through it, and initially extract all of the data to my 'open format' which is JSON and .bmp images... I'm bound to run into most/all of the components above and need some of the data from them, on the ~3000 layout pass for making the 'MAME classic internal layout set'.Big Bucks looks a bit different than usual
TMS1000 update: The doorbell has made it to Sean, with the right chip inside! Now he needs to actually decap it, but we're getting very close to being able to emulate the chip now.
Also more Black Box progress: found a £1 all cash ROM for Upstairs N Downstairs (the Nudge Climber ROM turned out to be all cash as well), and found The Nudge Machine by ADMC. Notably it has yet another different type of sound board that I can't emulate this time, because the only machine on YouTube has the board missing. Also it's the first game I've encountered that has protection (a la Characteriser), looks like they didn't want anyone bootlegging. This whole thing has taken quite longer than I anticipated
, but I don't have many ROMs left now, so getting close.
-
2
-
2
-
-
17 hours ago, Altharic said:
Will be funny if the doorbell ends up in MAME/MESS I think it qualifies just about
I'd say that is definitely going to happen
Ironically that doorbell is probably harder to emulate than the Bellfruit music board, because it does some analog processing to the audio coming out of the chip, whereas Bellfruit just pipes it straight to the speaker.
4 hours ago, Altharic said:Yeah the problem with the MPU4 driver is that it's a bit of a mess, it was first written well over 15 years ago and is in need of some major refactoring to keep up with MAME's code standards today. It'll definitely get there at some point, just needs some time.
-
35 minutes ago, Altharic said:
That doorbell is now sold hopefully to our mame guy
Aaand it's on the way
-
1
-
1
-
1
-
-
5 hours ago, johnparker007 said:
If you want to DM me Sean's info if he replies and is up for doing the dump, I'm up for sorting out sending him the dosh (he'll have to make the purchase though as I don't have an eBay account)... and then anyone who wants to contribute can make an Arcade Sim donation to my donations link in my forum sig below (so Sean doesn't have to deal with a bunch of different people sending him fractions of the money).
Sean replied, he's up for it
Payment stuff sounds good to me, I PM'd you his PayPal. Checked the price on eBay and got the $49.50 as well. Also nice progress on Arcade Sim as always!
-
2
-
-
10 hours ago, johnparker007 said:
I have some budget left in Arcade Simulator (I've got a pot built from ~2/3rds donations from kind AS supporters, along with ~1/3rd suggested donations from real fruit machine peeps I have built patched ROMs for). I didn't take VR headset from that as it only benefits a small subset of users, but things like this that benefit all users generally I take from the fund, so this falls under that I feel
9 hours ago, Altharic said:I am happy to put in a tenner if it helps
6 hours ago, wolf676 said:
Very cool, thanks for the offers
I fired an email off to Sean now, hoping to hear back soon. Maybe I can give you guys his details instead to reduce fees a bit.
Also some unrelated news: I found the ROMs for Nudge Climber, which seems to be the first ever Black Box game. Probably an updated version since it's on 2 ROMs instead of 1 that it should originally have, but the jackpot is still £1. Didn't expect that one to be dumped
-
2
-
-
23 hours ago, andrew96 said:
I can't believe it is working again! I am overjoyed!
My mother did like this doorbell!!
That is great to hear! Didn't expect things to go from emulating Black Box to this haha!
3 hours ago, johnparker007 said:I know it's just for sound on one obscure machine, but I had a look and there is actually one on US eBay haha
@SomeRandomGuy
https://www.ebay.co.uk/itm/302524285134
I guess if it was to be bought so the chip can be decapped and scanned for the MAME driver, if the MAME decapping peeps are stateside, might make more sense to wire them the money/get it sent direct to them - to avoid paying import fees from USA, then import fees again from UK-> USA.
Also, seller says "I tested and does work.", I guess someone with an eBay account should message first to ask to check that song 2-3 is the Oranges And Lemons song:
https://www.youtube.com/watch?v=om-fw_Ty0ek
... to verify it is programmed with the correct set of 24 songs.
But... it is out there anyway
That one can work, it's got a very familiar song list
You're probably right on the shipping thing, Sean Riddle, who's one of the main guys involved in TMS1000 decapping is in the US, so makes sense to cut out the middleman. Definitely looks like a viable option for getting it dumped
-
1
-
-
2 hours ago, andrew96 said:
OMG are you kidding me!!!!!!
I actually bought one of those chips back in the day and made a doorbell
Well daaaamn, what a coincidence, that's def the right chip!
1 hour ago, andrew96 said:sadly I don't think the chip will be any good, it doesn't play anything correctly now, its worse than when it was removed!
Even if the chip is dead then I don't think mask ROM suffers from bit rot, so in theory it should still be decappable as long as it hasn't blown up or something, I'm not an expert on this though. That being said there's no rush in getting this dumped, it's just for one obscure game, though if you're interested then I can ask around
And some more progress on stuff that isn't Oranges And Lemons: Fiesta (Fire Cracker rebuild) is now in and I've identified 2 of the mystery ROMs - Bell Trail and Spin Up, which is a Double It rebuild. Definitely not expecting to make it in for this month anymore though, with all the TMS1000 discoveries and Bell Trail having needed more emulation of things it wants it's own way, and this is probably not the end of it. Getting closer though
-
1
-
-
9 hours ago, Altharic said:
I am wondering if there is more than one version of that software link below mentions "( the pink phanter,Tico Tico, the Marseillaise,the Cucaracha) non of those tracks are in the list of the doorbell?
2 hours ago, johnparker007 said:Note the A suffix, perhaps they used the standard MP0027 for test dev of the fruit machine, then once the knew they could make it work/speed it up for their electronic sound effects/music system, they got in touch with TI to request a custom variant, with their own note data.
Thinking about it now it's likely IMO, a new revision wouldn't make much sense if you're not changing anything, and there isn't much to change there other than the song data. The magazine articles about this thing say that MP0027 was the original program made by the Chroma Chime designers, I'd imagine the same for the A revision. I doubt that Bellfruit had a one-off chip made for probably a single game, makes more sense to buy an existing part instead. Either way, we'll only know for sure once someone gets one of the chips to play all it's music or dumps one someday
1 hour ago, johnparker007 said:Haha in theory the notes could be 'dumped' and a simulation (not true emulation) made of the sound, even for the fast effects
Well, that kind of approach is doable
. I even very briefly thought about it, but these kinds of hacks don't really fly in MAME nowadays, I very highly doubt that Vas would have it merged. I guess if someone really happens to have an itch for Oranges And Lemons, then there's custom builds, but I've got loads of fruities to emulate already, not that interested in making music hacks for one. Sampling all the tunes and playing them according to commands sent to the chip would be a quick and dirty way to do it
1 hour ago, johnparker007 said:It's a lot of work for one machine though
Definitely agreed
-
1
-
OASIS (working title)
in Arcade Simulator
Posted · Edited by SomeRandomGuy
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!