Hardware listing and info?

[james-wallace-ghub]

Given our quest for accuracy with this sort of thing, I'm trying to track down the ancilliary components of these things so that we can at least emulate their behaviour according to the stock datasheets etc, or ideally, dump the MCUs where they exist.

I'll braindump what I know here when I'm near my parts list, but offhand does anyone know what the BFM Scorp 4 alpha (BFM BDA)was actually based on? The command codes are clearly a custom thing, as most of the behaviour matches the original starburst (BFM BD1), aside from the new character set and a few other enhancements.

Main reason I ask is that MFME in the officially released source has a character font for what looks to be that alpha, in a column-based encoding (so y=0,y=1 etc to make the 8x5). The closest part match for the Scorpion I can see made by Futaba is row-based, which seems inefficient to me, but if we're going to do it, do it right I guess.

Any help gratefully received

[james-wallace-ghub]

So, as far as I can tell the non BFM single strip alphas are parts derived from the Samsung 16l02da4 (which is a clone of MSM9202). That addresses its characters column by column, which makes more sense.

[Paul-Arnold]

Had a search through my stuff but can't find anything on the early displays. I doubt even BFG have much/anything either - discs with BD1 and BDA source were thrown when the factory shut.

The design of the most recent dot matrix displays for use with Scorpion6 was outsourced to Noritake-Itron. These used a Noritake-Itron glass - MN09608A.
There were two versions:
GU96X8M-K629C1 and GU96X8M-K657C2
The only difference between the two was K657C2 had RGB led backlighting.
ATMEGA8515 was used on the C1, I don't have a C2 to check but don't recall it being changed.

All devices I've got are code protected, don't know if there's a way of bypassing that without de-capping ?

99% working emulated versions of these exist which could be converted for MAME if needed.

[james-wallace-ghub]

Well, anything will help, with FME being so splintered its hard to keep track. Main reason I've come back to try to help with this is because so much of this seems to have been lost to posterity because of Chris' passing.

As for SC6, I don't think we do much with that, but I have some of the truth table already from some enterprising hardware hacker. (the C2 version)

[Paul-Arnold]

OK, I need to add a couple of the new commands to my emulation then I’ll convert and add to MAME.
Testing is a pain as there are new commands which have never been used by games :(

SC6 doesn’t have a placeholder in MAME yet. At some point I’ll add what I can.
Still trying to get hold of some update files which are loaded via USB for the Reflex Games version of SC6. Don’t suppose you have any ?

[Paul-Arnold]

Thanks very much for those John. That's exactly what I was looking for.
Have updated my board and they work :)
Just need to work out the encryption now to save the hassle of dumping flash from the board.

Must get back onto the alpha at some point to but this is far more interesting.

Thanks again.

[SomeRandomGuyIdk]

Since you're mentioning flash dumps, is the game just stored there in plaintext? In that case the updater should be somewhere on that flash as well, together with keys for decrypting the updates 😄. Unless they're using the FPGA in some way for doing crypto, which complicates things a bit, but as long as it isn't some scheme where the FPGA sits between the flash and CPU and decrypts data on the fly, then it shouldn't be that hard to decrypt the games.

[Paul-Arnold]

Game is stored in flash in plaintext together with the bootloader/updater.
I had the bootloader and updater but had difficulty getting any of the Reflex update files to verify but John was kind enough to provide the above.
Nothing too special from Reflex.

Emulating a Coldfire at 240mhz needs a much faster pc than what I've got though.

BTW, Great work on the Black Box driver. Why are they still sitting on it ?

[SomeRandomGuyIdk]

So that's how Reflex did it at least, more of a security-through-obscurity thing but I guess they succeeded in keeping nosy people out 😄. I wonder if the updates are signed or not (not that much point in doing it since a really determined person can just program the flash themselves to run custom code).

That's fair, though if there isn't any code in the games that makes CPU speed affect timings then you can probably get away with slashing the emulated CPU clock. Might end up needing hacks for peripheral baud rates etc. though. Makes more sense to get Scorpion 4/5 dealt with first though.

I'm sure Black Box will make it in eventually. I'm still learning the ropes here and Vas is finding dumb mistakes that got in, basing new things off legacy code also isn't helping 😄. At the end of the day it's a volunteer project, things take a while sometimes.

[Paul-Arnold]

