Games Exposed

[lexi]

Copy anything and everything that is useful to you, I don't mind at all.

I barely knew what I was doing and I didn't expect anyone else to ever look at it, so please forgive any mess or ridiculous comments I might have left in there. I've never programmed in ZX Spectrum assembly, so I've no understanding of labelling conventions. A lot of it won't be 100% accurate, but most things should be roughly sensible. I know there are inaccuracies where I've documented something as doing just one thing, when it actually has multiple uses I've not got round to discovering.

It was fun reading over your work! Hope this helps.

Omg - that is super generous! I just spent the last hour or so looking over it and you've done an incredible amount of work - it compliments the existing zxnet disassembly with some pivotal insights and i'm only as far as merging #R$7D33

I don't see a way to merge it quickly due to the amount of investigative overlap and my own learning curve bumps.. and it depends how szeliga and guesser want to move forward.. but combined, it would absolutely be the definitive guide until another one-post-wonder drive-bys a fourth Chaos Disassembly

Either way - thanks again - amazing work and too humble - it's incredible that this years-long effort was created without before having programmed a Spectrum. I think it deserves to be archived separately from any derivative.

[lexi]

Here are some life-long questions that I'm hoping to have answered (though someone might know the answers without the disassembly):

• Are illusionary creatures tougher than real ones? I swear any time a giant rat survives one of my attacks it turns out to be illusionary about 90% of the time
• Exactly how does the manoeuvre rating work? Under what circumstances can you move away from an engaged enemy/undead? Does it just depend on your own/your creatures's manouevre rating, or does it include that of the creature you're engaged to, or other factors, as well
• You can see physical/magical resistance, attack strengths etc. How can I work out the % probability of being killed by something (e.g. creature/magic bolt)
• How come some dead creatures get 're-animated' when they get absorbed by a gooey blob, and then that blob gets destroyed?
• What are the criteria for randomisation of spells? What's stopping your spell list containing, like, 8 x dire wolf spells?

are you *sure* you want to know the answer to those life-long questions? is predictable Chaos really playing with Chaos at all?

[Guesser]

and it depends how szeliga and guesser want to move forward.. but combined, it would absolutely be the definitive guide until another one-post-wonder drive-bys a fourth Chaos Disassembly

If you want to take the lead, and field the questions from Szeliga on whether it's finished yet, you're more than welcome
I think I might have mentioned elsewhere, but after I put the disassembly on the back burner I took on a multi thousand hour project that I'm still a ways off catching up to the tail of.

[Guesser]

are you *sure* you want to know the answer to those life-long questions? is predictable Chaos really playing with Chaos at all?

Is it really predictable when it's governed by the random number generator?

(Yes, yes it is, especially with the random number generator Gollop wrote )

[lexi]

If you want to take the lead, and field the questions from Szeliga on whether it's finished yet, you're more than welcome

oh sweet, thanks! i'm happy to edit and help get the next revisions published with some suggestions of my own, and defer final decisions on naming/style/etc to others

I think I might have mentioned elsewhere, but after I put the disassembly on the back burner I took on a multi thousand hour project that I'm still a ways off catching up to the tail of.

sounds like a lot

how hands on/off would you like to be? i can take care of hosting the wip git/html elsewhere (github), or i could send you my ssh keys for your zxnet repo and ping you to rebuild the zxnet pages whenever there's a significant update/correction?

Is it really predictable when it's governed by the random number generator?

(Yes, yes it is, especially with the random number generator Gollop wrote )

maybe it's his mysterious ways. once i figure out how to write a better random number routine, i'm going to poke it in to try but.. my intuition is that it's not going to feel quite like the same game

[Guesser]

how hands on/off would you like to be? i can take care of hosting the wip git/html elsewhere (github), or i could send you my ssh keys for your zxnet repo and ping you to rebuild the zxnet pages whenever there's a significant update/correction?

It lives in my home directory at the moment, so will need to move
I might move it over to a suitable github repo tomorrow.

Do you do irc at all? When we're not procrastinating for multiple years at a time, szeliga and I discuss Chaos Things in #zx on the decrepit and dying echo.theairlock.net

[lexi]

ha! i barely recall how to use irc, but i managed to find it - thanks - i'll check it out again later.

i'll keep working on my branch locally until the github repo is ready - no rush - merging in the additional research from UsuallyDavid's detailed disassembly will take me "a while" but it'll be worth it

[szeliga]

I'll try to keep an eye out on github for your work, and scan between all the "Disconnect" messages on #zx!

[lexi]

I'll try to keep an eye out on github for your work, and scan between all the "Disconnect" messages on #zx!

Ha! Yeah, i am taking a long time figuring out which IRC Bouncer to go with before spamming my entrances and exits to the channel as often IRCNow seem like they could be a good option but are pretty ideologically driven, and after looking more deeply, it's still somewhat vague to me if that would be an issue with any of the available member orgs. Open to recommendations on trustworthy Bouncer options - doesn't have to be free necessarily.

