Recent Posts

Many thanks for that detailed response, it's clear there's more options in the software than I realised, I will experiment further and report back! I'm going to stick with file/folder sorting, I've no faith in ID3 tags, have tried repeatedly in "Fruitbox" and found issues, not least because there is no single tagging protocol and of course older files are tagged according to the whims of the original ripper. It would take a lot of work to standardise all my files, easier, in my case at least, to sort the files into appropriately named folders. Will have a play later today.

This is exactly the kind of error you have if you're running a newer plugin (post v17.0) with an older DemulShooter version (pre v17.0), or a newer DemulShooter with an older plugin.

Hey argonlefou!

I reinstalled a clean dump and installed the plugin using DS 17.2.0.0 but still have the same issue.
Don't know what to do here. Strange as it worked when released. Could it be something with the newer versions of DemulShooter maybe?

I've experimented with renaming files using the split5 format and can tidy up the titlestrips somewhat, by sorting by album I can get the 2 sides of a single in the same titlestrip but not listed correctly, if the program had a second sorting parameter it may then work (Album, Track No.) Ideally the titlestrips would be generated and then randomised as done in DWJukebox.

Hi Vampire, and thank you for your feedback!

Firstly, my apologies for not responding more quickly; it's been quite hectic here recently.


The primary reason the ini option is called 'SongSort', is to preserve a level of backwards file structure compatibility with DWJukebox, but the underlying logic is:

1. If the database is empty or invalid (or the 'UpdateIndex' option is set to true), we read in all the available metadata for each track, and build the database. If ID3 metadata is not sufficient to uniquely identify the track (or is disabled), we apply the selected 'FilenameCrop' option (ie, Split5/Smart, etc.).
2. Apply the selected sorting algorithm, based on each individual track's metadata.
3. Display the title strips.


If I'm visualising this correctly, your file system structure is:
    ArtistName
      └- Album1
        └-   Track 'A' Title
      └- Album2
        └-   Track 'B' Title

And your skin.ini file specifies 'SongsPerStrip=Double'.

