Jump to content


Popular Content

Showing content with the highest reputation since 07/14/20 in all areas

  1. 14 points
    I’m not posting this as an official update announcement as it’s not finished but wanted to whet your appetites. Also big shoutout to @Michael Steil and @Frank van den Hoef. Frank wrote the main driver which was way faster and more complete than the old one and Micheal extended its functionality. The next emulator release has major improvements to the DOS for the SD card filesystem. The main ones are: A lot of progress has been made with the X16 DOS. It's almost feature complete, and almost has feature parity with CMD floppy and hard drives. • Long filename support • You can open files for reading (OPEN2,8,2,"FILE") or for writing (OPEN2,8,2,"FILE,P,W"), read and write data, have four of them open at the same time, etc. etc. • Overwriting files is done with "@:". • You can copy files (DOS"C:BACKUP=ORIGINAL"), concatenate files (DOS"C:ALL=FILE*"), all with wildcards. • You can rename files (DOS"C:NEW=OLD"). • You can delete files (DOS"S:R*,Q*"). • You can lock/unlock files (DOS"L:R*" or DOS"F-L:R*"/DOS"F-U:R*"). • Like on CMD devices, create directories (DOS"MD:DIR), delete them (DOS"RD:DIR), change them (DOS"CD:DIR). • You can use paths everywhere (DOS"C//BACKUP/:FILE.TXT=FILE.TXT", DOS"$//BACKUP/:A*") • All commands and paths support drive/media numbers (DOS"$1:*"), but only 0 (current) and 1 (only supported partition) work. • You can get partitioning info (DOS"GP"+CHR$(1)) like on CMD hard disks. • You can even read/write DOS memory and execute code in a DOS context (M-R, M-W, M-E). Yeah, not that useful. • All error messages on the status channel (just type "DOS") are consistent with 1541/1571/CMD drives, e.g. 01, FILES SCRATCHED,05,00 etc. What's missing: • Open file for appending (,P,A). • Show/change disk name. • mkfs (N) • fsck (`V') • timestamp support What's missing that I'm not sure should be added: • REL files • block read/write API Sent from my iPhone using Tapatalk
  2. 14 points
    Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
  3. 8 points
    A bit late to the party, glad to see the forums live! So I hope this is the official post advertising Aloevera! Marketing spiel follows: Aloevera is a command-line tool that facilitates the development of graphical assets for use with the Commander X16. In a nutshell, Aloevera transforms images created with modern editors into formats that can be directly imported into your X16 development project. It aims to be a simple, easily integrated tool that: Outputs resources in a variety of formats ready to include or import into your X16 project, including: CA65-Compatible Assembly Statements (Which should also work in any assembler that supports a .BYTE statement) CC65 Header files BASIC DATA Statements .BIN Files (for use with the VLOAD Command) Assists your resource creation pipeline by validating your input data and ensuring that your source images match the format expected by your target VERA layer mode. Provides helpful information to help you fix problems when your image data cannot be translated into the format expected by VERA Gives you complete control of how and where assets are exported, allowing you to build a shippable 'Release' image Integrates into your preferred build system or development process as a simple command-line tool with minimal overhead. Supports all VERA modes and types, including: Text Tilesets Tilemaps Sprites Bitmaps There's also a usage guide that I hope serves as a half-decent introduction to VERA coding: https://github.com/yeastplume/aloevera/tree/master/docs Thanks everyone! I hope Aloevera can become the go-to tool for X16 projects. And if you're at all interested, I'm always looking for people to help with the effort. PRs very welcome!
  4. 7 points
    Thanks for the help guys. I was totally oblivious of the discussion going on here. I did notice yesterday that Try It button was not there and saw it is there now and working perfectly but had no idea what was happening in the background Of course I uploaded it late yesterday and today I was totally under water with work so that is my excuse. Next time I will make sure to upload BASIC encoded files. Cheers, Dusan
  5. 6 points
    You both have some good points, but just to repeat what has been said before, and is posted in the rules at the top of the main forum page: So as of now, we're not discussing open sourcing or ports to other machines. Our machine isn't even out yet. So let's save this discussion for a later time eh? 🕹
  6. 6 points
    On the real hardware, there will be a way to reprogram the FPGA image if necessary to fix any bugs that are discovered after release. (This involves putting a jumper on the VERA board to enable access to the flash chip from the CPU.) So yes, if you would like to hack around you can, it is (will be) your hardware. Also the FPGA does have a feature where it can store up to 4 FPGA images in the flash chip, which could be nice for hardware hackers to allow the original image to be present in addition to their own creations. Do note, that this will not be officially supported and normally users are expected to run original firmware. So if you mess up, it is on you.
  7. 6 points
    If like me you were a kid in the UK in the late 70's or early 80's there is a good chance you had some of the Usborne computer books, These are now free as pdf's on their website for that full on retro experience! Later today I will try typing a few in to the x16 emulator. https://usborne.com/browse-books/features/computer-and-coding-books/
  8. 6 points
    Hi all, I'm going to have to come up with a title for this project sooner rather than later.... Made good headway on coding up the different hex graphics on layer 1. I've done 8 different terrain types so far (sea, lake, beach, scrubs, meadow, pasture, orchard and cave) - there'll be 32 different types in the finished game. Pixel graphics is not one of my strong points, but hopefully it should be obvious which is which! I've finished the hex terrain text descriptions and written and debugged the scrolling routine that scrolls the message window as you move from tile to tile. It counts lines scrolled and if there's more than a window's worth of text to scroll all at once, it brings up a "Scroll..." prompt and waits for the user to press the enter key before continuing to scroll. The assembly for it runs so blinking fast, I had to write a delay subroutine that gets called inbetween each character being drawn so you can actually see the text scrolling, otherwise it looks like all the text just appears on the screen at the same time. (ignore the drawing glitch going on at the far left hand edge of the hex window, next thing on my list of things to fix!) Suddenly it's beginning to look more like an actual game now! ta ta for now
  9. 5 points
    It's not the color that gets me. It's not the features like the expansion slots, VGA out, IEC interface, or the SNES adapters. Apologies to Frank, but it's not VERA either (although it is supercool). It's not even the sockets. It's that there's a 65C02 there, and a straightforward but clever banked memory map, on no-fuss static RAM, and it's going to run an ancient (albeit upgraded) Commodore KERNAL. That's what gets me. That, and maybe the SD slot. But I like all the other stuff too of course.
  10. 5 points
    And for security reasons I've added a whitelist option to our server code that only allows certain extensions. Don't want someone to upload a .php file that can then be run straight from the server, right? So we're super doubly careful about extensions. BIN for all loadable assets is something I fully support.
  11. 5 points
    Eventually probably yes. But don't expect this until the system has been released and on the market for some while.
  12. 5 points
    For those not familiar, Nox Archaist is a game by 6502 Workshop which they've funded via a Kickstarter campaign. It's a throwback to the original Ultima games, and they even have the support of Richard Garriott (Lord British). Anyway, development appears to be coming along reasonably well and they're in the debugging phase. I pinged them on Kickstarter, to see if once the original Apple ][ release is completed, they'd consider porting it to the Commander X16. -Kevin
  13. 5 points
    Hello everyone! I live in Kalmar, in the southeastern part of Sweden. As a kid I dreamed of making my own C64 games in assembly code. But I didn’t really get anywhere. I found it hard to learn the language, lacked the necessary books and had noone to ask. With the CX16 it feels like I’ve got a new chance to fulfill my dreams. It sounds a bit silly, I know. I am a minister in the Swedish Church and I can truly say that there are few people I know that understand and appreciate retro computers. Actually there are quite few people interested in computers at all. Therefore I really appreciate this community, it is inspiring and motivating, and I have got help more than once from some of you knowledgeable and helpful experts : ). I hope that I can - at least in the long run - contribute with some software. Programming is really fun but I have sometimes hard to find the time for it. Keep watch for Rally Speedway 2020 this fall though, I hope for at least v 0.5...
  14. 5 points
    Update : I rewrote the parser in assembly (I admit it was way harder than with Millfork) but it's not only that. On my way to learn how the X16 works, I found out I didn't though about IRQs as a possible solution to my previous question. So what I did is write a custom IRQ routine that runs before the Kernal's own subroutine. What this routine do is find out when the cursor has changed its line and parses the potential code found in the cursor's old position. It ignores the line if it's not starting by a number. With that, the program is even lighter than the previous one, from around 200 bytes ! Internally, the program insert the classic BASIC program SYS command but also a second command "NEW" so that you can start writing your basic code directly after running the program. The main code is located at address $8000 so you have some space to write your basic program. Here's the prg file : highlight.prg The source code consist of few files so I will post a zip file containing them. don't mind the weird tree it's mainly because my programs shares the same libraries. basic_highlight_src.zip I didn't have tested everything so maybe there are bugs that I don't have found yet. Feel free to report anything you found while testing Again, thanks for reading !
  15. 5 points
    In addition to the absolute limit of 128 sprites on screen, there is a per-line sprite limit as well, which is roughly "the total width of the sprites attempting to draw on a line may not exceed 640 pixels", but not exactly. The exact definition is much more complicated: The VERA will process at most 801 "work units" of sprite data per line, after which it stops trying to draw sprites on that line. Each sprite is 1 work unit. Each time a sprite fetches 32 bits of color data is 1 work unit. Each pixel attempted to draw to the screen is 1 work unit. From some code inspection of this, the emulator may have a bug that's counting every 4 pixels as "fetching 32 bits" regardless of the sprite's color depth.
  16. 5 points
    Look what Lego are about to release...
  17. 4 points
    Hi all, Software engineer from Massachusetts here I've been a fan of 8-bit Guy and following the X16 for a while now. I first became interested in computers after my uncle showed me a simple C64 BASIC program when I was 8 and I loved the idea that giving commands to a computer could be so simple. Back then I never got further than learning BASIC, but since I started digging in to the X16 and all the various software out there I've learned a lot about 6502 assembly and the underpinnings of how the kernel works. I'm really excited to see where the X16 goes and what people make for it! Maybe I'll even work on a few things myself .
  18. 4 points
    Just finished going through Ben Eater's whole series on the 65C02 Breadboard computer. I am totally going to get his kits to make one. I find it so cool that it uses the 65C02, the same that will be in the X16! P.S. hope this is the right non-X16 forum if not please let me know
  19. 4 points
    Color Sketch (COLORSKETCH) View File When used with keyboard or SNES game-pad controls the COLORSKETCH application is somewhat analogous to an "Etch-A-Sketch" device but with support for assigning colors to the pen and toggling the pen state "on/off". When used with mouse controls COLORSKETCH is more akin to a primitive drawing/painting program. COLORSKETCH supports a resolution of 320x240 pixels at 8-bit color and is currently compatible with revision R37 of the Commander X16 emulator. COLORSKETCH also provides the ability to edit the RGB values of the color palette (except for color index 0 which corresponds to transparent). COLORSKETCH supports two primary modes of operation including sketch mode and color selection mode which are described below. Sketch Mode: In sketch mode the space bar toggles the "on/off" state of the pen which defaults to "off" when COLORSKETCH is started. When the pen state is "off" a pointer appears on the screen to show the current location of the cursor. When the pen state is toggled "on" the cursor pointer is turned off and the pixel at the current cursor location is populated with the currently selected color. The Arrow keys (and also "WSAD" keys) are used to move the cursor vertically and horizontally between pixels, and the "QEZX" keys are used to move diagonally between pixels. When the pen state is "on" the currently selected color is populated in all pixels visited as the cursor is moved. In sketch mode the "B" key may be used to toggle the pen between the layer 0 background color (which is selected at startup as described further below) and the currently selected color. This capability is intended as a means to quickly address/erase mistakes. In sketch mode the "F1" key may be used to toggle the display of the cursor coordinates between the top left of the screen (which is the default when COLORSKETCH is started), top right of the screen, and off. In sketch mode the "F3" and "F4" keys may also be used to cycle the layer 1 foreground and background colors used for the display of the cursor coordinates mentioned above and in the color selection mode menu described below. The layer 1 foreground color also affects the color of the cursor pointer described above. The layer 1 foreground and background colors can be set to any of the first 16 entries in the color palette except the layer 1 background color can not be set to index 0 (which corresponds to transparent). The "C" key is used to enter color selection mode which is described below. Color Selection Mode: In color selection mode the color palette is organized into 16 rows where each row contains 16 colors, and only a single row of the color palette is displayed at the top of the screen. The left and right arrow keys (and also "A/D" keys) are used to move between colors in the same row, and the up/down arrow keys (and also "W/S" keys) are used to move between rows of the color palette. The currently selected color is underlined and the left side of the color selection mode screen displays information including the color index and the RGB values of the currently selected color. The RGB values of the currently selected color may be edited using the "R/r", "G/g", and "B/b" keys (except the transparent color associated with index 0). The "0" key may be used to navigate directly to the first entry in the color palette (with index 0). When the Enter key is pressed the currently selected color is assigned to the pen and color selection mode is exited transferring control back to sketch mode described above. Color selection mode may also be exited by pressing the "Q" key which retains any changes made to the color palette but does not affect the currently selected color. Sketch Mode Background Color: When COLORSKETCH is started it initially enters color selection mode described above to select a layer 0 background color for sketch mode which defaults to index 0 which corresponds to transparent. Controller Support: COLORSKETCH supports the SNES controller when the emulator is started with the "-joy1 SNES" option. The D-pad is supported in color selection mode as well as sketch mode. When attempting to draw a diagonal line in sketch mode many times one of the D-pad controls activates before the other one. To address this issue the right or left bumper may be depressed and held down and then the up or down D-pad control may be depressed in order to draw a diagonal line. In sketch mode the SNES controller "A" button is used to toggle the pen state "on/off", the "B" button is used to toggle between the layer 0 background color and the currently selected color, and the "X" button may be used to enter color selection mode. In color selection mode the "Y" button is used to return to sketch mode. Mouse Support: I haven't found mouse support to be particularly smooth or reliable in the Commander X16 emulator at this point so COLORSKETCH provides the ability to toggle the mouse "on/off" with the "M" key. The mouse defaults to "off". When the mouse is turned "on" the left mouse button is used to control the pen. In mouse mode the cursor is always visible. When using the mouse to draw (with the left mouse button depressed) it is advisable to move the mouse slowly in order to color all pixels visited by the mouse. The mouse is only used in sketch mode and is disabled in color selection mode both of which are described above. At times the mouse seems to be restricted to a subset of the Commander X16 emulator screen and in this case sometimes the problem can be resolved by moving the mouse all the way to the left, right, top, and bottom sides of the entire monitor screen and then moving the mouse back into the window associated with the Commander X16 emulator. The cursor and SNES game pad controls provide more precise control than mouse controls. For example the cursor and SNES game pad controls can be used to draw perfectly horizontal, vertical, and diagonal lines. The option to display cursor coordinates also provides the ability to achieve exactness with respect to the placement and dimensions of drawn objects. It's desirable to add support for saving/loading of the sketch and color palette data to/from disk files but unfortunately Revision R37 of the Commander X16 emulator doesn't support file input/output to disk. Submitter CX16UserSteveC Submitted 08/08/20 Category Graphics Apps  
  20. 4 points
    I found out about this awesome new project and Platform via 8-bit guys videos. I would love to see a new "modern" 8-bit computer coming to live and to have one in my Men/Kids Room .. I am a child of the 80s area where I owned (or should I better say my parrents got me) a Schneider CPC (Amstrad) with a nice Z80 CPU and a pretty good computer around it. Many of my friends had a C64 and I also nowadays own a C64 breadbin and worked a lot on it (hardware wise). I am now into learning 6502 machine language (better said assembler) currently on the 6510 of the C64. However most of it will be reusable - the system calls and all of the C64 will be somehow as well. I am in real hope to get away from the poor graphics mode of the C64. It had sprites, yes, but the screen mode is so awkward setup for me. As I said I learned on the CPC and the screen was just a 16k memory area where you could do whatever you want. So memory was just a very simple representation of the lines on the screens. The calculation of lines was very easy and not organized in characters or anything alike. So anyhow does not matter. Now I will dive into all available details on the X16 and cannot really await when it is getting released as a real hardware platform.
  21. 4 points
    Remember, you can always use BIT instead of AND if you want to keep the original value in the accumulator.
  22. 4 points
    The line counter is active at all times. The (9-bit) line counter is increment by 1 in progressive mode, and by 2 in interlaced mode. In progressive mode a line IRQ is produced when the 9-bit line number matches the 9-bit line irq register. In interlaced mode a line IRQ is produced when the upper 8-bits of the 9-bit line number matches the upper 8-bit of the line irq register. The video timing has the active portion at 0-479, then 10 lines of front porch, 2 lines of v-sync and 33 lines of back porch, for a total of 525 lines. Rendering is started one line earlier, so at line 524. Composing the outputs of the renderers (2 layer renderers and 1 sprite renderer) is performed while outputting the pixel data. Eg. the line buffers rendered at line 524 are displayed (and composed) on line 0. Hope this helps.
  23. 4 points
    Hi, This will do the trick (this is for loading / executing to 32768 and your code in yourfile.asm) cl65 -t cx16 --start-addr 32768 yourfile.asm -C cx16-asm.cfg Stefan
  24. 4 points
    Those standard extensions should be working.
  25. 4 points
    This might be something the X16 becomes part of down the line. Quoting TRSE post: Turbo Rascal Syntax Error (TRSE) is a modern and complete IDE, compiler and toolshop for game/demo development for the Commodore 64, VIC-20, NES, Gameboy, PLUS/4, C128, PET, Atari 2600, TIKI-100, Amiga 500, Atari ST (520), and old-school MS-DOS (CGA). With over 250 tutorials from 42 sample projects spanning 12 systems, an image/level/sprite/resource editor, help text and extensive documentation and a fast compiler, TRSE currently enables extremely rapid prototyping and development of 8 and 16 bit software for the 6502, m68K, z80 and x86 line of computers. TRSE also contains fully programmable real-time ray tracer (using LUA) that exports (raw/compressed) image data to C64/Amiga formats. TRSE also contain example projects for demo and game development, both on the C64, the VIC-20, Gameboy and the NES. Try out TRSE today! Promo video (0.08) : https://www.youtube.com/watch?v=H3FQDnNP2m0 Promo video (0.09) : https://www.youtube.com/watch?v=xT-8cyqTbnE TRSE showcase list: https://lemonspawn.com/gallery_/ Get your fresh copy now (win/macos/linux) from http://www.turborascal.com Join the TRSE development group on facebook : https://www.facebook.com/groups/742955836046459/ C64 demo (1st at Flashparty 2020) made with TRSE: https://www.youtube.com/watch?v=IBQmXOSjVAc Gameboy demo (2nd at Solskogen 2020) made with TRSE: https://www.youtube.com/watch?v=2jY4wqkSxBs Amiga demo placed 1st at Revision 2020 with 1 effect (twister) written in TRSE : https://www.youtube.com/watch?v=6sFuvx8Sbao C64 demo written in TRSE : https://www.youtube.com/watch?v=RH39q_Vs4rc VIC-20 demo written in TRSE: https://www.youtube.com/watch?v=KmaK8ru2pz8 OK64 demo written in TRSE : https://www.youtube.com/watch?v=BqIxwTUWUh0
  26. 4 points
    Hi all, Im Diego from Miami. long time follower of the 8-bit guy. i'm an 80s kid so commodore computers were part of my childhood and youth. cannot way to see this computer finished and selling. will definitely get one.
  27. 4 points
    1. If the horizontal pixel counter equals DC_START the output will be enabled, at DC_STOP it will be disabled. So if DC_START is bigger than DC_STOP, DC_STOP is basically ignored and the image will be displayed up to the end of the line. 2. Sprites are rendered in order of their index, so higher index sprites will be rendered in front of lower index sprites, except when it has a lower Z-value. No garbage will occur. 3. On the real hardware, the noise generation is done using a LFSR. It could be emulated, but I think the rand is doing a quite similar job.
  28. 4 points
    Sprite Editor View File Commander X16 Sprite Editor This is a screen snapshot and the executable file of a Commander X16 Sprite Editor which is built from "C" source files I’ve been developing that currently runs on Release 37 of the emulator. Features The sprite editor supports all combinations of sprite height and width dimensions up to 64x64. The sprite editor is currently limited to 4 color bits per pixel, but provides the ability to edit the RGB values of the first 16 entries of the color palette. The sprite editor supports a pen mode which reduces the keystrokes required to assign colors to sprite pixels, and the ability to shift the design of the sprite to make more room near the edge of the sprite. The sprite editor provides the ability to export color palette data as well as sprite data to the terminal in a BASIC program format and also in a format more amenable to importing into a C program. The BASIC program allows the sprite to be rendered and moved around a bit using the W/A/S/D keys. This export capability requires the -echo option when starting the emulator. Operation Cursor Movement The arrow keys are used to move the cursor around the sprite pixel edit grid. When width=64 the edit grid can be paged left and right using the less-than and greater-than keys ("<" and ">"), and when height=64 the edit grid can be paged up and down using the comma and period keys ("," and "."). Assigning Colors to Sprite Pixels The 0-9/A-F keys are used to assign a color to the sprite bit corresponding to the current edit grid cursor position. When pen mode is turned on using the P key, the color at the current edit grid cursor position is assigned to the pen, and this color is automatically assigned to pixels as the edit cursor is moved. The pen color can be changed by selecting a new color via the 0-9/A-F keys. Pen mode is manually turned off by pressing the P key a second time, and is automatically turned off when the cursor is moved past the edge of the edit grid and when the edit grid is paged when height=64 or width=64. The fill command (F5 key) fills the entire sprite with the color at the current edit grid cursor position. RGB Edit Mode RGB edit mode provides the ability to edit the RGB values of the first 16 entries of the color palette. RGB edit mode is entered and exited by pressing the F6 key. In RGB edit mode, a right arrow appears to the left of the selected color, and selected color is changed by using the up/down cursor keys. The red, green, and blue components of the selected color are changed by using the R/shift-R, G/shift-G, and B/shift-B keys. Sprite Design Shifting The sprite design can be shifted up or down one pixel row using the U and shift-U keys, and can be shifted right or left one pixel column using the R and shift-R keys. This feature is useful when a sprite design is not centered correctly when started and one runs out of space near an edge. The sprite design can be shifted to make more room near the edge which avoids having to start the sprite design over again at a new location. Sprite Options V-flip and H-flip (V and H keys) affect the display of the actual sprite but not the sprite edit grid. The palette offset (+/- keys) also only affects the display of the actual sprite (the edit grid colors and remainder of the screen colors are not affected). Screen Options The BG and FG options (F3 and F4 keys) provide the ability to change the screen background color and the color of the text on the screen. There's an anomaly associated with color 0 which is black in the standard color palette. Color 0 is shown as black on the screen and edit grid but is transparent when used in sprites, so the edit grid doesn't match the sprite with respect to color 0. Exported BASIC Program The exported BASIC program between line 10 and the DATA statements is constant. Line 10 varies with the height and width of the sprite and the DATA statements vary with the color palette data and design of the sprite. The SA7 value is based on the enumerated values of the height and width dimensions (0 for 8, 1 for 16, 2 for 32, and 3 for 64) and places these values into the proper position to be populated in the most significant nibble of the last sprite attribute register which has an offset of 7. The least significant nibble of this register is the palette offset which I assumed to be 0. The SA7 value is computed in the C program, but it could have been computed in the BASIC program since the enumerated values can be determined from the height and width which are exported on line 10 and palette offset is assumed to be 0. I deferred support for saving/loading palette and sprite data because I'm under the impression the emulator currently doesn't support file I/O, but the BASIC program provides a near-term workaround. The palette and sprite data exported in the BASIC program format can be reloaded into the sprite editor via the following steps: (1) start the emulator using the -echo option; (2) paste the BASIC program into the emulator; (3) execute the RUN command; (4) push the Esc key to quit the running program; (5) execute the NEW command; (6) load the sprite editor; and (7) execute the RUN command. The sprite editor will then pick up the palette data that was loaded into the color palette and sprite data that was loaded into the VERA sprite attribute registers and VRAM by the BASIC program. The following two steps are an alternative to step (2) above: (2a) paste the BASIC program into a text file; and (2b) use the emulator -bas option to load the program from the text file when starting the emulator. This alternative approach is recommended if you're having problems with the emulator corrupting lines when pasting the BASIC program directly into the emulator. The palette and sprite data are automatically exported when exiting the sprite editor to avoid accidental loss of data. The exported data can be recovered before reloading and restarting the sprite editor as described above. Potential Future Enhancements I'm considering enhancements including support for 8 color bits per pixel, saving/loading of palette and sprite data, rotation of sprites, and undo/redo of changes to the sprite graphics data in VRAM. Submitter CX16UserSteveC Submitted 07/24/20 Category Graphics Apps  
  29. 4 points
    The previous board design wired the extra address lines in the High RAM to a port in a VIA interface chip. That's the register address of that port. There are eight sets of I/O register addresses at $9F00, $9F20, ... $9FE0, so $9F61 was the $01 register address in the fourth set of I/O register addresses. The new design uses dedicated latches for the extra address lines for the High RAM and Flash ROM, and writes the latches at the same time that you write to address $0000 or $0001. That change frees up one interface chip to provide a User Port.
  30. 4 points
    New version 0.7 ! Now there is a title screen with music! It doesn't play too well in the web emulator, at least with my laptop. It's fine with the native emulator (on Windows 10). Can anyone try? If it's not playing on the "tryout" web emulator, I'll disable the intro music by default and upload a new version. I'm pretty pumped that I managed to play music - and to find a royalty free VGM file. Thanks to Meits (www.meits.nl) the composer.
  31. 4 points
    Fortunately, it wasn't too bad to figure out how to update it. Try this code, instead: Edit: As an experiment, I'm going to try a copy-paste and see if something works... Edit: It did! Huzzah, I think I know how I'm going to sneak preformatted, colorized code into comments in the future.
  32. 4 points
    I want to plug a new Youtube channel called Coding Secrets, done by Jon Burton of the Traveller's Tales videogame studio. He's worked on quite a few games over a career that dates back to the Sega Genesis, and has put together several videos discussing how various effects were created within the very finite and unforgiving limitations of the consoles he was working on. Coding Secrets started as a series of videos on his original Youtube channel, Gamehut, itself a fascinating collection of videogame history from his career. Anyways, if you're potentially interested in retro games programming and haven't yet discovered his videos, give his channels a shot. Now's a great time, too, because he's re-exporting his Coding Secrets videos in higher-def and a higher framerate, so be sure to check back as he catches up with his back-catalog of content. Speaking for myself, this is one of my favorite videos from what's brought over to the new channel:
  33. 4 points
    Hello all. As the title says I came over from the Facebook group. I'm a longtime C64 & Amiga aficionado and I love retro-computers in general. Been following this project with great interest and can't wait until all is said and done. In short: greetings. Dan
  34. 4 points
    It's pretty cool that they're doing this at all though. I mean, would we rather have no retro Lego? BTW I'm pretty sure this is the work of Chris McVeigh. He made the mini Lego C64 that inspired my full-size Lego C64; The Brixty Four. Some time after my videos came out he was hired by Lego and moved to Denmark. I'm going to guess this was the result of that. Good for him! (My bags are packed and by the door...)
  35. 4 points
    Hello there! So the goal is to introduce ourself right? Well, here I go, I'm a french student of 20 years old and actually doing an applied physics bachelor. And I'm here because I just discovered the 8 Bit Guy like a month ago and its youtube channel fueled my pre-existing interest in retro computers (cause whats the fun with new ones really? ). I dont really own any retro computer for now because I dont have either money or space, so my oldest computer is a Toshiba 4010CDT that I use to play dos games (on floppy disks I adore those). So the idea of this commander x16 interest me as it could give me a small feel of what computing was back then, before I can get old hardware. So thats really all, I code in python and a bit in C#. Hopping to meet some of you on other topics
  36. 3 points
    Simplest Sound Effects Library for BASIC programs View File 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 EXPLODE Electricity zapping or perhaps a laser gun sound. SYS $409 ZAP 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: Submitter DusanStrakl Submitted 08/12/20 Category Dev Tools  
  37. 3 points
    Hello, I am Marcelo, and I work as a professor in the department of electronics and computing at a federal university in the border of the brazilian Pampas, but I am actually from São Paulo region. Being an enthusiastic for retro computing and the approachable learning and teaching opportunities it allows, I am looking forward to the launching of the Phase 1 X16! Please, take my money
  38. 3 points
    We're certainly thinking about that. I have been in touch with some coders for exclusive versions of well known games. We'll have to wait and see to be sure, but it's an appealing idea.
  39. 3 points
    Thankfully we don't have to delve too deeply into that subject, because the emulator is being made available, for free, and folks are welcome to contribute to it through bugfixes and improvements. I've personally had a lot of pull requests accepted by now, too, so I'm definitely speaking from personal experience contributing to the emulator. Actually, I've been thinking about starting a subject to discuss what technical shortcomings might be addressed in the emulator... for instance, the VERA is probably no longer faithfully reproducing NTSC graphics. I don't think anyone has tested line IRQs on NTSC, either. We also need some unit testing for the emulator, either prgs so we can capture the output to compare between real hardware and the emulator, or a unit testing framework in the emulator so we can run tests to compare output state of the machine with known correct examples. (Unit testing is something that @Michael Steil has directly brought up a couple of times, especially recently.) ...and this is where I blather on for 4 paragraphs about optimizing the emulator, so feel free to stop reading if you're not interested... On the performance side, I know there's interest from multiple folks to try and run the emulator on RPis. I have a brand-new RPi4, and it runs the emulator at about 40% normal speed, or 45% when the new "warp" mode is enabled (it's not in the r37 release, but it's in the github repo and will be in r38). 40-45% is a long ways from running at full speed on an RPi. Besides the VERA, which will likely always remain a pain point, it looks like there may be some gain to be had from optimizing the PS/2 emulation (comments in the code actually directly point out a couple of places where improvements could be made). Profiling with some specialized tools has also suggested that the basic CPU emulation could be sped up by around 10% if folks found ways to remove branching from various opcodes, such as when we branch between ordinary binary arithmetic and BCD arithmetic. In the the case of BCD, specifically, perhaps we could split the instructions into binary versions and BCD versions, and then alter the function call table whenever we run SED and CLD instructions, so that branching within the instruction itself is unnecessary and we only pay for the cost of flipping contexts. Or, since the memory to emulate an 8-bit machine is hardly a concern even on a meager RPi, we could just keep two instances of the entire instruction table for that case, and choose one as the "current" table. Or I'm sure there are other approaches with varying pros and cons, and I'm sure we'll discover other pain points as we play whack-a-mole with hotspots. And when it comes to the VERA, there's a lot of work it could choose to do once, and then rely on cached data to speed up the final draw process, and refactoring for that would probably open up more opportunities for multithreading (actually, I've been working in this direction, and there are lots of opportunities for multithreading when we attempt to do most of the work up-front instead of re-performing work every single line). Also, the VERA emulation makes almost no use of SDL2 functions to try and accelerate any of its tasks, so that's another avenue possibly worth exploring. And then there's sprites. Sprites are hard, and there's no two ways about that, especially if we want to emulate the VERA's work limitations with sprites. But overall, the VERA is in fairly good shape for now... it's expensive, but even turning it off (effectively what the new "warp" mode all but does) only gets us from 40% to 45%. I mean, sprites are still a major pain point even in warp mode, but that's because warp mode still calculates sprite collisions. But it's not all VERA, all the time, at least not anymore, thanks to the contributions of at least several people, and hopefully more in the future.
  40. 3 points

    Version 1.0.0


    Tetris Clone written in BASIC. Source code tutorial available at: https://www.8bitcoding.com/p/crazy-tetrominoes.html Enjoy
  41. 3 points
    I think it should also be reiterated that there is a difference between open software and system development and open source licensing. The fact is that there is no open source license for anything in the X16 project. The team has merely been open with their process and making their software repo public to better engage the community. At any point, those repos can be taken private and further development done in confidentiality. There is no legal means for people to do anything with the ROM code or emulator other than use them as intended.
  42. 3 points
    Beta version 0.2 now on GitHub, and available here for download/"Try It Now". This version supports color:
  43. 3 points
    My first real computer (not counting pocket PCs) was a C64 so I feel right at home with the X16. I started with a C64 and a cassette unit, playing ping-pong with friends while games loaded. Then I got a 1541 because it was essential for programming (and games, too!). You never forget your first computer and I really regret having sold my C64 and C128 a long while ago. I still have my Amiga 2000 that I remember buying with money I got from some C64 programs that were published in Compute’s Gazette. What an unforgettable memory to buy a magazine in the newsstand and see your name in it! I’m now a computer tech and I started by helping others in the local C64 club then I got into a self employed computer tech, making calls for the then emerging market of PCs users. Self employment is very taxing and after 10 years of it I decided to work for a local computer shop instead, with regular work shifts and free time in the weekends. I now work as a computer tech, repairing PCs in the only computer store that remains in the small town where I live. Sounds boring but I love my job and repairing came naturally. I don’t have a degree in computing or anything close, having learned it all on the spot. Recently, I’ve switched to a Mac and got back at programming with Xcode. Programming is so different now, I have some difficulties remaining interested in it with all the constantly evolving frameworks you must learn. This is why a project like the Commander X16 has got my attention: programming could be fun again with its immediate interaction, like on the C64. I miss having total control of the machine, with nothing between you and the hardware.
  44. 3 points
    The difference is that the documentation is effectively referring to emulator r38, which isn't out yet but would be up-to-date with the latest technical design decisions of the X16 if it were. Most people, on the other hand, are programming against emulator r37, where the ROM and RAM banks are selected on register $9F60 and $9F61, respectively. On real hardware and on future releases of the emulator, $00 and $01 will be correct.
  45. 3 points
    Hmm. Maybe they should be linked to in Support too. That's easy enough, without adding clutter to the menus. Edit: Done. I think that's a good compromise.
  46. 3 points
    Good question. Tom is right. You might also find this video helpful Full disclosure: It's by me Your friend in retro, Perifractic
  47. 3 points
    Hello everyone! I'm a software engineer/architect by trade, but I also occasionally write retro software in my spare time, mainly for MS-DOS era PCs. Strangely enough, I was never a Commodore user back in the day - in fact, I never even owned a C64 until I was an adult and started collecting older computers - my 8-bit PCs of choice growing up were the Atari 8-bits (specifically the 65XE) and Apple II. That being said, I'm a big fan of the idea of the principles behind the X16 - modern hardware with the ability to directly access all the hardware like old school computers - so I've been following the project closely ever since David announced it on his channel. I don't have any specific details planned out for what I want to do yet, but long term I'd like to create a little old-school roguelike - something like Angband, but stripped down enough to make it feasible on 8-bit hardware (in other words, something closer to the original Rogue). Since my 6502 assembly skills are limited to a 6502 emulator I wrote for a long-abandoned NES emulator project I toyed with and a little bit of NES dev (both nearly 20 years ago!), I'm still trying to figure my way around the hardware and software. Anyway, I'm glad the see the project is not only alive, but thriving. So many 'dream projects' never seem to gain the critical mass necessary to find their way to completion, but both the team behind the project and the community continue to deliver. I'm looking forward to the day where I can buy real X16 hardware!
  48. 3 points
    Thank you everyone for your input. I can hardly wait for this product to launch. I sold all of my Commodore equipment in 1992 to raise money to move to the other side of the US, and have had the desire to get back into it from time to time since then, especially after I started getting into other programming languages. I feel that I've shorted myself in a big way by not taking the time to master basic and machine language, coupled with a more thorough understanding of the relationship between software and hardware. This is why I enjoy listening to the 8 bit guy explain things. It makes me feel like a kid again.
  49. 3 points
    I was also thinking of writing BBS software designed specifically for the X16, but I've put that on pause while devs figure out a nice and proper way to implement serial/UART/networking and terminal software have been written for it. Which I'm pretty sure it will happen. Maybe it can interface with this forum and pull off downloads, why not. I already wrote some code before UART has been killed off in the emulator r37.
  50. 3 points
    Aha, that makes sense then. Sounds like a comfortable limit so long as you’re not lining up pathologically worst case rows of green aliens.
  • Create New...

Important Information

Please review our Terms of Use