Jump to content

StephenHorn

Members
  • Content Count

    88
  • Joined

  • Last visited

  • Days Won

    4

StephenHorn last won the day on July 5

StephenHorn had the most liked content!

Community Reputation

65 Excellent

2 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. What kind of magic syntax nonsense is that? Is this something specific to CBM prg studio, that it'll translate from ASCII to the appropriate screen codes? Or is/was this a standard convention for C64-type software?
  2. Shrug. At this point, I'd be spending a lot of time with the built-in debugger, trying to suss out the exact layer settings I'm working with when things go awry. Is it possible that someone has switched out the character sets between the ASM function being called via SYS and the BASIC version of the same?
  3. Huh. What happens when you change this: lda #$00 sta vera_choose_port ; choose vera port 0 To this: lda #$01 sta vera_choose_port ; choose vera port 1 ?
  4. If the problem seems to be a bug in your assembly code, then seeing the assembly code would help immensely. Do you have a Github account, or similar? Is the code available somewhere for other eyeballs to have a look-see?
  5. I had originally planned to leave this topic alone if there wasn't much interest, but now I want to plug just one more video from this channel, because the exact parallax technique Sega used in Sonic the Hedgehog is something that I've discussed a couple of times in the Facebook group, as a viable technique on the VERA. And, in fact, this video shows just how similar the VERA's capabilities are to the Genesis' video processing, right down to the limitation on how many sprites can be drawn on a single line. (However, line IRQs are broken in r37, but the github repo has the fix so you can either grab and compile from there, or wait until r38.)
  6. The debugger doesn't currently allow you to fill values in memory... that said, I happen to be in the middle of some changes to the debugger based on a separate suggestion to make it possible to dump VRAM, so I think I'll go ahead and add a "fill" command while I'm at it. So hopefully it'd make it into r38, which shouldn't be too far off on the horizon.
  7. There are a couple of people working in C. In particular, folks have been getting X16-specific updates pushed to cc65, a C-compiler and linker that specifically targets 8-bit platforms based on the 6502. cc65 is being used by a few folks for straight-up 6502 assembly programming, since it includes a fully-featured segmented assembler as well. I believe someone is working on a version of Turbo Rascal for the X16, but I can't recall who that is. They've been on the Facebook group somewhere with a tech demo. And then there's @SlithyMatt, who benefits from a seemingly endless well of energy, passion, and time, and has not only already completed a game for the X16, but is working on a high-level game and scripting engine called XCI (eXtremely Compact Interpreter). And is contributing to a JRPG being developed for the X16. o_O I'm not sure what his secret is. I just hope its more along the lines of being excellent and not mysterious transparent pills. I don't know of any assemblers or compilers that run directly on the X16 yet.
  8. Not at present, I'm afraid. The debugger's sections are as follows: Disassembly view of memory. CPU status, Banks, program counter, stack pointer, current breakpoint, VERA Address ($9f20-$9f22), Data0 ($9f23), Data1 ($9f24), and Control ($9f25) registers. Stack memory System memory view Debugger command line It probably wouldn't be too bad to add a VRAM display, and maybe I'll get around to it at some point if nobody beats me to it. The emulator's source code is available, and its maintainer is accepting pull requests again.
  9. Are you still accepting pull requests for r37? I can't help but notice that I have a relatively simple one that's been waiting for months...
  10. For various reasons, I've never bothered to swap the character set through assembly. But if you PRINT CHR$($0E) as a statement in BASIC before running your program, you can get the kernal to swap in the shifted PETSCII font that has both upper- and lower-case letters. (Doing this work in assembly could be much more involved-- if the character sets are not always kept in VRAM, then you'd need to copy them over, and I don't know where the kernal keeps the font data.) Edit: And swapping back to uppercase-only is PRINT CHR$($8E).
  11. If my guess is correct and BASIC is scanning memory for the start of a BASIC program, then you'll have to add the auto-launching BASIC header to your program as well, John. See my link: https://github.com/commanderx16/x16-emulator/wiki/(ASM-Programming)-Creating-"auto-launching"-programs. You'd add that header immediately after the $01 $08 file header.
  12. I can appreciate that cc65 may seem a bit arcane if you're not used to command line programming workflows, and especially so if you downloaded its source code and first need to compile that. Myself, I found it convenient to download their Windows snapshot on https://cc65.github.io/. The Windows snapshot comes already built into executables. They can be found in the /bin/ folder of wherever you extract the snapshot zip file. The main one we care about is cl65.exe. It's smart enough on its own to interpret a text file full of assembly instructions, and it's the program that spits out the final .prg. You can tell it to assemble a bunch of code into a .prg file by calling: cl65.exe -o print.prg -DC64 --cpu 65C02 print.asm If you open this in a hex editor, you'll probably see the expected $01 $08, but then the stuff immediately after that is probably going to be a mystery. This is because cc65 creates "auto-launching" programs. I've previously explained how that gobbledy-gook works elsewhere, it turns out! https://github.com/commanderx16/x16-emulator/wiki/(ASM-Programming)-Creating-"auto-launching"-programs The benefit of "auto-launching" programs is that you don't need to use SYS to call them. You can just use RUN, like you were starting a BASIC program, and the X16 will do the rest. If you checked out my link to the X16 github wiki (or just do LIST right after your LOAD), you'll see it's because the file is beginning with a 1-line BASIC program that does the SYS command on your behalf. Very slick technique, in my opinion. But if you're looking to write bespoke assembly functions to call from BASIC programs, pretty useless to you. Oh, you're just saying that because CBM PRG studio didn't add the additional header for making an "auto-launching" program, the way cc65 would. From the screenshot John provided of the hex dump of his file, it looks good to me. Proper file header for loading at $0801, the jmp instruction appears to point to the proper memory address, the lda for the string also appears to be referring to the proper location. Then again, though, maybe you have a point. I made a clone of John's file, based on the screenshot he provided from his hex editor and tried loading it myself. BASIC is clobbering the first two bytes of memory to $08 $08 for some reason, deleting the lda $10 at the start of the program. I don't know why it's doing this. At a guess, I'm thinking it's scanning through memory to find what appears to be the first valid line of "BASIC" code, and then clobbering $0801 to point at that memory address. $0808 does suspiciously appear to be the first location in memory that would map to a BASIC token. Edit: I should add, I tried renaming the file from a .prg to a .seq, in the hopes of avoiding this behavior, but no dice. BASIC still clobbered the first two bytes starting at $0801. This probably means $0801 is special, not just in the sense that it's the start of where BASIC stores programs, but also in the sense that BASIC enforces specific requirements on the contents of memory starting at $0801.
  13. I can think of no reason the gunpowder treason... could possibly have worked after sending a letter to a member of Parliament, Catholic or no, and seriously what's with that alias? "John Johnson"? I mean, there have been some pretty comical attempts at regicide and revolution throughout history, and this is easily one of the best of those worst. (Though my favorite is probably the unknown number of attempts to poison the Pontic King Mithridates VI, which ultimately ended with Mithridates even attempting to poison himself... and still failing.)
  14. Well, this is probably pretty easy. You're dropping a string right into the middle of your code, and I'll bet CBM PRG studio isn't politely shuffling that to the end of your program like a segmented assembler would. I don't actually know anything about CBM PRG studio, and there didn't appear to be any online documentation, but the author seems insistent that his program is not an assembler, so I'm guessing it doesn't have the smarts to work that out, by design. ¯\_(ツ)_/¯ Try moving that string to some point after the rts instruction at the end there. If that's not it, then I agree with @SlithyMatt that the most suspect thing is that *=$2C00, which is setting the instruction pointer to $2C00 and will, under most assemblers, cause it to begin emitting instructions and addresses as if the following portion of the file began at that address. There are a bunch of things to check to follow this rabbit hole. Firstly, open your .prg file in a hex editor of some sort (I frequently go to https://hexed.it online for these purposes) and check that the first two bytes are $00 and $2C, in that order (this is $2C00 in little-endian order, which is what the X16 expects). If you're loading the file either through the -prg command-line option or with LOAD"FILENAME.PRG",8,1, then these bytes need to be correct or else the program is being loaded somewhere else, meaning you'll need to change your *=$2C00 to match wherever CBM PRG studio is indicating the file should be loaded. Worst case, if you open the file and discover the starting bytes are your assembly instructions (A9 10 8D 22 9F A9 00 8D 20 9F 8D 21 9F...), then CBM PRG studio is not placing ANY header at all and you'll want to manually add one with a byte statement, probably byte $00, $2C or byte $00 $2C, depending on the specifics of its syntax. If you're loading with LOAD"FILENAME.PRG",8,0 or LOAD"FILENAME.PRG", instead, the file will always be loaded into $0801 with a LOAD command. (That is, unless you're trying to poke memory to clobber this behavior, but to my knowledge that technique is completely undocumented on the X16 and probably subject to change with future revisions to the kernal, so I wouldn't personally try that). The next thing to do would be to run the debugger with the -debug command-line option, in addition to whatever other command-line options you're currently using. Load the file, and then press F12. This should pause the emulator and bring up a panel like this: From here, type d2c00 and press enter. This is similar to how the monitor worked on the C64, 'd' is a prefix meaning you want to change the address inspected by the disassembly view in the top-left of the debugging panel. At this point, the disassembly view should be showing your assembly instructions, at $2C00. If you don't see your assembly there, the code got loaded somewhere else, and we need to go back to the beginning and figure out why it didn't get loaded where you think it did. But if your code is there, you can now press F9 to set a breakpoint at $2C00. Debugger panel breakpoints will pause the entire emulator at the point of execution. I love them. So at this point, press F5 to close the debugger panel and resume emulation. Try doing that SYS$2C00 call, and the emulator should automatically pop open the debug panel again, this time paused immediately before executing the instruction at $2C00. From here, you can inspect the state of the machine and step through your code, instruction by instruction, with F11 (step-into). Alternatively, you can step with F10 (step-over), the difference is that F10 will run a jsr and all the code that executes after it, until immediately after the matching rts instruction is executed. If you need to inspect memory instead of disassembled code, you can use the prefix 'm' instead of 'd', to change the region of memory shown in the lower 2/3rds of the debug panel. And if you've gotten all the way to the end here, then yeah, I wrote basically all of this before seeing that string being dropped right in the middle of your assembly code. Rather than discard it all, I guess I'll just own up to my own failed spot check and hope the rest of this ends up being useful for someone at some point.
  15. Oh, by the by: This is not true. Well, okay, this is partially true. True if and only if you are using 1bpp tile modes (a.k.a. "text" modes). Other tiled modes (2, 4, and 8bpp) support up to 1024 tiles. See also: https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md#tile-mode-248-bpp
×
×
  • Create New...

Important Information

Please review our Terms of Use