Jump to content

Leaderboard


Popular Content

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

  1. 21 points
    Hello Commandos! Here’s an update video all about the latest visual design aspects of the Commander X16. Regulars here will know some of this already but I hope you still enjoy it Your friend in retro, Perifractic
  2. 16 points
    David has finished the port and here it is running on the X16 prototype! Perifractic, X16 Visual Designer http://youtube.com/perifractic
  3. 13 points
    During my conversion of Petscii Robots over to the X16, it was relatively smooth until I added sound support. So, I thought I'd talk about the one big issue I ran into, which I wasn't expecting due to my previous experience coding for Commodore machines. Because the Vera has it's own video RAM, you have to set the VERA_L, VERA_M, and VERA_H every time you are about to write something to video RAM. It's a little more cumbersome than the way things are done on other Commodore computers, but not terribly so. In fact, in about 25% of cases, I found it easier to use this than the C64, depending on what I was trying to modify on the screen. So, In my sound/music routine, I'm using the VERA's built-in PSG. Which means my sound routine is changing VERA_L, VERA_M, and VERA_H every time the IRQ routine runs. And the IRQ can run right in the middle of your writes to VRAM. And unless you want to add an SEI and CLI before and after every routine that writes data to VRAM, you'll need to backup the VERA address registers in your IRQ routine. So, I did this: LDA VERA_H PHA LDA VERA_M PHA LDA VERA_L PHA ***insert IRQ code here *** PLA STA VERA_L PLA STA VERA_M PLA STA VERA_H Now, while this may sound obvious to some people, I wasn't accustomed to dealing with this sort of thing when writing to sound registers in the SID or VIC-20 or whatever, since they were their own separate registers. Anyway, hopefully this piece of advice will help somebody else not pull their hair out in the future.
  4. 11 points
    I spent some time the last few days converting Petscii Robots over to the X16. It's now more or less fully functional. Well, you can play the game from beginning to end, anyway.. But it still lacks sound, and it is using the default font, which I hope to change soon to the PET font, which will make it look nicer. It also lacks a lot of effects like screen-shake, EMP flash, etc. I'll be working to add those in over the next few days. Also, since the game is designed for 40x25 screen, there is some black area at the bottom. That being said, once I get this version completed, I'll slowly begin the transition to a custom graphic version for the X16 as originally promised, which should fill the whole screen.
  5. 8 points
    The X8 is a somewhat cut-down X16 that exists entirely in FPGA. It has much less RAM. It does use the VERA, albeit with reduced VRAM. I have one of the few prototypes in existence on my desk. It is a concept we have toyed with and may or may not release at some point after the X16 launches. The core team is somewhat divided over whether or not it is a good idea as it does somewhat compete with "stage 3" of the X16.
  6. 7 points
    My WASD keyboard arrived.... now I just need a white retro-style case.
  7. 7 points
    Ok, this is a violation and we are going to have to remove it for several reasons. The first is that the KERNAL and BASIC are proprietary code and as such any software that contains that proprietary code in whole or part is not allowed. Secondly, must such software should leave the ROMs untouched and instead load from the SD card. You don't add custom software to most BIOS systems and likewise you shouldn't indiscriminately add code to the OS ROM unless it provides real world functionality without breaking compatibility. As a whole we are not interested in micromanaging what users can and cannot do, so long as it doesn't introduce legal or ethical issues. We simply cannot allow users to distribute or alter the code we are licensing from Cloanto or Microsoft or any other entities. Before you include any code in your projects make sure you check and understand the license agreement to see what you are or are not permitted to do. Never assume that something is open source unless explicitly stated. Making custom ROMs as a rule is allowed. So long as it doesn't violate any license agreements. However some custom ROMs may overall be harmful to the community if they break compatibility, or if they risk hardlocking the physical system.
  8. 7 points
    Well, I happened to have this recorded. I hope Perifractic wouldn't mind me reposting this:
  9. 6 points

    Version 0.6a

    20 downloads

    VTUI (Vera Text User Interface) library Can be used to create text user interfaces using VERA instead of relying on the KERNAL functions for writing to screen. The library is less than 1KB which means it can be loaded into Golden RAM at $400. As an alternative, include files are provided for Acme and CA65 assemblers. See https://github.com/JimmyDansbo/VTUIlib for documentation, examples and include files.
  10. 6 points
    Also isn't it more fun to work with the constraints we have now! Instead of having a 16 or even 32 bit true color screenmode we could try to do something like FLI on the C64 where a bitmap image was showing MORE colors by changing the palette every X scanlines or interpolating 2 colors in interlaced frames.... This kind of trickery is for me a big part of the charm of the original 8 bit systems. Push them to the limits and beyond normal expected results by using interesting new tricks. I wonder what we can do with the Vera
  11. 6 points

    Version 1.0.0

    25 downloads

    This is a raycaster demo written in c for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster. Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! Right now I've got a simple raycaster working in c. Just to try out how VERA works mainly. # Usage To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG -l ray.list ray.c To run: x16emu.exe -prg RAY.PRG -run To play: use a,s,d,w for control # Known issues: - There is no collision detection - Nearby walls have strange colors - Performace is not great. It's just a proof of concept. - The top and bottom of the walls are 'edgy' because a 'naive' ray-casting approach (see comments source code) - No textures - No sprites I would like to start working on a version that works in assembly. After doing some calculations, I've concluded we need to do some crazy things to get this to work at 60fps... But I am willing give it a try Having fun! Jeffrey
  12. 6 points
    And just a heads up that we are adding a diagnostic LED or two to the PCB, mainly to assist with diagnosing power on/no picture failures. Perifractic, X16 Visual Designer http://youtube.com/perifractic
  13. 6 points
    I think I have reached a point where I have the Generic VTUI light-library finished. I have managed to fit the functions I initially wanted into 1KB so it can be loaded into golden RAM. The functions included are: initialize - Initialize the jumptable at the beginning of the library to make it easy to call the rest of the functions screen_set - Set the screen to 40x30 or 80x60 or toggle between the two clear - Clear the screen with a specified color set_stride - Set the VERA stride value set_decr - Set or reset the VERA decrement bit gotoxy - Point VERA memory to specific coordinates on screen plot_char - Put a screencode character and color code on screen at the current VERA address scan_char - Read a screencode character and color code from screen at current VERA address hline - Draw a horizontal line vline - Draw a vertical line print_str - Convert and print a 0-terminated PETSCII string to screen at current VERA address fill_box - Create a filled box pet2scr - Convert a PETSCII code to screencode scr2pet - Convert a screencode to PETSCII border - Draw a non-filled box with a border save_rect - Save an area from screen to memory rest_rect - Restore screen from memory I know that this is very basic, but hopefully it could, at least, help people get an understanding on how these things could work. I still have lots of work to do as I have not done anything on the ACME and CA65 include files. I also need to create another example and possibly a demo of how to use the library. I think I will leave the light version with the above functions, and focus on getting the include files finished as well as create a demo on how to use the library. I do plan on extending the library with scrolling, string input, hex/number to string conversion and more, but for now I will get this light version finished.
  14. 5 points
    Indeed. The 8 Mhz limitation is due to various components on the board such as ROM, the sound chip, the Vera, etc. In fact, we only have it working stable at 4 Mhz at the moment on the latest rev of the proto-board. But, with a few minor changes we still fully expect to get it back up to 8 Mhz and stable. Having said that, stage 2 and stage 3 do present the possibility to go faster. Specifically stage 3, which is all inside a single FPGA. We have a prototype of that which runs at 14 mhz and seems stable. But, as far as the DIP style board, which serves as the basis for the whole computer architecture, 8 Mhz will likely be all you will ever see.
  15. 5 points

    Version 1.0.0

    24 downloads

    I played this game with my friends in grade school on the PET. Though unable to find the original, I found a stripped-down VIC-20 version -- which showed me the program's essential structure -- and the later 1986 version by Commodore, mainly designed for the Commodore 64. I used both to create this version, which retains the original algorithms, and tries to emulate the older PET version. It uses very little X16-specific code -- exactly, SCREEN and COLOR. It relies on the 40 x 25 screen, and it uses just about all 25 of those rows. The rest is all PETSCII and BASIC 2.
  16. 5 points
    Tehtriz View File I've recompiled my tetris clone to the Commander X16! Features: holding area, wall kick rotations, shows next piece, staged speed increase It is functionally equivalent to the original C64 version except the sound effects are a bit simpler. Controls are printed in the screen, note that you can also use the cursor keys for movement if that's more convenient for you (not printed) Source code is here: https://github.com/irmen/prog8/blob/master/examples/cx16/tehtriz.p8 Submitter desertfish Submitted 02/10/21 Category Games  
  17. 5 points

    Version 0.0.4

    43 downloads

    This is a quick demo of a 2D graphics library I've been working on recently. It's written in assembler, and aims to make life a bit easier when it comes to drawing vector graphics. You can define individual polygons which can be moved about and rotated. The source code looks fairly daunting, but when it comes down to it, building, transforming and rendering the polygons is very straightforward. Hopefully this will form the basis of a game at some point soon. (Perhaps an Asteroids clone?) Once I sink my teeth into interrupt handling, I should be able to "vsync" everything so it's flicker-free. All comments and suggestions welcome! Short screen capture of this demo on YouTube (featuring my tunez!!): Commander X16 Demo - Vector Graphics in 6502 Assembly - YouTube WARNING: For those who are sensitive to flickering/strobing, please be aware that this may cause problems for you. -- See below for a quick preview of the game I'm working on, retro flickering and all!
  18. 5 points
    We’ve thought about that naturally but that advantage comes for unknown brands. David has over a million subscribers so we feel publicity wouldn’t be an issue. [emoji106] Perifractic, X16 Visual Designer http://youtube.com/perifractic
  19. 5 points
    I have come a bit further. The generic library is functional although it does not have too many functions yet. I spent all of the evening yesterday trying to write some documentation and hopefully it is understandable. Have a look at https://github.com/JimmyDansbo/vtuilib/blob/main/VTUIlib-generic.md You can also look at the examples and download the binary here: https://github.com/JimmyDansbo/vtuilib/tree/main/VTUIlib-generic The example shows off most of the functions currently implemented and should look like this: Let me know if anything is unclear ( there are probably things that needs to be rewritten or clarified)
  20. 4 points
    I have started developing the VERA Text User Interface Library (vtuilib) and could use a little help for ideas and suggestions. My plan is to create 3 different flavors of the library: Include file for the ACME assembler Include file for the CA65 assembler Binary library file that can be loaded with any program So far the library is still in very early development and there is no documentation yet, but I have implemented a few basic functions such as set_stride, set_decr, print_str and line drawing functions in the generic library. There will of course be functions to draw boxes, filled and not filled as well as functions to save and restore a certain area of screen. The binary library is designed to function in any memory location so depending on the final size, it might be possible to load it to "golden" RAM at $0400 which is what I am doing so far. Another approach is to design it to live in banked memory. What are your thoughts? How important is it that the binary library can be located anywhere in RAM? Which functions would you like to see? Anything I have missed?
  21. 4 points
    For a text adventure, I'd definitely go with BASIC on the X16. It should be plenty fast. There were plenty of text adventures written for Commodore systems in BASIC and those were only 1 Mhz. BASIC is certainly a lot better for dealing with strings.
  22. 4 points
    Hi, thanks to contributions from András Péteri, the vbcc compiler now comes with support for the X16. I am not very familiar with this machine, but the generated code seems to work well in an X16 emulator. Please let me know if something does not work. So far there is no banking support for this target yet. I am not sure about the state of development, but if the banking scheme is finalized, it would probably be a good idea to add the necessary library routines. A few of the good things: - compiler is under active development - supports C99 (variable-length arrays, designated initializers etc.) - generates optimized code (see dhrystones in sample directory) - supports banked memory and far-pointers - (limited) floating point support based on Steve Wozniaks code - (pretty good) 32/64bit IEEE floating point support based on SANE - support for 65C02 extensions - support for writing interrupt handlers - attributes for putting variables into zero page - supports stack-frames > 256 bytes Changes since r1: - new target: MEGA65 (native mode, some banking support) - new target: Commander X16 (thanks András Péteri) - new options -prefer-statics/-force-statics (allocate local variables in static memory rather than on the stack) - new option -range-opt (first implementation of some range-based optimizations changing induction variables to smaller types) - added support for o65 object file format - added support for Oric target format - better use of x register - improved cross-module function-inlining - IEEE math library works with 65c02 - several code generation improvements - fixed several bugs - slightly reworked examples
  23. 4 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
  24. 4 points
    Hey hey, I'm Sherm. I got my first taste of coding back in 1979 on a Wang 2200 and haven't stopped since. The Wang was short lived having discovered the Apple II in 1980. That was probably for the best. The apple was a great machine to learn to code on. Our library had two wire bound manuals that were almost exclusively borrowed by myself and a school mate in our small country town. In the end the library gave us one each when we left school. I still have mine all these years later. During that time I daydreamed and saved up for years to get my first Commodore 64 in 1984. That was such a trip moving to 16 colours in a device I could easily carry on my bike to see my friends for coding parties. I fell in lust with the Amiga 1000 the very next year before buying one in 1986 when I could finally afford it (I really couldn't afford it but I bought it anyway) then upgraded to the A2000 around 1990 to start taking advantage of all the third party cards. The Opal Vision, and the GVP Video Toaster were the two things I'd coveted and I spent countless hours pushing both to my limits. Stayed with the Amiga until around '97 when the PC started getting better graphics and I finally slipped over to what has really been a barely exciting growth since. Don't get me wrong; What a modern PC can do now is amazing, but it's been slow change and nothing that has felt as exhilarating as the C64 and Amiga for me. Linux and the Raspberry Pi sort of had a familiar buzz about it, but still not at the same level as those young years. Electronics engineer by trade, my love has always been the marriage of interfacing code with external devices. There's a lot more to me, but I figure there's a lot of people just like me here watching with keen interest, and old memories.
  25. 4 points
    No, the VERA cannot just do any signal that was ever put on a VGA cable. No, it is not just a matter of memory. Want to change the resolution? That means changing the pixel clock speed. It also means implementing additional smarts in the video processing to deal with rasterizing lines of multiple widths (and not at a convenient power of 2, either). This likely means having to put the VERA onto a more expensive FPGA to support the additional sophistication. Even if it were just a matter of memory, the VERA's memory is built in with the same FPGA used to implement the video processing. This kind of memory is not cheap. The cheap kind of memory would mean redesigning the entire daughter board for the FPGA chip to use external memory, and this still represents increasing the cost of the VERA due to the added components needed to deal with the external memory source.
  26. 4 points
    For a time i had a Sharp MZ-700 (more precisely it was the MZ-731 but the label on the chassis apparently always says MZ-700). I never knew how / where my parents picked that one up. It had a built in 4-colour plotter and tape for programs which was really cool. I did a lot with that and once scored a free set of the min-pens it used on CeBIT. Some very limited sound capability (more of a beeper) but I did a lot on that machine in basic back in the day. Only looking it up now I realize it also had a Z80 at its heart and 64K. Somehow I wish I had a plotter unit again. It feels kinda neat. http://www.idealine.info/sharpmz/mz-700/first700.htm
  27. 4 points
    The Trash-80 moniker fits for the original Model I. It was rushed to market, and it shows in the quality of the machine; not just in the manufacturing, but the underlying design as well. The Color Computer and its sequels and derivatives are just so different from the other TRS-80 machines that it's difficult for me to put them in the same category.
  28. 4 points
    The library has been updated a bit and I have added it to the Dev Tools section
  29. 4 points
    David can blow up what ever he wants. Paper clip? I have no issue. (Done that myself) Cut a computer in half and I will smile, laugh and cry with you. We are all here to have fun and learn and if people have an issue with that then do not watch the channel. Keep it up David. You are doing just fine.
  30. 4 points
    PCM Multi-Encoding Demo View File This is a demo of 26 different encodings for PCM audio playback, from the maximum bitrate (48.828 kHz, 16-bit stereo) the minimum (381 Hz, 8-bit mono) using the same non-copyright music track and fitting as much data as possible into 63 RAM banks (504 kB). Just press different letters to hear different samples. As seen on YouTube: Submitter SlithyMatt Submitted 02/12/21 Category Demos  
  31. 4 points
    I've just made a release for Version 0.1.1. There are no changes to the actual features of the synth engine. However, the code has been reorganized so that it is MUCH easier to include the synth engine with or without UI into your own ca65 project. Separated synth engine and UI so that they can be separately included Provided a simple API for both Added documentation and examples on how to use them Added precompiled binaries of all examples The example below shows what it takes to utilize Concerto in your own ca65 program .zeropage .include "concerto_synth/synth_zeropage.asm" .code jmp start .include "concerto_synth/concerto_synth.asm" start: jsr concerto_synth::initialize jsr concerto_synth::activate_synth ; play a note lda #60 sta concerto_synth::note_pitch lda #63 sta concerto_synth::note_volume lda #0 sta concerto_synth::note_channel lda #0 sta concerto_synth::note_timbre sei jsr concerto_synth::play_note cli ; and wait until key is pressed mainloop: jsr $FFE4 ; GETIN beq mainloop jsr concerto_synth::deactivate_synth rts
  32. 4 points

    Version (Video Demo)

    5 downloads

    This is a demo of 26 different encodings for PCM audio playback, from the maximum bitrate (48.828 kHz, 16-bit stereo) the minimum (381 Hz, 8-bit mono) using the same non-copyright music track and fitting as much data as possible into 63 RAM banks (504 kB). Just press different letters to hear different samples. As seen on YouTube:
  33. 4 points
    A video this time! If a short (and silent) one, but a video nonetheless! Here I'm showing off pattern navigation whee! It's nearly complete - there's still some note save bugs, but I squashed many of them. What isn't shown is scrolling left - right now you can only scroll right and otherwise have to reload the editor to get back I'll fix that, I just ran out of time this evening. Likewise, I'd like to have tab work for scrolling faster through the channels. As you can see, 25 channels is a lot! I'm not sure if the final version will have 25 or if I'll cut down the number of PSGs and do some sort of dual voice solution. Purists won't like that I"m sure (wanting to have the option to fully exploit all channels) but it does add some benefits like making it easy to do "supersaws" as instruments. As I plan on trying to use the Concerto synth engine still, this may not be that big a deal to worry about (with the trade-off being decoupling of channel vs voices). I'm also not sure if DPCM will remain as I'm worried it might be too CPU intensive to really be viable in the way it would be used in the tracker. I'm not sure on that one yet. I'd love to have it for some NES style DPCM drums and things. Fortunately, that's not something I have to think about in depth today and more on that at a later date I'm sure. I will fully admit the code is starting to get a little, erhm, artisanal? I'm going to need to clean things up some and add comments, organize variables, etc. so I might opt to consider that before I jump into the save/load functions but those are definitely next on the list once the UI is at a minimum viable state.
  34. 4 points

    Version 0.0.0

    16 downloads

    I've since removed the external file dependencies for building the UI which means folks can finally try Command Tracker out more directly in the emulator. A very basic song exists to start. There is no loading and saving yet and, as noted in the dev log on the forums, it's buggy and, as of yet, no real sound engine (rather a very very basic one) but it does work and demonstrates what I'm trying to work towards in a full featured tracker. It is modeled loosely after Impulse Tracker on PC.
  35. 4 points
    I don’t know if Frank has seen this or not but in the conversations about why the specific one was choosen, a couple big items. It was chosen because it is low cost with a large amount of RAM in it. If you look at most FPGAs that have large RAM they are almost always big expensive FPGAs. In the same product line there was another FPGA that had double the RAM but it was way more costly and was a BGA chip which would require outside manufacturing to assemble. This is bad for low volume test modules which are needed to even develop the system and none of us have the capability to handle those in house. Needless to say the VERA we have designed now is what we are sticking with. Limitations and all. It is for programmers to work with the systems limitations and either adjust the design to fit, or figure out clever tricks to work around them. Sent from my iPhone using Tapatalk
  36. 4 points
    I made a Ryu Sprite with the Sprite Editor from @CX16UserSteveC what is available here. Take a look of the Sprite. And that's the Original PNG file. I think I set the Color Palette a little bit wrong. And I found out that the Emulator works on Windows XP.
  37. 4 points
    I still think the Kaypro II is the sexiest 8 bit computer. I mean, just look at those metal sides and those square corners.... And, likewise, I still look with envy at the "lunchbox" computers, which now cost several thousand for the case alone. Laptops are convenient for a certain set of people, but sometimes you want a real, full size system you can take with you. The lunchbox form factor can't be beat for portable power.
  38. 4 points
    Thanks for the thumbs up. What you are describing is some thing we discussed and debated at great length internally about six months ago. Long story short that is likely what the phase 2 design will be as I showed in the video. The case is less tall but may still allow for a right angle expansion card inside, and possibly and external expansion card adapter to allow for cards to sit outside the machine, like those C64 cartridge port expansions. [emoji106] Perifractic, X16 Visual Designer http://youtube.com/perifractic
  39. 4 points

    Version 1.0.0

    40 downloads

    I needed a test program for the graphics routines in Prog8 that now also work in highres 4 color screen mode. I thought it would be fun to replicate a classic Amiga Workbench desktop screen, using just the graphics drawing commands. Note that the text font is actually the built-in iso charset. It is fairly similar to the Amiga's topaz font, so I just went with it and didn't bother to replicate the font pixel-perfect. Also I didn't bother to make a nice white/red sprite mouse cursor, maybe I'll try to add this in a later version. Here is a screenshot of a real Amiga workbench that I used as inspiration https://patric-sokoll.de/Museum/Computermuseum/Amiga_Kickstart/Amiga_Workbench_3.1_Vorschau.jpg
  40. 4 points
    Let’s keep it friendly here everyone. It looks like a cool product and I’ve seen it getting love elsewhere. I can also see how this could have been misinterpreted here. For the record the X16 will come with a compatible keyboard and 2 capable PS2 ports on the back for which we’ve had no issues so there’s technically no need for the device, but I appreciate any solutions to retro problems. Onwards and upwards... Perifractic, X16 Visual Designer http://youtube.com/perifractic
  41. 3 points
    Whew! Finally, loading and saving now works! I have no doubt there's bugs all over the place. And of note I'm not sanitizing inputs in all cases, etc., etc. but basic loading and saving does work, which will make it much easier for me to start working some of the important core features finally!
  42. 3 points

    Version 1.0.0

    2 downloads

    After seeing others post conversions of classic basic programs, I remembered this one where the computer plays an animal guessing game with you. It tries to guess your secret animal by asking questions about it, and if it doesn't know the animal, it asks about your chosen animal so it knows about it the next round! (It's basically building a binary search tree) note: all knowledge is lost when the program exits. (maybe I'll make a future version where it can save/load the animals and questions) Source code is here: https://github.com/irmen/prog8/blob/master/examples/animals.p8
  43. 3 points
    x16tial mouse aid View File The X16's default text screen is HUGE! 480% percent bigger than the C64's! Or is it 380%? Whatever, it's nice! This small utility is designed to help navigate this awesome space, primarily when developing in BASIC. It turns the mouse on and enables: Left Click: Locate cursor where clicked. Right Click: Clear screen and execute LIST. load with: LOAD"XMA",8,1 (or use XMA.PRG if you like typing, also LOAD can be abbreviated with L-Shift-O) SYS 1024 The idea is that it really improves getting around large basic programs. One hand on mouse, other on the stop key, right click to start listing, stop when need, click where you want to edit, boom. ** BUG **: To prevent a lockup, after loading and activating XMA, just type a quick NEW. If not, if you try to enter a basic program line (with a line number, not immediate) the emulator will hang. Or you can just load an existing BASIC file. This is probably a holdover bug from the C64 (or BASIC V2), where BASIC's memory pointers get set strangely when loading a program that doesn't sit in BASIC's memory area. With 1.1.0, you can now SYS 1024 after doing a reset to reactivate XMA. Submitter x16tial Submitted 02/09/21 Category Dev Tools  
  44. 3 points
    Ok that requires me to add some extended functions to prog8's textio library. Currently it only can do a C-64 compatible text output, i.e. setting a character in a single color at a location on screen. I'll have to add a background color option somehow edit: right, that wasn't so hard. Thanks for the suggestion, this looks good!!
  45. 3 points
    Note that a Basic compiler would allow for a development approach of working with integrated Basic for "rapid application development" prototyping, even if essentially "in slow motion", while compiling the most effective solutions allows it to respond "at full speed". However, early Basics were not natively equipped with the most effective information management keywords for managing the information needs of a typical adventure game, and implementing those IN Basic would further increase the overheads of working in Basic. In between Basic and Assembly, both C and Forth offer opportunities for more rapid development than working in straight assembly, with more efficient execution than allowed by a Basic interpreter. However, they are substantially different programming approaches, so there really isn't a "one size fits all" solution in the space in between Basic and Assembly ... its likely different types of people who enjoy C programming and Forth programming.
  46. 3 points
    That pretty much what the Color Maximite is doing, but that of course requires a lot more horsepower, and then BASIC becomes the main way of developing for it and the system itself becomes a black box that just speaks BASIC. And that's great, if that's what you want. Yep, and that's great too, and really gets down to the reason that the X16 exists. To have something simple enough that it is relatively easy to work at that level. That is the "dream" after all.
  47. 3 points
    I didn't make a video this time but I managed to fix the bugs with the pattern editor. It's now working reliably! Though I haven't yet implemented scrolling through the pattern while editing so that will be next. Part of the reason I didn't break out a video was because very quickly I can see the need to have some nice to haves (like copy paste, insert note/delete note which shifts the row, etc.) but those will likely wait until I have the basic functionality done. I can't even save songs yet which is the next thing I'll be working on once the initial work on the pattern editor is done. Currently, the program (including buffers) is 4934 bytes (on disk). I found that pretty crazy myself! I'm not suggesting my code if compact (it likely isn't) - moreso that it's amazing how much you can do in assembly on an 8-bit computer, particularly when comparing it to the huge sizes programs are on modern machines.
  48. 3 points

    Version 0.7.0

    18 downloads

    The project : https://github.com/VincentFoulon80/vixx Vixx: A bullet-hell game for the X16 Story: Your Commander X16 got a virus ! Thankfully you have an antivirus called Vix that'll get rid of the evil software. You play as the Vix Antivirus, scanning the computer trying to locate and destroy the virus. How to play : Joystick / Arrow keys : move the player Start / Enter : start the game, pause B button / Ctrl key : Panic! Your score increase over time, and also when you move near the bullets. You score points when defeating bosses and also when panicking ( 100 points per bullets on panics) Project status : The game is still in its alpha phase. I'm implementing new features and do not focus on the content. The first level is not final, and the second is just an infinite loop. It's more to give an idea of how the game will look. Devlog :
  49. 3 points
    When stepping through the Kernal, it is important to understand that the emulator doesn't work exactly the same as hardware. If you are using the host file system, LOAD and SAVE will use native file I/O on the host, so data just "magically" moves between the host file system and the emulator RAM. If you use an SD card image, you will be running the actual Kernal code to transfer data byte by byte through the CPU, rather than skipping over all that.
  50. 3 points
    Just a quick follow up. I started down the road of building my own eeprom emulator when I stumbled across the EPROM Emulator project by Kris Sekula. I built the kit and I have it working with my BE6502 setup and it works pretty much the way I imagined. It is designed to emulate a 27cXXX eprom, but with just a couple minor changes (pin 1 and pin 27) I am able to use it in place of the 28cXXX eeprom. Now I am able to write 6502 assembly in VSCode and use a Makefile to build and deploy the code directly on to the BE6502. It even triggers the reset line after code is deployed.
×
×
  • Create New...

Important Information

Please review our Terms of Use