You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 65816 sources attempt to maintain as much compatibility with the 6502 codebase as possible. This is laudible, but I find it gets in the way of reading the code and understanding what's happening or why things are happening. Here's an example:
; here is to manage 65xx02 code ***temporarily limited to bank zero TYX ; check bank for a moment BEQ exec_long ; already in bank zero means no need to install wrapper *** ***; ***** in case 6502 code is running beyond bank zero, setup wrapper here! *****; after that, push alternative (wrapper) return address; PHY ; push target bank; *** is the above needed for 02 code? should not harm anyway ***; PEA $FFC4 ; sample return address, will point to a JML sig_kill; BRA exec_retset ; all done?; ***** in the meanwhile, just reject the request *****; should deallocate resources, just like an invalid CPU! _DR_ERR(INVALID) ; 6502 code not yet supported on that address; long indirect call, just push the proper return address, both RTS & RTL savvy
I would argue that 6502-specific code should be tucked away in a set of sources reserved for just 6502 code, and 65816-specific code should be tucked away in a similar set of sources. Then, in the main source files, I'd .include them when and where appropriate. This already seems to happen in a couple of places, but it seems to only apply to major components and not to smaller functionality.
Then, for the 65816 chunks of code, I'd rewrite them just for the 65816, without fear or concern regarding the 6502.
The text was updated successfully, but these errors were encountered:
The 65816 sources attempt to maintain as much compatibility with the 6502 codebase as possible. This is laudible, but I find it gets in the way of reading the code and understanding what's happening or why things are happening. Here's an example:
I would argue that 6502-specific code should be tucked away in a set of sources reserved for just 6502 code, and 65816-specific code should be tucked away in a similar set of sources. Then, in the main source files, I'd
.include
them when and where appropriate. This already seems to happen in a couple of places, but it seems to only apply to major components and not to smaller functionality.Then, for the 65816 chunks of code, I'd rewrite them just for the 65816, without fear or concern regarding the 6502.
The text was updated successfully, but these errors were encountered: