Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/22/20 in all areas

  1. 22 points
    Please enjoy this mini update from @Kevin Williams about the second prototype. A fuller update will follow from David on YouTube soon (when we have a working prototype #3). Happy new year Commandos!
  2. 16 points
    We're not posting an official update until we have something more conclusive but just to put rest to this conversation and any speculation here, we have had some fantastic successes very recently and the machine is all but fully working. Just a few little tweaks to fix. So things are looking really great and will have a full update for you very very soon. [emoji4]
  3. 12 points
    Here is Adrian's video about the troubleshooting:
  4. 8 points
    Adrian Black is a class act. What a gracious and generous video. I have enjoyed his channel and hope he keeps producing new content for a long time. This is an important step. I hope folks in the community realize how much engineering work remains between "mostly runs on the bench" and "ready for production".
  5. 7 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"
  6. 7 points
    Part of my thinking as I’m the one who pitched the ZP banking feature to Kevin was that by making it a ZP feature it speeds up all banking operations. This includes many KERNAL functions since those are often in banked ROM, as well as user code that uses banked RAM. Admittedly in theory using ZP for VERA makes some sense for speeding up access, the added circuit complexity isn’t desirable and you have to be aware that the more memory decoding you add the more potential it has to add unwanted timing delays which could result in stability issues. On this I suppose I should clarify how the latches basically work and to do that I need to explain how the normal IO space works. So as you know there is a RAM and ROM in the base 64k memory map. By default the RAM is selected with exclusions. If the address lands in the ROM memory range the RAM is excluded and the ROM gets addressed instead. The same is true for the banked RAM range. This also applies to the IO range. This allows any of the chips in those ranges to be addressed correctly without any bus contention. However how the zero page latches work is a little bit different. The latches “shadow“ the ram. Basically the latches themselves are write only. When you write to $00 or $01 you write to RAM and the latches. The RAM is not excluded the way it is for other address ranges. When you read $00 or $01 you are reading from RAM. Now if you wanted to move VERA to zero page you would need to add exclusion logic to the RAM so that it doesn’t conflict. But every bit you add does 2 things. Firstly your part count goes up which drives up cost, but also you add propagation delays which if you get enough will cause unstable operation or non operation. Sent from my iPhone using Tapatalk
  7. 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.
  8. 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
  9. 6 points
    I think you misunderstood me you can read them technically the value stored in RAM and the value stored in the registers should always be the same. The only exception is during initial power up the ram might contain random values but is soon as the post rouroutine writes the bank it will immediately be updated and match. There is no condition once it is set where the value you read back will ever be different than the actual value stored in the latch. Sent from my iPhone using Tapatalk
  10. 6 points
    Because it isn't as simple as typing "just put a rocker switch". Every change we make from stock on the perfect case that we finally found, adds thousands of dollars. It also changes the design aesthetic. Can you find a rocker switch that sits at a diagonal slanted angle with a skewed top and bottom? This is a huge conversation that is not one we really need to have at this late stage. The best thing you can do is trust that every single tiny decision that we have made is in the best interests of delivering a product faster and better value than if we went with the alternate decision [emoji106][emoji973]️
  11. 6 points
    Not sure how far back you're quoting but the X16 version is very much happening and David can't wait to start. It's true that it didn't make much sense to start writing the port while we were having problems with the prototype (to be expected with any project) but he's only waiting for feature lock so he doesn't have to write it twice. The rest of what you say is hearsay and not particularly helpful, nor accurate. We're already discussing his "Part 3" video that he's making. I realize speculation can occur when we don't design the entire computer in the open, but as I say to others, please remember how unprecedented the level of access we have given is. Have you ever seen this openness before in any major project, before crowdfunding even starts? To summarize, Pet Robots is happening, David's next video is being planned, and there's nothing more to it really. ¯\_(ツ)_/¯
  12. 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  
  13. 5 points

    Version 1.0.2b

    1 download

    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!
  14. 5 points
    I've updated it with a new version that now can use 320x240 full-screen mode instead of truncated at 200 pixels, and it also can show IFF Color Cycling images to add a sense of animation!! The movie included with the download shows the program running with the included images on the SD card. I found and included a few basic IFF images with color cycling. The real amazing thing is that there are a few extremely high quality color cycling images available to view on-line here http://www.effectgames.com/demos/canvascycle/ as mentioned in the topic here: https://www.commanderx16.com/forum/index.php?/topic/770-new-demo-uploaded-basic-color-cycling-demo/&tab=comments#comment-5197 I've managed to convert these on-line images back into IFF files with color cycling information. Additionally I've halved their resolution to 320x240 (and lost 12 bits of color palette accuracy) but these images can now also be displayed by my image viewer program on the CommanderX16, including their color cycling animation! Unfortunately the images are copyrighted and I think we are not allowed to share them, so instead here is a video of them being displayed on the emulator: ccycle-demo.mp4 It's a pretty long video because there are many images and the loading is not very fast (because they have to be streamed from disk due to being larger than the available memory). A lot of detail is lost because of 12 bit color banding and the resolution reduction (some blending/dithering patterns are wiped out completely), but I still think they are amazing to watch. Watch the video first and then the Effect Games web site link above to admire them in all their original high res detail. You won't be disappointed.
  15. 4 points
    Hi all, I recently stumbled onto this website. My reason for being here is mostly to track progress, and as a potential buyer when x16 is for sale. I really like the project, it is almost like looking forward to the next cool computer, but a next cool computer in an alternative past. I am a developer/techlead myself, doing solutions for b2b. But as a Hobby I have spend tons of time playing with and programming the C64 and the Amiga, programmed basic, c & assembly 6502/68000. Also other weird and wonderful languages, and a bit of hardware soldering. No Python though, not really my thing. Right now though I am doing "hobby coding" in Javascript, a X16 sprite exporter to my paint program, and deciding if I will do some c or ASM stuff as well for the X16, or keep to BASIC. I got here when I was playing around with BASIC a bit. I started at a web page where you can directly type in and run Apple basic, but soon ended up modifying Apple basic to become more like commodore basic. (I was adding things like sprite support and so on to the Basic, and a commodore 64 sprite displaying capability. Anyway while doing that I happen to stumble on the X16 emulator webpage, which already had all that. So yeah apple basic with c64 sprites is how I got here I really hope the web ide / emulator will continues to be developed, as I like it a lot, almost more then the "real" emulator. Fantastic project otherwise. keep up the good work! Same for the YouTube channels 8-bit guy, and retro recipes, just a tad to addictive Greetings from Sweden
  16. 4 points
    If the YM2151 becomes unavailable it would be replaced with an FPGA on a daughter card with pin headers to plug into a dip socket. But we are only crossing that bridge if it becomes necessary. Sent from my iPhone using Tapatalk
  17. 4 points
    Slightly optimized... Thanks to @StephenHorn and @SlithyMatt
  18. 4 points

    Version 0.1

    3 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.
  19. 4 points
    Ok, many points on this subject are spread across multiple other threads and I’d like to have a specific thread where these ideas can be hashed out and discussed and pros and cons of various approaches can be addressed without distracting other threads. I suppose I should start by explaining in as clear of terms as possible what the design approach has been as it appears there is confusion on this topic. How the IO logic is broken down in simple terms. There are a total of 8 active low select lines. Three of these lines are used by integrated hardware. The first handles both ViA chips, the second handles video, and the third handles audio. This leaves 5 lines free to support expansions. Each IO line or range spans 32 bytes of addressable space. Most chips will use far less than this, but in the even a chip used more you could utilize more by occupying more than one select line. This is large enough for IO devices but not really large enough for a ROM, at least not a directly mapped ROM. Now on to how these IO select lines are routed. They are all routed to every expansion slot. In other words the system has no distinction for which slots perform which functions. As far as the X16 is concerned all expansion slots are essentially equal. The upside of this is it allows expansion cards to be configured in a flexible way, but the downside is it does leave room for configuration errors. A cards physical slot has no bearing on how it gets mapped to memory. So how then are we proposing that cards get mapped to the IO lines. By physical jumpers or dip switches on the card. What happens if two cards have the same address? There will be bus contention and it won’t work. Real damage is unlikely, but that hardware simply won’t work until the conflicting lines are corrected. This is a problem PCs did have however we have way simpler select options, you only have 5 potentially valid ranges so even if you tried by trial and error it wouldn’t take long to get a valid configuration. So the next major issues that can come up are IRQ handling and DMA. On the X16 there is no IRQ prioritization in hardware. There are two types of IRQ events. The first and more common is a standard IRQ which is invoked in hardware by pulling the IRQ line low. This will cause the CPU to complete its current instruction, then push its registers to the stack and then jump to the IRQ vector. It will then determine what caused the IRQ in software. This is the way the commodore machines handled it and even though you spend CPU cycles polling a few registers to determine what caused the interrupt, it for the most part works and is still handled faster in most cases than other CPUs of the era. IRQ events occur on a first come first served basis. In other works if an IRQ is triggered while an IRQ event is being handled the second IRQ is not handled until the first one is completed. Also the CPU can be set to ignore this type of interrupt. The second type of IRQ is a NMI or Non-Mashable Interrupt. This uses a separate NMI line and this type always gets priority. Even if the CPU is set to ignore interrupts, NMI will still interrupt normal operation. Even if the CPU is handling a standard interrupt, a NMI will take precedence. I’ll skip DMA for now. So now that I’ve explained the basic architecture that allows us to look at the issues you might run into and how you can best handle them. 1. Hardware can technically be at any one (or more) of 5 address ranges. 2. Hardware can potentially trigger IRQ or NMI events 3. Standardized ways of utilizing certain types of hardware and making it accessible to software may be desired. 4. The actual code to handle the hardware needs to reside somewhere in memory and needs to do so in a way that doesn’t conflict with other drivers. This code probably needs to have some degree of relocatability and any vector tie ins need to be configured based on where the code is located. So the approaches may vary based on what you are trying to do. So I encourage civil discussion. We don’t want any complex or severe changes. But that doesn’t mean we can’t discuss options and possible solutions. My primary approach is that as things develop we will try to get an auto boot feature working. The details on that haven’t been sorted yet, but I’m of the opinion that a type of config file written in plain text similar to dos allows a good balance between ease of use and flexibility. I’m in the fan base too that these config files are essentially BASIC while functioning like a DOS batch file. So you can potentially do some pretty powerful things without having to know assembly. These files can be configured to load drivers and even pass arguments in some cases. So my thinking is that a driver can be loaded and told where it’s hardware is located. The driver may load a config file or something, there are several ways it could be handled, but the main things is where the hardware is located since that also affects where the IRQ hooks need to be if there are any, and can provide a clean way that hardware can be accessed by relevant programs without having to build drivers into the programs themselves. Sent from my iPhone using Tapatalk
  20. 4 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.
  21. 4 points

    Version 1.0.0

    16 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
  22. 4 points
    Belated Hi from Germany, I'm Carl, and I have actually been around for some months, but never did this introduction. But I thought it might be neat to do so anyway. There's two things that brought me here. 1. My search for the "roots" of home computing. Because I am from the east part of Germany, my ancestors missed out on most of the first decade or so of home computing. Many things like the C64 are mostly unknown where I come from. But I really wanted to know about the roots of home computing, and thus on my journey found channels like The 8-Bit Guy. 2. One of my passions is to make music using synthesizers. However, I find much of the modern VST gear quite overwhelming. So many possibilites, I simply do not know where to start. On the other hand, I quite like the situation where the creativity is pushed by limitations. Simple and limited synthesizers are what I enjoy using. And at most so, if they are able to produce stunning results nonetheless. Those two things are what brought me here. I want to create some nice music software for the X16 and eventually use it if time permits. Also, allow me some words on my programming background. I initially started programming with Turbo Pascal. However, it was hopelessly outdated when I first got an old Win95 laptop with an IDE installed on it from someone. But I pretty much enjoyed life with it, because I kept discovering and trying new stuff, and was really impressed how much you could do with a 75 MHz processor. I can't remember hitting the ceiling of its processing power. At some point I found out about inline assembly, and first used it to access the mouse and do various other things. I even tried a small project entirely in X86 assembly, but I got frustrated with it, so I never went very far. Meanwhile, I have come to enjoy programming in 65C02 assembly over the past couple of months. The good documentation of the X16 and a helpful and active community are a big part of what makes it worthwhile. I wish you the best blessings for 2021! Take care!
  23. 4 points
    On the subject of potentially having a ROM on the expansion cards, a potential solution could be bringing SPI or I2C into the expansion slot. Then you could place a ROM on that card but this alone does not fully address some of the issues so the code in this ROM would need to have enough flexibility to handle the issues. The main issues 1. the code still needs to be able to account for the address the card has been assigned to. So you either need a way to assign what ID the card is or to auto detect the cards ID. 2. You cannot execute code directly from a serial ROM so it still needs to be copied to RAM in a way to doesn’t overwrite other important code. 3. The code has to set itself up or in order words it is self modifying code. It needs to basically load into a staging area, then execute and copy its routines to a safely assigned area and tie itself into the KERNAL vector table and tie in relevant IRQ. This is all doable, but whether it’s located in a ROM on the card or gets placed on the SD card it still has to account for and dolce the same problems. Locating it on the SD card allows greater flexibility. Putting it on a built in ROM kind of black boxes the code to a degree. Yes it may have a degree of plug and play ease if set up correctly, but it brings new challenges too. Sent from my iPhone using Tapatalk
  24. 4 points
    mkcard View File Someone asked for help creating new sdcard images to be used with the emulator, so I banged around in vim for a while and dug around in DDG until I found enough hints around using sfdisk and mtools to create a suitable file w/o needing any root permissions. Due to limits of the FAT32 filesystem, the smallest image you can format with FAT32 is 32 MB. $ mkcard -f scratch.img -s 32 Checking that no-one is using this disk right now ... OK Disk scratch.img: 34 MiB, 35651584 bytes, 69632 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes >>> Created a new DOS disklabel with disk identifier 0x9983f409. scratch.img1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 33 MiB. scratch.img2: Done. New situation: Disklabel type: dos Disk identifier: 0x9983f409 Device Boot Start End Sectors Size Id Type scratch.img1 2048 69631 67584 33M c W95 FAT32 (LBA) The partition table has been altered. Syncing disks. You'll need the mtools and util-linux packages installed to use the script. Unfortunately, this limits this to be only be usable by Linux users (maybe Windows 10 users with WSL as well, don't know, don't have a Win10 setup to try with), I don't see sfdisk in the macOS ported versions of util-linux packages. To make things even easier to use these files with mtools, create a ~/.mtoolsrc file with something like: mtools_skip_check=1 drive s: file="~/scratch.img" exclusive partition=1 drive x: file="~/basic-progs.img" exclusive partition=1 drive y: file="~/demos.img" exclusive partition=1 And now you can use mcopy to copy files to your s:, x: or y: drives. Just make sure you UPPERCASE the filenames so x16emu will display the filenames as you expect them to look. Submitter Michael Parson Submitted 01/07/21 Category Dev Tools  
  25. 4 points
    Here are some thoughts for @Kevin Williamsabout his latest video, "Commander X16 Hardware Changes for Proto #2". I see several youtube commenters suggesting an MCU for debounce and soft power-on. I attached some ideas for jellybean logic implementations for these. The debounce is a standard RC delay followed by a Schmitt trigger. There is plenty of literature available for this circuit, some of which I referenced below. The reset debounce includes a power-on reset for the 65C02. The first soft power-on is a light modification of the one featured in Kevin's video. It replaces the 555-based debounce with a Schmitt trigger, adds initialization for the toggle flop and removes the unnecessary Q2 (ATX PS_ON# is TTL compatible) The second soft-power-on is mostly stolen from http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch. The latch is built using a weak feedback inverter, similar to how SRAM bit-cells are constructed. Pressing the switch overrides the feedback to change the state of the latch. The circuit should oscillate if the switch is pressed indefinitely, so the RC time constant is a trade-off between responsiveness and unwanted state changes. Disclaimer: None of these circuits have been tested or simulated. RC time constants likely need some adjusting and there may be more serious errors. Fortunately it is simple to breadboard these circuits to do testing with actual switches and power supplies. At the very least I hope they provide some inspiration and provoke discussion. Cheers. References: https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1 (total of 9 parts) http://www.ganssle.com/debouncing-pt2.htm http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch cx16 debounce.pdf
  26. 4 points
    Because the price deal on the cases gives us a power supply built in. It’s less expensive than sourcing an external low noise power supply and it gives us multiple voltages. Sent from my iPhone using Tapatalk
  27. 4 points
    There is actually nothing to wait for : ). Sprites can absolutely be displayed partially on the top or left edge of the screen. Positions are represented by 10 bits (= 0 - 1023) and wrap around which means that 1024 is the same as 0. Let's say you have a sprite that is 32 pixels wide. If you set the horizontal position to 1024 - 16 = 1008, the right half of it will be visible.
  28. 4 points
    Kevin posted this video on the Facebook page
  29. 4 points
    multi format image viewer View File This is a multi-format image viewer program. It supports IFF, PCX, BMP and Koala (c64). It supports full-screen 320x240x256 color bitmap mode and IFF Color Cycling ! Due to emulator restrictions (it seems) It only works when running from an sd-card file, so I've provided a zipped one that contains the program and a few sample images. The source code is here https://github.com/irmen/prog8/tree/master/examples/cx16/imageviewer The video below shows the program in action! imageviewer-demo.mp4 Submitter desertfish Submitted 12/14/20 Category Demos  
  30. 3 points
    On the question of whether it falls in line with: QUOTE: I would want the CPU to be 6502 or compatible, such as 65816. However, I’d be fine with the traditional 6502. I would prefer a faster clock speed, such as 8 Mhz or better. That way people could write code in BASIC and it would actually run fast enough to be useful. As long as we aren’t stuck using something like Commodore’s VIC or VIC-2 chips, then this shouldn’t be a problem. UNQUOTE ... I don't see how it can be scored as "complies perfectly" unless they fail to get it running at 8.33MHz and have to settle for 6.25MHz. If you are simply saying your dream 8bit computer is a 16bit computer, well, no set of feasible design goals pleases everyone.
  31. 3 points
    Glad to see that a highly desirable community computer is about to be born. I would like to buy one (or a kit) once its finished. The big problem is that I'm in Europe (Germany). That means everything worth more about 25$ that comes from overseas must pass the customs. Everything electrical must have a CE-label otherwise the customs will either send it back or destroy it. Are there any thoughts on getting a CE-label? Basically it is a self declaration of the manufacturer/seller that the item meets all rules that apply in the EU. There are no really ways to circumvent this, but one trick is to find an importer in a EU country. So the end user buys it from there, thus passes no customs. The next thing is that the video out seems to be NTSC only. A PAL version would be great, this would let the EU users use their old CRTs. Are there thoughts on other character sets other than us? I don't bother about the power supply, that is something one can buy here or DIY.
  32. 3 points
    Or 320*240 @ 256 colors. (76,800 bytes of the 129,472 available) Or 640*480 @ 4 colors. (76,800 bytes of the 129,472 available) Or double-buffered 640*480 @ 2 colors. (76,800 bytes of the 129,472 available) Or 640*480 @ 4 colors plus a second layer 640*480 @ 2 colors. (115,200 bytes of the 129,472 available) Clever image authoring and color cycling can animate displays without having to modify pixel data. Or using the second layer as a tilemap for repeating 8x8 or 16x16 tiles at 256, 16, 4, or 2 colors. Tilemaps can specify their palette offset on a per-tile basis, so you could have a 16-color tilemap with up to 16 palettes. There are lots and lots of things the VERA can do. Edit: And I almost forgot about parallax effects. With clever authoring of tilemaps, combined with layer scrolling, you can create parallax effects. With clever use of line IRQs you can fake multiple layers of parallax. With strategic use of sprites as well you can fake an almost arbitrary number of overlapping layers of parallax, as long as you don't go over the 801 work units of sprite data allowed per line (described elsewhere on the forums).
  33. 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.)
  34. 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.
  35. 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
  36. 3 points

    Version 3.0.0

    8 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.
  37. 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.
  38. 3 points
    Hi guys'n'gals, ghosts'n'goblins, hobbyists'n'retroists and procastinatists I am a german end 70s born male with a strong addiction to everything that has buttons and lights. I started my "career" on a VIC-20 back in 1983 (was 6 then...) and went from BASIC to a C-128 (mostly used in C64-mode...) where I poorly experimented with 6502 Assembler. Leaving 8-bit road for a 386 SX-16 in 1991 and moving over to GW-BASIC and PASCAL, my computers started to add more bits over the years. I used almost any Windows derivate starting from 3.0 to 10 but got an early hang on to alternative systems, so I also bought OS/2 Warp and was a fond linux user since 1993. Being the nerd I am, I grew into IT and work as an enterprise IT architect where my design level is more complete datacenter infrastructures than tiny small IT components. My heart and soul being lost in the 80s, I was a retro fan early on and got me a CBM 4032 (now in very poor condition ) and a CBM-720 (nice design!) around 2000. At the moment, my C128 is sitting right next to me in my mancave, 80s80s radio running and typically Retro TV (aka all these great, entertaining and informational youtube channels) showing on the second screen. I started getting into arduino microcontroller stuff some years ago and liked what I saw and could do with this. Being it ATTinys or ESPs, interfacing the real world seemed very cool. My work is typically much more theoretical... (If you want to have a look: https://github.com/highno ) I am eager to learn new/old stuff and experimenting with it. Having a set of restrictions, finding a working and possibly elegant solution is what drives me - so 8-Bit systems are just a wonderful world. To give an example: Ben Eater's work on a Invaders-like console with a 6-Pin ATTiny is simply amazing, but also work of CNLohr, pressing out TV signals, color, framebuffer and 3D-Graphics out of a WiFi interface controller design (the ESP8266) is also just amazing. I love demoscene for being extremely creative in art and technique. I hope to be able to develop some expansion cards for the X16 - starting with a WiFi network card and possibly an I/O expansion card with BASIC addons so you can tinker Arduino-like with all I/Os, SPI, I2C, etc. interfaces using the card and convenient BASIC commands... (Supporters welcome!) I hope to learn a lot of all this and have fun doing it. I love the retro scene and hope to interact with it more - especially while supporting the X16 project.
  39. 3 points
    Here's the finished product, printed on weatherproof inkjet-printable vinyl sticker paper:
  40. 3 points
    Are you on Windows? Here's how you do it: Open Computer Management (click start and type the name) Select Disk Management on the left side Pull down Action and select Create VHD Enter the location and filename in the box. Select VHD (not VHDX) and Fixed Size Make the file at least 40MB. This will create the VHD and attach it as a drive in the list on the bottom half of the Disk Management window. Right click in the box on the left column for that new disk. Select Initialize. Select MBR and click OK Now right click on the RIGHT side (the 40MB Unallocated side) and select New Simple Volume Use the defaults on the first page and second page of the wizard (click Next twice) In the third page, select Format the volume with the following settings File System: FAT32 Allocation unit size: Default Volume label: whatever you want Perform a quick format Click Next You should now have a new drive letter. Copy files in, then eject it by right-clicking the drive letter in File Explorer and selecting Eject. (You can't mount it in the emulator until you eject it from Windows.)
  41. 3 points
    That's not quite correct, but Cyber's not correct, either. Hardware actually CAN directly access RAM. It just needs to assert the DMA pin on the CPU. This suspends the CPU and lets the hardware access the bus. However, that's not how I/O devices usually do it. They use something called the Chip Select (CS) pin. Every clock cycle, every device on the bus looks at the CS pin and decides whether or not it should respond to the address and data bus. If the CS for that device is high, that device is allowed to talk to the bus. If the CS is low, that device is NOT allowed to talk to the bus. On the Commodore 64, the device that controls the CS pin is the PLA chip. This chip examines the data bus address on every clock cycle, then sets the CS pin for every device on the system based on the current bank configuration and address on the bus. So when the address is in the RAM range, the PLA sets the CS pin tied to the RAM chips. When the address is in the ROM range, the CS pin for the ROM is activated. This is what allows RAM, RAM, and I/O to all live in the same address ranges and be banked in and out as needed by the operating system.
  42. 3 points
    Lesson 3: Branching and Subroutines
  43. 3 points
    For a couple of years of my time in high school (for those not familiar with US usage, the 4 years right before university), I used my Commodore 64 as an alarm clock. I first got my 64 for Christmas during my second year. I didn't do much with it at first, because I didn't have any sort of storage device. No peripherals of any kind whatsoever, really. I played some games on cartridge, and dabbled in BASIC. But starting in my third year, I'd been digging through the user guide and found out about TI$, and decided to use it to wake me up in the mornings. At first, I just PRINTed TI$ directly to the screen, with no formatting. And every cycle through the main loop, it would check for being equal to a hard-coded alarm time, and GOSUB to a subroutine that would play an upward frequency sweep in triangle wave at maximum volume, and I likewise had the sound on the television monitor cranked up... well, not all the way up, but quite loud. At least halfway through the volume knob's range. As the weeks and months rolled on, I added more formatting features to the output. Eventually it would parse the TI$ 24-hour time into 12-hour AM/PM and suppress the zero in the hours display, so that a TI$ value of "170522" would print out as " 5:05:22 PM". Even though I still didn't have storage (I finally got a 1541 in the middle of fourth year), I was so familiar with the structure of the program that I could type it in again in just a few minutes if the computer lost power. But once I did have storage, I saved my best version. Armed with my new Programmer's Reference Guide, I started working on a new version that would use the 6526 CIA internal time-of-day clock (TOD). I'd learned that any I/O would cause the TI$ clock to lose time, and I'd already noticed that it would drift quite a bit over the course of only a few nights. I still have a lot of bits and pieces of paper around that I've held onto since back in those days, over 30 years ago at this point, and as it turns out one of those bits pf paper was a listing from when I'd finally gotten a printer, only a couple of months before graduating high school, an MPS803, and I'd listed out the contents of the work in progress, probably right before I'd stopped working on it. The point where I'd left it was where I was comparing TOD to TI$, printing them both out, fully formatted, but without the alarm feature yet. (I'd had some ideas about changing that as well, such as making the alarm time user-adjustable instead of hard-coded, adding a snooze function, or a progressively louder alarm.) I wanted to see for myself ho much better TOD was before committing to it... and I still hadn't quite worked out how to check for the alarm-set time. What I had done was a fair amount of cleanup. I added some very simple comments, and had all the line numbers incrementing by 10. This would allow me to stuff in several extra lines to handle however complicated the alarm check might turn out to be. Anyway, I rewrote retyped it from the listing. I made PET-Gazette-style curly-brace replacements for special characters. I've included it here as 'time.asc'. I've also loaded it into VICE. However, the host computer I used does CPU throttling for power savings and heat reduction, so starting a run of the program when the machine was at full speed and then leaving it overnight caused both clocks to run almost 30 minutes slow over an 8-hour period. For best results, then, I would suggest running this on a real machine or, if emulated, on a host machine that doesn't slow down the CPU. time.asc
  44. 3 points
    I remember starting out with VERA a long, long time ago (= more than a year). I tried to figure out what concepts like tiles and layers even meant. In those days there were no tutorials by Dusan, very few programs with source code to study, but luckily I had great help of Stephen’s legendary, unofficial documentation. This is the true story of how the West was won, or maybe not, but definitely a story of how a new interest in assembly programming was found. [emoji4]
  45. 3 points
    rje, dunno the status of your endeavour but if you're still playing with the debugger, I've tweaked it a bit so I can use symbols... which is bloody useful to be able to sync the asm with the source Here is the PR: https://github.com/commanderx16/x16-emulator/pull/313
  46. 3 points

    Version 1.0.0

    34 downloads

    CX16 port of the "MAD-COMPUTER" program published in the October 1985 issues of Mad Magazine https://archive.org/details/mad-258
  47. 3 points
    The NES PPU is very much fixed-function, like a really simple VERA. Like a lot of basic nerd things, I have a video for that:
  48. 3 points
    I dunno, I think he's hit a pretty good stopping point for a video card right now. I would be interested in seeing him tackle a world's worst sound card next. You'd think that sound would be so much simpler, since it outputs kilohertz signals, but the shapes of those signals matter a great deal, and there may be interesting problems with mixing multiple channels. And would he dare tackle PCM?
  49. 3 points
    Been watching a lot of Adrian's basement recently. I don't know that much about him except that he is all work, no ego. He's happy to have his attempts to fix and conquer difficult issues play out live on his videos and revels in the thrill of real-time triumph once he gets something working. Big fan and inspired that he was called upon AND solved a problem. Does anybody know what his background is? (developer as a day job?) Great to see that update, it's Christmas again and just what we needed. Keep at it guys, wish I could pitch in. Someday... : )
  50. 3 points

    Version 1.0.1

    20 downloads

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

Important Information

Please review our Terms of Use