StephenHorn's post in "Try it now" web emulator limitations was marked as the answer
I'm not sure what the answers are to some of those questions.
If you rename the application to have a .prg extension, it might work to upload that. If not, then in addition to renaming the .prg, you'll need to pack it into a zipfile.
I would suggest using .prg instead of .seq for your program. I don't know if the extension will make a difference eventually, but I don't think it makes a difference in r37. My understanding, though, is that there is some subtle difference between how C64s treated .prg files and .seq files, and cc65 normally outputs .prg files. (There are ways to override cc65's behavior, but I assume you're not doing that.)
StephenHorn's post in Newbie file access and I/o struggles was marked as the answer
At present, the official emulator can only directly load and save BASIC programs in their tokenized form. If you want to export a BASIC program to a text file, you'll need to launch the official emulator with the "-echo" command line option, load your program, and then "LIST" it. From there, you should be able to copy the text from the console window.
If you have a BASIC program in text form that you want to "load" into the official emulator, you can use the "-bas <filename>" command line option to have the emulator automatically open the file and "type it in for you". You can also copy from the text editor and Ctrl-V to "paste" it, which works in a similar fashion under the hood.
StephenHorn's post in Emulator Debugger halting biased? was marked as the answer
The debugger would preferentially halt at particular addresses because of the timing of keyboard polling in the emulator. This happens once per frame, in response to the VERA module deciding to fire its VSync interrupt. This is a mostly arbitrary choice: it's convenient to do this here, as opposed to slowing down the primary CPU/execution loop when the vast, overwhelming majority of checks for keyboard input are going to come back empty anyways. The kernal's interrupt handler, which is what you're seeing, also kicks off in response to the VERA module's VSync interrupt.
Since the keyboard polling happens at a regular interval relative to that kernal interrupt handler, pausing execution through the keyboard at any given time is going to cause the debugger to stop at roughly the same execution addresses each time. $038B would likely be part of the kernal's trampoline logic for bank swaps, $E023 is deep in ROM.
I don't happen to know anything about your project, but if you're compiling with cc65, I would definitely recommend specifying `-Ln symbols.sym` in your linker options. This will produce a file name "symbols.sym", which contains a plaintext listing of all the symbols in your project, along with the hexademical address they occur at. With this, you can find a symbol and then set a debug breakpoint at it, so you can stop the debugger exactly where you suspect something is going wrong.
For instance, I have an ASM function named "generate_sin_curve", so in my symbols.sym file, I can find the following line:
al 003267 .generate_sin_curve
From this line, I know I can run the debugger, load my program, then hit F12 and type in "d 3267" and press enter to send the debugger directly to the start of that function. I can press F9 to set a debug breakpoint, then F5 to resume running the emulator. I can then run my program, and the debugger will pause execution immediately before running the instruction at that address.
StephenHorn's post in Quick Question: 65C02 Assembly was marked as the answer
Personally, I don't understand why folks decorate implied ops with A, given the design of the processor it's assumed that the instruction acts on the accumulator unless otherwise specified. I feel like it speaks to a misunderstanding about the processor's X and Y registers, which are not general-purpose. They are indexing registers. This is why the instructions dealing with them are special-case: INX and INY, DEX and DEY, for instance, compared with INC and DEC which have multiple addressing modes. The special-case instructions are not "shorthand" to turn a 2-byte instruction into a 1-byte instruction, nor are they simply differentiated as some 2 bits of addressing mode on top of a 6-bit opcode.
Now, if the 6502 had multiple general-purpose registers, such that it was meaningful which one you intended to act upon, that would be a different matter. Maybe that's where the decorated implied op folks are coming from: They're used to architectures with multiple general-purpose registers, so it would be valid to see something like LSR A, LSR B, LSR C, etc. And then, it's just more comfortable for them to see LSR A or INC A, even though the 'A' serves no functional purpose.
StephenHorn's post in cl65 to No Particular Address was marked as the answer
Many, many 65C02 instructions use absolute addressing. You would have to code your entire program to use relative addresses, ZP addresses, and ZP indirection, and you would still likely have, at the very least, regions of memory that were forbidden because the program needed them for variables.
The alternative, as Matt suggests, would be an OS to handle this for you, implementing some kind of virtual page table. I'm not actually sure how that would work without also having a hardware memory controller to aid with the mapping, which the X16 will not have and is not being considered, because c'mon, it's a 64K address space with bank switching on an 8KB window. It'd be like bolting the automatic transmission from a Nissan Sentra onto your 1HP push lawn mower. I'm sure someone is working on that Youtube video, but it's a bit much for the base X16. 😛
StephenHorn's post in Outside objects coming into view was marked as the answer
The trick is that even though the X and Y values are technically "unsigned" (i.e. non-negative), you can still get the effect of negative numbers by going ahead and subtracting from 0. The value will "underflow", but you can write the bits to the VERA anyways and it will treat it like a negative number.
Another way to look at it is that you've moved the sprite so far off the right side of the screen, that the VERA eventually wraps part of the sprite around to the left edge.
StephenHorn's post in Black area at bottom of emulator was marked as the answer
No, that seems correct. Same thing happens to me when I do SCREEN $80.
I can't speak for everyone, but my demos do not run in 320x200@256C. My demos leave the VERA at 640x480 scale, and takes advantage of the VERA's multiple layers and sprites at that "resolution".
@SlithyMatt's Chase Vault's title screen scales the screen to 320x240 resolution, and configures VERA layer 0 to be a 320-wide 4bpp bitmap. Gameplay leaves the global scaling and layer 0 configured like this, and configures layer 1 to a 128x128 tilemap using 16x16x4bpp tiles.
StephenHorn's post in Hello world asm question was marked as the answer
You can't just substitute CHROUT for console_put_char.
Per the documentation, under "Console":
With this documentation in mind, consider the following modifications:
; screen_set_mode lda #$80 jsr $FF5F ; SET 320x200@256C MODE ; console_init ; All zeroes in r0 through r3 result in a full-screen console ;r0 stz $02 stz $03 ;r1 stz $04 stz $05 ;r2 stz $06 stz $07 ;r3 stz $08 stz $09 jsr $FEDB ; rest of the code ldx #0 again: lda hello, x cmp #0 beq done stx SaveX sec ; Adding carry to wrap at word boundaries jsr $FEDE ; console_put_char ;jsr $FFD2 ; CHROUT ldx SaveX inx jmp again done: rts SaveX: .byte 0 hello: .byte "hello world! ", $00