Flight of a Dragon

Use this forum to share and discuss Uzebox games and demos.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Flight of a Dragon

Post by L4rry »

Jubatian wrote: Sun Jan 14, 2018 11:17 am I created a version which should work on the JAMMA, I added it to the wiki. Thanks for the info in the other topic, hopefully I could get everything at least sort of right!

Also I found a byte which I could free, so now the game has credits. In the normal game, you have 5 lives (you may retry the level you failed from the death screen), on the JAMMA, you may "buy yourself through" the game.

What I could not test is whether the JAMMA version reads and interprets the soft DIP switches correctly (it should), as I could not find the soft DIP switch setup program (does anyone know where it is?). By default if the JAMMA EEPROM block is missing, it assumes the soft DIP switches being zero, so one coin buys you one credit.

It was a ridiculous coding run by the way...

First of all I was lucky to find one free RAM byte, or better say, one RAM byte which I had reserved for something what I didn't need in the end, so I could utilize it (it is still not a completely free byte as it is an unused color on a palette, so Mode 74 is actually reading it, just having no effect on the display). That was necessary to implement credits.

Then to my luck the story sequence was programmed in such a manner that it's state was still there on the death screen, so I could add code to revert to the previously played level (however the score can not be restored to the start of the level, so I rather had to add a penalty which makes it certain that you can not get infinite score with enough coins on the arcade).

Then at least five or so times I totally drained the remaining ROM space making it necessary to invent things to reduce the existing game's code. Rewriting stuff in assembly, getting around crappy C code generation, discovering new attributes which make code smaller...

Anyway, it should work. Or at least if it has any bug, it shouldn't be hard to fix now.

The normal game is also updated of course (Nicksen!) adding the credits support. It is now easier to complete it with 5 lives to work with (or if you use the JAMMA version, you can essentially have infinite lives).
So I've just completed a JAMMA port for Iros (I'll release it as soon as I can test on hardware) and thought I'd play around with your FoaD Jamma build. I tested it on uzem because of the two controller support. Player 2 controller is used for inserting coins ofcourse. It seems to work fine. The one thing you will want to change though is to detect coin inserts everywhere through your game. Not just the start and continue screens. Also allow more than 1 coin in total. Imagine someone chucks in a coin while the game is being played. It won't register and the coin would be lost. Had to do the same for Iros.

I managed to get a hold of the Softswitch program and made an attempt at adhering to the dip switches. Unfortunately it seems the bit layout mentioned on the Uzebox JAMMA virtual DIP switch configuration is incorrect. For instance for the '1/2' coin setting I get a value of 16 for that byte which makes no sense (everything else default). So I ended up ignoring the dip switches and defaulted to 1/1 and a no-sound attract mode. I'll attach the Softswitch app here. Perhaps you'll have more luck. Let me know.

Hopefully soon I'll have some hardware to play with and I'll take a vid/pic of FoaD in action :) Ordered some boards built from the open source board files for the uzebox JAMMA and they should be arriving soon. Already have my JAMMA cabinet in place :) Will update the Uzebox JAMMA forum if I succeed with this little project.

softswitch05.uze
(28.15 KiB) Downloaded 1010 times
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Flight of a Dragon

Post by Jubatian »

L4rry wrote: Wed Jan 31, 2018 12:43 pmSo I've just completed a JAMMA port for Iros (I'll release it as soon as I can test on hardware) and thought I'd play around with your FoaD Jamma build. I tested it on uzem because of the two controller support. Player 2 controller is used for inserting coins ofcourse. It seems to work fine. The one thing you will want to change though is to detect coin inserts everywhere through your game. Not just the start and continue screens. Also allow more than 1 coin in total. Imagine someone chucks in a coin while the game is being played. It won't register and the coin would be lost. Had to do the same for Iros.
Thanks! That would be something very difficult to change as I have no RAM either to count coins or to keep track of the Player 2 controller's state. On the Start and Continue screens the game uses a different, special controller read suitable only for those screens where there is sufficient VBlank time to do it (although maybe I could replace the kernel for the JAMMA build if the JAMMA hardware is fast. The normal Uzebox version of the game has a novel approach for controller reading supporting slow wireless ones: since the new bootloader also has that, you can use a wireless SNES controller to select FoaD in the bootloader and then play it, but then still there is no RAM to hold the controller state & coin count). If I had the resources, I would have done it so the coin slot is always active, but I didn't.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Flight of a Dragon