So i have a local-branch commit on the merge-point branch from a few weeks ago which contains the the initial merge of your work into the chaos.ctl file, as transcribed from the notes you left for Guesser on your website. I'm currently working a forked branch merging that along with UsuallyDavids changes plusedits and errors added by me while combining everything into a cohesive style.

Would you like me to publish the initial merge i have of your work as-is? Or wait for the more boring version that i'm working on? They could be described as "informal" in places - but it could also be described as a charming insight into friendship and how communities get things done

[szeliga]

Ha! Yeah, i am taking a long time figuring out which IRC Bouncer to go with ...

So i have a local-branch commit on the merge-point branch...

Would you like me to publish the initial merge i have of your work as-is? ...

I've used the ZNC bouncer (link below) on my raspberry pi for years. It's free and does what I need apart from stripping out the stuff Guesser posts about Teletext...

I saw your branch earlier when I was setting up my PC and trying to remember where everything was at 3.5 years ago in terms of editing and generating skoolkit output! I've downloaded skoolkit-9.0, applied your DEFINE macro changes and had a bit of a look at the start of UsuallyDavid's stuff (so just from $7D00 to $7D5D !).

I've forgotten a lot of what is in there, so feel free to publish "as-is" and "informal" whenever you like and hopefully it'll restore some memories and motivation



