Jump to content

CursorKeys

Members
  • Posts

    86
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by CursorKeys

  1. On 11/24/2021 at 2:53 PM, Tatwi said:

    One important thing to note is that Notepad++ can't handle special character commands in strings for use with the PRINT statement, such as changing the color of the font, etc. Lower case letters will print their associated "shifted" PETSCII characters, but I don't think the Commodore key based characters can be done in Notepad++ (or any other ASCII/ISO based text editor). Perhaps someone else could tell us!

    Hi

    I am not 100% either, but I have a tip that can be done instead.

    use PRINT CHR$( <code> ) instead.

     

    Example:

    10 PRINT "HELLO"
    20 PRINT CHR$(147) 
    30 PRINT CHR$(18) ; "HELLO" ; CHR$(146)

    LINE 20 prints the code for clearing screen

    LINE 30 prints the code for Reverse ON and Reverse Off, to get inverted "Hello world"


    Petscii tables with control characters can be found online, like: https://sta.c64.org/cbm64pet.html

     

  2. Hi and welcome to the X16 community!

    It is funny and strange how preferences about keyboards can vary.  I always preferred the "shift-2" = double quote layout. 

    What to me is the most interesting things about commodore keyboards,
    was how the cursor keys layout was.  There are just 2 cursor keys, not 4 as we are used to nowadays (see my avatar :))

    Anyhow, nice to see new people having interest in the community!  

  3. Hi!

    I'm late to this thread, but below is my way of looking at it.

    I am going to put it straight.  Probably many disagree with me, but I am ok with that.
    To keep my enthusiasm for development for the platform, and to get me to spend money on the platform, below is more or less my list of thoughts / requirements to make that happen.
     

    Let's start with my view, and then I go into the questions.

    Quote

    What I really want is this.

    First: A breadbox like the C64, with PETSCII keyboard, but it says X16 on the top. What is in the breadbox is more or less irrelevant to me, as long as it boots up, and pretends it's the X16 that we now all know and love.  That would really make my day.  But since you can't have it all, below is some more nuance.

    Secondly: A cool development community like the X16 community is just now, where you can discuss development, and display your programs.

     

    Quote

    X8

    For me the X8, is a no go. 

    Unless,

    - You chuck away the X16 completely, and X8 takes over the show.

    - Or the X16 is really an compatible upgrade of the X8. Think C64/C128.  The X16 should at least have a "goX8" command, if both have to live in the same universe. Or at least they both should have the same way accessing the Vera.

    - Or there is at least 5 years time between the releases.

     

    Quote

    Keyboard

    About the keyboard, as it stands.   I don't mind at all how good or bad quality, ps2 or usb it is.  The only thing I REALLY want is the cool PETSCII characters on the keyboard, connected to my X8/16. If I can't have the breadboard form-factor, then the PETSCII keyboard is the next big selling point for me. 

     

    Quote

    KIT

    KIT or no KIT.  I am not buying a KIT, period.   I'd love to buy one and put it together, but I am way to clumsy, and I end up breaking the KIT.  If KIT is the only option, I'll be doing the rounds on eBay to see if someone wants to sell an assembled kit.

     

    Quote

    The insides and the outside

    I'd prefer a through hole circuit board of course, with all parts being discrete.  But since $$$ and also we already have a FPGA onboard, I more or less don't care what's inside.  Put in a raspberry pi, pre-configured to be an X16, and I am still a happy camper.  The thing that matters to me how it boots up like a X16 and how it looks like a X16.  So, does it look like a X16, or does it look like a generic box.  For example I LOVE the Myster, but the form factor is the worst I've seen in a long time. 

    I like my retro computers  not only to work great on the inside, but also look the part.  Since I rather have it in a display cabinet next to a C64, looking cool, during it's "off time" periods.

     

    Quote

    Approach

    Myself, I would perhaps take a different route.

    0. It sounds like the X8 has a better Vera architecture, change the X16 to copy that.

    1. Dump the X8, cool idea, but, nah.

    2. Phase 1, is the raspberry pi, bundled with a bare metal emulator of the X16 as it stands now, a generic box, but with PETSCII KB. (I would totally buy that)

    3. Phase 2, is a full FPGA version of the X16.

    4. Scrap the through hole. Great idea, but maybe only as a kit for the hardcore enthusiasts.  And my daughter can look at resisters, capacitors and transistors in my old C64, that's fine for me.

     

    Quote

    Conclusion

    In short, I really like this project.  And respect the people working so hard to make it happen.  So even if you ignore all my points, I probably stick around, and buy "one of whatever comes out of the oven" 🙂

    So please continue, and keep faith !!  

     

    But that being said, I will focus on one single platform, and buy one hardware, and ignore the other one. 

    Also, If prefer outside looks (with Keyboard) over inside looks, and a KIT won't do it for me.

     

    • Like 1
  4. 21 minutes ago, TomXP411 said:

    ....................I've written a specification for this. It's still out there in the forums (I believe I called it "Advanced PRG Format")...................


    Just for future reference, I think this is the one you meant 🙂
     

     

    • Like 1
  5. 4 minutes ago, TomXP411 said:

     

    "they" is "us." Mike, the person making the KERNAL changes already has a full pipeline. He can't do more than he already is, so it's up to us and other users like us to add new features like this. 

    I've written a specification for this. It's still out there in the forums (I believe I called it "Advanced PRG Format"), and it's still possible to implement. But right now, I'm a bit burned out on everything, and I just don't have the time and energy to put into Commander coding. 

    Cool, I did not know that.

    I have not been 100% aware of who does what on the Kernal.  But it makes sense, it is "us", not "they".

    But yes, I can understand the burnout feeling.  For me, I am just over it, so I am ready for a fresh dose of X16, this is why all the questions 🙂
    (I am right now trying to squeeze 60kb of data into a single prg file just now, with compression, so I am more or less just wishing, I could just read the whole thing in chunks into Vera and normal memory in one go....
    But no need to take my request seriously though, I can perfectly live without it, but I like the idea of extending things. (Hence my obsession with double Petscii) 🙂

    Anyway, I'll stop whining, and go back to my compression algorithm for now (Yes, I am a little obsessed of making 1 file programs, I am sure I'll get over it some time) 🙂
     

  6. 1 minute ago, SlithyMatt said:

    Well, then that would have to be something other than a PRG file. One could have a special loader program in memory that could open such a file and load its segments appropriately. But deployment of separate program and assets is just a much better way to deliver software, especially when you don't have the horsepower or RAM to load and decompress a large file. I think the common deployment strategy will be a zip file that you then decompress with a modern computer into an SD card directory, if you aren't buying a pre-loaded SD card (which I intend to produce for my games).

    Yep, that's what I was after. The "special" loader, would be a small adjustment to the Kernal.  And the file, in my mind, could still be a PRG file, just a new version of it. (but that could be discussed all night :))

    But indeed, the interesting thing is what is going to be the deployment strategy for the X16.  Buying a preloaded SD cards, sounds like a reasonable proposal to buy a game, but it would not really fill up a 4GB or larger SD card.

    And I probably would come to the conclusion that most games would just use only a few percent of the SD disk, so, I would want to collect several on a single SD disk, skipping the swap SD card step.   In that case, a single file may be a good way to manage assets. 

    But I agree, then compression comes in play.....  Well, maybe...  But not so much for saving space perhaps, since SD cards are huge compared to the memory size of the X16. Why compress? So the goal maybe would be speeding up load times, although that is maybe also not really a big bonus, since decompressing also takes time...

    Interesting, to compress or not.  On the c64 it was a no brainer.  The 1541 disks were super tiny compared to a modern SD card, and any type of content was filling up the disk quickly.  But now with SD technoglogy... 

  7. 7 minutes ago, SlithyMatt said:

    In a nutshell, there are two ways: make a big PRG file that can be loaded into contiguous RAM and then copied out to other parts, or just have multiple PRG and BIN files and one executive PRG that does all the loading so that the user only has to load the one file, while the others sit in the same directory.

    ok, like that.

    No this is not what I was talking about. I know that this can be done. What I am "dreaming" about, is being able to load a >64kb single pgm file, by having the X16 guys redefine the pgm format to the next level, so different parts of this same file can be redirected to separate parts of the ram (vera, banked or normal) 🙂  Also the Kernel would need to support it.  But then again, it's not that complicated.

    I agree, it may have limited use, but yeah, to me it would be a "cool" improvement.  Making the X16 one step more modern. (of course what is too modern is a question of taste)

     

    I'll still check out the the vid though, it looks interesting.

  8. Thanks. 

    On another topic I am still (somewhat a lost cause, I know 🙂 )  hoping they could somewhat extend the prg "format".
    Maybe first two bytes have $ffff reserved. If $reserved then prg v2 format.  Which would be something like

    byte1 byte2 (load ram  type and address of next chunk, some magic here to have 2 bytes both specify the address and the type of ram, or something....)

    byte3 byte4 (size of chunk)

    .....

    (next chunk)

    Anyway, one can keep dreaming, but it would be so cool, if single prg file could load stuff into base ram, banked ram, or vera ram, or most likely a combi, and also prgv2 files size would be not limited 🙂

     

     

  9. I like to return back to the prg topic (in another context).

    I just read this link on how prg files are used on the c64.
    http://fileformats.archiveteam.org/wiki/Commodore_64_binary_executable

    Here it states that either the data of the prg will be loaded in $0810 or the first two byte of the prg are used to determine where the prg dara is loaded in memory.

    This depends on if you do load "*",8 or load "*",8,1

    Is the behaviour the same on X16, and is the "magic" $0801 address also the same?

    Thanks

    /CKs

     

  10. Found this one on twitter, seemed appropriate to share.
    (Original tweet is here: https://twitter.com/C64Reloaded/status/1438602817116254213)

    Image

     

    I myself, and maybe many here, have never had a Sinclair Spectrum, but a best friend had, and I did end up sitting behind one many hours.   It was a nice bit of rivalry, when looking back,  between the "Speccy" and the C64.

    Always there was the friendly competition, which was best.  C64 was accused of being 'blocky', and the Speccy had 'terrible sound'.  For me it made me want to look into the details why things were as they were. Learn about the different graphics mode on the C64, to "on  up", my friend who had a Spectrum.  So I learned all about bitmap mode vs character mode, sprites, that were not on the Spectrum, the all mighty sid, and the fact that the Spectrum's CPU was much quicker (well in 4Mhz terms anyways), then the C64, 1Mhz. Learned some assembly, and did lots of drawing on the C64 in "Amiga Paint".

    So long old chap (Sir Clive Sinclair, RIP 2021)!

  11. 23 hours ago, Squall_FF8 said:

    Although BASIC is slow, using some asm routines for heavy CPU things might keep the BASIC useful.
    BTW Very lovely PETSCII artwork!

    That's true!  I did that once, long time ago, on the C64.  On the X16, I had some problems getting started that route though. 

    I would have liked the small asm routines to be included as data in the basic program.  But I stumbled on KickC before I figured it out practically, so this is why there is a "C" version of the game and a "Basic" version.
     


    Actually now I think of it, the pure basic version could probably be sped up significantly as well, since the scrolling on the X16, is pretty advanced. You can do alot by just moving one register around.

    About the PETSCII 🙂 Thanks!   It was cool to work in PETSCII again, it's always nice to hear someone likes it. 

  12. Welcome to group!   Lots of friendly people here, happy to help with X16 questions, and other 🙂

    Regarding the pictures, I am not sure what I am looking at, but it sure looks fast enough to run the X16 emulator flawlessly.

  13. Ok, I think I came to a bit of a conclusion.

    I was thinking what does disturb me the most on Video editing on Linux.   Most of it is actually long videos, and video capture.
    Long videos, actually I don't do so much... And video capture is a different program alltogether.

    So maybe Flowblade on Linux is fine for now.  It works, it does the job.  Some long videos are a bit tedious to edit, but most of my videos are not that long.
    What I will swap though, is using my Windows PC for footage capturing. Since the software I found there in my arch Linux, needs more CPU then my Linux Laptop can muster.

    I found out the GameBar in Windows11 is pretty cool.

    That said, I might still swap the editing of videos themselves at a later date.
    But probably I want to have clear to myself exactly what features I am looking for, since right now in my head it's more or less "Flowblade, but on Windows" 🙂

    Thanks for the inputs so far guys!

    • Like 1
  14. Thanks all, Mac or Linux is not an option for me right now.  I have them both, but they're not having the CPU/Memory as my windows PC has.

    @ZeroByte for Linux I worked with flowblade.  It does crash now and then, but not often enough to be a nuisance.  But it has many features, and filters.  Not so many transitions though.  Other than that on Linux I've seen Kdenlive being compared to flowblade.

    Not sure which to go for yet though, I don't like the subscription based softwares too much (mostly out of principle I think, but still)..  No keen for Adobe, if I do Adobe, I'll do it on my Mac, not my Windows, Adobe seems to me to be better on Mac... (but that's just a feeling so far)

    Probably I will be trying out in the weekend some of the alternatives mentioned 🙂

    • Like 3
  15. Hi!

    I am about to swap from on video editor program to another, and have noticed some of you have you tube channels and make pretty good looking videos there on commander x16 related topics.

    So I wonder what do you recommend for software?

    Right now I am using Flowblade on Linux, and I am satisfied with it, but my main computer is running windows, and is much faster, so I am thinking of moving to a Windows video editor.
    I tried Pinacle Studio on windows some long time ago, and was pretty happy with it, but this was many years ago. 

    What software for video editing are fellow X16'er (with you tube channels) using?

    /CKs

  16. What I did, was to edit in atom (another editor like Notepad++). Then when ready to test or save, copy and paste it into the emulator. (ctrl-v). 

    Note: Make sure your code is in upper case, otherwise you get lots of PETSCII characters instead of your commands.

    Before pasting, I usually typed "new", to start afresh.  When I was happy with it, I saved it within the emulator.

    Actually my code inside atom, had "new" on the first line, so it's automatic when I copy / paste.

     

    Usually during the testing phase, I used the web emulator, since there you have an edit window, for small changes, and from there it is easy to "copy back" to you editor. Only when satisfied, I pasted it in the "real" emulator, and did a save command.
    Hope it helps 🙂   To me it was super simple.

  17. On 5/27/2021 at 11:07 AM, Greg King said:

    ....

    Note that the __interrupt qualifier makes this function return by jumping to R38 Kernal's $E049, which pulls the registers and does RTI.

    I am using KickC, not cc65  is it the same there?

  18. Thanks Greg, that is correct.  So then the final code snippet for KickC compiler, vsync AND line interupts AND keyboard handling:

     

    Quote

    ..

    volatile char vbcounter=0;
    volatile char linecounter=0;


    __interrupt( rom_sys_cx16 ) void myInterupt() {

      if( *VERA_ISR & VERA_LINE ) {

        //DO Line interupt stuff

        linecounter++;

        //end interupt
        *VERA_ISR = VERA_LINE;
        asm {
          ply
          plx
          pla
          rti
        }

      }
      else if( VERA_ISR & VERA_VSYNC ) {
        //Do sync interupt stuff

        vbcounter++;
      }
    }

    ..



     

  19. Thanks for all the feedback,

    So today I cam back to this, since I forgot about it for a while, as everything that made sense just ended up not working.  And I needed to get some other things done.


    Now I noticed that when I disabled the interrupt it was not working either 😛, I noticed the combination of kbhit and vpoke, as defined in KickC, at least the version I have, crashed.


    So when I found this out, then I replaced the vpoke by my own implementation, and suddenly the version without interupt was all ok, now one more try WITH interupt.

    What I did get working on the end, is more or less described by the following minimal code snippet.
     

    Quote

    ..

    volatile char vbcounter=0;
    volatile char linecounter=0;


    __interrupt( rom_sys_cx16 ) void myInterupt() {

      if( *VERA_ISR & VERA_LINE ) {

        //DO Line interupt stuff

        linecounter++;

        //end interupt
        *VERA_ISR &= VERA_LINE;
        asm {
          ply
          plx
          pla
          rti
        }

      }
      else if( VERA_ISR & VERA_VSYNC ) {
        //Do sync interupt stuff

        vbcounter++;
      }
    }

    ..

    RTFM helped me a bit as well, seeing that KickC has some support build in for X16 interrupts, with or without keyboard (system or minimal). 

    All worked fine for none line interupts, but for line interrupts, I still needed a bit of assembly, as you see above, to exit correctly. (ply, plx, pla, rti )

    This is probably the best version I have right now, with the least amount of assembly code in it, and it works nicely together with keyboard.

     

  20. I'm pretty late to this post, but it's very interesting to me.


    To me it's all about how easy it is to get started.

     

    I would not be on this website as much as I am right now, for two things.

    • The 8 Bit guys' cool introduction video to this project.
    • The try it now button / integrated with the uploaded software section on this website.
    • The community of people, with the forums right here.

     

    For me getting the X16, which I definitely will do, is really cool.

    But what is cooler, for now, is this website, the online emulator, and the awesome community. 

    I could not stay interested long, otherwise.  Especially, if the release date is not fixed, to me the community and the emulator are more or less the X16, until the real thing comes out.

     

    For the Mega65, all information, chats, download site, emulator, is more scattered, and you need to put more effort into "getting something to work".

     

    And with only so much time to spend, (job, family and so on, it's not anymore when I was a student and could spend weeks and weeks on a single project),  it is simpler to go deep quicker with the X16.  For me the Mega involvement will be there, but is just lagging behind, because of the reasons above.


    To me the only drawback on the X16 so far is really sound.  Mega65 has SID, X16 does not. X16 is a bit unclear on what sound we will have in the end product.

    But then again, it's not a deal breaker for me.  I like the X16 as it is 👍

    In fact I also like the Mega65, I think both are amazing projects, by dedicated individuals.

     

    • Like 3
  21. On 6/18/2021 at 1:59 AM, desertfish said:

    wait... how did you manage that vertical wave effect???   I tried something like that but couldn't get the vera to do what i wanted with the vertical scaling register

     

    On 6/18/2021 at 2:06 AM, Elektron72 said:

    I believe this kind of effect is done by changing the vertical scroll register on each scanline, rather than vertical scaling.

    This is correct. And for double wave effect, I change both H and V registers, and since it's two layers, I am change 4 registers.

    Also I found it works pretty well every second line, but I am getting weird effects if I do it every scan-line. Anyway every second scan line is pretty good for the effects I want to do.

    The interrupt looks more or less like this.

    __interrupt void irq_line() {

    *VERA_L1_HSCROLL_L = WAVES[loffset];
    *VERA_L0_HSCROLL_L = WAVES[loffset];

    loffset+=2;

    // Reset the LINE interrupt magic below
     *VERA_IRQLINE_L = (unsigned char)loffset & 0xFF;

     if(loffset > 255) { *VERA_IEN |= 128;  }
     else { *VERA_IEN &= 255-128; }

    *VERA_ISR = VERA_LINE;

     

    • Like 1
×
×
  • Create New...

Important Information

Please review our Terms of Use