Post by Jubatian »

I tested the soft DIP switch configurator.

For a start, it can not reload the JAMMA block. I can save it, using Emuze I can view it, but the soft DIP switch configurator can not find it even though it wrote it. The block ID (0xAB0C) is correct. The soft DIP switch setup is off. There are three documents in existence describing it:

http://uzebox.org/wiki/Uzebox_JAMMA_vir ... figuration
https://basementhobbies.files.wordpress ... -rev-c.pdf
https://basementhobbies.files.wordpress ... manual.pdf

They are all the same. However the soft DIP switch configurator fails to respect this layout. Anyway, as of now it seems like FoaD neither loads it for some reason while it of course doesn't have any problem loading its own EEPROM block with the high scores.

Probably we could analyze some older JAMMA game to check how it handled the soft DIPs.

EDIT: The only game in existence specifically for the JAMMA at least by the Wiki is Smokey and the Bandit. Thankfully it has source, but the game doesn't use the EEPROM at all. Then of course there is Megatris JAMMA, which neither uses the soft DIP switches.

Maybe nobody ever used them and the soft DIP switch configurator ended up remaining buggy. Does it have a source somewhere? (I think the best would be following the documentations as only the Wiki is in our control of those).
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Flight of a Dragon

Post by L4rry »

Jubatian wrote: Wed Jan 31, 2018 6:33 pm Maybe nobody ever used them and the soft DIP switch configurator ended up remaining buggy. Does it have a source somewhere? (I think the best would be following the documentations as only the Wiki is in our control of those).
I found the sources on the Uzebox JAMMA forum in an earlier post. I attach it here. The original .uze file I attached was linked in the same forum a bit later on and from the comments it seems to be a later build then the attached sources.
softsswitch.zip
(218.17 KiB) Downloaded 1031 times
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Flight of a Dragon

Post by Jubatian »

L4rry wrote: Wed Jan 31, 2018 8:07 pmI found the sources on the Uzebox JAMMA forum in an earlier post. I attach it here. The original .uze file I attached was linked in the same forum a bit later on and from the comments it seems to be a later build then the attached sources.

softsswitch.zip
Actually this seems to be working better than the .uze, at least it is capable to load what it saved. I also see that it has the Cabinet DIP switches in reverse bit order (at least it has a definite bit order, not like the .uze which I couldn't figure out). I compiled it right now, it works with the current Master kernel. I think I will play around a little with it in the weekend, maybe I will add it to the Master as a tool, to have it alongside with Emuze.

EDIT: Added a post in the Uzebox JAMMA topic.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Flight of a Dragon

Post by Jubatian »

I fixed some bugs in the JAMMA version, now it should use the soft DIP switches correctly. The related JAMMA binaries are updated on the game's wiki page.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Flight of a Dragon

Post by Jubatian »

The game is broken with current GCC.

I found the origin of the issue, the current GCC reorders the resources of the game the way it feels fit, which breaks it (as those resources are laid out in strict order for getting things aligned). I am still looking for ways to get around this.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Flight of a Dragon

Post by CunningFellow »

linker sections ?
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Flight of a Dragon

Post by Jubatian »

CunningFellow wrote: Sun Jun 21, 2020 9:30 pm linker sections ?
That was my first jab at the problem, trying to just get it done by putting every piece of data in its own section and be done with it. It works until about line 5687 of res.c, from which point I used extensively the preprocessor to construct data, with tons of ordered const arrays defining pieces of map descriptions and such, which don't even have fixed sizes. The whole thing was possible because this could be done, manually building all the data for the game in this manner. It just wouldn't have been possible any other way, there are so many types of data there, such structures that it wouldn't have been done ever trying to create editors for those.

The only solution I could imagine is transforming the entire resource file into assembler, where the preprocessor can still be used the same way, but everything stays in order. Monumental repetitive work, though at least straightforward. Seems like it will have to be done at some point to keep the game compileable.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Flight of a Dragon

Post by CunningFellow »

Bugger. Does

-fno-toplevel-reorder

help ?
Post Reply