|
Post by turboxray on Nov 29, 2019 18:05:37 GMT
You can play around with stuff via the Demo program, which can also be extended with any data or overlays you'd like to load to take a peek at -- I don't have a PCE handy but I don't think disc swapping will work since you have to refresh the TOC manually in the BIOS IIRC, which I don't do. Anyway that's not very important. Off hand, I seem to remember a CD bios function specifically for disc changing.. or maybe I imagined it haha.
|
|
|
Post by DarkKobold on Dec 21, 2019 5:45:25 GMT
set_tile_data(tiles,154,table,4); load_tile(0x1800);
Forgive me for the dumb question, but elmer provided us with excellent tools for using promotion maps, tiles, and etc., and I'm just not sure how these two concepts (load directly into VRAM from CD) and (load tiles) merge.
My tile files are in 16x16 format, but then the load_tile function changes those to be 8x8 by some magic. Without having tiles, table, etc directly available, do I have to do the work that set_tile_data and load_tile do?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 23, 2019 18:56:30 GMT
IDK why you'd be using this in the first place if you're depending on the new huc.exe to have your data in suitable PCE formats. You can get away with using ISOLink in this case.
|
|
|
Post by elmer on Jan 11, 2020 0:58:44 GMT
- HuC .h header files for CD indexes and sizes
Fun and weird fact for today ... ISOLink can, and apparently already does, save a directory of CD contents into a HuC game that can be used to get CD indexes and sizes ... but it only does this for HuC projects compiled as "overlays". It seems to do this by *intimately* knowing the internal bank structure of HuC projects, and then hacking the data into pre-determined locations ...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 11, 2020 3:22:07 GMT
- HuC .h header files for CD indexes and sizes
Fun and weird fact for today ... ISOLink can, and apparently already does, save a directory of CD contents into a HuC game that can be used to get CD indexes and sizes ... but it only does this for HuC projects compiled as "overlays". It seems to do this by *intimately* knowing the internal bank structure of HuC projects, and then hacking the data into pre-determined locations ... Fun for you, maybe. I'm too busy *intimately* getting to know other platforms in which I get significantly less patronizing messages from other devs. For anyone that still cares about PCE, it would be neat to make ISOLink ditch its current model of injecting the indexes on a fixed table and an extra byte for initialization recognition. I'm happy with my script as a proof of that particular concept but it's always going to be awkward when HuC and ISOLink are so tightly coupled.
|
|
|
Post by dshadoff on Jan 11, 2020 3:26:20 GMT
Well... I wouldn't go so far as to call it "hacking" the data into pre-determined places. It's "placing". If the requirement is to be able to load any overlay from any other overlay, a directory is required...That directory needs to know - based on an array of overlay numbers - where each overlay starts (which is basically calculated based on each of their sizes).
At the time, I was told over and over that nobody wants to manage that themselves, so I built a system to manage it for them. I even heavily commented things for people who wanted to know...(but almost nobody ever looks at this documentation).
Would you have taken a different approach ? If so, what would that approach have been - keeping in mind that head seeks are super-slow and must be minimized at all costs ?
|
|
|
Post by dshadoff on Jan 11, 2020 3:34:02 GMT
I'm too busy *intimately* getting to know other platforms in which I get significantly less patronizing messages from other devs. Pot... Kettle... Black...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 11, 2020 3:38:07 GMT
Would you have taken a different approach ? If so, what would that approach have been - keeping in mind that head seeks are super-slow and must be minimized at all costs ? Yes? I don't see what's the argument here though since this is purely about indexing disc data. I just wanted to have a more flexible setup that didn't depend on injecting stuff into the overlays -- having those entries be compiler labels made more sense to me. I'd be happy with thin wrappers around the BIOS routines for disc loading, which is what I did by supplying a separate .c file with the script. Disc access is slow but doesn't make data centric applications impossible, JB Harold is my go to example. This did not attain any popularity whatsoever though, which is funny since I was perfectly fine with the very first version of it for my asm projects with almost no features compared to the current one. No one's using the hackish HuC integration haha.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 11, 2020 3:40:36 GMT
I'm too busy *intimately* getting to know other platforms in which I get significantly less patronizing messages from other devs. Pot... Kettle... Black... Hey hold on now, I hope this is not how you two are reading this thread/project. That was never the point.
|
|
|
Post by turboxray on Jan 11, 2020 3:54:40 GMT
This did not attain any popularity whatsoever though, which is funny since I was perfectly fine with the very first version of it for my asm projects with almost no features compared to the current one. No one's using the hackish HuC integration haha. I just assumed everyone made their own tool chain for CD stuffs. I never used ISOlink, or mkit, and figure others didn't as well (at least for assembly projects).
|
|
|
Post by dshadoff on Jan 11, 2020 4:01:27 GMT
Would you have taken a different approach ? If so, what would that approach have been - keeping in mind that head seeks are super-slow and must be minimized at all costs ? Yes? I don't see what's the argument here though since this is purely about indexing disc data. I just wanted to have a more flexible setup that didn't depend on injecting stuff into the overlays -- having those entries be compiler labels made more sense to me. I'd be happy with thin wrappers around the BIOS routines for disc loading, which is what I did by supplying a separate .c file with the script. Disc access is slow but doesn't make data centric applications impossible, JB Harold is my go to example. This did not attain any popularity whatsoever though, which is funny since I was perfectly fine with the very first version of it for my asm projects with almost no features compared to the current one. No one's using the hackish HuC integration haha. Actually, my question was directed toward elmer and the comment that he left. But it was not intended as rebuttal either; merely technical curiosity. Perhaps I misunderstood his emoji, but it seemed like he might not have approved of the method I employed when I wrote this 20 years ago, and I wanted to hear him expand on his thoughts. Pot... Kettle... Black... Hey hold on now, I hope this is not how you two are reading this thread/project. That was never the point. No, I recognize and respect the point of this thread/project. I understand Isolink (having written it), and anything I may have forgotten I can easily glean from the comments and/or source code, so I don't see any critical deficiencies with it... I say this as a means to explain why I haven't dug into your new code at this time. But perhaps I may in future, when I focus on something in that area (but currently I'm looking at completely different things). My comment was only to call attention to the fact that each of us writes our text with a tone, and that each of us should probably examine our own tone when we feel the tone of others is uncalled for. Sometimes we incite each other, and things can escalate. I notice that there is a lot of emotion expressed in your posts - you may do this unconsciously - and this emotion comes across with just as much impact as the tone of others to which you are calling attention (which also may be done unconsciously).
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 11, 2020 4:11:08 GMT
Ah yes I'm quite explosive nowadays, that's true. Fair enough.
|
|
|
Post by elmer on Jan 11, 2020 6:43:38 GMT
I just assumed everyone made their own tool chain for CD stuffs. I never used ISOlink, or mkit, and figure others didn't as well (at least for assembly projects). I guess that I mistakenly thought that ISOLink had been carried over from MagicKit, and so would be targeted at assembly-language programmers ... I had no idea until today that it was so closely linked to HuC. Part of my confusion over the years has been in understanding how the existing toolset was designed to be used for simple assembly-language development. Ah yes I'm quite explosive nowadays, that's true. Fair enough. I'm sorry if I sounded as though I was having a go at you, that wasn't my intention. You saw a problem, and you came up with a fix for it ... that's something that I always love to see! I was just pointing out that there apparently was already a directory that is saved into a HuC program if you build it with the appropriate options ... which is something that I didn't know until today. I knew that there was an "overlay" capability in there somewhere, but I had never really looked for it. I certainly had no idea that the overlay system actually provides a directory of *all* of the files that are added to the CD, and not just the HuC programs ... and so it forms the basis of a usable filesystem, but only for developers who are using HuC. This did not attain any popularity whatsoever though, which is funny since I was perfectly fine with the very first version of it for my asm projects with almost no features compared to the current one. No one's using the hackish HuC integration haha. Well, to be fair ... there's almost nobody using HuC at all, or doing any other kind of PCE development! Well... I wouldn't go so far as to call it "hacking" the data into pre-determined places. It's "placing". If the requirement is to be able to load any overlay from any other overlay, a directory is required...That directory needs to know - based on an array of overlay numbers - where each overlay starts (which is basically calculated based on each of their sizes). Dave, I'm not really trying to have a go at you either, as I just said to Punch ... you saw a problem, and you came up with a fix for it. But ... I'll stand by my word choice. The system that you designed has ISOLink writing to multiple specific hard-coded locations inside a HuC program, in my world that's a "hack". It totally depends upon those locations not changing, or else it breaks ... and "nope", the comments in either startup.asm, ISOLink, or overlay.h don't really make this particularly clear, although the overlays.txt doc file does provide a good explanation that helps to put it all in context. The important thing is, the system works, and you solved the problem, but IMHO it's not your best piece of design work. Anyway, yes, all games need to have a way of locating data and code on the CD, and providing some kind of directory is a very common and programmer-friendly solution. Would you have taken a different approach ? If so, what would that approach have been - keeping in mind that head seeks are super-slow and must be minimized at all costs ? I'd do basically the same thing, and put a directory block on the CD. The only real difference is that I'd have ISOLink put it in a fixed location on the CD, and then HuC (or an assembly-language program) would load it from there, and would keep it permanently in memory somewhere so that it could be used. That way there is no interdependency between ISOLink and HuC (or ASM). In fact, that's exactly what I'm modifying ISOLink to do now for my own assembly-language needs. But I don't see any reason to modify how HuC operates since your system is already in place and it works (which is the most important thing).
|
|
|
Post by dshadoff on Jan 11, 2020 11:19:35 GMT
Fair enough, it is tied to HuC, and I'll explain the reasons:
1) There was nobody back then (besides the authors of the compiler) who had any intention of writing in assembler. I participated in HuC thinking that it would be the gateway to bring "regular gaming programmers" (in the context of the 90s) to the point of becoming more comfortable with assembler.
2) Nobody (except me, while implementing HuC) ever wrote anything in assembler that tried to read from CDROM, other than the original developers. Startup.asm was the first instance of anybody ever making that happen without being an official original developer. (And I'm not sure that anybody since then has done it except while performing surgery on existing games.)
3) There was nobody back then who was writing more than, say, 1 bank of assembly language code, and therefore no foreseeable need for a disk paging mechanism to support assembler. However, HuC changes this equation considerably - (i) programmers have a longer attention span, and are far more likely to write larger amounts of functionality, and (ii) From the outset, the code produced by HuC is significantly larger than assembler for a given amount of functionality. -> The paging mechanism was requested almost immediately for HuC-based programs.
4) As turboxray implies, anybody sufficiently adept at assembler would probably want to build their own tools. And a secondary goal of HuC was to provide a commented, working code example for them.
Isolink was not conceived after lengthy design sessions, with an overarching goal of solving everybody's problem; it was designed to address a specific problem in the minimum amount of time and effort. And it was sufficiently abstracted from the HuC user that it could be replaced with a better solution if/when necessary with the minimum amount of pain.
...To assume that anything more than the above should have been created is to assume that there was more time available, more developers involved, and more information already known about the system.
As evidenced by what was developed during the next 10 years, that simply wasn't the case. I guess startup.asm must be a pretty good piece of work to convince so many people that resources were plentiful.
As was the ethos of the 90s, Isolink (and indeed HuC) was an idea that was "thrown at the wall to see if it stuck", with the intention to reveal limitations through actual usage, and address them in future versions. But I got busy, and it was also many years before anybody came close to putting it through the initial break-in period. (As it was such a long time before it got heavy use, I feel somewhat justified not to have over-invested in it).
Would I do it differently today ? Maybe... but I'm not entirely sure that I would. It would depend on more detailed conversations about how it is intended to be used, and by whom. And how much effort was required to implement each of the potential solutions.
...But certainly, if you see a different requirement, or a better way to address the stated requirement, I am not going to ever be offended if my code or ideas are replaced by a better or more universal solution.
|
|
|
Post by DarkKobold on Jan 12, 2020 2:33:16 GMT
Fair enough, it is tied to HuC, and I'll explain the reasons: 1) There was nobody back then (besides the authors of the compiler) who had any intention of writing in assembler. I participated in HuC thinking that it would be the gateway to bring "regular gaming programmers" (in the context of the 90s) to the point of becoming more comfortable with assembler.
I think this is kind of sad. HuC is quite capable of producing great games, with little to no assembly. I'm 100% reliant on HuC to make my games, and I'd like to think they are competent, quality games, despite the lack of asm knowledge.
|
|