There’s some sort of validation process which I’ll work out at some point but it’s only really needed if you want to load stuff via their loader.
Would be good to see SC4/5 progressed further and I’m surprised nobody has done them as there isn’t really anything tricky on them until you reach the point of emulating HI2 devices and that only applies to a relatively small number of games.

[Paul-Arnold]

Are there any working games supported by MAME which use the BFG dot matrix alphas ?

I would think updating the font is fairly easy but need something to test things like programable characters.

[Paul-Arnold]

The FATAL IIC1G is due to the clear command - 0xbX
In bfm_bd1 you've only got clear nothing and clear inside window, needs clear outside window and clear all putting back.
bfm_bd1 looks ok but I didn't try that.

The flashing in bfm_bd1 looks a bit odd too but possibly I've not understood - didn't look too hard. If "flash inside window" is sent it should only flash whats inside the window at the point that command is received. If you then add a new character to the window the new char shouldn't flash but previously flashing chars should remain flashing. Same for "flash outside window". Hope that makes sense ?

[james-wallace-ghub]

Main reason the flashing is bizarre is I only have the datasheet that was scanned ages ago, seemingly through a fax machine. While my image manipulation skills aren't bad, it was impossible to read that section. And then I couldn't find a workable example to test out.

Converting MFME style flashing code to our timing system was a challenge, to say the least.

BTW, how big is the font character list on the dot matrix alpha? I think the random lettering here is because of two things, one is I'm saying anything that doesn't have bit 7 set is a character, and then I'm ANDing with 0x3f to get an index. Probably on the real thing that's different, but I still have the starburst font in there. Again, MFME had some form of new font there, but I don't know how much I trust it, since it's stored by column it seems, and this code is clearly expecting to store characters in RAM rowwise.

As for Scorp 4 - I'm not a Bellfruit fan, and I was reluctant to do much to the SC4 stuff while that tech was still reasonably active in pubs through the myriad DOND knockoffs, Probably being too cautious, but still.

[Paul-Arnold]

I don't know what the early datasheets were like but the latest ones for the GU96X8M... are rubbish and don't explain the commands in any detail. For flashing they just say "D0-D3 Flash characters (none, window, background, all)."
The weird behaviour when sending multiple decimal points and other strangeness isn't explained at all.

The dot matrix font is 0x00-0x7f. In power-up default mode 0x00-0x3f is almost a mirror of 0x40-0x7f. Chars 0x25,0x26,0x3a,0x3b are blanks but 0x65 = percent, 0x66 = ampersand, 0x7a = colon and 0x7b = semicolon
It's also got a full upper/lower case mode which can be enabled.

Not sure how much Inspired Gaming is bothered about old tech, probably not much. As long as it's done without any prior knowledge is there much they could do other than ask you to stop ?

[james-wallace-ghub]

Probably not much, they haven't been fussed before, but MAME is higher profile, after all.

I don't really want to get in the way of your alpha work, but there may be some fixing needed to be done there anyway. I'll see if there's anything in the older techs for now just to make some progress, but I've been sidetracked with other projects that need some of my other skillset, and it's finding time to do both.

[Paul-Arnold]

I keep getting drawn to other stuff too, unfortunately stuff I can't release :(

I'll try and make a start on the alpha conversion this coming week or so. My font is stored as columns but whether that's right or not I don't know. I couldn't find any info on the actual glass used on the GU96X...

[Paul-Arnold]

Finally getting round to mame alpha stuff. Trying to get the dimming sorted so from other threads on here I've come up with this.
While it seems to work correctly I want to make sure this is the right approach.
I've assumed that treating the display as 8 rows of 96 instead of 96 columns of 8 is the correct thing to do even though I'm storing the font in columns ?

I'm not really sure what to do with the backlight but I don't think mame has anything which uses that anyway yet.

