Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 05/18/20 in all areas

  1. 32 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.
  2. 28 points
    The current "master" branches of the x16-rom, x16-emulator and x16-docs repositories now correspond to the "Proto #2" hardware, which is incompatible with the "Proto #1". banking is now done though zero page addresses 0 and 1 instead of VIA GPIOs the I/O area at $9F00-$9FFF has changed in layout (except VERA) the layout of the VIA GPIOs has changed 4 SNES controllers are supported there is now a real-time-clock – but it is not yet supported by the emulator or ROM If you have software that does manual banking or accesses I/O devices (other than VERA) manually, you will need to update it in order to be compatible with the next emulator/ROM release (r39) as well as real hardware. The Programmer's Reference Guide should have all the necessary information. Please file bugs on GitHub if you find any issues. Thanks!
  3. 28 points
    Just a little tease for all you loyal Commandos of how the machine is looking in the user guide illustrations:
  4. 27 points
    Hey Everyone, I just made a new video showing some updates on the Commander X16 second Prototype. I've been working on a few modifications, and getting them incorporated into a daughter-board. The board was updated, and sent over to Michael Steil to work on the kernal. At this point, he should have what will be pretty close to the final HW. I cover a few topics, so please take a look if you have a second and thanks for taking the time. Take care, -Kevin https://youtu.be/T5vjnBYGp2w
  5. 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!
  6. 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
  7. 20 points
    Very small update for you guys. First prototype PS/2 mini keyboard is in. Note: This is not representative of our colour scheme or keycap artwork. They used a default artwork but we'll be able to get more specific once the crowdfunding starts. But the goal of this prototype is to test the new more ergonomic raised up keycaps and overall feel and design. You may remember our early prototype keys were flatter, more laptop like, and less nice to type on. This feels REALLY good to type on, especially for a good value non-microswitch keyboard. Can't wait for you guys to be able to hold it in your hands. Well... under your fingers... You know what I mean. (And of course the deluxe microswitch keyboard made and sold by WASD remains an option for the most selective of keyboard connoisseurs: http://commanderx16.com/deluxekeyboard ) More updates soon! Your friend in retro, Perifractic
  8. 19 points
    Why we’re renaming the X16: Perifractic, X16 Visual Designer
  9. 18 points
    Hi Everyone, If you happened to see David's video on the Color Maximite 2, then you probably noticed that the new Commander X16 PCBs have arrived! David @The 8-Bit Guy just happened to swing by my house the day they arrived, and he picked them up before I was even able to get all of the parts in. I am still waiting on a few things, so I haven't been able to complete assembly yet. The VERA is also not complete for this reason, but I had to mock it up for the pics! Bear in mind, this is not the correct case, this is from an old tower ATX case I had sitting around. It's a nice platform to mount the board and make sure I have the placement of screws, slots & of course the rear ATX panel aligned correctly. I will likely make a few placement tweaks but overall I am quite happy with the physical layout so I just had to post some photos! So far, it's working but my ATX soft-start circuit is a bit squirrelly. Not only that, I kinda wired it wrong and didn't catch it before the run. Worked great on the breadboard, but I will have to revamp that before the final. There are also a few other little things discovered since this proto was run, but the real tests will be coming when @Michael Steil is able to get the Kernal up and running. (I would write some test code, but one part I'm missing is the ZIF socket for the ROM. Should be here in a day or two.) @Perifractic is also sending me the X16 case, so I should be able to install the board in there later this week. Happy Sunday, and Take Care Everyone! -Kevin Williams https://TexElec.com
  10. 18 points
    I figured it’s been a while since the last update. So I’m just letting you know where things are at. Kevin has sent me one of the prototype boards in the hopes that we can figure out why certain parts are not working. Timing on the ROM and RAM is stable, the two VIA chips are also stable. There is some odd behavior on the banking latches, and the audio and video are not working. We are certain it’s a timing issue and we will let you all know when that issue is resolved. By sending me a proto board the hope is that we have a second set of eyes since trying to debug it over email and phone calls isn’t very productive.
  11. 18 points
    Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
  12. 17 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]
  13. 17 points
    Just some further updates. I have finished the assembly of the board along with the patches that Kevin has documented. It’s not working yet, and my schedule has been very full this week. I’ve ordered some parts I need to build a test rig, and I have a logic analyzer that I just got. So not much to report yet. But just in summary my test rig lets me get to the very basics and monitor and control many parts of the system. Sent from my iPhone using Tapatalk
  14. 16 points

    Version 1.0.0

    1063 downloads

    This is a shareware version of Petscii Robots. It only includes 2 maps. It also lacks SNES controls and the cheat-code. It is also only presented in "color PETSCII" mode, as there hasn't been a version made yet with custom graphics and sound. The music routine is a direct port from the PET, which only uses 1 square-wave voice. PETFONT.PRG
  15. 16 points
    David has finished the port and here it is running on the X16 prototype! Perifractic, X16 Visual Designer http://youtube.com/perifractic
  16. 16 points
    Hi again! I've been working for quite awhile to get the new layout complete, and I think we are just about ready to run the second prototype! There are quite a number of changes to this board over the previous version, so I do expect a few, ahem, challenges perhaps? That said, a lot of time has been spent testing on breadboards and optimizing so I think we should be close to the final specs on this system. As mentioned, there are code breaking changes with the system. I will post more for the devs out there in a post below. The VERA has also changed quite a bit. Namely, it now has 32 registers, but I'll let @Frank van den Hoef talk more about that when he is ready to post some updates. Also, I made two proto boards to test the bus and get the alignment right for the final design. Progress is being made, thanks for everyone's patience and have a great day!
  17. 16 points
    Hi all, I've spent that much time rummaging through documentation for vera trying to find how to set things up and which blasted $9f!*'@! did what, I thought I'd make myself a crib sheet with all the info on a single page (well, most of it!). I've attached a .png and a .pdf here for anyone to download and use if you want. I'm working exclusively in tile mode at the moment, so this crib sheet only covers that - I might do another one for bitmap mode when I start trying that. Hope it's useful to someone else! vera register info sheet.pdf
  18. 15 points
    Attack of the Petscii Robots (Shareware) View File This is a shareware version of Petscii Robots. It only includes 2 maps. It also lacks SNES controls and the cheat-code. It is also only presented in "color PETSCII" mode, as there hasn't been a version made yet with custom graphics and sound. The music routine is a direct port from the PET, which only uses 1 square-wave voice. PETFONT.PRG Submitter The 8-Bit Guy Submitted 03/04/21 Category Games  
  19. 15 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.
  20. 15 points
    I’m not posting this as an official update announcement as it’s not finished but wanted to whet your appetites. Also big shoutout to @Michael Steil and @Frank van den Hoef. Frank wrote the main driver which was way faster and more complete than the old one and Micheal extended its functionality. The next emulator release has major improvements to the DOS for the SD card filesystem. The main ones are: A lot of progress has been made with the X16 DOS. It's almost feature complete, and almost has feature parity with CMD floppy and hard drives. • Long filename support • You can open files for reading (OPEN2,8,2,"FILE") or for writing (OPEN2,8,2,"FILE,P,W"), read and write data, have four of them open at the same time, etc. etc. • Overwriting files is done with "@:". • You can copy files (DOS"C:BACKUP=ORIGINAL"), concatenate files (DOS"C:ALL=FILE*"), all with wildcards. • You can rename files (DOS"C:NEW=OLD"). • You can delete files (DOS"S:R*,Q*"). • You can lock/unlock files (DOS"L:R*" or DOS"F-L:R*"/DOS"F-U:R*"). • Like on CMD devices, create directories (DOS"MD:DIR), delete them (DOS"RD:DIR), change them (DOS"CD:DIR). • You can use paths everywhere (DOS"C//BACKUP/:FILE.TXT=FILE.TXT", DOS"$//BACKUP/:A*") • All commands and paths support drive/media numbers (DOS"$1:*"), but only 0 (current) and 1 (only supported partition) work. • You can get partitioning info (DOS"GP"+CHR$(1)) like on CMD hard disks. • You can even read/write DOS memory and execute code in a DOS context (M-R, M-W, M-E). Yeah, not that useful. • All error messages on the status channel (just type "DOS") are consistent with 1541/1571/CMD drives, e.g. 01, FILES SCRATCHED,05,00 etc. What's missing: • Open file for appending (,P,A). • Show/change disk name. • mkfs (N) • fsck (`V') • timestamp support What's missing that I'm not sure should be added: • REL files • block read/write API Sent from my iPhone using Tapatalk
  21. 14 points
    Hello all, My name is Frank van den Hoef and I am responsible for the design of the VERA module (the audio, video and storage hardware module), which is part of the Commander X16.
  22. 14 points
    Hi everyone, while The 8-Bit guys needs no introduction, we thought the rest of the team should properly introduce themselves! I'll start the ball rolling... I'm a husband & father of 3 (furbabies), & actor-writer with a love of retrogaming. You might have seen or heard me at Perifractic’s Retro Recipes on YouTube, and I've been making retro music since before it was retro! For the fantastic Commander X16 project I'm proud to be heading up the design and branding, among other things. Here's what falls under my umbrella, along with the help of some other very talented folks: This website's creation and hosting Case design & manufacture Keyboard design & manufacture X16 Butterfly Logo design & implementation Licensing Commodore BASIC & Kernel "Just the BASICs" user guide Packaging design & manufacture BASIC screen visual design/logo... I'm super excited as David's vision of his dream computer comes closer to fruition and am proud to be a small part of making that dream come true. I look forward to chatting with you all here further! Your friend in retro, Perifractic
  23. 14 points

    Version 1.3.0

    219 downloads

    Raycaster demo (written in c and assembly) This version is a big improvement in performance: it now runs at 10+ fps! I am quite happy with the speed. The demo plays quite nicely now. See below description of version 1.3.0 for details. --- This is a raycaster demo written in c and assembly 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! This is how it looks now: Speed improvements in 1.3.0: Now running at 10+ fps! - Using zero page addresses for pretty much all my variables - Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication - Inlined the fast multipliers, so less copying of values, no jsr and rts - Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done) - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused - Cleaned up the main loop and several other parts - Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) New in this version 1.2.0: - draw functions have been ported to assembly. Much faster! - dda casting functions have been ported to assembly. Much faster! - drawing textures! - automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel) - automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel) - using joystick controls (you can use arrow keys and alt to control, you can hold down keys) - a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup) - changed the map to look like the first level in Wolfenstein 3D - added a border around the render area, just like Wolfenstein 3D Usage Unpack the zip. Make sure you have the .BIN files in the same folder as the source files. To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3 To run: x16emu.exe -prg RAY.PRG -run To play: up - move forwards down - move backwards left - turn left right - turn right alt-left - strafe left alt-right - strafe right To debug: p - turn on log screen o - turn off log screen t - turn on test ray l - rotate test ray left j - rotate test ray right Known issues (1.2.0) - Sometimes there is a corner of a wall not drawn correctly - Since there is no real V-sync you get "shearing" in the screen (requires double buffering) Next up: - Lots of speed improvements - Lots of cleanup of code (its messy now) - Add a time-per-frame indicator (using a vsync interrupt counter) - Mooaarr wall-textures! - Double buffer to prevent shearing - Show a map on the screen - Bigger map (limit is now 16x16) - Opening doors - Add (scaled) "sprites" - Lamps (scaled) hanging from ceiling - Stats in lower part, gun visible - AI, enemies Having fun! Jeffrey
  24. 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.
  25. 13 points
    David has posted a video defending his actions and why the IBM thing was not "really dumb" as you put it. A vast majority of electronics engineers agree. Please watch your language and remember the group rules you agreed to when joining.
  26. 12 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
  27. 12 points
    Here is Adrian's video about the troubleshooting:
  28. 12 points
    Right, as I think David said, the only people who get nothing wrong are the people who do nothing. Whilst I can see the perspective of some people about some of the things, with nearly a million people having lost their lives from this terrible pandemic, abusing somebody because of an old metal screw is frankly preposterous. Some people need a reality check.
  29. 11 points

    Version 1.0.1

    27 downloads

    This is a simple voxel demo written in 65c02 assembly. It has been tested in the r38 emulator. Press W A S D to move around. Press SPACE to quit.
  30. 11 points
    I've been working on a simple text editor for some time, and uploaded it to Github today. The editor is heavily inspired by GNU Nano, but not intended to have all its functions. It's just too much work in 65c02 assembly, at least for me At this moment basic editing works more or less, and the program is fairly stable. Text entered by the user is stored in banked RAM. File handling waits until the emulator supports reading and writing sequential files. Check it out on github https://github.com/stefan-b-jakobsson/x16-edit I also include the binary for my 0.0.1 release. It's tested in emulator version r37. x16edit-0.0.1.prg
  31. 11 points
    Hello Everyone! I know it's been awhile since there has been an update, so here goes: Earlier this year I had mostly completed the "Proto #2" motherboard. It was a mad dash to get the PCB made before we met in New Jersey at VCF. Right at the end, @Frank van den Hoef made a pretty substantial change to the VERA, which required a bit of reworking. April came, the trip was cancelled and life went sideways for a bit for the world. As such, I decided I needed to focus on a few things for TexElec, and took a bit of time off from the project. Last month I picked up where I left off and planned to make minor changes for the VERA and get the PCB made. However, the team had some time to think and oversights and optimizations became apparent. One change led to another, and let's just say, we're gonna break some code. Sorry. I do believe the changes made will not disappoint. I'm not going to reveal them just yet. I am still laying out the PCB and would like to do some testing to make sure it's going to work as designed. I am trying not to release too much of the schematic until the end, as anything is subject to change at this point. The pic below is how I have the expansion bus pinned out. I may well move some the pins around to simplify layout, so again, not in stone yet, but I do think this is pretty close to what pins will be present. This post is majorly TLDR already, so I'll add a comment below with more info on the pins, and the idea behind some of it. Take care!
  32. 11 points
    The Assembly Environment (V0.8) is released, you can get the beta here: https://sites.google.com/view/x16asmenv/home I've also got a video about this release: https://youtu.be/adohtDGGPbE This release is now the first to be considered "beta", since I believe it to be feature complete (based on original plans). From here on out I'll be fixing bugs and making it rom enabled. Comments and bugs welcome!
  33. 11 points
    On the real hardware, there will be a way to reprogram the FPGA image if necessary to fix any bugs that are discovered after release. (This involves putting a jumper on the VERA board to enable access to the flash chip from the CPU.) So yes, if you would like to hack around you can, it is (will be) your hardware. Also the FPGA does have a feature where it can store up to 4 FPGA images in the flash chip, which could be nice for hardware hackers to allow the original image to be present in addition to their own creations. Do note, that this will not be officially supported and normally users are expected to run original firmware. So if you mess up, it is on you.
  34. 10 points
    I'm Matt and I'm helping out with the boring tech stuff behind the scenes on here. My journey began with a VIC-20 in the early 80s, followed by a C64 and an Amiga 500 before being dragged kicking and screaming into the PC era in the mid 90s. And basically, it's all downhill from there, which is why when I saw David's video on his dream computer, I simply sat there with an open mouth, nodding along vigorously. Other than that, I'm the writer and producer of the Blue Skies Chronicles® series of novels and audiobooks. Give them a listen, people seem to like them.
  35. 10 points
    This is an unnecessarily critical and inaccurate comment, and isn’t the first time. It is not the tone we want for our forums. Please moderate your future comments before posting. I and others work extremely hard to keep the FAQ up to date and strongly dispute that “obsolete info is the norm around here”. In fact I do not believe there is one piece of obsolete info in the FAQ. And the FAQ is the single point that we send everyone to for the latest info. We are consistent about that. We cannot control somebody outside the core team mentioning to you something that they saw in a video by Kevin, and that person you chatted to labelling it an official announcement. Criticising a team who are working for free for not copying every thing that is said in a video into the already extensive FAQ is unreasonable. Michael is also not done with the new emulator version or the GitHub. You need to be more patient. The physical prototype will always be ahead of the GitHub. You also cite a wiki but as I have mentioned before, and as is clearly stated in the wiki itself, it is not official and we do not run the wiki. Would you prefer we have the fans who do run it take it down permanently if it does not meet your requirements? Finally please remember that this product has not even been released yet, nor have we taken a penny from anybody for it. We are offering unprecedented behind-the-scenes access to the development, which I don’t think has ever been done to this extent before even crowdfunding commences. Criticising us because we do not meet your high (and erroneous) standards will not be tolerated further. This thread has also run its course, with some unfriendly moments before today, so I hope everybody can just take a breath and perhaps move onto a different topic. Thank you for your understating.
  36. 10 points
    Hello everyone! My name is Michael Steil, and I'm a member of the X16 development team. I am the lead developer of: the X16 ROM the (advanced) KERNAL operating system our version of the Microsoft/Commodore BASIC interpreter our MONITOR the DOS for the SD card the GEOS port the X16 character sets the X16 Emulator the X16 Reference Documentation I'm thankful for any help on these projects, all of which are Open Source projects on GitHub: https://github.com/commanderx16/x16-rom https://github.com/commanderx16/x16-emulator https://github.com/commanderx16/x16-docs (Edit: Or via this website's Support page: https://www.commanderx16.com/forum/index.php?/forum/17-x16-help-support-lounge/) Technical discussions on these projects should happen in the form of "Issues" on GitHub, but I'm happy to discuss more generic topic here in this forum! Michael
  37. 10 points
    What do you guys think of the Raspberry Pi 400 complete computer kit?
  38. 10 points
    Maybe I am too old, but I don't see the big deal. I see tech videos all the time (modern and retro) that do things differently than I would. Sometimes it works, sometimes not, we all live and learn. As far using a paperclip to power up a PSU or jump a connection, that's common, even today on modern hardware. Similar to firing up a build outside of a case with no switch, just shorting the power switch pins on the MB with a screwdriver. Cutting proprietary or uncommon screw heads off, I have done that as well on old hardware. Eventually, all hardware needs servicing, one way or the other. Personally, none of this changes how I feel about the X16 or David. He had nothing to go on with that computer, other than his experience, and as he said, he's done that sort of thing many times with no problems at all. As have many of us. I didn't even know this was an "issue" until I seen this post.
  39. 10 points
    We don't have the final power draw figures as yet, but the plan is to ship without a cooling fan being necessary. Again that is not final, but is the hope. Crucially I have allowed space in the case to add a standard fan should you expand to where that is necessary. The fan can connect to the PSU directly and there is a place for the cable too. The current PSU we are using (photos coming soon) is 180W. This isn't because we need it (though we can't rule out the community's expansion needs) but is the smallest that is available which is also compatible with the board and case. Expansion needs also therefore benefit in future. We could have gone with an external PSU and a smaller case, but I'm not a fan of the external bricks and we love the idea of machines like the Apple ][ where the PSU is enclosed and you just plug in and go. Also again, a little spare space in the case allows for community expansions, mods and hacks. Also some other thing(s) I can't mention yet (nothing to get too excited about). The Picos have some small issues, they were discussed, but we opted for the more solid solution.
  40. 9 points
    The initial production run is going to set us back some serious cash. So, I'd think everyone involved would be happy to sell them all as quickly as possible to get us back in the black.
  41. 9 points

    Version 1.2.0

    147 downloads

    This is a minesweeper clone for the Commander X16. It allows custom minefield sizes up to 38x24, with almost any amount of mines. To start, load and run MINEX16.PRG. Controls: Main Game Left click to reveal a tile Right click to flag a tile Click on the face to reset Press space to open the configuration screen (will reset the minefield) To exit, reset the machine (Ctrl-R on the emulator) Configuration Space to open and close Use the + and - buttons next to each digit to change the width, height, and number of mines Numbers are capped to a specific range; attempting to select an invalid value will set the number to its maximum or minimum value Click any of the presets to set all of the numbers at once Note: The game uses kernal functions to handle the mouse, so any weirdness is most likely caused by the emulator.
  42. 9 points

    Version 1.0.0

    11 downloads

    This weekend, I decided to play with X16 BASIC using the emulator and wound up making an X16 adaptation/extension of a short program for the Plus/4 that appeared in 'The Transactor' journal decades ago. The program uses three parameters: "S" (squiggles/spokes/segments), "W" (wave factor), and "A" (amplitude). Using X16 BASIC's extensions in terms of bitmap drawing commands, it outputs a neat design with lots of color and a surprising amount of visual variety. The original Plus/4 program just plotted in black and white and had some built in limitations (and at least two bugs), but I decided to extend the program, add a menu, and upload it after I added color and decided these were fairly cool looking results from such a short simple BASIC routine. It strikes me as a cool demo because with just three core parameters, you can get an astonishing range of outputs. Of course, like many graphics demos based on stacking transcendental functions, there are combos of inputs where the functions will sort of fall apart and produce something akin to a kiddo scribbling with crayons , but there are also weird "islands" in the domain of possible parameter combinations where order re-asserts itself, both in terms of what gets drawn and (because colors are picked by an AND mask over one of the function variables) how the colors play out. Note that I included a sample screen shot about some weirdness you can get with very high numbers. Mostly that is the result of my simple use of .01745 to convert between degrees and radians, and is caused by amplifying that really simplified rounding of PI/180. There are 4 'modes' of operation you can pick from the menu. You can specify inputs for S, W and A manually; the program can run a sequence with fixed S and A while incrementing W; there is a mode that tries to picks random parameters within several domains where the program produces nice outputs; and there's one that just reads the inputs from some "presets" in DATA statements. (You can of course add your own 'best of' examples by adding data statements between lines 432 and 499). I always considered myself a passable BASIC programmer, but this weekend showed me I'm really sort of rusty so please go easy on me if I did something inefficiently or especially 'dumb' in my implementation. The main output routine is extremely crunched (sorry, not sorry) and I did some further things to optimize from the original program for purposes of getting a bit more performance out of the main routine. Although it absolutely crawled on the Plus4, I think its fairly impressive on the X16 especially if you look at the sheer amount of sines, cosines, multiplications, and variable fetches /updates that occur during an entire cycle through the primary output drawing loops. The X16's 40 column mode (SCREEN $00) was used to key this in and format it, so its probably best if listed/ displayed/reviewed in that mode, Tested on emulator r.38, and I don't see anything in the pending updates for the next emulator release that would break anything here. If there are questions about why/how I did something I'll be happy to answer. In fact, if there's any interest in a more detailed write-up of this short and fairly simple program (e.g., section by section, and line-by-line), I would be happy to give it a shot, especially if there are folks new to Commodore BASIC that might find it useful. It seems to me there are many highly advanced programmers for the X16 posting on this site who are using assembly, C, and even languages they are developing themselves. Its amazing! However, its surely the case that part of the mission of the X16 is to get some newbies involved, and from where I sit, that really does mean getting some more content up here written in BASIC. Keeping that in mind, I'll probably be diving back into more old issues of The Transactor to do more conversions for the X16 and will continue to upload as long as I'm still having fun with BASIC. Cheers.
  43. 9 points

    Version 1.0.0

    23 downloads

    Another small intro. Sadly still no audio. If only it wasn't so painful to debug audio and if I had any sort of musical talent... Thanks for looking! Spinner.zip
  44. 9 points
    https://youtu.be/tPZNQcl0JYE I've written a proof-of-concept program that uses the actual AdLib music data from Wolfenstein3d and plays it back on the YM2151 chip by translating the register writes from OPL commands into their equivalent OPM (2151) commands if possible. There is still work to be done. The vibrato effects are definitely doable, but the translation is going to take some consideration on my part, as the two chips do it in very different ways. The Wolf3d title screen music does not make use of percussion mode (as far as I could tell) but obviously a true translation driver must be able to handle those, and I think I'll work on doing that with the VERA PSG voices. I will post a link to the sources once I get the ability to load the titlescreen graphics, etc. from within the program itself. (my vload() function doesn't seem to work properly).
  45. 9 points

    Version R39 Preview

    967 downloads

    X16 Edit is a text editor for the Commander X16 platform. Design goals: Use plain text files Store text buffer in banked RAM (512KB to 2 MB) Handle large texts efficiently Simple modeless user interface inspired by GNU Nano Implement basic editing functions well - refrain from making the program too feature-rich Support both ISO and PETSCII modes Tested with emulator version r38. Run with the following command: x16emu -sdcard sdcard.img -prg X16EDIT-x.x.x.PRG -run where x.x.x is the program version. You can also run the program with the "Try it now" button. There is, however, no attached disk in the online emulator, and consequently you cannot save or open files. Also, some of the Ctrl+key sequences are not working in the online emulator. To fully test the program you still need to download and run it locally. Please read the attached file romnotes.pdf if you want to try the ROM version. Source files available at https://github.com/stefan-b-jakobsson/x16-edit Released under GNU General Public License v 3 or later. romnotes.pdf manual.pdf
  46. 9 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.
  47. 9 points

    Version r38 ("Kyoto")

    6978 downloads

    Precompiled emulators for Windows, Mac, and Linux. This is the latest version. Older versions can be downloaded from the GitHub releases page. (Note: To run on Mac use "Ctrl-click/Right-click > Open" instead of "Double-click" due to security protocols)
  48. 9 points
    You both have some good points, but just to repeat what has been said before, and is posted in the rules at the top of the main forum page: So as of now, we're not discussing open sourcing or ports to other machines. Our machine isn't even out yet. So let's save this discussion for a later time eh? 🕹
  49. 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".
  50. 8 points
    Another reason is that it is an 8-Bit machine with 16-Bit tendencies.
×
×
  • Create New...

Important Information

Please review our Terms of Use