[ ZNC bouncer: https://wiki.znc.in/ZNC ]

[lexi]

Awesome - i've pushed your changes to github now UsuallyDavid was working on the skool file directly, so i don't know if there's an easier way to merge it than what i'm doing by comparing the html output side-by-side, as trying skool2ctl on it created so many merge conflicts.

[mrcook]

I'm not sure if this would help, but:

I took the UsuallyDavid skool file and generated a valid control file , which allowed me to then generate a new skool file directly from the TZX file. I also took all those separate guesser/szeliga control files and reconstructed them into a single control file (assigning various code/data blocks, and adding a few missing ones), which also allowed me to generate a skool file - hopefully I didn't delete too much valuable info during that process

They're in my speccy repository for your perusal:

* UsuallyDavid: https://github.com/mrcook/zx-spectrum-g ... ally-david
* Guesser/Szeliga: https://github.com/mrcook/zx-spectrum-g ... er-szeliga

[lexi]

I'm not sure if this would help, but:

I took the UsuallyDavid skool file and generated a valid control file , which allowed me to then generate a new skool file directly from the TZX file. I also took all those separate guesser/szeliga control files and reconstructed them into a single control file (assigning various code/data blocks, and adding a few missing ones), which also allowed me to generate a skool file - hopefully I didn't delete too much valuable info during that process

Ah - there's a third semi-unreleased ctl file created by Guesser/Szeliga for their disassembly at https://zxnet.co.uk/spectrum/chaos/ - that's the base version i'm currently merging those additional contributions into. It has all the spiffy macros that generate the wonderful animated pages like more than all of the creatures The .ctl file generated from the .skool file provided by UsuallyDavid, formats lines and blocks for the same addresses wildly differently.. and i could tweak/reparse that.. but then a clean address-line merge would not make sense as merging technical commentaries requires human interpretation. (aside - you could probably boil several baths of llm water autobreaking that process)

Yet, looking at other disassemblies though (thanks for your server bytes!), i'm struck how they focus less upon the technical details of which register is getting loaded where, and read more like a narrative of how the routine flows - that's an additional task atop purely containing the technical insights from multiple sources. I've also spent some time trying to ensure some internal consistency in style/naming conventions - i couldn't find and i'm not sure if there's a set of loose or defined standards followed by most disassembles.

It's really awesome that there's so much interest in getting this done! We have all the tools for collaboration if anyone wants to help write-up a function or two. I thought this would just be a sleepy project that'd keep me busy for a month or two, but either works

They're in my speccy repository for your perusal:

Maybe consider adding a link to this thread or an explanatory note? My understanding here is subjective and not authoritative:

* UsuallyDavid: https://github.com/mrcook/zx-spectrum-g ... ally-david

I take this to be a WIP solo-project that was donated as-is to help Szeliga/Guesser finish theirs. I find it remarkable how much they discovered on their own, and feel their contribution should be preserved and noted accordingly as part of the whole story.

* Guesser/Szeliga: https://github.com/mrcook/zx-spectrum-g ... er-szeliga

This commentary seems more of an informal pull request/set of commits to me - it's already in git and being merged with UsuallyDavids work into the Guesser/Szeliga repo at https://zxnet.co.uk/spectrum/chaos/ - to be released when the active stakeholders are happy with it

[mrcook]

Ah - there's a third semi-unreleased ctl file created by Guesser/Szeliga for their disassembly...

I did try to find all the sources but I guess I missed that ctl file!

I created my zx-spectrum repository as an additional place to backup projects like this. So much stuff "on the internet" has been lost over the years and I find that rather saddening. I added these two sources as another backup, another historical reference if you will.

I'm looking forward to seeing this disassembly evolve and I will certainly add a link to it when you make it available on your gihub account. BTW, I would prefer you to make the WIP available now rather than "waiting till it's finished". Often the finishing is the hard part, so at least having the current version available means we don't lose what effort has already been put into it.

...i'm struck how they focus less upon the technical details of which register is getting loaded where, and read more like a narrative of how the routine flows

This to me is what a disassembly should be! Stating: "LD A,4 ; load A register with 4" has no benefit, the assembly itself tells you that, but a "; load A with the max lives for the player" now that's something

...i'm not sure if there's a set of loose or defined standards followed by most disassembles

I don't suppose there is. For my Jetpac disassembly I just did what I thought was right...I guess that's all we can do

Here's wishing you all the luck on this project!

[Guesser]

I feel I should defend what szelega and I had done as very much a first pass. In some senses we're not much beyond the "identify what is code and what is data" stage. I got carried away making things like the spells table pretty, because that was easy
A lot of it merely describes what the code is doing but not why, as at the point it was written the reasons were mysterious. Multiply a mystery variable by four and add one then store the result in a mysterious table and so on
I don't know if there's any generally agreed standards for how to document a disassembly but I certainly haven't read them if there are (We can tell! Ed.)

[lexi]

BTW, I would prefer you to make the WIP available now rather than "waiting till it's finished". Often the finishing is the hard part, so at least having the current version available means we don't lose what effort has already been put into it.

I see what you mean. Beyond the sources you already have - i haven't added anything beyond a few cosmetic edits to work out how to include tables for bits and input registers, and how to make it look pretty/standardised style etc - this is my first experience with Skoolkit so most of my time so far has been learning not doing

I will be pushing my changes either per-function or in small groups as they come - i'm proactive about backups/archiving.

I don't suppose there is. For my Jetpac disassembly I just did what I thought was right...I guess that's all we can do

Here's wishing you all the luck on this project!

Aw, thanks!

[SkoolKid]

this is my first experience with Skoolkit so most of my time so far has been learning not doing

On that note, I've just had a look at the chaos-disassembly repo on GitHub and I do have a couple of suggestions on how to make (slightly) better use of SkoolKit. If you're interested, I can fork the repo and submit PRs, or send you diffs either here or via e-mail, or whatever. And if you're not interested, I'll keep any diffs to myself.

[lexi]

Heck yeah! Even a few examples would set me on the right path and save a lot of time - thanks so much!

Happy to take the diffs either over email, or as a github fork if that's simpler - thanks again

[SkoolKid]

Happy to take the diffs either over email, or as a github fork if that's simpler - thanks again

PR 1 submitted: https://github.com/ZXGuesser/chaos-disassembly/pull/1

If that works, I'll get started on PR 2.

[lexi]

PR 1 submitted: https://github.com/ZXGuesser/chaos-disassembly/pull/1

If that works, I'll get started on PR 2.

Thanks! These are great, and very welcome

[lexi]

I'm running into a couple of issues with how to best handle labels for subroutines:

1. Subroutines with no external entry points given labels indistinguishable from common routines
2. An attempt to fully-qualify the label leads to less ambiguity but also makes the html disassembly slightly more unsightly
3. What i'd like to do, but runs into issues with duplicate _InnerLoop, _OuterLoop labels, etc

I suppose the easiest way would be to use option #2, then add a script locally to tidy up the html. The example used above is not my disassembly, but it is an issue I haven't found a tidy solution for yet.

[SkoolKid]

I'm running into a couple of issues with how to best handle labels for subroutines...

I'm not really sure what you're asking here, so I won't attempt an answer, but I have to ask: Are you assigning labels to instructions that aren't jumped to or called from anywhere else in the code? If so, why?

[lexi]

I'm not really sure what you're asking here, so I won't attempt an answer, but I have to ask: Are you assigning labels to instructions that aren't jumped to or called from anywhere else in the code? If so, why?

No - these are labels already present in the control file that i'm renaming for consistency/readability - inner loops, logic branches - "private goto''s" is more accurate than "subroutine vs routine"

A better example - except for the delineated entry point, the repeated "TurnMenu" text for the private-goto labels doubles the amount of text and reduces the speed at which i can follow the code:


Here are "private goto's" with the unnecessary repeating text adding visual noise:
TurnMenu_LoadWizard, TurnMenu_NextWizard, TurnMenu_PrintOptions, TurnMenu_PrintLaw, TurnMenu_PrintChaos

For the HTML, it'd be easier for me to read them, without losing meaning, if they were just displayed as:
_LoadWizard, _NextWizard, _PrintOptions, _PrintLaw, _PrintChaos

After i posted, I looked up your HTMLWriter extension docs, and it looks like that's probably the way to go.

[SkoolKid]

After i posted, I looked up your HTMLWriter extension docs, and it looks like that's probably the way to go.

An HtmlWriter extension would be one way to go, but...there is no established public API for mangling labels before they're rendered, so whatever modified writer you come up with may not work from one version of SkoolKit to the next.

Perhaps a better way would be to embed some JavaScript on disassembly pages that finds <td> elements whose class is "asm-label" and strips away any text up to (and maybe including) the first underscore (if there is one). I'm pretty sure that should be doable, but I'm no web developer, so I can't give any detailed advice on how to do that.

Probably the simplest way to embed JavaScript on disassembly pages is to create a custom asm template.