Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 01/11/21 in all areas

  1. 6 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. 6 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. 5 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  
  4. 4 points

    Version 0.1

    2 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.
  5. 4 points

    Version 1.0.2b

    0 downloads

    This program is written using kickc of Jesper Gravgaard. I'm helping him to create a framework encapsulating the CX16 vera in order to be able to quickly create graphical effects for games. This is a short demo and I hope you like it. This program uses the keyboard to progress through the program! So be sure to run this from the desktop, since the emulator on mobile phones do not have a keyboard!
  6. 3 points
    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.
  7. 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.)
  8. 3 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. 3 points
    I created this image for converting a classic mechanical PC keyboard into an X16 keyboard. You can print it on inkjet-printable sticker paper, and cut out the stickers. It works with the "print then cut" mode on my wife's Cricut cutting plotter. BTW, Although the graphics are obviously inspired by Commodore's work, I created this image from scratch by hand-editing a PostScript file in a text editor, so there shouldn't be any copyright concerns. Edit: The image should be printed at 600dpi, with a size of 6.5" x 3.125"
  10. 3 points
    Here's a version of the assembler to play with. It doesn't support symbols yet so stick with basic assembly. It also only writes output directly to memory for now. The video shows it in action on a simple hello world program: cx16mf-2021-01-14_22.07.31.mp4 assem.prg
  11. 3 points
    OK, I reformatted this to look like the C64 promotional at the end of the 1983 Christmas Demo. I figured I could push some of the X16's features while playing that little ditty from Bach. And I backed off a bit on the sprites, so they're more subtle, but still there of course.
  12. 3 points

    Version 3.0.0

    7 downloads

    I was missing Bach's "Invention 13", and so here's my first attempt. Naturally, this will need to be debugged... I think I heard a couple bad notes in there. Then, naturally, this will need some sprite graphics... the X16 butterfly in shifting colors or something. But for now, here's the first 13 bars that Commodore Business Machines used in the early 80s.
  13. 3 points
    Thanks. This makes me wonder why Butterfield suggested we read the Zero Page variable directly. In fact, I found that by accident while browsing a really nice API list, here: https://www.pagetable.com/c64ref/kernal/ I finally finished my directory reader in assembly: it's basically a line-for-line translation of the BASIC code... it took a while to get the file open correctly, do the correct CHKIN, and all of the other fun stuff that goes along with it. Either way - now that I can read a directory, this is the first step to building my file manager.
  14. 3 points
    VERA window panning demo View File This program is written using kickc of Jesper Gravgaard. I'm helping him to create a framework encapsulating the CX16 vera in order to be able to quickly create graphical effects for games. This is a short demo and I hope you like it. This program uses the keyboard to progress through the program! So be sure to run this from the desktop, since the emulator on mobile phones do not have a keyboard! Submitter svenvandevelde Submitted 01/12/21 Category Demos  
  15. 3 points
    I wrote a Z80 scrolling sprite and tile engine for one a few years ago and while it worked fine the quality of the display took a bit of a thumping.
  16. 2 points
    Sorry for being late to the party. I'm currently using CC65 tool chain since it provides relocatable object models and a capable linker, plus integration with C. On top of that, since it runs on my modern machine, I have access to GIT (or what ever SCS you want). With out a source code control system, life ain't worth living! I totally get the idea of having a native development system, but modern editors (although I use Emacs) and source control are too much of an ask for me. Combine with the X16 emulator, and it's a pretty fast edit-compile-debug cycle.
  17. 2 points
    If you've ever played 7 Cities of Gold, you remember that the map felt HUGE. It seemed to take forever, exploring an unknown continent, wondering if your men were going to starve. Rejoicing when you finally rounded the continental cape and began sailing north up the western coast. I took a glance at the map today, and it seems that it's not as memory intensive as it looks. I suspect this map renders each piece of topographic data, except for the rivers. The continental mass in this example is something on the order of 40 pixels wide, maybe 80 pixels tall, and only four colors. If that represents a third of the total height (240 pixels?) and maybe it's 100 pixels wide, and each pixel is 2 bits, then that's 240 x 100 x 2 = 48000 bits = 6K for the base map. (Looking closer, the map is actually more detailed than that, so it's larger than the measly 6K... looks like the Big Map has 1 block averaging out 4x4 actual map pixels, so total map size is 6 x 4 x 4 = 96K. Which is more like it, since that plus native data would take up most of a diskette.) It still astounds me.
  18. 2 points
    Just a quick FYI: I just fired up rev 38 of the emulator on my M1 MacBook Air and it seems to be working.
  19. 2 points
    Yes, running the User port lines out to a breadboard to talk to microcontrollers or microcontroller petipherals. Bringing up a tethered Forth in a small microcontroller is one example. And before people jump in and say, "no, the way you do it is this way with these software tools", I'm going to point back to where I said, " not everyone will want to" ... a lot of people are happy with the tottering piles of tools on development environments that run on dlls from other development environments talking to proprietary drivers, but those who are not thrilled by that approach exist. Indeed, it's almost guaranteed that if there is a mainstream approach, there will be pockets of people who are not enamored with the mainstream.
  20. 2 points
    I added a bunch of videos to the playlist already, and just added this one tonight. I think the topic covered might interest a few people: Reverse-Compiling PETDRAW.
  21. 2 points
    No, VPOKE is not meant to take advantage of auto increment. VPOKE more fully takes advantage of direct access, but for speed once you set up auto increment you would just keep poking additional values. So if you are sending a sequence you would enable auto increment then VPOKE the first byte in the sequence and POKE the rest. Sent from my iPhone using Tapatalk
  22. 2 points
    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
  23. 2 points
    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.
  24. 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.
  25. 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
  26. 2 points
    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.
  27. 2 points
  28. 2 points
    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. 2 points
    Very nice! But you got the date a year late. Probably [emoji39]
  30. 2 points
    These chips are readily available through our supply channels. This chip was an exception because firstly it met our cost goals and secondly developing an open source FPGA core if the supply dries up isn’t a problem. Yes it is paired with the YM3012. Sent from my iPhone using Tapatalk
  31. 2 points
    No, generally speaking, they were not interlaced. They ran a mode called "240p", which was progressive scan at 60Hz. Instead of sending both fields of an interlaced frame, the console just repeatedly sent the first field, and so a CRT TV set would just render the same scanlines over and over, never switching to the other field. (I'm not actually sure if this was always odd or always even.) Strictly speaking, 240p is a hack, and some displays or converters get confused dealing with it. This is because they read in the odd and even fields for de-interlacing, then spit out a progressive-scan frame at 30Hz. When the second field never comes in, the converters will get stuck rendering half of the frame and never actually spit out the full de-interlaced frame. I have a couple of monitors with this problem, and an otherwise excellent Dell monitor with S-Video input doesn't work on my Commodore 64 at all. The Atari VCS, NES, SNES, and Sega Genesis all ran 240p, although the Genesis and SNES had hardware support for 480i... it just wasn't used very often. The SNES and Genesis actually did have some titles that ran 480i, but they were few and far between. It wasn't until the GameCube/Playstation days that 480i became the norm, from what I recall.
  32. 2 points
    I loved this driverless approach in the past, despite it being primitive and obsolete in modern world. And I'm happy that X16 brings back this experience.
  33. 2 points
    Same here. If I try read this forum with zoom lower than 125%, my eyes cry... Fortunately I can adjust different zoom level for each site, and browser remembers the setting per site.
  34. 2 points
    Hi, I'm Michael/Mike Losh AKA Sohl. I'm interested in this project and hope to write some code for X16 sooner or later! (Although to be honest my current hobby project is for Atari 2600... at least it's 6502-family, right?) I got started with Commodore in 1983/84 when my parents upgraded from a CoCo 1 to a C64. I was very into BASIC programming and learning as much as possible about computers and digital electronics. It must have worked because I'm a lead software engineer in a major auto company R&D department now. Just before going to college in `85 my dad found some C64s, disk drive and monitors being sold as factory refurbished, if I remember correctly. So I got my own C64 setup to take to college. I later got a REU and geos, but by that point, I was starting to use the college VAX to type and laser-print my papers and whatnot. By graduation, IBM PCs and clones were pretty much taking over everywhere. My biggest regret with the C64 is not getting a decent assembler for it and learning assembler coding better back then. I just dabbled with hand-assembling a few short routines or using a really crude monitor and not getting very far with it. But with a good assembler in a cart/disk (or maybe even Forth!), I think I would have done even more with that C64. But I kept that college C64 setup. I get it out once in a while to dabble again and have some fun. I'd like to at least get a SD2IEC device to make using a lot easier. But I'd also like to get a X16 now after seeing the really cool 8-Bit Guy videos and supporting ones from Perifractic, Adrian Black, TexElec, Matt Heffernan, and others! Best wishes to everyone and hoping for you all great success with the Commander X-16! -- Mike
  35. 2 points
    I've just made a BETA release of Prog8 6.0 available. It contains a huge pile of improvements and changes, among which: restructured part of the library modules, may break old code moved many built in functions that should just be subroutines, to the library module "sys" or "string", may break old code commanderX16 virtual registers cx16.r0 .. r15 available (for both cx16 and c64 compiler targets) added new library modules and routines such as gfx2 and new diskio stuff I've been using this version to create the multi-file-format imageviewer demo with color cycling, the highres bitmap graphics demo, and recently the W.I.P. file-based assembler. It's still a beta release so things might still change, but I wanted to shove it out the door because it works very well for me at this time and the list of changes and improvements is getting pretty huge so it would be a waste to not let others use it as well already.
  36. 2 points
    It's a random access construct (drive seeking) for fixed length 'records' with variable data held within with zero overhead required by the Commodore deivce. With one command (via a 15 command channel), you can instantiate file of [as example] 192 characters per record; once created, you can open and close a file via simple open command without describing the structure; then via command channel, seek to any 'record' between 1 and 65535 with an offset in the record from 1st to 192nd character. Each record can have a varied structure (like a MongoDB document) and once open and positioned, you use typical "input #2,a$,b$" in order to read data. Again, zero overhead to the computer, all done within the 1541 (as example) drive. Anybody know?
  37. 2 points
    It's a mode designed for random access files. The file has two parts: a vector table and the actual record data. Essentially, the vector table is a list of indices into the table that allow you to point to various locations in the file and (I think) update the order of the records without physically re-writing the records (you would just change the index). I think the primary use cases was for databases, since a separate chain for indexes would let you re-order data without physically re-writing the data portion of the file.
  38. 2 points
    I would agree that it seems to be an issue with clear type. I tested on Mac and Android devices. Increasing the font size may be a solution but we chose the font size for a reason. I'm not sure we want it any bigger as it is already somewhat large and would look overly large. if this was a issue that had been reported more than this one time in the past (nearly a) year including the website beta, that would be different. I will also add that it looks great on mobile, and I'm sure the same goes for Apple phones. I would propose as a solution increasingly your browser zoom by one notch, or disabling clear type, or living with this very small issue in the big scheme of things, or even changing the username to SixtySix [emoji4]
  39. 2 points
    After programming a while for the emulator I'm generally very pleased with how things are working. There are a lot of free ZP addresses, at least when you program in assembly. Typically even a large program really requires only a few ZP words, mostly for indirect addressing. The bank switching works well as is, and it will work even better when moved to ZP. But I have the advantage of not having done bank switching 6502 programs before, so I have no fixed view on how this could or should work. The interface to VERA is logical and easy to work with. I'm especially fond of the auto increment/decrement feature, making it possible to do really fast writes to the memory in VERA. And there's a lot of RAM and ROM, making it possible to do things never imagined on 8 bit computers. I think it really is a dream to program.
  40. 2 points
    There is a set of vectors that various I/O routines use, between the hardware stack at $01xx and the Golden RAM at $0400-$07FF. As I did not previously know of these vectors, I went hunting and found this... I believe that the Commodore 64 vectors are as follows (and Commander X16 seems to be the same): $0314-$0315 788-789 Execution address of interrupt service routine. Default: $EA31. $0316-$0317 790-791 Execution address of BRK service routine. Default: $FE66. $0318-$0319 792-793 Execution address of non-maskable interrupt service routine. Default: $FE47. $031A-$031B 794-795 Execution address of OPEN, routine opening files. Default: $F34A. $031C-$031D 796-797 Execution address of CLOSE, routine closing files. Default: $F291. $031E-$031F 798-799 Execution address of CHKIN, routine defining file as default input. Default: $F20E. $0320-$0321 800-801 Execution address of CHKOUT, routine defining file as default output. Default: $F250. $0322-$0323 802-803 Execution address of CLRCHN, routine initializating input/output. Default: $F333. $0324-$0325 804-805 Execution address of CHRIN, data input routine, except for keyboard and RS232 input. Default: $F157. $0326-$0327 806-807 Execution address of CHROUT, general purpose data output routine. Default: $F1CA. $0328-$0329 808-809 Execution address of STOP, routine checking the status of Stop key indicator, at memory address $0091. Default: $F6ED. $032A-$032B 810-811 Execution address of GETIN, general purpose data input routine. Default: $F13E. $032C-$032D 812-813 Execution address of CLALL, routine initializing input/output and clearing all file assignment tables. Default: $F32F. $032E-$032F 814-815 Unused. Default: $FE66. $0330-$0331 816-817 Execution address of LOAD, routine loading files. Default: $F4A5. $0332-$0333 818-819 Execution address of SAVE, routine saving files. Default: $F5ED. Information taken from https://sta.c64.org/cbm64mem.html
  41. 2 points
    Worked a bit more on my attempt at a file-based assembler. Basic assembler functionality more or less done, it can more or less assemble a raw disassembly now. No labels, symbols or other things yet I also ran it on a 8200 lines long disassembly dump of the Commander X16 ROM region of $c000-$ffff (16 KB) and it took about 12 seconds to assemble that (into memory). Half of that time is spent just loading the source code from disk... and we're not yet writing the result to a new file so that would probably add about six seconds more... adding labels and symbols functionality will require re-reading the source file at least one extra pass so that adds six seconds once again. A disk-to-disk assembler will be pretty slow compared to an in-memory assembler... For now it's still an example that's part of the Prog8 compiler repository so the source is here https://github.com/irmen/prog8/blob/master/examples/cx16/assembler/assem.p8
  42. 2 points

    Version 1.1.0

    17 downloads

    Usage Because of its simplicity the library can be stored in a 1K space below basic programs, starting at $0400. Save the EFFECTS.PRG program in the directory where your BASIC program is stored, which would typically be in the same directory from where you are running the emulator. Load library with LOAD command: LOAD”EFFECTS.PRG”,8,1,$0400 Since this routine after the first run adds a new interrupt handler it is good practice to only load it once. It is therefore recommended to do a simple check: IF PEEK($400)=0 THEN LOAD”EFFECTS.PRG”,8,1,$0400 And that is it. Now you only need to call the needed sound effect from the BASIC program with a simple SYS command. We have four different effects so four different addresses can be called: SYS $400 PING Is designed for events like picking coins or rewards. SYS $403 SHOOT Effect that can be used for shooting the gun or other weapon. SYS $406 ZAP Electricity zapping or perhaps a laser gun sound. SYS $409 EXPLODE Long explosion for when we successfully blow something up Alternative binary named EFFECTSHI.PRG that loads into memory at $9000 can be downloaded. Of course calls are then $9000 for PING, $9003 for SHOOT, $9006 for ZAP and $9009 for EXPLODE. Full source code and walk through is available at my blog: https://www.8bitcoding.com/p/simplest-sound-effects-library-for.html Demo video:
  43. 2 points
    I subscribed. Just doing my part!
  44. 2 points
    Your YouTube tutorials are great Matt! I've always wanted to learn assembly, and this has been a really fun way to get started. I can't wait to run my creations on the real hardware.
  45. 2 points
    Funny.... following your thread, I landed on the wikipedia page. And reading it, I stumble upon this: Sounds like there's a touch of 9918 in VERA
  46. 2 points

    Version 1.0.0

    14 downloads

    A small intro/demo type thingy as the result of me trying to "dust off" and re-learn some 30 year old assembly. This took most of my Christmas break. Starting out I was really stumped by some of the VERA stuff: The registers, the layers, loading data, 4bpp colors, high bit addressing. But, eventually it started to make sense a bit. All this would have been impossible for me without the very helpful blogs at https://www.8bitcoding.com/ and https://justinbaldock.wordpress.com/category/retrocomputing/commander-x16/. The Vera Graphics Convertor was also very useful. I used KickAssembler for the code. I've uploaded the .asm file as well, just in case it's useful for anyone else learning this stuff. dust.asm
  47. 1 point

    Version 1.0.0

    1 download

    A simple game fully in Basic. This is a very little game I wrote on the commodore 64 ages ago, I changed it a little to work with vpeek, vpoke, the new color command, and the new screen resolution. To me starting with a simple game in basic is how I learned about the c64, and now the X16, before jumping in machine language. In the code for this game you can see practical examples, on how to set characters on the screen, read characters from the screen, change colors for characters, listen to the keyboard, set a screen mode. What surprised me was that I needed a delay in the code in order to have it not run too fast. This was not the case on the c64. I really like the way you can use the emulator in the browser, as it allows you to type in basic inside the browser, using "regular key mappings", and the run it. When I wanted to save it, I copy-pasted it into the installed emulator (hats off for who added he paste function there), and types the save command. This was done, because in the browser you cannot save it, and see it on disk (as far as I know) I added many REMs in the code, in order so it can be understood, and it is more of a tutorial, then a "real" game. Below I will go through the code. From line 5, the program initializes From line 9, the title screen is drawn From line 49, the game is initialized From line 199, the game loop starts From line 300, the game over screen is drawn Some miscelanious notes: The SCREEN command is used to set the screen in text mode (Petscii) 40x30 The color command is used to set character fore and background colors. Unlike the c64 each char has its own background color. There is no "global" background color CHR$(113) is used to draw the Petscii circle character, used on the title screen. Adding the actual character into the code listing, makes it hard to edit outside the emulator. CHR$(119) is another Petscii character VPOKE 0,0,x, pokes a character on the top level corner of the screen. So the text screen address = 0 (not like on the C64) On line 52 the bottom of the screen offset is calulated. NOTE: Even though the screen is 40 chars long, to get to VPOKE address of the next line, you need to add 256 bytes. SI and PI (StoneImage and PlayerImage) are Petsci chars, that are used in the game. NOTE: Petscii chars have different values in the PRINT or the VPOKE commands. Reminder: In C64/Microsoft basic a variable name is only two characters long max. Reminder: Lines in Basic should not be longer then 80 chars. When you make them longer, the emulator ignores them. A good place to see all PETSCII character codes is here: https://www.commanderx16.com/forum/index.php?/files/file/23-vera-chars/ Have fun! And the code itself: (it is easier to copy paste it in the browsers emulator and be able to modify it more easy here: https://www.commanderx16.com/emulator/x16emu.html ----- code below for copy past----- 5 REM SET TO 40X30 CHARS SCREEN 6 SCREEN 0 7 HM$=CHR$(19) 9 REM TITLE SCREEN ----------------- 10 REM SET COLORS TO BLACK AND WHITE, CLEAR SCREEN 11 COLOR 1,0: CLS 12 PRINT:PRINT:PRINT:PRINT : REM PRINT TITLE 13 PRINT " FALLING SNAKE": PRINT: COLOR 15 14 PRINT " YOU ARE FALLING DOWN A HOLE" 15 PRINT " AVOID ALL OBSTACLES" 16 COLOR 7: PRINT " PRESS SPACE TO START" 17 BA$=CHR$(113):BB$=CHR$(119) : REM BALL SYMBOLS 18 COLOR 2,0 : PRINT " "+BA$ 19 PRINT " "+BA$:PRINT " "+BA$ 20 PRINT " "+BA$+BA$+BA$+BA$+BA$+BA$+BA$+BA$+BA$;:COLOR 8:PRINT BB$ 25 GET A$: IF A$="" GOTO 25 : REM WAIT FOR KEY 35 TS=0 : REM SET TOP SCORE 49 REM START GAME ----------------- 50 COLOR 1,0: CLS 51 FOR T=1TO29:PRINT:NEXT 52 BO=29*256:SI=42: : REM BOTTOMSCREENOFFSET, STONEIMAGE 53 PO=15*256:PI=81:PC=2:PX=20 : REM PLAYEROFFSET, PLAYERIMAGE, PLAYERCOLOR 54 DE=1000 : REM DELAY VALUE 55 S=0 : REM SET SCORE 199 REM GAME LOOP ----------------- 200 GET A$ 201 IF A$=CHR$(29) AND PX<40 THEN PX=PX+1 : REM GO RIGHT 202 IF A$=CHR$(157) AND PX>0 THEN PX=PX-1: REM GO LEFT 210 X=INT(RND(1)*40)*2: C=INT(RND(1)*15)+1 : REM GET RANDOM STONE POSITION 211 PE=VPEEK( 0, PO+(PX*2)) 212 IF PE=SI THEN GOTO 400 220 VPOKE 0, BO+X, SI: VPOKE 0, BO+X+1, C 221 VPOKE 0, PO+(PX*2), PI: VPOKE 0, PO+(PX*2)+1, PC 296 FOR W=1 TO DE: NEXT : REM DELAY, SLOW DOWN CODE 297 PRINT : S=S+1 : DE=DE-1 : IF DE<0 THEN DE=0 298 GOTO 200 399 REM GAME OVER ----------------- 400 IF S>TS THEN TS=S 401 PRINT HM$:PRINT:PRINT:PRINT " GAME OVER": PRINT 402 PRINT " SCORE: "+STR$(S); 405 PRINT " TOP SCORE="+STR$(TS) 410 COLOR 7: PRINT: PRINT " PRESS SPACE TRY AGAIN" : PRINT:PRINT 420 GET A$ 421 IF A$ = "" OR A$=CHR$(29) OR A$=CHR$(157) THEN GOTO 420 422 GOTO 50
  48. 1 point
    Waoo ! That seems very very promising ! I'll give it a try. Meanwhile, I was a bit curious looking at the source code you showed in the first post so I went to read the doc Quick remarks: - The high low operator. Pretty obvious when you're in asm. In C, it looks really weird. Not to mention your highlighter didn't recognize it. I would rather go with the same kind of logic you're using for string with a postfix modifier. addr.H and addr.L or simply an explicit HIGH(addr) - The floating point type Could you have a placeholder type like float and some pre defined functions ? Therefore the compiler would be able to compile those. The only thing is to add the library for the target system - function calls Is there a way to tell how the parms have to be passed (thru registers, thru stack....)? I didn't see anything on that matter. - inline kickasm code: Absolutely brilliant !! Congratulations, Sir. ps: any chance we have at some point other targets.... like the apple // ?
  49. 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.
  50. 1 point
    Expansion hardware is a great point. I still think between all the options discussed across the forums that one of them will stick So I have to imagine we'll have some sort of file copy solution - other than Sneaker Net. I'm just not sure which one. I would imagine the simplest one will be the first one that works (and that sounds like some sort of user port solution is my guess - or perhaps the IEC port). I think I'd be less bothered by SD cards if they weren't so small and were more purpose made for frequent insertion and removal. Something between an SD card and 3.5" would have been nice, with slots intentionally made for the purpose. Micro-SDs are even worse - I've lost several already behind my desk and that's where they're staying. I have to swap SD cards between devices several times a week and it ends up being a pretty big annoyance for me and they definitely do wear (both the SD cards and the readers) if you swap cards a lot.
×
×
  • Create New...

Important Information

Please review our Terms of Use