Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many comments can be very confusing. #6

Open
sam-falvo opened this issue May 9, 2017 · 0 comments
Open

Too many comments can be very confusing. #6

sam-falvo opened this issue May 9, 2017 · 0 comments

Comments

@sam-falvo
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant