Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by rje

  1. On 1/6/2022 at 1:46 PM, TomXP411 said:

    Fair enough. With the fact that we have at least another year to wait for hardware (thanks, COVID), there's not much else to talk about. 😃

    LOL, well that's absolutely true.  People gravitate towards what they like to do, and there's a wide spectrum of stuff here.


  2. On 1/6/2022 at 11:29 AM, Stefan said:

    My guess is that the community is not interested in the keyboard solution per se. We just want it to become functional so that we can get on with what really interests us, eventually owning and using a X16.

    Yes, no doubt about that.  And the group has enough energy to talk about technical details.


    • Like 1
  3. I've only ever worked with the SID, which had good Usability.  I can tell it was usable because I was able to use it... and I don't know anything about anything except programming.

    What I found useful about it was (1) ADSR envelopes, (2) multiple voices, and (3) multiple waveforms, including noise of course.

    So anything that gets me those three features in reasonable registers is fine by me.


    If the PSG had envelopes I'd be content and productive.

    Frankly, it could be any chip(s) under the hood, as long as I could use it in a manner similar to the SID.

    It looks like the POKEY didn't have ADSR envelopes, so I can't vote for that.

    • Like 1
  4. I don't mean to sound like Paul Scott Robson, so I'll try to dance around the issue a bit.


    At work, we periodically have to assess whether what we're doing is worth the effort we're putting into it.
    I understand that sometimes, business is driving the work, and there's nothing we can do about it.
    But it never hurts to let business know the issues and how much trouble they will cause.


    I hear that USB is more expensive than PS/2, which is cheap.  But... I'm starting to wonder if PS/2 is not really cheap, but rather pushes time and expense and complexity back to the board.

    Do we really want home-brew complexity to drive a modern keyboard -- a solved problem?  


    I would much rather that your efforts went into the KERNAL and toys for the banked ROM.


    "I have this awesome retro machine, but 50% of the build time and effort goes into the keyboard interface, which has nothing to do with the retro nature of the machine."



    And what's the QA effort around debugging keyboard routines?  


    Or is this the kind of fun everyone signed up for?


  5. Okay I will start with a SET.  It looks like R1 is safe for this, so I can do SET R1, and let's see, let's give it the value $1541.

    I'll use your binary, which loads to $4000, and I'll make sure to load in the data before I load the binary too.

    And I'll put the "program" in $0700.

    I think that would look something like this:

    $0700: $11    ; SET R1
    $0701: $41
    $0702: $15
    $0703: $00    ; RTN
    $0704: $02    ; 6502 BRK

    Then I poke $00 $07 into R15:

    $0020: $00
    $0021: $07

    Then sys $4000.
    Then peek $02 and $03 and hope that $41 and $15 are there?




    Screen Shot 2022-01-04 at 12.42.01 PM.png

    • Like 1
  6. My attempt to modify your source for cc65.

    Yes, I know I should FORK your repo and push an update to it and do a merge request... blah blah blah.   My brain is reeling from even considering trying this out in the first place.  Excuses excuses.

    I've probably broken it too.  I'll load it and try to poke at it (no pun intended) with the debugger and see what I can try to do.






  7. Just yesterday, I watched 8 Bit Show-And-Tell's video on the "Atari 64".

    It's a demo of tweaked KERNAL + BASIC ROM images that were adjusted to load into and run on the Atari 800XL and 1200XL.  The ROM images essentially turned this Atari 800XL into a new type of Commodore 8-bit machine. 

    The hardware is all Atari, so it's NOT a Commodore 64.  

    There's no I/O, so you can't load or save.  You can use the keyboard and the non-color screen RAM works, as well as the Atari-style sprites (which are strange to me).  Atari's graphics registers are of course different.


    But then, I understand that that's what just about all Commodore machines are like: every model has different hardware, so the compatibility layer is KERNAL + BASIC.  Everything else is completely up for grabs.


    So in my mind this is not much different than having Yet Another Commodore 8 Bit Machine.





    • Like 5
  8. I have a two-parter question.

    1. How might I dump a screen of PETSCII to a binary file?

    I print splash screens and similar, storing the content char arrays in C, or sometimes programmatically printing it out.  I’d like to store that data in a binary.  I’m not sure how to do that from the X16.


    2. Then of course I want to write a short asm that prints that to the screen.  The only way I think of this is by using FFD2, but maybe there are better ways?  Also note problems with my code here!


    lda clear-screen-code

    jsr $ffd2

    ldx #0


    lda $8000,x

    cmp $ff  or whatever makes sense here

    beq done

    jsr $ffd2 

    inx    Uh oh that won’t work because x is only 8 bits.... can I increment A indirectly?

    jmp printloop.  But I know there’s a better way to do that.




  9. My really cheap proof of concept ADSR code is here: https://github.com/bobbyjim/x16-c-tools/blob/main/PSG.c

    Note that the code that "runs the envelope" is not an interrupt.  So it's a POC, not a real usable thing really.


    Envelopes use:

    typedef struct {
      long phase; // along the ADSR envelope
      int attack :16;
      int decay :16;
      int sustain :16;
      int release :16;
      } Envelope;


    They're linear timeouts.  So, not as versatile as the C64's envelopes.  Still, 2^16 jiffies is... uh, I think it's 18 minutes.


    65536 jiffies x 1 second / 60 jiffies x 1 minute / 60 seconds = 65536/3600 = 18 min.

    • Like 2
  10. So back to Zero's talking about library files.   Looks like the rule is:

    1. If the very-common pattern is to USE all of the functions, then gang them together.
    2. If someone might just want to use ONE function, then split them apart.
    3. And make the common data its own library as well!

    This could make for a very leggy set of libraries!


  11. If it were a labor of love, and you had the means (skills and component access), the motive, and opportunity, then targeting one particular game makes sense.  FPGA and CPLD (etc) makes your job easier, again assuming you have the materials and the skill.

    In other words, you have to have a goal in mind that hasn't already been done.  "Because I haven't done it" can be a valid reason.... but it really does have to be your goal.


  12. Back to your original post, in particular:

    Would the pi1581 give a reasonable data transfer rate?  Assuming the x16 could do fast serial?

    If so, then it seems “easier”(?) to modify the pi1541 project to include a piIEC mass-storage option that uses the 1581 fast serial?  

    Makes me wonder what a nice base image size would be.  4 megabytes?  16?  Or am I off by three orders of magnitude?

  • Create New...

Important Information

Please review our Terms of Use