Jump to content


Popular Content

Showing content with the highest reputation on 09/07/20 in all areas

  1. 5 points
    We're all passionate about the things we like (or don't) but always remember, no piece of technology is worth getting irritated over. Or getting others irritated. We're all here to enjoy the same hobby.
  2. 3 points
    3d wire frame animated spaceship View File 3d animated Cobra MK3 ship from Elite! Uses 16 bits integer math and has hidden-line removal.. This is an almost 1-to-1 conversion of the same program I wrote for the C64, but it runs a lot faster on the CommanderX16 Here is the (prog8) source code https://github.com/irmen/prog8/blob/master/examples/cx16/cobramk3-gfx.p8 I haven't figured out how to wait for the Vertical blank yet, to reduce the flickering perhaps... Submitter desertfish Submitted 09/07/20 Category Demos  
  3. 3 points

    Version 1.0.0


    3d animated Cobra MK3 ship from Elite! Uses 16 bits integer math and has hidden-line removal.. This is an almost 1-to-1 conversion of the same program I wrote for the C64, but it runs a lot faster on the CommanderX16 Here is the (prog8) source code https://github.com/irmen/prog8/blob/master/examples/cx16/cobramk3-gfx.p8 I haven't figured out how to wait for the Vertical blank yet, to reduce the flickering perhaps...
  4. 2 points
    Sea Battle View File Sea Battle is a variation on the classical game "Battleship". Sea Battle is a cc65 application currently compatible with revision R38 of the Commander X16 emulator. The graphics and computer targeting could both stand some improvement, but the game is fairly playable in it's current state. I believe computer targeting is strongest when "HIT NOTIFICATION" is configured as "IMMEDIATE" and "SHIP NOTIFICATION" is configured as "SHIP" which are the default settings. I'm at the point where I've had to optimize the code several times to squeeze in more functionality, and adding any significant additional functionality will likely require an investigation into the possibility of taking advantage of memory bank switching. Configuration Options: The "P" key is used to toggle the player-mode between single-player, two-player, and computer-vs-computer modes. The entity names on the bottom of the left and right grids illustrate the currently selected player-mode. The "S" key is used to toggle the fleet size between 5 and 6 ships. Player-mode and fleet size can only be changed before player-1 accepts configuration of their ships after which the "Q" key must be used to quit the game in order to change player-mode or fleet size. The "F1" key is used to select the number of "TURN GUESSES" which consists of an initial number of guesses for the first turn and also the number of guesses for each subsequent turn. In "1/1" mode each player is allowed one guess per turn including the initial turn. In "n/SHIPS LEFT" mode the entity (player or computer) taking the first turn is allowed "n" guesses, and the number of guesses allowed on each subsequent turn is based on the number of ships left in the attacking entity's fleet. The ability to configure the number of guesses for the entity taking the first turn is intended to be a way to offset the advantage of taking the first turn. The "F2" key is used to toggle the "HIT NOTIFICATION" between "IMMEDIATE" and "END OF TURN". This configuration is only relevant when "TURN GUESSES" is set to the "n/SHIPS LEFT" mode described above (since both "HIT NOTIFICATION" options are equivalent when "TURN GUESSES" is set to the "1/1" mode described above). The "F3" key is used to control the "SHIP NOTIFICATION" related to the sinking of ships. When the "NONE" option is selected there is no notification of sunken ships. The "NONE" option only applies when "TURN GUESSES" is set to "1/1" as described above. When the "COUNT" option is selected the notification is limited to the sinking of a ship. When the "SHIP" option is selected a hidden ship is displayed on the grid when sunk. Fleet Setup: Two-Player Mode: In two-player mode player-1 selects their ships using the "1-6" keys, moves their ships using the cursor keys, and rotates their ships using the "L" and "R" keys. Ships of odd length are rotated about their center, and ships of even length are rotated about the the first segment behind their center. The currently selected ship is indicated by the cursor. Movements and rotations that result in part of the ship being off-grid are disallowed.The space bar may also be used to generate a random ship configuration. When player-1 presses the "ENTER" key the display of player-1's ships is turned off (assuming a valid ship configuration with no overlap of ships) and then player-2 configures the location of their ships in a likewise manner. When player-2 presses the "ENTER" key the display of player-2's ships is turned off and player-1 then takes the first turn. It is assumed each player looks the other way when their opponent configures the location of their ships. Single-Player Mode: In single-player mode player-1 configures the location of their ships as described in the preceding paragraph. When player-1 presses the "ENTER" key the locations of the computer's ships are randomly generated and hidden. The location of player-1's ships remains visible to player-1 and the referee part of the application but are hidden from the computer opponent part of the application. Game play begins after player-1 chooses whether to take the initial turn or let the computer take the initial turn. Computer-vs-Computer Mode: In computer-vs-computer mode the player configures the location of the ships for both computer opponents. Both ship configurations remain visible to the player and the referee part of the application for the entire game, but each computer's ships remain hidden to the opponent computer part of the application. After accepting both configurations with the "ENTER" key, the left computer takes the first turn. Computer-vs-computer mode is intended as an aid to explore the strengths and weaknesses of the computer targeting system and the effects of "n" on the game outcome when "TURN GUESSES" is configured to "n/SHIPS LEFT". Game-Play: Player: The cursor may be moved on the opponent's grid using the cursor keys. The "0-9" and "A-J" keys may also be used to select any column or row respectively. The space bar may be used to select a random untested coordinate, and the "T" key may be used to select a coordinate preferred by the computer targeting system. This last option is intended as an aid to explore the strengths and weaknesses of the computer targeting system. When the user presses the enter key the selected coordinate is fired upon. Hits are indicated by red, misses are indicated by white, the last hit that sinks a ship is indicated by orange (assuming "SHIP NOTIFICATION" is not configured to "NONE"), and yellow is used to temporarily indicate selected targets when "TURN GUESSES" is configured to "n/SHIPS LEFT" and "HIT NOTIFICATION" is configured to "END OF TURN". Computer: When the computer takes it's turn the player is prompted to press a key to acknowledge each of the computer's guesses. Support: If you encounter a problem that you think is related to a bug in the source code please take and submit a screen shot in a problem report illustrating the configuration where you're having a problem to aid in diagnosis of the problem. Future Strategic Mode: My ultimate goal is to develop a game mode with a much deeper strategy than the classical "Battleship" game. The basic concept is to allow each player to see the position of their opponents ships at all times, and also to allow movement of each of a player's ships on their turn. Each ship may be moved one position backward, starboard or port on a single turn, or it may be moved multiple positions forward on a single turn. The number of positions forward is based on the length of the ship (smaller ships which are presumably faster can move further than larger ships). Alternatively a ship can be rotated 90-degrees clockwise or counterclockwise. Movements and rotations that result in part of the ship being off-grid are disallowed. At the beginning of the game player-1 (who takes the first turn) configures the position of their ships, and then player-2 configures the position of their ships. This is intended to partially offset the advantage of player-1 taking the first turn. This player-1 advantage can be further offset by configuring the number of shells that can be fired on player-1's first turn to be less than the fleet size (which is the maximum number of shells that can be fired on each player's subsequent turn until their first ship is sunk). Each ship segment is initially loaded with a shell, and each ship with a remaining shell can fire each turn. Shells are only fired horizontally along the same row and limited to a range of 10, so a only a shell fired from the closest column adjacent to the enemy's grid can reach the furthest column of the enemies grid. The probability of a hit can be adjusted such that it decreases with range, and also can be adjusted such that it decreases when a shell is fired after a ship moves (instead of before it moves) on a player's turn. A ship's shells can be reloaded when part or all of the ship is on the column furthest from the enemy's grid which is considered home base (which is column-0 for player-1 and column-9 for player-2). When a ship segment is damaged that segment can no longer be reloaded, and when all segments are damaged a ship is considered sunk. A player's ship shells are reloaded at the beginning of their turn assuming one or more of the ship segments is on the home-base column. When only a single segment of the ship is on the home-base column a single shell is reloaded to the first undamaged and empty segment of the ship closest to the home-base column. When the entire ship is on the home-base column all undamaged and empty segments of the ship are reloaded in parallel at the beginning of a player's turn. I was originally thinking of integrating the future strategic mode into the current Sea Battle application, but due to memory constraints mentioned above I'll probably end up making it a separate application. I'm planning on implementing two-player mode first since the computer targeting strategy required for single-player mode is much more complicated for the future planned strategic mode than it is for the currently implemented mode which is only a slight variation of the classical "Battleship" game. Collaboration: I'm defining an API for the computer targeting function which I'm separating out from the rest of the current Sea Battle application, and I'm planning on taking a similar approach with the future strategic mode application. The intent is to support collaboration on enhancing the computer targeting function of the current Sea Battle application as well as collaboration on the development of the computer targeting and ship movement functions of the future strategic mode application (which I consider to be the most difficult part), so let me know if anyone is interested in collaboration on the computer functions of either of these two applications. Submitter CX16UserSteveC Submitted 09/06/20 Category Games  
  5. 2 points
    Hi, I am Philippe, from France. I followed the x16 project for a while and now hop into it. Quick background : C64, then Atari ST, then several PCs, and finally Apple, ... Software engineer now working at IBM France Lab. Few months ago I also followed and started to work with the C256 Foenix project by Stefany Allaire, a very interesting and promising (imho) new retro computer that aimed to be what a successor of the C128 could have been. Unfortunately Stefany decided to stop the development of the hardware and the project seems now a bit calm, even on sleep . As I still want to try to do some developments from scratch on a "basic" computer (compared to nowadays standards) I will try to do that with the X16. I am mainly interested in graphics and UI programming and have some ideas about that. I have done some work on the C256 and will try to reiterate for X16. I will keep you updated here. As I am not a assembly guy I will code in C with cc65. So, stay tuned, lol
  6. 2 points
    I think the idea is tres bien, but perhaps a little early. If someone wants to start a French discussions thread I have non objection (pardonez moi, it's been a while!) Let's see if we get lots more requests for it or not. It does add a moderation problem, although you could oversee it, but it would be hard for David and the rest of the team to jump in. For now, using Google Translate extension would be my preference. But I'm happy to see how it goes... Merci et salut mon amis
  7. 2 points
    Fantastic, thanks @SebastianVoges! I've updated the version on our end to R38.
  8. 2 points
    Version 38 based web emulator build https://github.com/sebastianvog/x16-emulator/releases/tag/1.0.0-beta.5 e.g. https://x16emu.s3.amazonaws.com/x16emu.html https://x16emu.s3.amazonaws.com/x16emu.html?manifest=https://x16repos.s3.amazonaws.com/chasevault
  9. 2 points
    I'm not sure if @DoubleA refers to the CLR or the .Net (or .Net Core) framework itself. The CLR itself is considered very stable in the industry and is extremely compact. But then - without the .Net framework is not of much use. But I personally never experienced the .Net Framework as bloated, especially since .Net Core.
  10. 2 points
    I agree to try some BASIC first to get a hang of the machine. You'll need some commands anyway to operate it regardless -- as Ender pointed out above. That said, the C64 basic isn't a very good basic. Even the PET that came before it had a better basic... and I remember being extremely jealous about the basic on the BBC Acorn Electron that my friend had in school, it was way more advanced. I think I wouldn't stick to basic beyond the basics (pun intended) and switch to something else once you mastered it a little. Personally I made the jump to assembly code back in the days. But there are a lot more choices available today... My own interests nowadays lie with cross-compilation that allows you to develop comfy on the PC and just run the compiled output on the target machine. This is what CC65 does and also my own Prog8 language and some others too. ( Obviously I'm using Prog8 myself but its kinda experimental and very very new on the CommanderX16 but I think I'm making good progress )
  11. 2 points
    Actually, you don't need a MMU, if you are okay with a system that doesn't have memory protection. (Wich is a weird thing to expect from a 8 bit system anyway..) I believe the only thing that you have to do is: save cpu state including status flags on a context switch give each thread access to their own hardware cpu stack. The second point means that you have to write stack swapping code on a plain 65(c)02 because it has its stack fixed at $0100 in memory at all times. I believe the Commodore-128 had a tiny MMU that allowed to remap the zeropage and stack to another page in memory, but I am not sure about this. Here is a multitasking unix-like operating system for the Commodore-64 that uses multiple threads and stack swap trickery: http://www.6502.org/users/andre/osa/index.html It's quite unbelievable to see it in action to be honest https://youtu.be/jtlAOdJmeDI
  12. 2 points
    My favorite joystick was the little one that stuck to the corner of my C64 with double sided tape and let me cursor around my word processor more conveniently than the cursor keys, though from the color it was obviously intended for pseudo mousing around GEOS on a C64C, not navigating TheWriteStuff from Busy Bee software on a first year breadbox. I never did play a lot of games on it, though I eventually started to get less atrocious at Loderunner. But I had very few of the commercial games that is the focus of a lot of retro C64 fans. Most of my games were type-in using the error-detecting program from one of the C64 magazines.
  13. 2 points
    Love the idea of making it possible to run CP/M on the X16! Used to have a Microsoft Z80 SoftCard for my Apple computer to be able to run CP/M and software not native to 6502/DOS3x/ProDOS. Classic:
  14. 2 points
    Definitely learn BASIC. The thing runs on a BASIC interpreter. You need to know how to make the machine do things outside of just loading in your compiled program and running it. Writing some BASIC programs to play around with graphics, etc. is a good way to get a feel for how the machine works and the ways to make it do things. For C, honestly? Not a lot of people are using C right now. Probably 90% of the people messing around with the X16 are using BASIC or assembly. I think I've seen one game written in C (there are probably more though). cc65's X16 support is a bit shaky. As development of the ROM continues (although I think the major breaking changes are over/close to being over) cc65's X16 support will break and you'll have to keep waiting for fixes or fix them yourself. For assembly, though, support doesn't break since it's just dependent on the 65C02 instruction set. I think also, in order to understand what your program is doing, or why your program will have to do a lot of seemingly random placing of values into certain memory addresses, it's good to learn the assembly first so you can understand what the heck is going on in a X16 C program. For threads, I'm pretty sure it's possible but it would be very tricky to do. It's definitely something the 6502/65C02 wasn't designed for, and not something natively supported in the C.
  15. 2 points
    Yep, that might be a thing and the approach is different. However the Z80 had so much other thing (other than the memory access issue) like 16bit index registers and other stuff. The concept of pages in memory was also completely new to me, as the Z80, did not know any pages. But anyhow .. the beauty of the 6502 is that it is very easy to learn. On the other hand it is at the same time very difficult to master. You need to be either very bright, or read a lot of stuff that is not officially documented, but hidden everywhere (like in this thread now ). Thanks @BruceMcF for the knowledge sharing .. appreciate it.
  16. 2 points
    You said what I felt exactly. I always thought the Applesoft BASIC was better than C64 BASIC because doing graphics was easy: HGR, HPLOT, HCOLOR, etc. and kids NEED graphics! GW-BASIC is also pretty straightforward to use graphics and is very mature with lots of books available, BUT that's the "problem"... just BASIC and not too much hardware (emulation of course). X16 BASIC would allow me to teach BASIC, then 6502 Assembly, then talk about memory map, zero page, stack, soft switches, ROM, etc. Then the real Commander X16 will allow me to teach about the expansion slots and hardware hacking akin to the Raspberry Pi and Arduino. The plus being the child/teen can learn A LOT with an 8-bit machine without getting LOST with 64-bit wide registers, 16GB+ RAM memory space, complex OS APIs, etc. Learning 8-bit assembly within 64K memory space allows for efficient coding, something that's been lost today! Who remembers Michael Abrash's extremely tight x86 assembly code?
  17. 2 points
    It's a great project, I was a backer from round one. In fact you might recognize me in the video you posted! For anyone with nostalgia of the ZX Spectrum range, it's highly recommended.
  18. 1 point
    Hi everyone! This may be a long one... so hang on tight cuz' I don't have a TL;DR Although, if you just want to take a look my questions, you can check that at the end of the post. I am looking to understand the first steps I (or, in any case, anyone) should take while starting to use the X16 and how to develop any kind of stuff for it. In fact, if things go as expected I am thinking of using this thread as a kind of log about my journey through the X16 developing world . This is in order to achieve a greater goal, an educational one, not just for me but for anyone that finds this interesting. So, let's begin with a short(ish) introduction! Main goal: From what I've seen on the videos Dave uploaded to his channel, I get that the computer should be "simple" enough for someone with some knowledge to understand what is going on at any moment without having to worry about other much more complicated concepts. Basically what I see about it is that it should let me build things that emulate how an OS works in real life or, even better, work like that. It may sound a little boring or even non-ambitious at all, but after getting there I will obviously set other goals in the future. Right now my main focus is on learning and building things that help me get to a more in-depth understanding. My background: I am 30 years old and work focused mainly on Integration (REST APIs, SOAP, etc). Basically some of the products I worked with tend to have a kind of unique way of solving their deployment challenges, including being non-dependant to a JVM and run a direct communication with the OS to manage their processes and access memory. That means I usually take into account how things work inside the server I am using and what would be the way to extract the best behaviour out of it, what relates to the other thing I've done in my career: getting to understand how OS's work and, more important, learning about low-level coding. From my experience as a student (I'm still working on getting my degree), I think there are features anyone could take advange of with the X16. So, yeah, it should be mainly about software, and very little about hardware... well, just enough hardware in order to be able to do what I plan to do. My experience with retro computers: Given my age you would think it's not great but it is something. Well... I have no experience at all. My dad had a 386 clone running DOS back when I was 5, but after that we jumped directly to pentiums and such. I did use plenty of DOS and Windows 3.1. Skills I have and stuff I do know about and think will be useful: C (And I think this is an important one) Process management (Multithreading, planning, etc.) File systems (NTFS, FAT32, EXT2) Skills I do not have and stuff I do not know about and wish to learn: 6502 architecture Assembly (I'm guessing this is a must) Basic (I am reading about that at the moment) cc65 Skills I do not have and stuff I do not know about but are not a priority: GUI design Graphics in general What I do not care about (for the time being, at least): Games: I know this may be a bummer to many of you and will stop reading after looking at this, but while I love retro games, I am not interesting in developing them. In-depth knowledge of hardware: By this I mean soldering, boards, chips, etc. I do not have any skills for that and never will, so I better keep it real and learn about what each component does without caring about how they are built and wired in. Building an entire OS: It is not my scope at the moment, and tbh I don't know if it will ever be. But dreaming is always allowed, right? lol. Ok, enough of introduction. Let's pan out my current location on this "journey": What resources have I checked? What was the outcome of that? I checked the FAQ, Docs, and the "Getting Started" Wiki. I don't know if I am short of knowledge right now or if I need things layed out differently but while I got to run things on the emulator (programs of the software library and some small basic tests), I haven't been able to understand yet what should I do as a first "hello world" creation using something else apart from BASIC. What have I done? What am I doing at the moment? So, as I said before, I've been reading all the docs and tried some software from the library besides trying some basic examples on my own. Right now I am trying to learn a little bit about KERNAL and BASIC with the C64 user guide in addition to the X16 Programmer's reference in order to get a little more experience on how to operate the X16. What's the primary objective right now? To get something running that has been written on my own. Just a basic program asking for an input and returning something. But I don't know if I should change this, maybe you can help me with my questions. Here are all the questions I have at the moment Should I bother to learn BASIC or maybe should I get straigh into C? I am skipping assembly for now, but will tackle that in the future. If the previous answer is C : How should I start? I've seen the cc65 webpage, but should I take something else into account? Is there a "hello world" example or something like that to get into terms with the compiler and such? Is process management a too far-fetched concept with the 6502? I'm guessing that if C is usable, I could use concepts as threads, but I am hesitant about that being doable on that CPU. DISCLAIMER: I haven't seen any posts like this one, or at least haven't found them. If you deem this is a "repost" please let me know and accept my apologies Ok, I really hope you find this interesting. Let the learning begin!
  19. 1 point
    I teach a small group of children the programming language Scratch and ScratchJr. While it is easy, cute, and simple, I don't quite like it. I want to be able to teach the kids more about the computer architecture in general. The 6502 is a perfect choice for that IMHO. I can teach everything there is to know using an Apple ][, C64, or X16, but that means using BASIC. Question: Should I teach C64 BASIC, X16 BASIC (similar but better "hardware"), or GW-BASIC (A very solid BASIC using the awesome PC-BASIC emulator)? What are the pros and cons and what are your thoughts? Maybe even ditch BASIC altogether? Is it a waste of time to teach an "obsolete" language?
  20. 1 point
    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!
  21. 1 point
    T'as de la chance, le plus beau coin de la belle province! On se tue et on s'emmerde avec les nid-de-poules et les forêts sans fin par ici! J'aurais voulu habiter à Québec, mais malheureusement mes liens sociaux sont presque tous à Montréal ou dans les environs :-(
  22. 1 point
    This also brings up another good point... we become slaves to the hardware, i.e. closed systems, proprietary hardware or software, many layers of security (e.g. TPM chip), kernel space vs user space, memory write protection, and being at the mercy of the OS. While all these things were created with security in mind, it is against the hacking spirit (old-school definition of hacker, i.e. MIT hackers during the 70s-80s) much like what Steve Wozniak wanted in his dream computer (Apple I/II)... direct memory access, and direct video ram access, many expansion slots, crashing the computer with memory corruption, writing tight code with prodigious assembly language skills, etc. We want a simple hardware that is entirely open and at the mercy of the hacker! The computer is our playground to explore and create havoc! Good havoc! And lastly... I would like to be able to fix my own computer when it blows a fuse or capacitor or what-not. I don't want to spend lots of money for a hardware and then the manufacturer will no longer fix "vintage" products. Just heat up my soldering iron and have a go! Hmm... a not-so-important issue is that I also want my computer to survive an EMF blast or some apocalyptic event that will take us back to the stone-age... I want my car with its old fashioned carburator, and my 65C02 computer running when that day comes... maybe I am asking for too much!
  23. 1 point
    On commence à avoir une grosse communauté francophone par ici I did heard of the C256, but opinions were kinda divisive from what I heard. Maybe too ambitious for what it is? But eh, kinda sad to see this abandoned.
  24. 1 point
    This more or less sums up my real reason for being here. I want my kids to learn to code, and as stated previously, kids NEED graphics to get them interested. Meanwhile, the reason modern languages need the layers of dependencies and libraries is because the operating system and hardware have gotten so complicated. Placing a pixel on a screen isn't actually a thing that is allowed. Instead, you need to use a graphics library in conjunction with a windowing toolkit that runs on your window system which calls the OS to communicate with the graphics hardware's pipeline to put that pixel on the screen. It's really not the fault of modern languages; the computer is too complicated. When teaching kids graphics on a modern computer, you have to just hand wave a mountain of boilerplate code and ask them to just trust you that it is needed. You can't provide them with an explanation why it's needed because the explanation is simply too much for a beginner to take in. I'm probably among some of the younger members of this forum (got my first computer in 1997, running Windows 3.1), and I dealt with a lot of this hand waving. It was extremely frustrating, and I don't want my kids to deal with it. I'd like to show them how to put a pixel on the screen, and when they ask how it works, I want to be able to explain it in less than a minute. The Commander X16 will give me that, whereas a modern computers won't...no matter which language I use.
  25. 1 point
    @sebassco sure, I announced it in the X16 General Chat subforum, there should be the links you asked for ! Here it is:
  26. 1 point
    cool .. I should revisit my prog8 ide project. Like so many things I start, it somehow just fell off my radar..
  27. 1 point
    No, you don't need assembler at all if you don't want to with cc65. It will for sure offer more performance than Basic. But if you just want to get going right away - Basic is the right choice. No installation needed, except for the emulator.
  28. 1 point
    Just want to cover some thoughts on the threading. Threading has come up with CPUs with a lot of cycles and the main routine sitting around most of the time and idling. Also having multiple cores requires threads as otherwise you would not be able to use it in a single program. Threads come with at least two disadvantages: 1. you need to make your code thread save. As threads will run asynchronous, you cannot forecast when a thread will finish its task and if this is inline with the main loop. So you need to write message queues and handlers and such things to ensure that you have everything in the right order. That will put a lot of overhead on both CPU and RAM. Even if RAM is not a big issue any longer with the X16, CPU cycles are precious. 2. You need a MMU or you need to program one yourself to ensure that threads are always accessing their memory. Regarding the first point: X16 has a very small CPU that is not powerful at all. Yes it is 8times faster than the C64, but the compute power on your hands is less than an Arduino (ESP-12f for instance with WIFI and USB and other components runs at 80Mhz and with much better CPU. 4USD price range ) . So if you are starting to use thing like threads you need to use Interrupts, each of the interrupt handlers need to decide what to do (actually multitasking/multithreading) and then save everything somewhere (stack), load the current thread environment and start executing, until the next interrupt happens. Depending on the complexity you are wasting 50% of the available cycles just for the thread handler. Remember the CPU and the whole System has no support of that ready. No multi tasking, No multi threading. No MMU. So given all that, it is definitely possible to implement multithreading in any CPU as long as you have enough memory to handle it (and you have on X16), however there is most likely nothing that justifies the overhead. Instead you write a main loop (game loop) and branch into all the individual "tasks" and ensure that it is as efficient as possible and that whatever task you have to complete within a frame fits into the available cycles of a frame (e.g. 8.000.000 cycles/60 = 133k cycles per frame. If you consider that you need at least 2 cycles per instruction, that is not a lot of things you can do within that time frame. (C64 had only 16k cycles per Frame).
  29. 1 point
    If you reset the video settings, then you just need to restore the ROM bank to 4 and then just RTS from the initial RUN/SYS call. Make sure you don't have anything left on the stack from your program! This should bring you right back to the READY prompt and your program should still be in memory and runnable from BASIC.
  30. 1 point
    Yes, I can understand that. It is just that anything Commodore (or Atari) is so (for me) tightly linked to that type of connector and style of joystick! But I can see why you would like to have something better. In fact I did that even back in the days; As the Apple II+ (and not the Commodore/Spectrum/Atari) computers where my own machine growing up, I actually prefer/preferred the analogue joystick input those provided (way better than digital only directions).
  31. 1 point
    Yes, saw you in the vid! It is a great project, so wanted to let everyone know (a lot missed first round). But I have personally not decided to back it yet. It is quite expensive I think. But I do love the design. Will think about it for 2-3 more days (up until the KS closes).
  32. 1 point
    Oh nice! I can already see something like "Elite" coming...
  33. 1 point
    I'm also one of those using cc65 and implement my games for the X16 in C. Sometimes there is a need of implementing some optimized parts in assembler (interrupt handlers, sound effects player, etc.). cc65 has the advantage that combining C and assembler is easy. I sometimes check the generated assembly code, to see what the C compiler does and the hand-optimize some of it. Or I change the way I do my C code. I also didn't experience any case of cc65 being really broken... if so, it was possible to fix it myself as the source is on github. Basic was too limited for me and I wanted the comfort and usability of cross development tools on a PC - and then run it on the emulator. So I went for Visual Studio Code and cc65. But hey - the beauty of the X16 is that there are different ways of programming for it.
  34. 1 point
    Salut Philippe, je suis bien content de voir un autre francophone dans les environs! IIRC the Foenix started as a response to David's first blog post about his dream computer, however it quickly became its own thing with very different goals. I wasn't aware it was sort of dead. It's sad, but I guess it happens when the project has only a small following.
  35. 1 point
    I've written a tutorial a while ago on how to use BASIC to generate webpages, as how you would use PHP, it's almost useless but thought you guys'll want to see that https://toasters.rocks/esoteric-uses-of-cgi/
  36. 1 point
    I really think that the 6502 is not harder to master if it's your first processor, rather it's harder to master if it's your second or later. The peculiarities are not on their own hard to master, what is hard to overcome are habits of thought assuming more orthogonal operations. "I want to do a post-indexed indirect, which index register is that again?" is a question of someone who has originally learned programming on a chip with multiple registers able to do a set of indirect addressed operations. Someone who learns the 65C02 at the outset thinks, "I want to do an (a),Y" and which register it is that can do it is not a question. Indeed, since I learned 6502 programming by the seat of my pants, I've had to unlearn some bad habits to get xForth working reliably ... like trying to use BMI and BPL after a CMP operation for an unsigned comparison instead of using BCC and BCS. The Z80 is DEFINITELY kinder to high level languages. A main reason I would like a CP/M box of a Z80 and it's own RAM, calling a support program in the CX16 for it's I/O, are all of the old classic languages available in CP/M ... not only multiple Forth's and both interpreted and compiled Basic's, but also bytecode & Turbo Pascal, Aztec, BDS, and Mix C, and the original self-hosting Small C, Microsoft Fortran and Cobol, Nevada Fortran and Cobol, Modula2, APL, Ada, etc. A CP/M box is a 1970's and 1980's "living programming history in a can".
  37. 1 point
    There is NO BASIC computer on the market, now or ever, that's quite like the CX16. The 128 is much, much slower, and the Amiga and ST are not BASIC computers. The closest thing might be the MSX computer running one of the faster CPUs... but it's awkward and hard to use in emulation, and setting up and running it properly in MiSTer has proven to be a bit of a challenge. I've done so, but it's... complex.
  38. 1 point
    6502 is also very bare bones ... you cannot even add x to a. I grew up on a Z80 and never understood why people loved the 6502. It is most likely a nostalgia thing, as the C64 were everywhere and people had access to a 6502 . Z80 was much more in UK and in Germany present and still compared to Commodore a fraction of the Market. However looking from today’s perspective the Z80 was much easier to program for real things. For learning assembler in general the 6502 is pretty good as it has only very few commands to learn. The addressing modes then makes it difficult to understand. Esp Indexing has some serious limitations that you need to work around and that no one would put in any CPU anymore those days.
  39. 1 point
    Yes .. X16 is much better, cause BASIC is much better on X16 than on C64. As I wrote .. it is really painful and ugly on C64. Not enough space in ROM for C64 BASIC 2.0. The C128 hat much better and the C+4 even better, however the C+4 is a completely different machine and the C128 requires to run in 128 mode to see the new BASIC. In 64 mode you are back to square one as it is 100% compatible with a C64 in that mode.
  40. 1 point
    I'm teaching my 9-year-old daughter python, and it's going pretty well. Like BASIC, it has the benefit of an interactive shell, but is a better introduction to actual modern programming. At the end of the day, she has learned an actually useful language, and it wouldn't be as difficult to move on to other languages. And she can do it on pretty much any platform, so not tied to any hardware or OS. That being said, she sees what I'm doing with the X16 and she's really curious about 65C02 assembly. Can't wait till she's ready to dive into that!
  41. 1 point
    I would use actually anything then C64 for BASIC. The reason is, that they run out of ROM space and did not imlement a lot of basic things. So you have to use Peek and Poke with weird numbers and you will never get to it - actually very painful. You cannot even plot a point or draw a line on the screen. To be honest everyone had a 6502 based computer (C64 for the most part) in the 80s, but C64 Basic was never good. Also the C64 architecture esp. the video modes are so weird, if you come from any other computer you will think that the developers were insane. Yes it had hardware sprite support, but the pure basic (not the language) design of the video memory was a nightmare. Drawing a line on the C64 is absolutely painful, as the memory is organized in a very weird structure. It does not simply count up the lines one by one etc. So X16 IS a big improvement in BASIC dialect as the developers have implemented a lot of those missing functionality. That will help to avoid all Peeks and Pokes (hopefully). Look at Amstrad CPC Basic. The computer is very simple as well and even simpler in certain aspects. It has a great and full featured BASIC implementation that let you program anything you like without the need for Peeks and Pokes. The only time you need Peek and Poke is if you want to embed Machine routines in your BASIC code and want to poke that to memory and then run the routine. Also I would go with emulation. No reason to buy real hardware for learning to Programm BASIC. Hardware makes a lot of sense if you want to teach how computers work and BASIC is just your vehicle for easy access. Then the X16 is my clear recommendation. It has a much simpler architecture compared to the C64 (the bank switching alone on the C64 is a nightmare and much easier to understand on the X16). Just my personal thoughts.
  42. 1 point
    Not at all a waste of time. It's important to teach CONCEPTS, not languages. Learning BASIC is about teaching kids how stuff works. I keep seeing programmers leaving college being unable and unwilling to look beyond the language they've been taught. That's the main reason for this JavaScript everywhere madness. So I'm all for teaching BASIC, but making it clear that this is a first stepping stone. Thanks for teaching the young! We need more people like you.
  43. 1 point
    Welcome Christoph/SerErris. I hope you find the VERA chip interesting!
  44. 1 point
    I've been using acme, simply because it was the easiest to get started learning 6502. As for my development environment, I just use vim and a simple Makefile with build, clean, and run commands. I use vim at work all day (I'm one of those guys), so this feels the most natural for me. Shameful secret: sometimes just for kicks, I run vim from cool-retro-term and feel super nostalgic.
  45. 1 point
  46. 1 point
    I'd be down for a Commander zx80 project! Or should it be Commander Z16? MP/M would be my preferred option built on an eZ80 based system. But right now I am thinking GSX for VERA would be pretty cool.
  47. 1 point
    I'm a CP/M fan. I used it heavily back in the day on our Amstrad PCW. I have a PCW now as you probably have seen. I also installed CP/M on the ZX Spectrum Next, along with some PCW software. And if it's an option I'll do the same on the X16. Why? Because if it's possible to run a language I used in 1986 on 3 machines in 2020, two of them brand new, and one not even a clone but a completely new brand, then that is incredible to me. (And also of course, nostalgia.)
  48. 1 point
    I'll second the use of Brown in an office environment. If you get the Brown with some key dampeners , it's easily quiet enough for an office environment while still providing reasonable tactile feel. I get my clicky-feeling keyboard without my coworkers being annoyed by the clicking. That said, I wish there was a buckling spring option for the x16 keyboard. I may have to just get a custom set of key caps for a Unicomp. I don't mind subjecting others to the machine gun fire sound of those keys!
  49. 1 point
    Now the big question.... why not just put VERA directly on a Z80 board? A VERA daughterboard for RC2014 should be simple to build, and then we could have a stand-alone "Commander ZX80", which could run at 20Mhz and not need any fancy interface logic to work with the CX16.
  • Create New...

Important Information

Please review our Terms of Use