`

<group name="vfd0">
	<repeat count="8">
		<param name="s" start="0" increment="96" />
		<param name="y" start="0" increment="1" />
		<repeat count="96">
			<param name="x" start="0" increment="1" />
			<element ref="vfd_dm_dot" >
				<animate name="vfdduty0" />
				<color state="8" red="0.0" green="1.0" blue="1.0" alpha="1.0" />
				<color state="0" red="0.0" green="1.0" blue="1.0" alpha="0.0" />
				<bounds x="~x~" y="~y~" width="0.8" height="0.8" />
			</element>
		</repeat>
	</repeat>
	<repeat count="8">
		<param name="s" start="0" increment="96" />
		<param name="y" start="0" increment="1" />
		<repeat count="96">
			<param name="n" start="~s~" increment="1" />
			<param name="x" start="0" increment="1" />
			<element name="vfddotmatrix~n~" ref="vfd_dm_dot" state="0">
				<animate name="vfdduty0" />
				<color state="0" red="0.0" green="1.0" blue="1.0" alpha="1.0" />
				<color state="8" red="0.0" green="1.0" blue="1.0" alpha="0.0" />
				<bounds x="~x~" y="~y~" width="0.8" height="0.8" />
			</element>
		</repeat>
	</repeat>
</group>

`

[Paul-Arnold]

The meter error problem was introduced in mame0213 in September 2019.
The Starpoint Electronic Counter (SEC) was converted to a proper MAME device.
When writing the data bit the old version would do m_data = bit ? 1 : 0;
The new version doesn't convert to 1 or 0 and just copies the value to m_data so only works correctly if the caller is passing 0 or 1. Sc4 passes 0 or 0x10.
Re-instating the 1:0 conversion fixes the issue :)
I'll do a PR tomorrow. Ooops, later today :)

[rb6502]

I'd recommend instead fixing sc4 to pass 0 or 1, because that's likely more correct to how it's hooked up. BIT(whatever, 4) should do the trick.

[johnparker007]

Awesome work :) I'll download a ~2016 version and see if I can find some more of those machines that have developed issues since then, that Gen Meter Error sc4 one affected lots of sc4 machines though, a good fix!

[Paul-Arnold]

@rb6502 Should the clk_w function in sec.cpp be the same then ?
ie, remove the current state = state ? 1:0 and force drivers to pass 1 or 0 ?
That would make the two functions consistent.

[rb6502]

@Paul-Arnold Yes, that would be great.

[james-wallace-ghub]

An actual layout editor would be great - the main reason I've pulled back from this has been that we need better art support before we can realistically do anything, and I just totally burned out. Any obvious gaps in the 'old' techs I should probably try to probe as I think a lot of the 6800 series peripheral space is different now than then, and regressions may be rife.

…

On Fri, 8 Dec 2023 at 11:42, John Parker ***@***.***> wrote: Would be nice to see BFM stuff working, especially the early video SWP but I just don’t know anyone who wants to get involved :( Many years ago (2016ish), a lot more of the Sc1/Sc2/Sc4 machines worked correctly. Sc4 need to be in Door Open mode, due to unemulated ccTalk system, though we did get a hacked in basic implementation working, but that code has been lost (just simulating the various packets really, nothing too crazy. It was a guy Keith on the dadsfme forum who was looking at it, not heard from him). There's been various general refactors etc over the years that have led to these regressions. So they may not take much work (relatively speaking of course), to fix those regressions and see some games become playable again. I've had a nightmare year with health this year unfortunately, so I've not been up to doing much coding at all, and also I'm more focused on stuff that uses MAME as an emulation backend like those projects above - though, a part of this will be a layout editor (that will be able to export MAME .lay files and resources), so that should be helpful to MAME :) So next year hoping to get back to a bit of FME dev here and there, health allowing. The above , or similar, is in the recent PR which has been tested on my Scorp6 emulation and works fine but the led backlight isn’t 100% right visually. Great news - be nice to see a standard base .lay for sc6, maybe see a boot error message on the display for the one DOND game that is in there! :) AFAIK no public emulator has ever ran any sc6 games. — Reply to this email directly, view it on GitHub <#16 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFVXMETL7HI32AJYEWJ3VTYIL4LPAVCNFSM6AAAAAASB7WZDKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOOJYHE4TK> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[johnparker007]

I had been working on doing bulk conversions I think around end of last year, but then got ill. New approach is a project called 'Oasis', that will be able extract and import MFME layouts to its own internal layout format (just simple JSON). So when I get back to this, I need to continue with that, and then implement 'text' components, so the 'classic' layouts can be processed from MFME and ultimately exported as .lay files.

Later I'll be adding in editing facilities directly in the Oasis editor... currently, it is of course depending on layouts built in MFME.

Will take longer but I think it will be the way to go, so then others can sort out all the MAME internal layouts using Oasis without needing me to do anything :)