YM2203 tunes on Taito L System

[cmonkey]

I take no credit for the tunes OR the playback routine. I 'borrowed' the tunes from the TFM Music Maker package and ported the playback routine from the ZX Spectrum version of it (wasn't exactly hard as both the L System and the Spectrum are Z80 based), then I simply wrapped a bit of glue logic around it all to hold it together.

Huge thanks go out to legendary Russian coder Shiru for his sublime TFM Music Maker, without which none of this would have been possible as quickly as it was.

 

[silverfox0786]

That's pretty awesome

I have a play girls Taito L board

would this code work with that as well

 

[cmonkey]

Thanks.

It won't work as is on a Playgirls board but it only takes a few mins to modify the source to get it to run on a Playgirls board.

Try the attached file in MAME or on your board. The text will be 90 degrees out because Plotting is a horizontal game and Playgirls is a vertical game and I couldn't be bothered re-writing my text blitting routine for a vertical screen.

Also the button mapping is different on Playgirls so to move the caret up you need to push right on the P1 stick, to move it down you need to push up on the P2 stick and to play the selected tune you need to push left on the P1 stick. Again, I couldn't be bothered re-writing the input handling routine for this quick and dirty port to Playgirls architecture!

Works fine in MAME like this but I don't have a Playgirls board so can't test on hardware. Let us know how it goes!

https://www.ukvac.com/forum/data/uploads/1497/pg03.ic6.zip

And here's the archive containing the Plotting version :-

https://www.ukvac.com/forum/data/uploads/1497/ic10.zip

 

[silverfox0786]

that's awesome Adrian thanks

will give it a go in the morning

not sure what the architecture is but would love to see bounty bob strikes back on arcade silverfox07862015-01-18 00:17:14

 

[ArcadeHacker]

Rocks!

 

[ben76]

Amazing

Awesome stuff mate

- Ben

 

[Alpha1]

Man oh man that's awesome.

 

[silverfox0786]

got some grest results using my Play Girls Board

The screen is right way up in Horizontal and not in vertical

although controls are as you mentioned above

looks like the roms control the orientation

 

[Hurray Banana]

This is great Ade, never really did sound coding myself, was wondering if re-purposing tracker code was the way to get started and you proved it right there. great job again.

 

[cmonkey]

So today I worked on my BMP to L System gfx conversion tool. It now supports input BMP files with a max size of 512x256 pixels and generates all the sprites/tiles needed for use on L System. Input BMP x and y dimensions need to be multiples of 16 and the image needs to be 4 bits-per-pixel colour depth.

I converted a JPG of an Out Run marquee which had over 50000 unique colours to the 15 colour tile format used by L System. The results were pretty impressive, if I do say so myself.

 

[ben76]

Awesome

Really awesome

- Ben

 

[silverfox0786]

now that is bloody marvellous

 

[Hurray Banana]

That is great Ade, does it allow each tile to have a separate pallete?

 

[cmonkey]

Are you talking about the L System hardware or my gfx conversion tool?

L System hardware DOES allow a separate palette per tile (up to a maximum of 16 palettes, which is what the hardware supports). To display tiles you write 2 bytes to tile ram, first byte is tile index (0-$ff), second byte upper nibble is palette (0-$f) and lower nibble is tile page (0-$f).

My tool merely processes a BMP of max dimensions 512x256 and iterates through the image, processing a 16x16 chunk and writing the L System data to the 2 files required for each pass through the loop.

This is why I have to reduce the input BMP to 15 colours (colour index 0 for each palette is ALWAYS the transparent colour) before processing it with my tool.

If I've got time I'd like to be able to add the ability to eliminate duplicate tiles in the output files. This could be done by creating a hash for each 16x16 chunk of the input file, comparing hashes as I process each chunk and then skipping the writing of duplicate data if a hash match is found from a previous processed chunk.

The only problem with that is the Z80 tile displaying routine that I'm currently using works on the principle that duplicate tiles are NOT removed from the tile roms. Bit of a chicken and egg situation really!

 

[Hurray Banana]

so it can access 16 banks of tiles? that's quite a few.

my student game engine just raw compares tiles rather than generating a hash. your idea is a bit more elegant. It does have to tile to arbitrary dimensions so that would make the hash more tricky.

time id crippling me at the moment. I did use your pacman hello world to introduce assembly language to my second years so they could compare with high level implementation. they quite enjoyed messing with it and running it in mame. do thanks for that ade

 

[cmonkey]

It can actually access a lot more than that....at any one time there are 16 pages of 256 tiles banked in but a simple write to a bank control register allows you to page in/out another 16 pages. I haven't yet found the limitations of how many sprites/tiles you can have in total but I guess it's more limited by rom size rather than anything else. Some of the beefier L System games like Raimias use 2 x 4mbit roms. That's a LOT of tiles and sprites!!

Happy that I'm helping the next generation of games designers/developers to see what it was like to develop for slightly more limited systems!

 

[guddler]

I'm struggling with "too many fingers in too many pies and not enough time" syndrome