by Tdarcos » Wed Nov 23, 2016 1:18 pm
Ice Cream Jonsey wrote:It's not possible to convert the entire system to 64 bit right now.
I said, 32 or 64. It's essentially an early 1990s design on a 16-bit base. And to realistically go above 16 bits it would require that the game file format be changed to support either 32 or 64 bits.
Ice Cream Jonsey wrote:Property limits can be adjusted in the actual source code for the game. I forget the command but it's something like MAX_PROPERTIES=1000 or whatnot. The defaults are not hard limits.
I may have to go back and look at the manuals; my memory was there is a hard limit of 127 or 128 properties.
I looked it up and found out on page 12, I was wrong, the thing I was thinking of were attributes, not properties, and of all the things to limit, the ones that are only one byte long are hard limited to 128. This was one thing I knew was a huge mistake in putting such a tiny limit on, it reduces the potential complexity of some games that might have been possible unless you resort to "overlay schemes" by which various attributes have multiple aliases. Workable, but still feels like a kluge you have to use to get around a problem with the compiler, and sure enough, that's exactly what it is.
Now, it might be possible to do one of two things: If there are any unused opcodes then that is a potential means to escape to higher bit levels (both DEC and IBM did this with their PDP-11 minicomputer and 370 and z/System mainframes, respectively; the original instruction sets had new opcodes inserted to add new functionality, old programs could still run unmodified but new programs could be run on the new hardware), or else the old format could be extended by having a new file format and new interpreter support both kinds of game files.
But that still means the compiler has to be rewritten and this is such a niche environment that it's probably not worth it for a potential audience of perhaps 50 people using the system.
[quote="Ice Cream Jonsey"]It's not possible to convert the entire system to 64 bit right now.[/quote]
I said, 32 or 64. It's essentially an early 1990s design on a 16-bit base. And to realistically go above 16 bits it would require that the game file format be changed to support either 32 or 64 bits.
[quote="Ice Cream Jonsey"]Property limits can be adjusted in the actual source code for the game. I forget the command but it's something like MAX_PROPERTIES=1000 or whatnot. The defaults are not hard limits.[/quote]I may have to go back and look at the manuals; my memory was there is a hard limit of 127 or 128 properties.
I looked it up and found out on page 12, I was wrong, the thing I was thinking of were attributes, not properties, and of all the things to limit, the ones that are only one byte long are hard limited to 128. This was one thing I knew was a huge mistake in putting such a tiny limit on, it reduces the potential complexity of some games that might have been possible unless you resort to "overlay schemes" by which various attributes have multiple aliases. Workable, but still feels like a kluge you have to use to get around a problem with the compiler, and sure enough, that's exactly what it is.
Now, it might be possible to do one of two things: If there are any unused opcodes then that is a potential means to escape to higher bit levels (both DEC and IBM did this with their PDP-11 minicomputer and 370 and z/System mainframes, respectively; the original instruction sets had new opcodes inserted to add new functionality, old programs could still run unmodified but new programs could be run on the new hardware), or else the old format could be extended by having a new file format and new interpreter support both kinds of game files.
But that still means the compiler has to be rewritten and this is such a niche environment that it's probably not worth it for a potential audience of perhaps 50 people using the system.