The reason why the addresses for the a/x/y registers changed with the c128 is because the c128 does a lot of bankswitching, and calls between code in different banks need a similar mechanism of first storing x/y/a (and actually more), then switching banks, loading back the registers, calling a function, storing x/y/a, switching back to the original bank the calling code is in, reload x/y/a (etc) and then return. To ensure the addresses used for those are always available, and do all this saving/loading with as little overhead as possible, the storage for this must be on the zeropage. SYS uses part of the same mechanism. Commodore never considered the actual addresses used by the sys command for x/y/a as part of the kernal interface. The kernal interface is really intended to be used from assembler, not from basic. It being possible, and even usefull, to use if from basic not withstanding. That is a logical consequence of being able to call machine code from basic, but not an intended use of the kernal interface. And hence, while what you do is pretty neat and usefull, it is outside how this interface was intended to be used, and this kind of use was simply not considered as part of the 'standard'. You'll find those addresses also changed on some other 8 bit machines (b500/p500 and similar come to mind)
I appreciate the comment! I am very much still learning about the C128, but my understanding is that the entire bottom 1K of RAM is shared memory, hence I didn't see why the previous addresses couldn't have continued to work, for the benefit of BASIC programmers. If the memory management of the C128 resulted in those addresses being hit so frequently that efficiency became an issue, that would indeed explain why they allocated them precious zeropage space! -- JC
@@BasicBitesCA The amount of shared ram is configurable (common ram configuration in $d506), and is 1k at the bottom of ram by default. It can be disabled, enlarged, and you can also have common ram at the top of the address space. This is also observed by both the 8502 and the z80. Zeropage and stack however will always be shared, but the actual rules for where they are in physical ram are a bit too complex for a facebook comment. The mmu is great, lacking, simple and yet fairly complex all at the same time 🙂
@@BasicBitesCA btw, I see your point with regards to those addresses having changed. To at least partially make up for that however, basic 7 provides you a much more direct way to provide values for registers in a sys call by providing them as extra arguments to the sys command.
"Not a bad idea for the next guy who'll read your code." - and by a very good chance, this next guy will be yourself, a few months or years down the line, scratching your head what the heck did you even do there. :)
My hunch is not without further modification -- but if those machines similarly contain a unique RESET vector at 65532, then further values of Machine Type can be added using the same method as is used to detect the C128, and tweaks made based upon that. I don't code for any of those machines, but VICE emulates them all, so I would encourage you to download the code and experiment with it further. ☺️ -- JC
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
Once again interesting information and great video, thanks!
The reason why the addresses for the a/x/y registers changed with the c128 is because the c128 does a lot of bankswitching, and calls between code in different banks need a similar mechanism of first storing x/y/a (and actually more), then switching banks, loading back the registers, calling a function, storing x/y/a, switching back to the original bank the calling code is in, reload x/y/a (etc) and then return.
To ensure the addresses used for those are always available, and do all this saving/loading with as little overhead as possible, the storage for this must be on the zeropage.
SYS uses part of the same mechanism.
Commodore never considered the actual addresses used by the sys command for x/y/a as part of the kernal interface. The kernal interface is really intended to be used from assembler, not from basic. It being possible, and even usefull, to use if from basic not withstanding. That is a logical consequence of being able to call machine code from basic, but not an intended use of the kernal interface.
And hence, while what you do is pretty neat and usefull, it is outside how this interface was intended to be used, and this kind of use was simply not considered as part of the 'standard'.
You'll find those addresses also changed on some other 8 bit machines (b500/p500 and similar come to mind)
I appreciate the comment! I am very much still learning about the C128, but my understanding is that the entire bottom 1K of RAM is shared memory, hence I didn't see why the previous addresses couldn't have continued to work, for the benefit of BASIC programmers. If the memory management of the C128 resulted in those addresses being hit so frequently that efficiency became an issue, that would indeed explain why they allocated them precious zeropage space! -- JC
@@BasicBitesCA The amount of shared ram is configurable (common ram configuration in $d506), and is 1k at the bottom of ram by default. It can be disabled, enlarged, and you can also have common ram at the top of the address space. This is also observed by both the 8502 and the z80.
Zeropage and stack however will always be shared, but the actual rules for where they are in physical ram are a bit too complex for a facebook comment.
The mmu is great, lacking, simple and yet fairly complex all at the same time 🙂
@@BasicBitesCA btw, I see your point with regards to those addresses having changed.
To at least partially make up for that however, basic 7 provides you a much more direct way to provide values for registers in a sys call by providing them as extra arguments to the sys command.
Great video!👏👏👏
I found this channel just now. Liked. Subscribed. I hope to get a vice emulator going again, I had it once then my hard drive died. Great content.
Thank you, and welcome! -- JC
"Not a bad idea for the next guy who'll read your code." - and by a very good chance, this next guy will be yourself, a few months or years down the line, scratching your head what the heck did you even do there. :)
Ain't that the truth! -- JC
Would be interesting to see if the same program runs properly on a PET or 16/116/+4 :)
My hunch is not without further modification -- but if those machines similarly contain a unique RESET vector at 65532, then further values of Machine Type can be added using the same method as is used to detect the C128, and tweaks made based upon that. I don't code for any of those machines, but VICE emulates them all, so I would encourage you to download the code and experiment with it further. ☺️ -- JC
Great channel! :)
Thank you! I have enjoyed videos on your channel as well. ☺️ -- JC