Warning! Very long post!
------------------------------------------
If anything, it's partly because I am growing older and can no longer spend whole days on PlayStation 2 development, willingly or not.
Berion having designs for some of my software, was also my fault. I shall explain below.
You don't 'have to'... In the end, it is about the fun, gathering knowledge and experience, getting contact to people and etc.
Ah, I see.
I understand.
Well, I was thinking about it, back when I was trying to rearrange the memory used by FMCB, so that everything could fit and give the exact same functionality.
Well, if you consider changing it (number of supported OSDSYS-Items) at any point in time, I'd be very happy!
You know, it is merely changing one variable. I remember you asked me back in the days (in a PM) specifically about the item-number and I first pointed you to the wrong var (something with 'MAX'[?] and later corrected my statement).
On another note: If I remember correctly there was also a 'pointer-array' (or similar?) which grew depending on the number of supported items... I think it used either ~1700Byte or ~17KB (I suppose it is the former/first value, because the second seems unproportionally large.). Something like 4*128Bit*100(OSD-Items) +10% because of something else or so? Well... It was ~9 years ago... I do have a serial/photographic memory (damn... Amnesia didn't help... Everything comes back... :'-D), but I can't recall it all (every single piece of the structure).
What I do know is, that this would statically grow and not dynamically. So regardless of the amount of paths or items added to the CNF, depending on the amount you set for the variable [for compilation] (in 1.8(b), that part is still in launcher2.c), that thing would grow ('statically')...
It has advantages and disadvantages...
I would prefer a dynamic allocation [atleast size, but possibly in which RAM-Region as well] (or possibly another way), but that just doesn't give as much control (about [preventing] overflows, etc.) like a fixed size array does... It takes some space/RAM, it doesn't need to be dynamically placed somewhere in the RAM, nothing to care about, etc.
Another thing to note is, that the 'places' within the array are 'fixed' as well ('line' 55 'cell' 3 [to put it in a kind of excel-visual perspective] would be Item 55 path 3... EVER.), which probably could be optimized as well.
However... Optimizing these things is just for 2 things... If it ever became open source and other features or more paths&items could be chosen, then this would spare some more RAM just on that already tiny array (but still... Possibly more items could be 'allowed', especially if the 'CNF-Creators' would optimize (like 'shrink' i.e. by removing unnecessarily paths) and for the sake of optimization, skill-training or whatever.
Sooo... Other things might be well more worth it.
As of now, the 3 versions of FMCB (FMCB, FHDB, XFMCB) are built off the same code base.
That is GREAT! GREAT GREAT GREAT GREAT GREAT!
This avoids (code-)redundancy and if you ever intend to release the source of the Loader/Payload, this will be VERY useful to any following developer to maintain the code in a proper way! One more reason to release it! :lol:
That compilation from the same code-base could be interesting for HDL-GameInstaller and HDL-GameUpdater as well, or not?
That is what I meant: FMCB currently has no such function. I currently have no wish to extend on my existing projects, but I will take note of these suggestions.
Yes, you already did and still do a lot of stuff for the scene. I understand that...
It would be interesting, if you would publish your sources (HDL-GameInstaller, HDL-GameUpdater, PS2Ident, etc.) on your github-account as well.
It might lead to a few people (trying) to contribute to them (via forks, etc.).
...and I really hope for the newest Loader/Payload-Source to be open somewhen, but that is entirely up to you (and like I said before, possibly @l.oliveira has got a vote in/on it).
This is clearly due to some interference by the modchip's code. :|
Yepp, definitely!
I cannot quite do anything about this, sorry.
Well, back in the days we placed the code somewhere, where a modchip doesn't place it's own code. That worked to get a ~80% (or more) compatibility with modchips.
However, this does not e, that this is the cause of the freeze... It also could be to something else.
We wanted those chips to be compatible as well and tried the best we could (because we also wanted to 'extend' modchips with new features).
Some things you might consider 'awkward' or inefficient were actually due to us trying to get every model (including atleast some prominent Modchips [like the MI and it's clones) to be compatible with FMCB.
Sorry, but I have no wish to start on another project.
You don't have to! You contributed so much to the PS2-Scene... I doubt anyone ever had so many projects (except probably for 'sjeep').
One more reason for an open source/project and publishing atleast your already opened sources to GitHub (I wonder why you didn't. I have the feeling that you've mentioned it somewhen, somewhere!
I did not deliberately make this slow/unresponsive either - it's just FreeType.
It is possible that I have been doing things wrong, but I am already very tired of everything.
No problem! Take a rest!
If the text are burned into the graphics, then the functions we have are also restricted to the graphics.
Yes, the FMCB 1.8b-Installer uses pre-made 'pictures', where the writing is part of the picture (for the tabs and the bottom-line of the installer).
However, it also uses a font to draw the notes on screen!
So it is a mix!
Until today, there's no graphics on any of the buttons.
How do you mean that? It is 'not a picture' or 'not a rendered' object? I can clearly see some button-gfx on screen...
I regret not making the system first before asking the artist for work. I felt really bad about it, and still do.
Erm... Free hug?! Hehe...
Well, it still might be of use to someone and 'somewhen'!
I used to like to try creating my own works. Both for the experience and it was something that I wanted to take pride in. But well, I just never had the skill levels of some of the older developers.
Don't underestimate yourself!
'You already reached a quite high level!'
Your job on the SDK, in the scene, your projects and FMCB has been fantastic so far.
I really like the work you've done on FMCB. I suppose you are just not so interested in OSDSYS-Hacking.
Btw.; A lot more is possible (in that regard) via quite short code, tho'. Just thought, I'd mention it.
I don't have the source code (not even the graphics) for the v1.8 installer. Even if I did, it would require work to convert the old installer to fit the new requirements.
You can find it here:
https://github.com/TnA-Plastic/FreeMcBoot
However, the loader/payload-source is not yet 100% clean (but it doesn't matter for the installer).
@bootlegninja still has got the clean source and possibly @l.oliveira as well.
This function is not implemented because the new series of FMCB no longer uses any KELF hacks. The only exception to this, was the transferring of the signature, so that we can sign a PSX's KELF with a CEX PS2.
I know! However, you somehow convert your Loader/Payload to a KELF, so that tool/part can be ported or rebuild on a PS2 (theoretically).
That's what was done when FMCB 1.2 was 'in the works' (getting the PC-Tools to the PS2, which essentially was the 'birth' of the FMCB-Installer.
Even if I do implement it, what software will you install?
It is a very useful feature for testing new/modified loaders/Payloads or even other/custom projects (XEB+, etc.).
Back in the days it was continually used for testing new builds, because we could solely compile the Loader/Payload and not the whole project.
O.k. It is possible to do that as well on a PC, but do you really expect all beta-tester to be able to make KELFs out of them and sign them properly for their MC? That's where the usefulness of this function REALLY triggers in.
'Place any ELF with this name there and done...'
I think if the project (newest version) is ever opened again, it will be as useful as back in the days.
Rightfully, the PS2's kernel has to have the user settings initialized and set in, which nearly no other software will do (correctly). Even modchips with DEV1 booting don't seem to do it right.
Well, if modchips which support DEV.1 boot the ELF directly, they skip the original one/initialization and their own/initialization often is not complete (I suppose it also depends on the FW-Version, how complete it is and which modchip.).
They have the same fault, if they support 'Fastboot (disc)'.
I have no such function implemented. Neither do I have the know-how to do such a thing.
I know... (the difference can be seen between some DVDPLx)
It also isn't necessary, because we can simply 'flag' it for all regions... (like any 1.8c and upwards is 'flagged')
Thanks. This was essentially how I have been doing things lately. I have also been occupied with debugging and fixing issues that pop up in the PS2SDK. It's not so fun, but somebody had to do it and so I really wanted to see it done.
Actually, your updates to the SDK are VERY important! I also remember pointing out one thing to you, which ever annoyed me a lot... SMAP.IRX! :'-D This 'bastard' was sooo bad, caused sooo many stalls and so on... I suppose it was one of the worst modules in the whole SDK. Nothing against the dev. THX for his contribution, but it was a bad module (structure-wise)... ^^
Things like Kernel-Loader (3.0) or myPS2 (1.3) do hang with a Gamestar-Adapter for example... (beside other issues and not being performant or less efficient)
(Your) Newer modules probably will work!
Some glitches were there since day 1, and we're now in 2018 (14 year old bugs!).
Indeed... Well... It was a rather hackish and 'patched together' convolut(e?)... erm... SDK! ^^
It was o.k. (NOT 'good') for it's purpose, so 'it did the job' and got people started into creating more sophisticated Homebrew...
I wanted to be clear of all the old projects, so that I might be able to focus on the new responsibilities in life.
Well... An open FMCB might (help to) relieve you!
Gone are those days when I could spend 8 hours on the PS2.
Or 16 (hours)... Continuously... ATLEAST for half a year... Being involved in the project, explaining EVERYONE (including Devs and the tutorial-creators and the users) EVERY single bit of it... xDD
OMFG... (I can perfectly relate to that is, what I intend to say.)
Just take a rest, if you want (to)! There is no obligation to anything, but rather desire (to get something done and i.e. proving skill-set, even if it's just for yourself and nobody realizes it... :'-D)!
The problem I have here, is that my code is tainted with stuff that I cannot disclose at this point. I have neither the source code for FMCB 1.8b nor 1.8c.
Well,... Now you do (have the sources to 1.8b).
About the stuff you can not disclose: Hm... I don't know what to say about it specifically. I suppose removing it, (probably) would render it non-functional.
My package was some late design of 1.8c, which might not have been actually used in 1.8c.
Yes, you've got the cleaned (no functional changes, but rather a bit restructuring of files and moving some stuff, separating or combining it and so on) source of the 1.8c-Version.
I could clean it up, but I have been going on and on with PS2 development, ever since my holidays started on May 12th. This is not even funny anymore.
The reasons for an open project and a rest on your side add up! Hehe...
Thank you very much!
I think he's more... vocal. But well, I guess it is fine as long as he doesn't become like somebody who wanted obedience.
Nah,... If some people who know me in person would describe me in one word, there is a 30%—chance of them saying 'anti-authoritarian' (from around 10-15 words, that's quite something).
I know, I have crushed the dreams of some. But this was the best I can do. I do not know how much resources they had to commit to make such a thing, but it got really tiring to work on these projects quite quickly.
Didn't everyone's first dream (an app for ALL [multimedia, file-/save-/HDD-/whatever-management or so...]) crush, when any newcomer asked for their honey and milk giving cow-pig-chicken, which was said to be a dream, which would never happen?
In the scene it is an IF, not WHEN (most of the time)...
Thanks for the list. There's also proper initialization of the user settings, for all PlayStation 2 models.
Well, 1.8(b) was the first who had an almost complete ( it probably not 100 correct) initialization, thought...
Since it's also shorter, it tends to boot up faster.
A faster unpacker-stub would probably yield some more ms, but it is very fast, so this would only be useful if the MC-KELF would be quite a bigger.
I'm just mentioning it for the sake of completeness.
FMCB was also redesigned to allow for a proper boot screen... which was never implemented. It also had anti-disassembly code, as well as code to block ps2-unpacker.
??? Would you elaborate a bit more on these?
Option for preserving the old user CNF.
FMCB 1.8 had that as well!
@Nold360
https://assemblergames.com/threads/need-help-compiling-fmcb.69101/
------------------------------------------
Well, if you (anyone reading this) really went through the whole post and really didn't just skimmed it, you got my respect!
Best regards,
TnA
