Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by StinkerB06

  1. AMAZING JOB!!!!!! This likely wouldn't be reliable for use in an actual game though, considering how CPU-intensive synthesizing PCM audio on the fly is.

    If you want to reduce the CPU usage though, have you thought about using some of the additional 65C02 instructions? All of them are said to be compatible with R38.

    • Thanks 1
  2. 31 minutes ago, Gernreich said:

    Cheers again!  I'll need to look at this for a bit.  Is this the minimum code for me to reset and play a new frequency? (no other change is made).  How about rewind by four, increment, increment, rewind by two, increment, increment, rewind by two..........

    I have another version that does a dummy read:


    LDY $9F22 ; Save ADDRx_H and auto-indexing factor

    LDA $9F25 ; Retrieve CTRL register

    AND #$01 ; Mask all but the ADDRSEL bit

    TAX ; Put in X index register

    LDA #$38

    STA $9F22 ; Decrement=4

    LDA $9F23,X ; Do the dummy read and decrement (Can you give a clue why I used an index register?)

    STY $9F22 ; Restore ADDRx_H and auto-indexing factor


    This one probably is less efficient, but it only takes 1 label instead of 2.

  3. 23 minutes ago, Gernreich said:

    Cheers StinkerB06 !!!  Do I need to reset to play another note?

    Yep! After the code is executed, ADDR0 points to $1F9C4, which is the start of the 2nd channel. So you'll need to manually rewind it by 4:


    LDA $9F20 ; Retrieve ADDRx_L

    BEQ rewindChannel16 ; Skip this if zero


    SBC #4 ; Subtract 4

    STA $9F20 ; We're done



    DEC $9F21 ; If past 16th channel, decrement ADDRx_M

    LDA #$FC

    STA $9F20 ; ADDRx=$1F9FC


  4. 1 hour ago, Gernreich said:


    LDA #$00
    STA $9F25
    LDA #$01
    STA $9F22
    LDA #$F9
    STA $9F21
    LDA #$C2
    STA $9F20
    LDA #$FF
    STA $9F23
    LDA #$C3
    STA $9F20
    LDA #$3F
    STA $9F23
    LDA #$C0
    STA $9F20
    LDA #$4A
    STA $9F23
    LDA #$C1
    STA $9F20
    LDA #$04
    STA $9F23


    Why are you re-setting $9F20 every byte written? You could just use the VERA's auto-increment feature.

    Here, this code should work better:

    STZ $9F25 ; ADDRSEL=0, DCSEL=0

    LDA #$C0

    STA $9F20 ; ADDR0=$xxxC0

    LDA #$F9

    STA $9F21 ; ADDR0=$xF9C0

    LDA #$11

    STA $9F22 ; ADDR0=$1F9C0, Increment=1

    LDA #$4A

    STA $9F23 ; Frequency=$xx4A

    LDA #$04

    STA $9F23 ; Frequency=$044A

    LDA #$FF

    STA $9F23 ; Volume=63, Left=1, Right=1

    LDA #$3F

    STA $9F23 ; Duty=50%, Waveform=Square

    • Like 1
  5. 4 hours ago, StephenHorn said:

    A straight translation into 6502 assembly would be:

    lda #$00
    sta $9F25 ; Set ADDSEL to 0
    lda #$C1
    sta $9F20 ; Set ADDR0_L to $C1
    lda #$F9
    sta $9F21 ; Set ADDR0_M to $F9
    lda #$01
    sta $9F22 ; Set ADDR0_H to $01
    lda #$04
    sta $9F23 ; Write $04 to VRAM addr $1F9C1

    Also, don't forget the "LDA #0 / STA addr" combo can be replaced with "STZ addr" on the 65C02.

    • Like 1
  6. 54 minutes ago, dr.diesel said:

    I fail to see why the topic was even mentioned and has nothing to do with the X16 or it's future.

    Ok then.

    At first, people thought he was a good-enough retro tech-content creator with over a million subscribers. But when his video of his IBM "restoration attempt" came about, people have started to become angry. Even when I don't have any experience with electronics, I pointed out that he was doing many things wrong.

    He didn't test the monitor power lines correctly, so he went ahead and bent a paperclip, shoved it into the PSU's male connector, turned it on and SNAP! Blown fuse! Next, he used a Dremel saw and some other tool to pull out the 4 security screws, only to find the fuse. He then bought the wrong type from the hardware store, putting it in the PSU caused the machine to not turn on. After this, he refused to do additional work and sent the rare IBM back.

    PS: I don't know if this discussion should stay here or go to off-topic. But this thing he did is really dumb in my opinion, and is a good starting point for hardware technicians to know what not to do.

  7. Are any of you aware of the controversy he caused from destroying that one extremely-rare IBM prototype? By bending the paper clip to short out the whole system and cutting open the PSU with the saw?

    Although this should probably be on-topic: Is the controversy declining interests in the X16, or would it still do well?

  8. On 9/19/2020 at 12:50 PM, Elektron72 said:

    According to the current documentation, the VERA does contain a PCM playback system.

    Except it's buffered. There would be a pause in the audio at AFLOW intervals, as the CPU spends its time computing the new samples to be written to the buffer. There's no DAC mode for that matter.

  9. 8 hours ago, Fnord42 said:

    Let me clarify: I don't think that the X16's audio capabilities are disappointing. I was personally a bit disappointed because I had hoped that it could also do MOD files. MOD files have very high retro nostalgia value for me, but that was maybe just a bit much to hope for. Additionally it's probably also a matter of personal preference, because I just don't like the sound of the YM2151 very much.
    That being said, the current audio capabilities are of course not bad at all - Amiga-like sound capabilities just would have been the icing on the cake for me, so to speak.

    To me, the YM2151 FM chip in the CX16 feels very Genesis-like (since that system has a very-similar chip). It was the FM chip found in a lot of 16-bit arcade games, and was also part of the SHARP X68000 Japanese computer.

    The addition of the VERA PSG (which is more SID-like) and the SAA1099 (which was a pretty advanced AY/SN7 sibling for its time) pushes the X16 beyond the level of what I think is "8-bit" music. It would sound more like 16-bit (or even 32-bit?) arcade games, as the channel count currently surpasses even the PS1's SPU.

    The 8 MHz 65C02S probably won't be able to catch up with playback, so the music engine would have to be heavily cut in features for it to work within a game or demo. Or just follow a simple convention: Don't use all channels at once.

  10. Each of the 4 bits represent 4 groups of sprites that collisions would be checked for. For example, if 2 or more sprites with bit 0 set are "touching" each other on a given pixel, then the VERA knows there's a collision in group 0, thereby setting the corresponding bit in the ISR register upon V-Blank. The flags must be cleared after they're checked, so collisions that just happened won't "spill" into the next frame.

    PS: Using the hardware collisions is known to cause different behavior/side effects, depending on the video output mode, start/stop/scaling, and (as I'm pretty sure) the sprite "work units" that are being spent on each line. It's considered best to use software collision detection (though it may not be pixel-perfect, considering that's a CPU-intensive operation).

  11. 34 minutes ago, SlithyMatt said:

    In all of my projects, I am running in either 640x480 or (the vast majority of cases) 320x240. So, I always want DCSEL to be zero as well, so I can save a few cycles. Something to consider if you want to have a non-standard display.

    Tbh, the dual-port techniques really conflict with being able to use the VERA PSG in your music/SFX engine. In my case, when wanting to write to the PSG, I'd save the values of the CTRL register and the Port 0 address/stride to 4 locations in RAM, so I can restore them back when the PSG writes are done.

  12. From Wikipedia:

    INC and DEC with no parameters now increment or decrement the accumulator. This was an odd oversight in the original instruction set, which only included INX/DEX,INY/DEY and INC addr/DEC addr. Some assemblers use the alternate forms INA/DEA or INC A/DEC A.

  • Create New...

Important Information

Please review our Terms of Use