Jump to content


Popular Content

Showing content with the highest reputation since 06/15/20 in Posts

  1. 13 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
  2. 11 points
    Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
  3. 7 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
  4. 6 points
    The Emulator and the ROM have been adapted for the new board. You can check out branches x16_board_r2 in the source of the two projects. The official reference manual has also been updated. In short, these are the major breaking changes: RAM and ROM banking is done through magic zero page locations 0 and 1. Up to 512 KB of ROM are now supported. VIA#1 is now at $9F00, VIA#2 at $9F10 YM is at $9F40 All I/O (PS/2, Controllers, Serial) has been moved to VIA#1 PA and PB.
  5. 6 points
    I am an expat professor teaching in English before our students transfer to the US. My first computer was a Timex Sinclair, which turned out to be closet compatible, but the next summer when I had the chance to buy better, I was shopping for the cheapest home computer with a real keyboard and disk drive, which was the C64. I used it to edit my undergrad senior thesis, play a few type in with error check magazine games and get started programming in Forth. I took a Epson Geneva with me to the Peace Corps, and got a C128D when I got back... which I all too soon fried with a power tap for my parallel printer interface which didn't have the block inserted to prevent plugging in upside down and shorting out the datasette lines connected directly to the processor. So it was my old C64 breadbox and portable color TV with bad ghosting on one color which was the computer I took to grad school in the late 80s early 90s. My daisywheel printer was slow but looked prettier than classmates with IBM pcs and dot matrix printers, and my 1581 which survived my C128D dying worked fine with my warpspeed cartridge. But I got a cheap Amstrad double floppy transportable with flip up LCD screen and it was on my PC compatible I did my only serious programming, a brute force maximum entropy estimator of an economic Input-Output model. It took near a day to do a run, while I am sure with the right R package I could do it today in a couple of minutes. I went off for a decade to teach in Australia, and played around with Forth now and again, but if I turned on my PC for research it was mostly using Excel to figure out what suspect games public planning agencies were playing with public transport cost benefit analysis. Now there are no kids in the house, and I have some notions I never followed up on in the 80s which would be a lot more pleasant to play around with on the CX16 than on a C64. So I can't wait to get my hand on a CX16c or e (depending on what I can afford with 8 grandkids to get gifts for).
  6. 5 points
    Hello I've been slowly trying to learn 6502 assembler by building an X16 game engine. But better than that - you can watch me do it on twitch as I stare confused at my screen whilst mumbling to myself next to a microphone! Please visit the channel and say hi or follow
  7. 5 points
    My path is recounted in my intro in the intro thread, so the quick shortcut version ... Timex Sinclair, membrane keyboard, tape storage, 16KB RAM expansion crashing, into the closet, next comes the C64, an Epson Geneva for my Peace Corps teaching in Grenada in the mid 80s, back to US, a C128D where I fried the processor, back to my C64, off to Grad School where my C64, BusyBee PerfectWriter, Big Blue Reader, 1541 and 1581 drives and daisywheel printer were my paper writing setup for two years, then a cheap liquidation two floppy transportable as hard drive systems were becoming the main thing, then relying on office PCs and cheap two generations old PCs until the present.
  8. 5 points
    Hi everyone I'm Andy (Andreas, actually) from Switzerland. Back in the 80ies I came into computing because of my father. It all started with a Texas Instruments TI99/4A he bought in 1982, I was 12 by then. So I did some Basic programming, even got a little into assembler. The machine was quite limited, but I loved it - it did what I told it to do! Mostly that was also what I wanted it to do... We then moved on to a Commodore SX64 (the 'portable' version of the C64) in 1984, although that was my fathers machine he brought home from the office frequently. The amount of software and games for that machine was quite overwhelming. In 1986 we then got an Atari ST. For me this was just plain magic! With it's large memory, colorful graphics and (not so much sound) capabilities it was just crazy! I there got into programming with structured languages like Pascal and C - there I decided to go into computer science as a profession. Around 1989 onwards the IBM compatibles took over and I started my study. That was the time when computers kind of lost their magic for me... Don't know, but somehow they were just boring tools which did their job. But they were never as exciting again. Just boring grey boxes which initially didn't even compare with the Atari ST. So now I stumbled over this project here - and I get it! 8 bit computers like the C64 or to some extend the original Atari ST were simple and actually easy to understand. My dayjob doesn't involve programming any more - and I miss it. Tinkering with IoT stuff and my smart home setup is fun, yes, but not as rewarding as getting the maximung out of a limited machine. I'm now thinking about getting into developing for the X16 - just don't know what it should be yet... so let's see what happens ...
  9. 4 points
    Look what Lego are about to release...
  10. 4 points
    YM2151 SYNTH UI View File A simple user interface for the YM2151 synth. Usage: LOAD "SYNTHUI.PRG",8,1 SYS$1000 Use the keys as any tracker to play. Use the sliders an buttons with the mouse to adjust synth params. Submitter Miklós Pathy Submitted 07/11/20 Category Audio Apps  
  11. 4 points
    Brixx View File This is a Breakout/Blockout/Arkanoid inspired game. . It is early stages, this is my very first try on the X16. You have to use a mouse. I'd also like to improve it with more sound effects, title screen, intro music etc. I've only tested it on the emulator, so if anyone of the few with real hardware can give it a go, I'm eager to know the result. Available power ups (no keycodes, you have to catch the dropping batches): [L]: adds one live to player [M]: paddle is magnetic for 30 seconds. Can only hold one ball at a time. [C]: twin laser cannon for 15 seconds, 16 rounds in a row (if you are quick). [D]:Duplicates ball, so now you can have fun with 2... Keyboard commands: 's': sound on/off. 'q': quit game. Roadmap: - basic sound effects. done - power ups like double size paddle, 3 balls at once etc. done - Joystick support - Intro screen (with intro music?) - High-score screen Let me know what you think... Submitter AndyMt Submitted 06/29/20 Category Games  
  12. 4 points
    The debugger doesn't currently allow you to fill values in memory... that said, I happen to be in the middle of some changes to the debugger based on a separate suggestion to make it possible to dump VRAM, so I think I'll go ahead and add a "fill" command while I'm at it. So hopefully it'd make it into r38, which shouldn't be too far off on the horizon.
  13. 4 points
    Maintenance releases? How about more regular releases? I'll try that!
  14. 4 points
    I started to program as a young child in the early/mid 80's on an Acorn Electron (you may not have picked up on it, but there's a clue to my first favourite game, and most nostalgic). Eventually got an Amiga 500, and soon after that an Amiga 1200 - loved using AMOS, Octamed, Deluxe Paint, WordPerfect (for course work) and of course hundreds of games and demos, which I used throughout college. While at university I had moved on to a 486dx66 with DOS and Windows 3.11 (although I still far preferred the Amiga). The last 20 years I've almost exclusively been using Linux, although I still occasionally use my A1200 and Acorn Electron, both of which have been upgraded to varying degrees since I first got them.
  15. 4 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!
  16. 4 points
    So I've made up my mind what to do. I'll start by implementing a Breakout/Arkanoid alike game in C using cc65 and maybe some assembler . I think this will get me into sprites and tiled graphics. Some very early prototype is already working, showing some sprites, accessing the mouse and switching video modes etc. It was fun digging into the VERA documentation and fiddling with bit fields again... I'll post a Prg when there is something playable.
  17. 3 points
    I want to write a programming language for the X16 called Base Camp. I want to write a language because although BASIC is an awesome language the one issue I have with it is that its interpreted so I want Base Camp to be similar to BASIC but with components of modern languages(for example functions) I also would like it to be compiled. Before I can start I have a few questions: 1. Is it practical(should I create Base Camp or is it a bad idea)? 2. Is it possible(is it possible to write Base Camp)? 3. Are there any text editors for the X16 and if not how could I write one? 4. Should I write Base Camp in BASIC or assembly(I'm pretty sure ill write in it assembly but I want to hear other peoples opinions.) My skills: I have worked with x86 assembly and am learning 6502 assembly. Any comments would be appreciated. Thank You!
  18. 3 points
    Hi all, I'm Ron Rhodes from Sunnyvale, California. I first started programming in Fortran on punched cards at U.C. Berkeley. Then I learned IBM Assembly on a 360. I worked at Radio Shack so I learned BASIC on the TRS-80, Color Computer and the PC (the Tandy Pocket Computer came first). My first programming job was CBasic on an 8 inch floppy system running Chromix. Then Captain Kirk told me to buy a Vic-20, so I did. My first real program used up all the memory so I got a 5K extender, and then a C64 and eventually a C128 (still have them). I longed for an Amiga for a long time until it was too long. So I got a PowerPC Mac. Of course I used PCs at work. We also used an HP 3000 (IMAGE database), DEC VAX VMS, Silicon Graphics and finally some generic hardware running RedHat Linux. Got heavily into Oracle relational DB and Informatica, Spotfire and whatever else worked. I once wrote a bar code reading script that ran in Reflection terminal emulator for a drug testing robot. I can remember typing in hexcode programs from the magazines, and trying to download programs from Quantum-Link at 300 baud. (I still have my 5 inch floppy notepad with the hole in the middle of it). I played around with a FORTH cartridge and ended up instead sending PostScript to a Laserjet. I created my own barcode labels. Joined the Stanford Macintosh Users Group to get the monthly shareware diskette. Saw Jay Minor at an Amiga meeting in Palo Alto. I kept trying to learn JAVA but the environment changed so fast at the time. I did more JavaScript coding. Wrote a useful program in HyperCard for a presentation at work. Wrote one side scroller game in Flash when I had some time off (laid off actually). Currently, I'm playing around with Arduinos and circuits using C but would like an excuse to learn Python, maybe an ESP32 app. I don't know if I'd buy a Commander X16 but I love the enthusiasm of the retro community.
  19. 3 points
    If you have a Best Buy or similar store nearby, they have Corsair keyboards on display that you can try out. Granted, you'll want to wash your hands thoroughly afterwards (or wear rubber gloves), due to COVID. But the Corsair keyboards will use Cherry MX switches of some sort, and you can get an idea for how they feel. If it's not evident, just pop a keycap off and look at the color of the stem, and you'll know what kind of switch it is. I'm typing this on a keyboard with MX Reds. I'd prefer Blues, but I spend too much time on conference calls for the noise level to be acceptable. I used to get comments from coworkers when I was on calls and typing on an old IBM keyboard with buckling springs (best keyboard ever).
  20. 3 points
    Hi I'm Ed Minchau. I started programming in 1981 on the Apple II and quickly bought myself a Commodore Vic-20. Due to financial difficulties, I ended up using that Vic20 until 1999 or so. As a result, I got a lot of practice programming in 6502 assembler. Oftentimes while I was in school taking FORTRAN77 or Pascal or C courses, I'd write the program first on the Vic in BASIC just to get the logic right and then translate it into whatever language I was studying! I've been spending the last ten months or so writing an assembly language editor for the Commander X16. Version 1.0 came out in January, version 1.1 came out in April, and the new and much bigger and vastly improved version 1.2 is nearly done.
  21. 3 points
    I had originally planned to leave this topic alone if there wasn't much interest, but now I want to plug just one more video from this channel, because the exact parallax technique Sega used in Sonic the Hedgehog is something that I've discussed a couple of times in the Facebook group, as a viable technique on the VERA. And, in fact, this video shows just how similar the VERA's capabilities are to the Genesis' video processing, right down to the limitation on how many sprites can be drawn on a single line. (However, line IRQs are broken in r37, but the github repo has the fix so you can either grab and compile from there, or wait until r38.)
  22. 3 points
    Just for fun and because it has been asked a few times I want to explain what would be required to use a VIC-II or SID or really any chips that are too slow under normal circumstances. I’m not saying either of these is really a useful idea, but it makes a good introduction to how to use such things on expansion cards. Also up front this article is going to use layman’s terms but is still geared at those interested in hardware. Since it’s the less complex option, I’ll start with how you would use a SID chip. Probably the best point to emphasis because it affects any chip you want to interface to the bus is the access window. The CPU in the x16 uses half cycle access for memory or IO. This means that in each clock cycle the first half of the cycle is spent doing internal processor stuff and setting this up for the actual bus access. During the second half of the cycle the cpu performs either a read or a write access to memory or IO. This time we will refer to as the access window. And all chips on this bus need to be able to respond to read/write operations within that window. So how long is this access window? Well it is measured in nanoseconds. To give you some context, if you have a clock running at 1 MHz, there are exactly 1000 nanoseconds in that one cycle. So if our cpu was running at 1 MHz our access window would be slightly less than half that, about 500ns. If we increase to 2 MHz that access window decreases to about 250ns. However I’m doing a rough approximation because there are some factors that also affect how much of that access window is really usable. There is address deciding aka glue logic that reads which address the cpu is trying to address and then selects or enables the appropriate chips. This process is not instantaneous, and the amount of time it takes for the inputs address lines from the cpu) to the outputs (chip select lines from the logic) is going to be referred to here as propagation delay. This delay is also in nanoseconds and for the sake of simplicity we are going to state this value as 20ns. So with this value we will then see our usable access window at 1mhz is closer to 480ns and at 2mgz would be closer to 230ns. So let’s consider this for the 8MHz that the x16 runs at. We get an nominal window of 62 nanoseconds but an effective window of 42 nanoseconds. So what this means is that any chip that will connect to the bus, be it RAM, ROM, IO chips, video chips, audio chips, etc. must be able to respond to a read or write in less than 42 nanoseconds in order to work reliably. There are ways around this and I will get to them later, but I’m just making the point that any chip that connects directly to the system bus must be able to respond within that access window. In the case of a SID chip I’m not sure what it’s access time is, but it’s likely in the 150-200nS range. So it would work at 1-2 MHz reliably and might work with 4mhz. But it won’t work reliably on an 8mhz bus without some type of buffering. So if you were to implement one, you have several option on how to go about it. If you aren’t concerned with reading the chip, then you could use latches. You would need to latch the data and the address and implement some type of timer to extend the hold time. What you are doing in this case is that instead of interfacing to the SID directly you are instead interfacing to a simple latch which just captures the relevant address lines and the 8 bit data. This buffer then outputs those values for as long as needed. To enable the chip to be read requires some additional circuitry. This method can actually be used for both reads and writes and involves halting the CPU to extend the access window across one or more CPU cycles. Basically when an access occurs the RDY line needs to be pulled low while the BE (Bus Enable) line is pulled high. This causes the CPU to be halted in its current state. Using binary counters we can hold this state for as many cycles as we need. Keeping in mind for an 8 MHz bus if we extend the acces by just one cycle what we actually get is 42ns+125ns for a total of 167ns and if we need more time we get an additional 125ns for each cycle we extend that window by. Keep in mind this method does require the use of bi-directional tranceivers or equivalent. Now to use the VIC-II chip is quite a bit trickier. Basically the main issues is the VIC-II needs access to memory. Since there is no way you could make it play nice with the X16 memory space you’d need to give it its own memory. You would need to design some kind of circuit that would act as a bus bridge. this bridge would have to facilitate both reading and writing to the Vic-IIChip-II chip itself but would also have to act as an indirect memory window. This is doable but is not a lighthearted undertaking. I’m not suggesting anyone actually tackle this I’m just saying that it is possible and that this is what would have to take place. I feel I should also add though that doing these things would not make the X16 capable of running C64 software. i’m merely laying out what would need to take place to make it possible to interface with these chips not what would need to take place to emulate another system. This is just a fun thought experiment and a good opportunity for me to explain how it would be done. One follow up too, this is by no means a definitive guide on the actual timing requirements. The reality is the timing is probably more forgiving that what I’ve stated here, my 20ns example is more like a worst case scenario. We don’t have hard figures on the actual timing yet, for that we need to finalize all details of the board and measure multiple samples at different temperatures and voltage ranges. . Sent from my iPhone using Tapatalk
  23. 3 points
    Im a spanish kid that likes electronics, In 2018 I discovered the retro computer comunity and obviously the 8 bit guy and LGR.
  24. 3 points
    I've been busy with all kinds of other projects for quite a while, but I'm back to X16 development now. I'm currently in the process of changing the emulator and the ROM over to revision 2 of the actual board, which has changed in respect to memory and VIA layout. As for pull requests, that's the next thing that I'll have a look at!
  25. 3 points
    Introducing the new X16 Twitter Bot: send it a program on Twitter (if you have an account) and it will run it! See by yourself: Okay, that was kind of a boring example, but you get it. Once you mention it on Twitter (the messsage must begin with a line number), the bot will take your message, run it in the emulator for 33 seconds, leverage its GIF-making feature and reply to your message with the last 3 seconds of execution. The bot also support binary PRG programs (tutorial coming soon, uses base2048 if you can figure it out, experimental). So in short, it works very similarly as other bots such as @bbcmicrobot or @auto_tweetcart. Very useful to share cool snippets on Twitter, or for practicing yourself at code golf. I kinda want to build a community on Twitter around it as well, so why not? It's also gonna unofficially post the interesting news for those who don't have Facebook. So yeah, try it out and have fun! Note that the same rules apply as here.
  26. 3 points
    Thanks! Also since it's still the 4th of July here... (gotta love the automatic Twitter embeds :))
  27. 3 points
    Another demo update:
  28. 3 points
    I wouldn't be surprised either. Also, you should read the FAQ right though every morning before you get out of bed.
  29. 3 points
    For me, it was an Apple //c with an Epson FX-80+. I typed up a lot of papers on that, and made a lot of money doing so, as well.
  30. 3 points
    Having way too much old stuff in my garage, I wanted to have an other 8 bits thing to play with Making electronics and software for more than 30 years now, a new 8bits platform is always a new playground to experiment and keep my assembler skill at level. In this FPGA era I love (cheap FPGA was a dream only 10 years ago), programming on real silicon is always a good thing. Now I'm waiting for the pre-orders .... Keep up the good work ! Olivier
  31. 3 points
    Started 40 years ago with a Sinclair ZX80. I'm very curious to see if a Z80 card can be made that will run on the Commander x16
  32. 3 points
    Glad I stumbled here. As I don't use Facebook, I had felt out of the loop with the Commander X16, and the murray2.com forum just disappeared, so I found this (almost) purely by chance. Actually, I had built my own Gigatron, as I was really lucky to get one of the last ones including a case. https://gigatron.io/ (yes, the one that The 8-Bit Guy reviewed, along with Dave EEV Blog and Ben Heck)... I can't recommend it enough, for soldering, hacking, software, and the still active community. So, long story short, I found myself here! However, the Commander X16 seems to tick all of the boxes I had in a "modern-retro" device, and it looks like everyone involved here are doing a fantastic job. Looking forward to all and any progress
  33. 3 points
    Hello, everyone! My real name is Vladimir (like in Baron Vladimir Harkonnen from Dune, hehe). I'm from Kyiv (Kiev), Ukraine. I got my first PC at the age of 12. It was POISK, a Soviet not fully IBM compatible machine from the early 90's. With it I got familiar with BASIC and computers in general. I'm very happy that retro computing lives to this day, and has a significant burst in the last several years. I'm following the development of X16 from the very beginning, when David mentioned about his dream computer for the first time. And I'm looking forward to all future events. To the final product... and beyond!
  34. 3 points
    The hardware really only has one output resolution: 640x480. 320x200 isn't a resolution that is natively supported by VERA. As far as I know the kernal has this 320x200 resolution as part of the GEOS drawing code, which Michael didn't yet update to make use of the full 240 lines height. As Stephon Horn showed, you can use the scaling to make the 200 lines cover (almost) the full 480 output lines, but it will give some scaling artifacts.
  35. 3 points
    I've removed the case conversion from the code and it's working again. So it's up to the programmer to take care of referencing files correctly again now.
  36. 3 points
    Hi everyone! I've been following the development of the Commander X16 since its announcement, and I'm very impressed with the progress. I've been trying to teach myself 6502 assembly so I can write software for the X16 at the lowest possible level. I've been a bit busy the past few months, but finally feel I have the time to pick it up again. I have a few ideas for software that I'd like to write, and have started learning the basics so I can make it happen. I'm hoping that the Commander X16 can be my 5 year old daughter's very first computer (we don't even give our kids phones or tablets), so she can explore computing from the ground up. I love the ethos and mission of the project, and feel that this computer is going to be the most approachable way for kids (and adults) to learn about computers. I'm happy and grateful for such a wonderful community!
  37. 3 points
    I popped open the emulator source and it looks like "no", which means it's my fault, in my assembly source I'm specifying filenames in upper-case ASCII, which isn't going to map to unshifted PETSCII. My b. Let me make a new release and see if that fixes things. Edit: Perfect. All fixed up.
  38. 3 points
    Hi everybody, I've had a C-128 in the early 90ies and had my first programming expericene on it. I've been following this project since the beginning, but wasn't on FB. I'm mostly interested in programming C for the CX16, gradually optimizing it as my assembler skills improve. Looking forward to buying the machine, once it goes on sale. So all in all, a big shout out to the CX16 team. You guys are amazing!
  39. 3 points
    Hi, Its been 30 years since I got hooked on programing with my Tandy 2100FD in GW-BASIC... I later watched kids learn stuff online that took me years to figure out! Im starting on a quest to learn assembly for my new-ish Plus4 and maybe teach my kids if they get interested. The Commander X16 is deffinately on my wish list ...and maybe the kids can get one too?
  40. 3 points
    Agreed! In future we'll try to only make announcement posts here, then paste the link into FB (which will generate a preview of the post anyway). The website will be the go-to #1 source.
  41. 2 points
    Hello there! So the goal is to introduce ourself right? Well, here I go, I'm a french student of 20 years old and actually doing an applied physics bachelor. And I'm here because I just discovered the 8 Bit Guy like a month ago and its youtube channel fueled my pre-existing interest in retro computers (cause whats the fun with new ones really? ). I dont really own any retro computer for now because I dont have either money or space, so my oldest computer is a Toshiba 4010CDT that I use to play dos games (on floppy disks I adore those). So the idea of this commander x16 interest me as it could give me a small feel of what computing was back then, before I can get old hardware. So thats really all, I code in python and a bit in C#. Hopping to meet some of you on other topics
  42. 2 points
    Hoo boy, that unofficial documentation I wrote so long ago is somewhat out of date. I never updated it for VERA 0.9 (which is rapidly looking like it'll turn out to be VERA 1.0). I wouldn't use it anymore, and in fact I thought I'd made the document private... hrm... Anyways, to most directly answer your questions: Switching layer 0 to "text mode", where the text starts at VRAM address $00000 and glyph data starts at VRAM address $0F800: You can set layer 1, instead, by moving the registers $9F2D-$9F33 to $9F34-$9F3A. In either case, you may need to copy glyph data into VRAM, but apparently the kernal can do this for you if you call the screen_set_charset function: Adding characters to specific parts of the screen: Each cursor location in VRAM is stored as two bytes: Character index (a.k.a. screencode, a.k.a. tile index) in byte 0, color data in byte 1. So if you've configured a layer into text mode per the assembly above, then $00000 contains the character at <0, 0> (top-left corner of the screen), $00001 contains that character's color. $00002 contains the character at <0, 1>, $00003 contains its color. If you inspect the configuration options carefully, you'll see that the text mode setup here is 128x64. This is the same as the default text console on system startup, you'll have to handle the 80-column limit yourself, just as the kernal does. Or not, use layer scrolling and have up to 128 characters per line. Besides being a technical limitation of the VERA (it can't specifically do an 80-wide map, the map sizes are all powers of 2), 128 is convenient because it means a row of characters is 256 bytes wide (128 characters * 2 bytes per character = 256 bytes). So for any coordinates <X, Y>, the lowest byte of VRAM is always 2*X, and the next byte is always Y. $00708 is <4, 7>. $00F10 is <8, 15>. In general, any character's address in VRAM is 2*X + 256*Y, and its color is 1 + 2*X + 256*Y.
  43. 2 points
    Yes, I've noticed that problem with the auto populated fields, too. I'm looking into a config option to change that, it seems to be a "feature" of the Invision Community system we're using.
  44. 2 points
    Hi, Yes I believe so, it should behave normally in that case. Only the keycap text is changed. Silent Red is a good choice. Others may have other opinions. A very small amount goes towards the development costs of this keyboard. The majority goes to WASD for manufacturing & profit. So the answer is yes, but minimally. Your friend in retro, Perifractic
  45. 2 points
    This is the exact kind of thing I'm looking for - a little higher level than pure 6502 assembly with the ability to still inline assembly as needed. I'm definitely going to check this out. For those interested, the GitHub for the project is https://github.com/KarolS/millfork EDIT: Since the native version of Millfork on Github is based on a release from April, and doesn't appear to include support for the latest VERA, I just spent the last 3 hours fighting Java/Scala, GraalVM, native-image and Windows to create a native copy of millfork.exe based on the latest commit on master in the repo. I tested it out in VSCode with the CommanderX16 plugin and it runs a simple Hello World app just fine. If you want to grab it, I've popped it in my Google Drive here.
  46. 2 points
    More progress, starting to get closer to real map mechanics, as shown in this demo:
  47. 2 points
    It will cost more, but the vision of the first step is through-hole and easy to understand. Later versions will be surface mount and cost reduced.
  48. 2 points
    Why are you trying to load this at $2C00? Have you tried running your code from $0801 instead? I'm not familiar with this assembler, so I don't know if you are doing the right SYS command to run this. Have you tried running in debug mode, with -debug? You can check to make sure your code is in memory where you are expecting it.
  49. 2 points
    Thanks for sharing this! I have started watching the tutorials , for someone like me who would like to create something but has very little knowledge of BASIC and none at all of assembly language this is an ideal solution To help make the creation of sprites a little easier I've made a little sprite editor in excel, you put the values in the grid and using the palette you've defined it shows you what the sprite will look like. I've used your sprite from the example game as an example https://drive.google.com/file/d/1qo2sMf3W6AlYdl5eMp5xlsAgIwYAgEZo/view?usp=sharing
  50. 2 points
    Well an adventure game might be an easy place to start: https://www.commanderx16.com/forum/index.php?/files/file/18-xci-extremely-compact-interpreter/
  • Create New...

Important Information

Please review our Terms of Use