Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Community Answers

  1. ZeroByte's post in cc65 wait_vsync breaking between r40 and r41 was marked as the answer   
    Here's what you do:
    in C files that need waitvsync() - make this declaration:
    extern void __fastcall__ vsync();
    Then include this as an assembly source: (e.g. vsync.asm)
    RDTIM := $FFDE

    .export _vsync
    .proc _vsync: near
      jsr RDTIM
      sta lastjiffy
      jsr RDTIM
      cmp #$FF
      beq keep_waiting
  2. ZeroByte's post in YM2151 easy note conversion? was marked as the answer   
    This is the fastest routine I can quickly think of:
    LDA semitone ; not counting this as this has to happen no matter what alg is used
    CMP #9 ; 2 cycles
    BCS @add3  ; 2 | 3 cycles
    CMP #6 ; 2
    BCS @add2 ; 2 | 3
    CMP #3 ; 2
    BCS @add1 ; 2 | 3
    BRA @add0 ; 3
    INC ; 2
    INC ; 2
    INC ; 2
    ORA octave ; 4 ; assume octave is stored pre-shifted into 4 msb
    STA keycode ; same as LDA semitone
    So the number of cycles is: 2 + (9|11|13|13) + 4 --> average of 17.5 cycles - so let's call it 18 cycles.
    a lookup would be something more like:
    LDX semitone
    LDA kc_lut,X ; 4+
    ORA octave ; 4
    STA keycode
    So twice as fast, requiring 12 bytes of RAM.

    Given that this operation doesn't happen super-often (pretty much only up to 8 times per frame?) I'd call this "pitayta-pitatta" / "six in one hand, half a dozen in the other" / pick your idiom. In the end, 12 bytes of RAM ain't much to sacrifice, plus the code's a lot easier to read, too.
  3. ZeroByte's post in Understanding graphics rendering was marked as the answer   
    I'm not sure about the internal workings of VERA, but in general, all a VGA display needs to do is have a range of memory that it can dip into for pixel color data and then dump it to the screen at the correct timing. Ben Eater did this with some basic address decoding being done by a gaggle of binary counter ICs.
    I saw in the beneater subreddit where a guy actually made a clone of the NES PPU on breadboards! 🤯
    If you want some insight as to how a chip like the PPU does its job, go watch OneLoneCoder's series on writing his own NES emulator from scratch. He covers how pixel buffers work in gory detail. Granted, it's from a software perspective, but the procedure is what counts here, right?
    If you want to show a bitmap, you're going to need sufficient RAM to hold it. If you want indexed pixel data (e.g. 8bpp, 4bpp, whatever) then the colors those values reference can either be done by hard-wiring your palette (like Ben Eater did using a resistor ladder) or else having a block of palette data that the chip uses to convert the indexes into RGB values (which then get written to the display using a hardwired circuit like Ben Eater's resistor ladder).
    If you do tiles / sprites, your chip will need to cycle through the various objects that may be on the pixel row, and write them into the pixel buffer. The pixel buffer would be the data getting written to the screen by the dot clock.
  4. ZeroByte's post in pre-R39 cc65 question was marked as the answer   
    It's broken for two reasons:
    The RAM banking method changed (my version of cc65 still uses the VIA banking method) The address in BANK 0 for the jiffy timer changed to 0xa043 waitvsync() just waits for that value to change, as the kernal inc's it during each vblank IRQ from VERA.
    Here's a myvsync() routine to fix it until such time as cc65 is updated:
    #define time (*(uint8_t *) 0xa043)
    #define rambank (*(uint8_t *) 0x0000)
    static void myvsync()
        uint8_t b,j; // bank, jiffy
        b = rambank;
        rambank = 0;
        j = time;
        while (time==j) {};
  • Create New...

Important Information

Please review our Terms of Use