To 'tie' two tracks together, the album title is used (currently), which (in the example above) would be two similar (but not identical) albums, resulting in a loss of fidelity (assuming we were to rely on the folder name to contain the album name, which we don't do at this point).

If (on the other hand) your track filenames contain ALL the relevant data in Split5 format (ie, album name - disk number - track number - artist - track title; eg: "Singles-01-01-John Denver-Take Me Home, Country Roads.mp3" for the 'A' side, and "Singles-01-02-John Denver-Thank God I'm a Country Boy.mp3" for the 'B' side), regardless of where they're stored in the filesystem, the correct relationship should be in no doubt.

Obviously, my assumption is that, for a single, track number 1 will be the 'A' side, and track number 2 the 'B' side.


So, if (for whatever reason) the track numbers aren't accurately read in during metadata parsing, this relationship will not be stored correctly, and the sorting step will yield inconsistent results, causing the title strips to appear jumbled.


Your suggestion is completely valid, and I'll be reviewing the code for filename-only based metadata creation and sorting methods.

To date, this hasn't been much of a personal priority, as I spent considerable time a few years back running my collection through MusicBrainz Picard to update the ID3 info on every track, and have been focused on ensuring ID3 info works reliably.

I agree completely that it's VITAL to be able to display singles as singles (with A/B side preservation), so I could easily add a 'FileFolder' option to the sorting methods (or maybe just enhance the 'Smart' FilenameCrop method?), to ensure singles are treated as a discreet unit (even when randomly sorted) - the caveat being that the file system would be required to match a highly structured layout and naming convention, which may be fragile and difficult to detect/maintain/enforce.


Also, you're quite right to point out the inaccuracy in the ini documentation regarding Album sorting - that's a holdover from a previous strategy. We always allow Album sorting now, precisely so that singles are grouped together whenever 'SongsPerStrip=Double' is set.

From the latest ini file:
    ; If SongSort is set to:
    ; Album: title strips will be sorted by the album name.
    ; Artist: title strips will be sorted by the artist name.
    ; Popularity: sort by playcount, in descending order.
    ; Random: title strips will be randomized.
    ; Title: sort by song title.
    ; Type: sort Video tracks from Audio-only tracks (Video first).
    ; Unsorted: Tracks will appear in the order they're stored in the database.
    ; Note that Album sort no longer only applies to CD-based skins.
    ; The default is Artist.
    SongSort = Artist


Hope this helps.

Ah, thanks for the info jeremymtc, well hopefully my board is a win-win for Malenko and I anyway.
 

It's a fork of MAME where I implemented the motion for most of those games as it wasn't emulated at all.

MAME already has the ability to send strings out on the 'localhost' to software on the same PC, so I wrote my own program to do that and then send it out the PC on RS232. But that bit is pretty much what MAMEhooker already does, I'm told.

My fork's on github. I'm not sure the PC tool is on there yet, but I'll get it all uploaded if people are interested in trying it.

Nice! Which piece of software dis you use to gather feebback/rumble from MAME?

Ok, staying within the rules this time and avoiding ROM links

My ropey emulator is linked in the video description above .

@Sailorsat - fancy making it better and the world can use your C139 branch instead of my hack?
It seems different to Full Scale - I had a lot of wild shuddering of the side screens until I dropped it to one sample per frame around the middle scanline.


The CRCs etc to add it:
/*
ridgerac3m
Three Monitor Version
*/
ROM_START(ridgerac3m)
ROM_REGION(0x200000, "maincpu", 0) /* main program */
ROM_LOAD32_BYTE("rrc_prgll.4d", 0x000003, 0x080000, CRC(82ac55cf) SHA1(fdbf32598b846df4227c21895d5ff037388bfe86)) // Ridge Racer Standard  -Foreign B-  Date 1993-10-28
ROM_LOAD32_BYTE("rrc_prglm.2d", 0x000002, 0x080000, CRC(b6b7e74e) SHA1(6fbda5684de792a59757e90fbf09c6e4576de393))
ROM_LOAD32_BYTE("rrc_prgum.8d", 0x000001, 0x080000, CRC(67838e47) SHA1(fa88b535f45e47b9cf47f9023ccfb8e335293096))
ROM_LOAD32_BYTE("rrc_prguu.6d", 0x000000, 0x080000, CRC(59e7f8d2) SHA1(7e743b31cd59a300ea68d7844d89f5f1d42dc2b9))

--------------------------------------------------------

PORT_MODIFY("DSW")

PORT_DIPNAME(0x00030000, 0x00000000, "PCB (screen) Select")
PORT_DIPSETTING(0x00000000, "No position (service)")
PORT_DIPSETTING(0x00010000, "Centre/Main (PCB 2)")
PORT_DIPSETTING(0x00020000, "Left (PCB 1)")
PORT_DIPSETTING(0x00030000, "Right (PCB 3)")

---------------------------------------------------------

GAME( 1994, ridgerac3m, ridgerac, namcos22,  ridgerac3m, namcos22_state,  init_ridgeraf,  ROT0, "Namco", "Ridge Racer Three Monitor Version (World)", MACHINE_SUPPORTS_SAVE) // 1994-07-01, Standard game with Fullscale 3-monitor linkup

OutputHooker v1.2.0 released!

- Added LEDWiz support
- Added new "Ultimarc - Set RGB LED Color" command

https://github.com/PolybiusExtreme/OutputHooker/releases/tag/v1.2.0

mjr posted this note on his page:

"Warning: NXP recently shipped a new batch of KL25Z boards that's not compatible with the Pinscape software. To run Pinscape, you need an original KL25Z, manufactured before 2021 or so, and those have become scarce over the past few years. I recommend looking at the new Pinscape Pico project as an alternative if you don't already have a "classic" KL25Z on hand."

I think he's been active on the forum at VPF, so it may be worth asking him directly what the incompatibility concerns. I assume that there's something more than just the lack of accelerometer at play, but I only know about this stuff kind of tangentially.

Very cool, Ond!

The only issue with wider adoption of that design is that the KL25z was recently revised/cost reduced and the current versions don't have an accelerometer. There are some efforts underway (Pinscape Pico) to port the functionality to a Pi-based sbc (RP2040 iirc) to work around the lack of suitable KL25z's. I believe that those require an add-on for accelerometer input too though.

That's interesting!  Hmm I feel tempted by the challenge.  So, the MEM accelerometer chips are available as well as the cheaper KL25Zs.  I think just for the hell of it I'm going to buy both, solder the chip on and load up the Pinscape firmware. The cost of my original KL25Z from Pinscape was still more than the cost of those parts. I'm ok these days with surface mount stuff, any other reasons my idea won't work? Anyone have thoughts on that?