Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/16/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
    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
  6. 6 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"
  7. 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
  8. 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]️
  9. 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. ¯\_(ツ)_/¯
  10. 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.
  11. 5 points
    Lesson 2: Addressing Modes
  12. 4 points
    KickC is a C-compiler for 6502-based platforms creating optimized and readable assembler code. The newest version 0.8.5 adds support for developing for the Commander X16 platform. The compiler includes header-files and linker-files for the chipset of Commander X16. Also included is veralib.h and a conio.h implementation contributed by @svenvandevelde. It also includes some example-programs that work in the emulator (and hopefully on the real platform). Below you can see a bit of the included sprites.c example program. You can get it here: https://gitlab.com/camelot/kickc/-/releases PS. I am the author of KickC.
  13. 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
  14. 4 points

    Version 1.0.2b

    0 downloads

    This program is written using kickc of Jesper Gravgaard. I'm helping him to create a framework encapsulating the CX16 vera in order to be able to quickly create graphical effects for games. This is a short demo and I hope you like it. This program uses the keyboard to progress through the program! So be sure to run this from the desktop, since the emulator on mobile phones do not have a keyboard!
  15. 4 points

    Version 1.0.0

    12 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
  16. 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!
  17. 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
  18. 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  
  19. 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
  20. 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
  21. 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.
  22. 4 points
    Kevin posted this video on the Facebook page
  23. 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  
  24. 4 points
    [emoji817] piano roll for me, for reasons that are hopefully obvious Your friend in retro, Perifractic
  25. 3 points

    Version 0.1

    1 download

    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.
  26. 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.)
  27. 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.
  28. 3 points
    OK, I reformatted this to look like the C64 promotional at the end of the 1983 Christmas Demo. I figured I could push some of the X16's features while playing that little ditty from Bach. And I backed off a bit on the sprites, so they're more subtle, but still there of course.
  29. 3 points
    Thanks. This makes me wonder why Butterfield suggested we read the Zero Page variable directly. In fact, I found that by accident while browsing a really nice API list, here: https://www.pagetable.com/c64ref/kernal/ I finally finished my directory reader in assembly: it's basically a line-for-line translation of the BASIC code... it took a while to get the file open correctly, do the correct CHKIN, and all of the other fun stuff that goes along with it. Either way - now that I can read a directory, this is the first step to building my file manager.
  30. 3 points
    VERA window panning demo View File This program is written using kickc of Jesper Gravgaard. I'm helping him to create a framework encapsulating the CX16 vera in order to be able to quickly create graphical effects for games. This is a short demo and I hope you like it. This program uses the keyboard to progress through the program! So be sure to run this from the desktop, since the emulator on mobile phones do not have a keyboard! Submitter svenvandevelde Submitted 01/12/21 Category Demos  
  31. 3 points
    I have started a new tutorial series on YouTube to teach you how to program in Assembly Language for the X16 and other 6502-based systems. The first lesson -- and introductory overview of the basics -- is now on YouTube:
  32. 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.
  33. 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.
  34. 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.)
  35. 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.
  36. 3 points
    Lesson 3: Branching and Subroutines
  37. 3 points
    Well said and I love this forum and the helpful people here to make sure we all can progress
  38. 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
  39. 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
  40. 3 points
    Another update from Kevin! I looked around and didn't see that it was posted yet, but sorry if it was and I missed it:
  41. 3 points
    I'm subscribed to Adrian's channel partly because he's a superb troubleshooter - very glad he helped the project this way! He also has the most 80s intro music, which is cool.
  42. 3 points
    Some of the components of retro computers are no longer available, so FPGA is the only option. The 6502 is still being made and it's cheap (like under $10 US), but on the Commodore for example, the VIC chips are no longer available. Having an FPGA VIC replacement would be fantastic for keeping my machines running for the long term. Since an FPGA can be a functional equivalent, it's certainly convenient from a design standpoint to use them. They are certainly more flexible. Might be the most exciting technology at the moment really. The main argument seems to be a purist one and personally I stay out of that argument as much as possible. I'm THRILLED that there is so much activity in this space and if people can make more interesting projects out of whatever they want, then I'm a happy camper. I think out of all of the projects on the horizon, both the Spectrum Next and Mega65 are really interesting. Gideon's Ultimate 64 is also fantastic. I'd buy a Mega65 right now at ANY price under $1000 (US).
  43. 3 points

    Version 1.0.0

    30 downloads

    CX16 port of the "MAD-COMPUTER" program published in the October 1985 issues of Mad Magazine https://archive.org/details/mad-258
  44. 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:
  45. 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?
  46. 3 points
    Progress!! Huzzah to 2021!
  47. 3 points

    Version 1.0.1

    18 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.
  48. 3 points
    As a novice the X16 appeals to me because it is kept simple so that I feel I can still learn to understand the inner workings. It’s close to a c64 which I had as a child so it checks that nostalgia box, and it pushes the envelope a bit by having a higher clock speed and some other features that make it superior in specs to a c64 which makes it a new thing. Also keeping it at a lower price point makes it accessible. Sent from my iPhone using Tapatalk
  49. 3 points
    You're just not being creative enough. All of the DAWs I've used recently have a split view mode on the piano roll. The top half of the window shows the note, while the bottom half shows one or more controllers. I'll work up a quick mockup of what I mean and post it in a few minutes. So here's what I mean. Note events are drawn on the piano roll portion at the top and the numbers below are control values applied to each note. Look at something like SID Wizard, with 5 data elements per note, you could stack those data elements below the roll. With 60 rows on the screen, you can afford to have 20 rows dedicated to note data, while still having a linear track on the top... and you can offer different modes, with two or three levels of detail on the data elements part of the screen. For detailed editing, you could color code the channels (White=1, Yellow=2, etc), then show just one channel at the bottom and let the user use the TAB key to cycle through the channels.
  50. 3 points
    Seems @Michael Steil was way ahead of us. After further studying of the Kernal sources I noticed the function "kbdbuf_get_modifiers" in kernal/kbdbuf.s. In R38 the call address is $ca64. I've just tested it briefly, and I think it is working properly. The function returns value of shflag in A register, where each modifier key is represented by one bit. This also makes it possible to detect combinations of several modifier keys.
×
×
  • Create New...

Important Information

Please review our Terms of Use