Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 01/16/21 in all areas

  1. 4 points
    KickC is a C-compiler for 6502-based platforms creating optimized and readable assembler code. The newest version 0.8.5 adds support for developing for the Commander X16 platform. The compiler includes header-files and linker-files for the chipset of Commander X16. Also included is veralib.h and a conio.h implementation contributed by @svenvandevelde. It also includes some example-programs that work in the emulator (and hopefully on the real platform). Below you can see a bit of the included sprites.c example program. You can get it here: https://gitlab.com/camelot/kickc/-/releases PS. I am the author of KickC.
  2. 3 points
    I wrote a series of blog posts/articles on Commander X16 architecture and coding. I have started with focus on beginners and then slowly moved to more advanced topics and techniques. First I tackle smaller chunks and use simple examples to show the topic in practice. After enough new knowledge is covered I write a complete game to utilize several of the techniques to illustrate how it all comes together so each new complete project is more complex than the one before. I do cover only Commander X16 specific so I recommend reading Commodore C64 BASIC tutorials and guides. Please note that the games and most examples are written with a goal to be as clearly readable and understandable so there is very little source code optimizations. Snake Game This game is written in very clean BASIC with very little trickery so not much special Commander X16 knowledge is required. We do VPOKE directly into video memory so only understanding of fundamentals is required. Recommended reading VERA Overview Topics Covered in Game Analyzing the game itself is a great way to learn basics like: How to structure source code (outer loops, game loop) What is Game loop Use of Data structure like multiple Arrays How to read Joystick, Keyboard How to use VPOKE to “talk to” VERA Video RAM organization and using colors Writing to certain location on the screen Using PETSCII control characters to display messages and title screen GOTO Crazy Snake Tutorial GOTO Download Tetris Clone This game introduces some more advanced features of Commander X16 and we have to take a bit more care of how to use data structures and optimize some parts of the game to make it playable. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Colors and Palettes Topics Covered in Game Tetris clone requires us to improve on pretty much all parts of the snake game structure: We have additional loops outside and inside game loop Advanced game collisions based on screen state Pre-calculate relative positions of four segments of each tetromino Customize color palette Customize tiles (characters) Speed increase per level Adding sound to the game GOTO Crazy Tetrominoes Tutorial GOTO Download Boulder Dash style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. We have to pay close attention to timings, synchronizing scrolling and animation, take care of different types of collisions, etc. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Simplest Sound Effects Library for BASIC Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Two phase approach to development Full color mode Full screen scrolling Two layer graphics Scrollable playfield Static HUD Animated full color sprites 256 color title screen in graphics mode Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset Sprite Sheet Fonts Sound effects library Title screen GOTO Crazy Boulders Tutorial GOTO Download
  3. 3 points

    Version 0.1

    11 downloads

    ux16vt is a UTF-8 and somewhat ANSI compatible terminal emulator for Commander X16. Currently the only useable "serial" port uses LOAD & SAVE to communicate between the X16 emulator and a glue process that moves data in and out of a POSIX pseudo-terminal. In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run emulator_glue.c. ## Unicode Support ux16vt supports up to 4096 1-bit 8x16 pixel glyphs selected at compile time from the Unicode Basic Multilingual Plane. Unknown characters are displayed as blank. Currently 672 of these glyphs are used covering 862 different code points. The following blocks are mapped: - Basic Latin (00-7f) - Latin-1 Supplement (80-ff) - Greek & Coptic (370-3ff) - Cyrillic (400-4ff) - Box Drawing (2500-257f) - Block Elements (2580-259f) Limitations: - no support for right-to-left text - characters are represented internally as 16-bit values, making any characters outside the basic multilingual plane complete inaccessible - completely mono-spaced text. full-width glyphs are not available ## ANSI Support Only sequences beginning with ^[[ are supported (Control Sequence Introducer). Only numeric parameters are read. A control sequence with more than four parameters will cause an unchecked buffer overflow. The following functions are available: A CUU Cursor Up B CUD Cursor Down C CUF Cursor Forward D CUB Cursor Back E CNL Cursor Next Line F CPL Cursor Previous Line G CHA Cursor Character Absolute [column] H CUP Cursor Position J ED Erase in Display K EL Erase in Line S SU Scroll Up T SD Scroll Down d VPA Vertical Position Absolute [row] f HVP Horizontal Vertical Position m SGR Select Graphics Rendition The only available modes for SGR are 31 to set foreground colour to red and 30,32-39 set the foreground colour to black.
  4. 3 points
    There are already solutions for the C64 that load data into RAM over the User port. It would be trivial to implement a similar solution on the Commander. And, again, don't forget that I've already put together a basic spec for communicating in parallel over the User port. All we need to do is implement that in code (which we can't reliably do until we have hardware.)
  5. 2 points
    ux16vt (Unicode Terminal for X16) View File ux16vt is a UTF-8 and somewhat ANSI compatible terminal emulator for Commander X16. Currently the only useable "serial" port uses LOAD & SAVE to communicate between the X16 emulator and a glue process that moves data in and out of a POSIX pseudo-terminal. In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run emulator_glue.c. ## Unicode Support ux16vt supports up to 4096 1-bit 8x16 pixel glyphs selected at compile time from the Unicode Basic Multilingual Plane. Unknown characters are displayed as blank. Currently 672 of these glyphs are used covering 862 different code points. The following blocks are mapped: - Basic Latin (00-7f) - Latin-1 Supplement (80-ff) - Greek & Coptic (370-3ff) - Cyrillic (400-4ff) - Box Drawing (2500-257f) - Block Elements (2580-259f) Limitations: - no support for right-to-left text - characters are represented internally as 16-bit values, making any characters outside the basic multilingual plane complete inaccessible - completely mono-spaced text. full-width glyphs are not available ## ANSI Support Only sequences beginning with ^[[ are supported (Control Sequence Introducer). Only numeric parameters are read. A control sequence with more than four parameters will cause an unchecked buffer overflow. The following functions are available: A CUU Cursor Up B CUD Cursor Down C CUF Cursor Forward D CUB Cursor Back E CNL Cursor Next Line F CPL Cursor Previous Line G CHA Cursor Character Absolute [column] H CUP Cursor Position J ED Erase in Display K EL Erase in Line S SU Scroll Up T SD Scroll Down d VPA Vertical Position Absolute [row] f HVP Horizontal Vertical Position m SGR Select Graphics Rendition The only available modes for SGR are 31 to set foreground colour to red and 30,32-39 set the foreground colour to black. Submitter lamb-duh Submitted 01/15/21 Category Productivity Apps  
  6. 2 points
    Why are we discussing active trasfer of files between X16 and PC? And why do testing on emulator? X16 is not a microcontroller which essentially needs to be connected to PC for development. X16 is a freakin standalone self-sufficient computer! It should be possible to do all development directly on it.
  7. 2 points
    Again to all the people discussing serial over the user port. RS232 serial is already planned. The routines just have to be written and the vectors are there. Sent from my iPhone using Tapatalk
  8. 2 points
    You get to choose your poison: Copy the VRAM data you want to preserve to somewhere else, where it'll be out of the way. Clobber the VRAM data you would have otherwise been preserving. There is no reason you have to keep the character set at $0F800. If you intend to use it, copy it to somewhere else in VRAM and update the layer data that would use it, accordingly. I also want to point out that the VERA does not have "banks" in the sense that I think you mean. It simply has 128KB of addressable memory, however the tail end of that (starting at $1F9C0) is overlapped with the audio generator, followed by the palette, and finally sprite attributes. So don't clobber that area with pixel data.
  9. 1 point
    Just a quick FYI: I just fired up rev 38 of the emulator on my M1 MacBook Air and it seems to be working.
  10. 1 point
    One thing to note though is you should from a good coding standpoint, never attempt to read the keyboard or mouse directly. You should use the KERNAL routines instead. If you try to write your own routines it will cause several bad side effects. One is that if the way the keyboard works changes, it will break your code every time. What if a future version used a USB keyboard or a direct matrix? If you use the KERNAL routines you will always work and it would be the KERNAL that would change to match the hardware. Also we have found some keyboards have different requirements. We are making our routine as robust as possible. Custom routines may not be as forgiving. Sent from my iPhone using Tapatalk
  11. 1 point
    Hi @TomXP411 Thank you for trying out KickC. I hope you like it, and would appreciate any feedback from you to improve it! I have found out why you are getting the "Called procedure not found" error. It is an embarrassing forgotten include. If you add the following line at the top of lib/cx16-conio.c. then helloworld.c will compile as it should #include <veralib.h> In the other included CX16 example programs veralib.h is included in the main C-file, so the compiler is happy. Let me know, if this works for you. I will of course include the fix in the next release.
  12. 1 point
    Hi, @Jesper Gravgaard I'm trying out Kick C (I appreciate it doesn't require CygWin just to compile some c code), but I can't get the examples to compile for the Commander X16. I'm getting this: I tried adding veralib.c to the command line, and I get Redefinition of variable: vera_layer_config The error on the initial compile is telling me there's a library or object file missing, but I can't figure out how to add it on the command line. Do I need to compile something else first to create the Commander X16 library file? What am I missing? (On another note: the program compiled and ran perfectly on VICE without any errors. Thanks!) ** edit: figured it out. I had to add #include <cx16.h> #include <veralib.h> To the program. Once I did that, everything started up. Now I just have to remember my old school C and console commands. Thanks! This works great!
  13. 1 point
    It's very straight forward, but I'm going to do a quick write up on it today or tomorrow. The relevant 6502 code is in src/emu_serial.s and the host-side code is in emulator_glue.c, if you want to see what it's doing in the meantime.
  14. 1 point
    I think I'll make a separate github repo for the assembler. It's now "an example" in the prog8 repository but I feel it is growing way beyond that. Also I don't think I have the time to implement everything myself and I much rather would like to see this as a joint effort! It's meant to be open-source after all Great tips though Stefan. I am quite confused still though by the "select kernal ROM" -- isn't it there by default? How else could we call CHRIN() and its brethren?
  15. 1 point
  16. 1 point
    This sounds like a fantastic hack. I am deeply intrigued!
  17. 1 point
    Actually on the contrary, while it may be fun to do all this myself, that's a pretty big lift! And the ultimate goal for me is having a tracker on the X16 so I can make music with it. Once there is a MIDI interface, perhaps in tandem with a modern DAW; but I'm looking forward to the offline isolation of a dedicated tracker running right off the X16. I suppose there's a small part of Nostalgia at work there but not much as I do find using my modern DAW can be pretty distracting. Even if I just unplug the damn network cable, Windows still wants to make sure that I know that my online account isn't sync'd just in case I changed my mind, in addition to myriad of other nonsense. So yeah, anything that gets the closer to the finish line I'm all about! The portmento in particular is something I didn't know quite how to implement. I assumed it was similar to what I was thinking a pitch slide would be (in the tracker case, it's a shift and offset is how I thought about it, though I haven't yet looked at, say, Famitracker, to see how it does it) but with a end frequency to shoot for (namely the note that was played). In any case, when you get down to it, what makes a tracker is mostly the UI and approach. I think the only thing potentially special about a sound engine for it is, like we discussed previously, channels are typically hard set to particular hardware voices where the composer decides how to use what channels. This has benefits for being of being able to saturate channels more. I like I could use PSG channel 1 for both a chip bassdrum, hi-hat, and maybe an arpeggiator within the same track. The above is no longer true some modern trackers, like Renoise but in the case of the X16 is how I was going to approach it as it's still sort of "standard" when looking at say Famitracker or Deflemask and this makes the file format more straightforward. This concept doesn't really save any screen real-estate either - I think in the case of Renoise, being largely a sampler at the end of the day (though it has VST and MIDI support), it makes a lot of sense, especially with its out of tracker automations it can do. Not sure how familiar you are with trackers so forgive me if I'm rehashing what you already know, but essentially you define notes and effects on a piano roll using, typically, a concept of instruments. The instruments would set up defaults and be where you might define a default envelope, etc. They make more sense for FM but even with the PSG make sense - you can setup a "pluck" sound that has a short volume envelope on it, optionally along with a PWM envelope to give it a nice timbre for the pluck. Then you might have a bassdrum which is a fast pitch slide down also with a volume envelope. Then in the patterm data, I tell it what note, octave, instrument, and optional effects I want. Something like: | VeraSound 01 | V02 | ... | F1 | FM 2 | ... | PCM | ## | -------------------- | --> | | --> | ------------- | | --> | 00 | ... .. .. .. ... ... | C-1 02 | | G-3 | D#2 01 FF M01 | | C-4 | 01 | ... .. .. .. ... ... | C-1 03 | | ... | ... .. .. ... | | ... | 02 | C-4 01 .. .. A37 ... | D#1 02 | | ... | ... .. .. ... | | ... | 03 | ... .. .. 20 ... ... | D-1 02 | | ... | ... .. 50 ... | | ... | 04 | D#4 01 L. 20 A00 V10 | D#1 03 | | D#3 | --- .. .. ... | | ... | 05 | D#4 01 .R 10 D04 V1A | G-1 03 | | ... | ... .. .. D0A | | ... | 06 | ^^^ .. .. .. ... ... | D#1 02 | | ... | ... .. .. ... | | ... | ... 06 | ... .. .. .. ... ... | C-1 .. | | ... | ... .. .. ... | | ... | My current file format definition allows multiple effects, so there could be D04, G37, ... I'm not sure if I will keep that yet as another way to do combination effects is with macros (or instruments with their own automation if the effects don't need to be modulated). I also though about allow different envelopes to be selected on the tracker data but I need to see how that might fit into the effect column while trying to keep the pattern data small. I said all that to say a tracker could surely use a sound engine probably without too many modifications? I wonder if any modifications that would be needed might be something that can be added to the engine. It would be pretty amazing if both an X16 tracker and DAW used the same engine. In fact that might not be the only thing that can be shared - a MIDI solution could be one that might be shared by both. A tracker tends to be a little more limited here - one could set it up to output MIDI but that seems like a bit of an odd solve on the X16. It could read incoming MIDI as an alternative means to edit patterns. Primarily for me, I'd like MIDI sync so I can use the X16 is sort of another instrument in my greater orchestra as it were. I'm super rambling sorry haha I thing long story short, it makes a ton of sense to me for really all the music and sound applications to be able to reuse and share as much code as possible. A tide lifts all boats kinda thing. So yeah I'd be quite interested in learning more about your engine, absolutely!
  18. 1 point
    Yeah, the floating point routines are on different addresses in the X16 rom. Also I think not all "internal" basic routines of the C64 basic rom can be used or are even available. I stuck with the exposed routines listed here: https://github.com/commanderx16/x16-rom/blob/master/fplib/fplib.inc (translated into Prog8 here with a little bit of description added for each routine) Unfortunately FIN is listed as ";fin = $fe7b ; XXX TODO" and the routine is not implemented. So converting a string to a floating point value is "Left As An Exercise For The Reader" I think..... I haven't had to do this myself so far--- all I ever needed was the user inputting an integer . This can be converted to float using GIVAYF for instance. For floating point constant values in the program, the Prog8 compiler itself is doing the conversion to the 5-byte binary format so the program never sees the string...
  19. 1 point
    I don't think that there is an implication that EVERYONE need to or want to transfer files in and/or out of their CX16 at speed faster than the built-in serial port allows, but coming up with use cases for SOME people to want to do so is not hard. (1) Because for many people, the easiest backup for the SD-card will be to write it out to some folder in a PC's mass storage (2) It doesn't REQUIRE cross development, but many people will do cross development. (3) Some people have things they'd like to do that exceed their budget for bespoke hardware and see a way for an existing PC to be used as a resource to fill the gap. (4) The amount of GPIO and freedom to program to the bare metal makes the CX16 attractive as a bench computer for some kind of work, and you'd like your bench computer to be able to talk to your laptop.
  20. 1 point
    @Jesper Gravgaard Hi Jesper, Congratulations with your compiler. This is a truly amazing work. Really! Your compiler does a trade-off between efficiency (and it does it very, very well), and functionality. It is also very transparent, the assembly code generated is readable, which makes it very useful for debugging or learning. Kudos! Sven
  21. 1 point
    It is. That's what I do in most of my programs, and it works just fine as long as I have the bank set back to 4 before the RTS that should take us back to BASIC. However, certain RAM and VRAM states may make that difficult, so there may need to be other resetting needed.
  22. 1 point
    If you want a more convenient form factor for sneakernetting, there's always compact flash, a 2GB CF card is around $12 on Amazon, and there are USB CF readers available. I'd assume that a Device #9 file server over the serial port will already be sorted out by launch, so the issue is if that is not fast enough. An EPP Parallel port interface to a USB / DB25 converter with full LPT and COM functions would be plenty fast enough if bit banged RS-232C serial is not, and if the other capabilities available from higher speed serial are desired, some form of dedicated UART would also fill the bill. At the cost of a USB/DB25 converter, or the cost of a UART card, an accelerated-SD2IEC solution would be more for those who already have or want an SD2IEC for a VIC-20 or C64 in their setup, so the SD2IEC is not really an extra overhead expense.
  23. 1 point
    I've created a blog post about using tiles in BASIC. Going over the fundamentals of getting a Tiled map and graphics in to the X16 and displayed. https://justinbaldock.wordpress.com/2020/10/09/commander-x16-basic-tiles/ Feel free to comment here when providing feedback.
  24. 1 point
    The problem being that this ReadMe is not included in the emulator package, so I had no idea it existed until earlier today (when I was looking at the block I/O API.) Yes, the P command works great. I've already written a small demo program to test it. Also, it's worth noting there is an error in the ReadMe. The ReadMe says: POSITION P channel p0 p1 p2 p3 Set position within file (like sd2iec); all args binary "all args binary" is not correct. The channel number needs to be passed in ASCII, so the correct syntax to seek to position 128 on channel 1 is.... DOS"P1"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0) Channels 10-15 need to be entered as the ASCII characters after 9 (:;<=>?) here's an example: 20 OPEN 1,8,8,"@:DEMO,S,W" 40 FOR L=0 TO 255 50 PRINT#1,CHR$(L); 60 NEXT 90 CLOSE 1 100 OPEN 10,8,8,"DEMO,?,M" 110 DOS"P:"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0) 115 DOS 120 FOR I=1 TO 4 130 L=0:GET#10,L$:IFL$<>""THEN L=ASC(L$) 150 PRINT L; 160 NEXT I 170 PRINT 999 CLOSE 10 When you run this, it will create a 256 byte file. Then it will re-open the file for random access and seek to position 128. It will then print 4 bytes byte at that position. That should be 128-131.
  25. 1 point
    Except I don't know of any commonly-used PC programs that render markdown properly. If you're going to go to those lengths, you might post it on GitHub or something and link to it.
  26. 1 point
    The CODE tag here is broken. You can use the BBCODE tag, but blank lines cause weird indentation. line 1 line 2 line 3 I've taken to just attaching code as text files.
  27. 1 point
    When I wrote the "Invention 13" player, I thought up seven points that exemplified the X16. I'm wondering what your list would look like, if you had to list out seven short bullet points. (This will help me refine my list, too). Here's my first stab: WD65C02S at 8 Mhz 512K ROM 128K Video RAM Kernal with 16 bit ABI PS/2 and SNES IEC and SD I/O Expansion Slots Note that lots is left out that come from questions leading from one of the above; for instance the huge pile of banked RAM (RAM is a complicated issue, so hard to do justice to with a bullet point). And I've completely not mentioned VGA or sound... surely VGA should be there somewhere? I figure video and sound gets asked about once someone sees "128K Video RAM", so that is the gateway drug to learning about VERA. Same goes for the Commodore ROMs, BASIC, DOS wedge, and various environmental enhancements: mention that the Kernal includes a 16 bit ABI, and there's the gateway drug to learning what else is on-board.
  28. 1 point
    Your RLE format is somewhat hungry for memory space . I'd use a [RunLength], [Value] format where RunLength's MSB indicates whether it's followed by a single byte value that is repeated N times, or by N bytes that are only used once. So, a data stream that looks like ABCDDDDDDDEFGHIJJJJJJ would be stored as 3,A,B,C,135,D,5,E,F,G,H,I,134,J for a total of 14 values, while your format would be A,1,B,1,C,1,D,7,E,1,F,1,G,1,H,1,I,1,J,6 for a total of 20 values. The difference would be even greater if there are many non-repeated values. Of course, this could be extended to indicate, for instance, that what follows is a pattern of M values that should be repeated N times, by using a few bits of the RunLength byte.
  29. 1 point
    I uploaded v 0.3.3 of the X16 Editor today. New in this version: I have implemented a directory listing view, that you can use to select files for opening or saving. The default option is still to enter the file name manually at the prompt, similar to how GNU Nano works. At the open and save file prompts you may press Ctrl+T. "To files" in GNU Nano jargon. I hope that X16 Edit will be usable for native programming on the computer. The ability to easily open different files should be valuable. I have also made an alternative entry point that loads a specified text file immediately on startup. I have discussed this option with @pzembrod who also came with valuable input on the function. The idea with this function is that it may be useful when integrating X16 Edit with other programs, for instance Volksforth and the C compiler Philip is working on. If this is hard to understand, the functions are described in more depth in the manual and the special notes on using the ROM version that is available on the download page. Or you may watch this video. X16 Edit 0.3.3.mp4
  30. 1 point

    Version 1.0.1

    24 downloads

    I learned about the various screen modes of the Vera chip. As long as you reduce the number of colors to fit it all in the available video memory, high res 640x480 bitmap images are perfectly possible. 256 colors requires way too much memory though, so for simplicity sake, I reduced it all the way back to 2 colors black and white.
×
×
  • Create New...

Important Information

Please review our Terms of Use