Jump to content

G David T

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by G David T

  1. Good point. If I were writing 65816 code, I'd keep that in mind, but I'm just working specifically on x16 code, so the 'direct page' issue isn't really relevant. The main reason I'm using ABS,Y on the zero page is I'm performing a direct transfer to the zero page from indirect addresses. My code therefore operates as thus: LDY #$00 *LDA (src),Y STA dest,Y INY CPY #limit BCC - It is being used specifically for screen blanked video tile loading or file access, so speed isn't quite as important as code density (besides which, adding an LDX #$00 before the loop and an INX inside the loop would take longer, even replacing STA dest,Y with STA dest,X).
  2. I haven't tried BBR or BBS because I'm not trying to modify bits, I'm just trying to branch on flag states. After some further research, if I'm inserting an instruction, Bxx instructions assemble fine, but if I'm editing an existing line, the bug I'm reporting always occurs. Oddly, something appears to have happened to the ROM file, despite my not touching it, and CodeX now locks the emulator completely if I attempt to jump to access an address directly. Don't know what happened, but I'm not sure it is a problem with CodeX directly, just something that may be wrong with the emulator. Whatever the case, Monitor is not causing problems and is working fine.
  3. I've been doing some experimentation on CodeX16 without any documentation and I've noticed a few frustrating bugs. First, I can't get ABS,Y to assemble for the zero page, so, for example, LDA $0024,Y won't assemble, instead giving me a syntax error. If I put a zero page reference through ABS,Y in through the monitor, I can get it to disassemble in CodeX16, but I can't edit it to use a different zero page address, forcing me to go back to the monitor to make such changes. Second, relative addressing is badly flawed, requiring that the offset be on the same page as the next instruction, but also requiring that I add 2 to the target address to get the correct address. This further complicates the effort required to get the correct address. Disassembly again shows everything correctly, both target offset and offset value, but the assembly is much more complicated than it needs to be. For example, if I'm at address $0BA7, for example, and I need to branch on equal to $0C04, I must type BEQ $0B06 to get BEQ $0C04 in the disassembly. If I'm at address $0C07 and need to get to address $0BF4 with a branch with carry clear, I must type BCC $0CF6 to get BCC $0BF4 in my actual code. And if I am at address $0B70 and need to branch positive to $0B90, I must type BPL $0B92 to get BPL $0B90 in my code. Hope both of these issues are addressed soon. CodeX is an interesting environment and I'd like to see it improve, but I don't believe it's ready for mainstream use yet.
  4. I'm looking forward to the documentation. I'd love to see what CodeX16 is capable of.
  5. 2bpp Character Fonts View File MAKE4COLORFONT reads whatever data is currently stored from $0F800 to $0FFFF of Video Memory and converts it into two different 2bpp fonts. One is a two tone font that will be legible in 2bpp mode, with color 3 used as the main font color while the other is a four tone font reminiscent of multi-color text mode on the Commodore 64. This has been coded in BASIC, primarily because I cannot figure out how the save command works in the monitor, and don't think I have the patience to code such a thing from there. The remaining files contained herein are fonts created by running this program with the default fonts, the two U files being the upper case font and the two L files being the lower case fonts. The remainder of the names of these files specify which font is contained within the file. Submitter G David T Submitted 11/09/21 Category Graphics Apps  
  6. Version 1.0.0

    25 downloads

    MAKE4COLORFONT reads whatever data is currently stored from $0F800 to $0FFFF of Video Memory and converts it into two different 2bpp fonts. One is a two tone font that will be legible in 2bpp mode, with color 3 used as the main font color while the other is a four tone font reminiscent of multi-color text mode on the Commodore 64. This has been coded in BASIC, primarily because I cannot figure out how the save command works in the monitor, and don't think I have the patience to code such a thing from there. The remaining files contained herein are fonts created by running this program with the default fonts, the two U files being the upper case font and the two L files being the lower case fonts. The remainder of the names of these files specify which font is contained within the file.
×
×
  • Create New...

Important Information

Please review our Terms of Use