Пікірлер

• 
  @cosmicrdt13 күн бұрын

  CODEX is removed from the ROM as of R47 for some inexplicable reason... I wish there was a decent IDE for writing and debugging CX16 projects.

• 
  @digitaljestin11 күн бұрын

  It's not inexplicable. It was never completed, never fully fit into ROM, was abandoned by the developer, and I personally recommended that it be removed from the ROM. Not to worry, however. A text editor already exists, and an assembler will hopefully come soon. CODEX was never the optimal way to do on machine development in the first place.

• 
  @cosmicrdt11 күн бұрын

  @@digitaljestin ah I see thanks. Unfortunately that wasn't in the release notes so I had no idea! Love your work!

• 
  @tja29782 ай бұрын

  Thanks for this, can't wait to see the next Episode! :)

• 
  @IapetusRetroStuff3 ай бұрын

  thanks

• 
  @collinvisser71084 ай бұрын

  very useful thx

• 
  @neilthomas25494 ай бұрын

  Maybe it came too late for this 2012 video, but these days, just include the BSOL library, then use the gear() module from the involute_gears.scad file

• 
  @xlar544 ай бұрын

  Tried using it, but I cant shake not being able to just type what i want, where I want. I accidentally deleted all my lines, and now I cant add new ones. Not sure this one is for me.

• 
  @digitaljestin4 ай бұрын

  Honestly, it's not for me either. I made this video because I spent an hour or two figuring it out, and figured that I should give everyone a demo so they didn't have to. I've actually argued to remove CODEX from the X16 ROM, due to it requiring files loaded from SD in order to bring in all the features. That's fine for a program loaded from SD, but not one that ships on the ROM.

• 
  @pcallycat90435 ай бұрын

  Out of curiosity, what are you using for line numbering in vim, and... are you using an autoindent?

• 
  @digitaljestin5 ай бұрын

  It's relative line numbering.

• 
  @jsmythib5 ай бұрын

  Your the only video source on this subject I can find. First mover advantage! :) This was a great 10 minute intro into codex. Make more! Humanity needs you lol :) Thankyou.

• 
  @jsmythib5 ай бұрын

  Sidenote. I forgot to exit my loop on my second itteration and x16 emulator exploded and took my desktop video with it, temporarily. So. That was exciting.

• 
  @zingerpop5 ай бұрын

  Wanted to point out for anybody following along... I'm on Linux Mint and installed cc65 through the default apt repo on the system. The compiler wouldn't recognize '.LITERAL' as a control command. After manually compiling and creating symbolic links (using the Getting Started tutorial on the cc65 web page), it worked great! Thanks for the tutorial! Excited to continue my assembly journey!

• 
  @user-bn7cr1pk6x3 ай бұрын

  Thanks for this! I was completely stuck trying to do this on OSX but this fixed it. For any other OSX folks, I had to run `sudo make avail` (instead of `sudo make install`) once I'd compiled everything. This symlinks the binaries from the compilation directory into /usr/local/bin instead of copying them.

• 
  @nate66926 ай бұрын

  You might want to avoid putting text at the very bottom as pausing the video blocks this with youtube controls.

• 
  @catmeowmeow47227 ай бұрын

  I like that you use a tiling window manager, and use gaps!

• 
  @lupedarksnout7 ай бұрын

  6502 is my thing, but after nearly 30 years of using the PAL assembler (and an ML monitor) on my C64, I am definitely afraid of change. Even though PAL shares memory with the program it creates (where either can corrupt the other) it makes sense in my head. I have a feel for where things are. I can tweak, re-assemble, and re-run in seconds - and that's using the pesky BASIC editor (with line numbers) to write source code! I wonder if there are other options for directly assembling code on the Commander X16 - something similar to what I'm used to?

• 
  @digitaljestin7 ай бұрын

  In the latest ROM, there's a built in text editor. There's also going to be a BASIC loader for text files (non tokenized), and hopefully an assembler sometime soon. Personally, I don't think CODEX should make the cut for the final ROM. It needs some fixes, the original dev isn't patching it, it's a little awkward to write anything large in, and it doesn't fit the development model the X16 is going towards. More likely it'll have an assembler that integrates into the text editor. Someone just needs to write it.

• 
  @DesignByKirk7 ай бұрын

  This is exactly the kind of video I needed. I've got a fair bit of experience in many programming languages, but Assembly is something that always seem a little too hard to wrap my head around and daunting from the outside looking in. Thank you for this video and helping me realize it's not as bad as it looks

• 
  @tomraidna84218 ай бұрын

  Nice video , too bad the save/load doesn’t work correctly with the .Cstr

• 
  @astroprotector9 ай бұрын

  terrible tutorial. you skip steps. what happened after bsout? you didnt tell how to go to the accumulator. waste of time watching this video

• 
  @digitaljestin9 ай бұрын

  Not sure what you think was skipped. What do you mean by "what happened after bsout"? What do you mean by "go to the accumulator"? After bsout, we increment X and branch to the beginning of the loop. The accumulator isn't something you go to, it's just something that is used by different instructions.

• 
  @astroprotector9 ай бұрын

  @@digitaljestin you did not show what function key to use after entering bsout

• 
  @digitaljestin9 ай бұрын

  @@astroprotector after entering each instruction, bsout or anything else, just hit enter. This is an assembly code tutorial (that doesn't use an assembler) for a hobby computer nobody is forced to use. I assume anyone following along is willing and capable enough to figure some basics out for themselves. There's no manual for Codex, by the way. I had to figure it all out by trial and error. I only posted this to show others what I figured out. Feel free to make your own video covering anything I missed. I'll watch it.

• 
  @astroprotector9 ай бұрын

  @@digitaljestinyou can't, not for the next step you show. it is a different section in the assembly program

• 
  @digitaljestin9 ай бұрын

  @@astroprotector I just rewatched both the cstring section and the pstring section. In both cases I do exactly what is done for every single instruction entered. After each, there's an increment instruction added (one time was X one time was Y). You just enter another instruction with f2, just like with every other line. I don't know why you expected it to be different.

• 
  @mitchmccracken305010 ай бұрын

  Extremely well explained lesson on Makefiles. Great job.

• 
  @belalehner393710 ай бұрын

  The music with the chip of the x16 is a great quality, it's a pleasure to hear. Congrats!

• 
  @AndreHermanBezerra10 ай бұрын

  Great content! Great explanation! Waiting for the next one!

• 
  @customsongmaker10 ай бұрын

  I love the pre-rendered 3D reindeer and sleigh. Is that something like a background layer that games could put sprites on top of?

• 
  @digitaljestin10 ай бұрын

  Those _are_ sprites. I'm using 4bpp, so each can have it's own 16 color palette, which was more than enough to highlight and shade the pre-rendered images.

• 
  @customsongmaker10 ай бұрын

  @@digitaljestin That's like Mortal Kombat photorealistic sprites

• 
  @customsongmaker10 ай бұрын

  And only 8 frames of animation, looks like. Imagine a racing game with a 3D car that size, or a game like Metal Slug with a huge tank

• 
  @belalehner393710 ай бұрын

  In the documentation of the x16 I did read about more programing language options, for example C. C would be a more modern and usable mode to work with the X16 as the Assembly, which is really hard work for nowadays programmers. C is more elegant, easy to use language, and back in the early 90-s many great programs was written with it not on the 8bit platforms but on pc an Amiga. Can You make a video about this option and possibilities for C programmer, because I'm afraid I don't see any common future for me and assembly on this platform. (In the 90-s that was fun, now it's only fuzz for me.)

• 
  @digitaljestin10 ай бұрын

  I'd argue that C on 6502 is _not_ as elegant as you probably think. It still has the limitations of the platform, but presents an illusion that it doesn't. You should instead look into the prog8 language being developed, as it is both higher level (like C) but cognizant of the limitations.

• 
  @belalehner393710 ай бұрын

  @@digitaljestin Well, i've noticed, that the compiler generates way too "huge" file sizes for the x16's memory. I presume C is not the language this machine could "tolerate"... But talking about the Prog8 and it's development state ... can someone join in into the dev. or give proposals for the developer because I took a look at it and there are some solutions i don't like much. Is there a mailing list or something?

• 
  @digitaljestin10 ай бұрын

  @@belalehner3937 not sure about a mailing list, but the dev hangs out on the X16 discord server

• 
  @belalehner393710 ай бұрын

  @@digitaljestin thanks

• 
  @eliseulucenabarros392010 ай бұрын

  I LOVE IT

• 
  @bleggett2911 ай бұрын

  If you're getting an error about .LITERAL , make sure you have an updated cc65. I had version 2.18 and got the error. After I installed version 2.19, it worked.

• 
  @elijahvincent985 Жыл бұрын

  The effect looks like a hybrid of Mode 7 and this game's effect: kzread.info/dash/bejne/nJempryTYcasf5s.html

• 
  @digitaljestin Жыл бұрын

  That game looks like it's doing exactly what I'm doing here. All I do is raster line interrupts that scale the VERA. I had to mess with both hscroll and vscroll to get it right, but that's the whole trick. No real matrix transforms at all are happening.

• 
  @elijahvincent985Ай бұрын

  Great work!

• 
  @OpenGL4ever Жыл бұрын

  I see one issue with your Makefile. It's not platform independent. Someone who wants to use it under windows will get an error message, when sth. like "make clean" is run. The "rm" command doesn't exist on Windows, Windows requires "del".

• 
  @miselzivanovic2181 Жыл бұрын

  Thanx for showing codex environment and how to use it I tried it some time ago and gave up very quickly... Unfortunately, i still think codex and i won't be friends. I hope BASIC Editor will be more user friendly, no lines and have a compiler. Last environment i tried was v38...

• 
  @digitaljestin Жыл бұрын

  There will still probably be line numbers, but there's a new REN command that renumbers an entire program. That should help quite a bit. There's still a lot of talk of an optimizing BASIC compiler, and I think it's going to happen. A lot of recent discussion has been around developing on the system, including things like C compilers. It's going to be fun to see which things get made and watch it happen!

• 
  @miselzivanovic2181 Жыл бұрын

  @@digitaljestin Thanks for replying. Just checked and saw that version 43 is available. I have to try it later. My first computer was C128 and it also offered a possibility to renumber lines, but i later switched to A500 and BASIC there offered no lines. I somehow got used to that... Anyway, could be that codex in its final version is going to be more flexible. It's just odd to see no cursor, not being able to move around. Then being unable to type commands directly, instead of into a separate window (line)... It's somehow all strange and difficult to communicate with (but can be that i am the only one. (No need to change anything then 🤫) Well, it's not finished yet, all work in progress. Let's hope for the best...

• 
  @digitaljestin Жыл бұрын

  @@miselzivanovic2181 That's actually the problem...it's not a work in progress. Nobody is fixing it up to my knowledge. The original developer created it and then walked away after slicing it up to fit into a single ROM bank. In my opinion, it's half finished, and needs some work if we want to consider it shippable.

• 
  @mlindroth Жыл бұрын

  Hi there, great videos. I'm curious is that the Awesome window manager? What distro are you using?

• 
  @digitaljestin Жыл бұрын

  The distro is just Ubuntu, but I'm using i3gaps for a window manager.

• 
  @AlexeyFilippenkoPlummet Жыл бұрын

  It's so obvious why assembly wasn't the language that loads at boot. My brain hurts from just looking at it - I can name commands but I have no idea why they work lol

• 
  @digitaljestin Жыл бұрын

  Assembly really isn't an environment to boot into. Being a higher level language, BASIC works not only as a programming language, but can also serve as a set of operating system commands. Assembly, on the other hand, is just a human readable representation of a processor's instruction set. Any interpretation of a single instruction from an interface would require far more instructions just to execute it. That would make no sense.

• 
  @willibald-nq1dz Жыл бұрын

  BRA is 65C02, BEQ would be more retro.

• 
  @digitaljestin Жыл бұрын

  I'm using a few op codes only available in 65C02, I believe. The point isn't to be retro, but to show off the X16 a little. And the X16 has a 65C02.

• 
  @OpenGL4ever Жыл бұрын

  I have three questions: 1. Does it use the Microsoft floating-point number encoding or the standardized IEEE-754 floating-point format? 2. Does the BASIC count loops in floating point numbers or as integers? The early Microsoft Basic version did everything in MS floating point. This changed in the early 90 with Quick Basic on the PC. 3. Is the Commander X16 shipped with a extensive programming book?

• 
  @digitaljestin Жыл бұрын

  1. Not sure, but I think MS floating point. The ROM has been licenced and forked from the C64, so whatever that used. 2. I'm pretty sure it's floating point for loop counters, for the same reason as above. 3. No official word on that yet, but I just so happen to be writing one that I hope becomes official. Even if so, it may not ship with the computer. github.com/X16Community/x16-user-guide

• 
  @OpenGL4ever Жыл бұрын

  @@digitaljestin Thank you for your answer. If the ROM is the same, than it is definitely MS floating point. And i must also correct one of my statements above. The sentence "This changed in the early 90 with Quick Basic on the PC" belongs to the first question. I moved the question around and forget that sentence. Quick Basic and QBasic both use IEEE-754 floating point, while its predecessor GW-Basic and all the other home computer BASIC variants from Microsoft use MS floating point. In Quick Basic and QBasic there is a compatibility mode to use the old MS floating point format to ensure that old code and data can run and be used without problems. I don't know if Microsoft eventually switched to using integers for the loops, maybe in Visual Basic? Thank you for the info about the book. In my opinion a printed programming book shipped with the computer is a must for such a computer. Especially when it is aimed at young adolescents. Without that, it's just an empty machine that the user doesn't know what to do with. The only pity is that the machine uses a BASIC interpreter instead of a PASCAL compiler. Of course I can understand why it had to be BASIC for retro reasons. But it says classic BASIC tends to make users write spaghetti code, while PASCAL teaches them structured programming. I took a look into your book. The SETUP chapter and the body text in chapters 2 to 4 are written in Latin and have nothing to do with computers and programming.I'm assuming it's only a stub and will be replaced later by real programming text.

• 
  @OpenGL4ever Жыл бұрын

  @@digitaljestin One more Question. Does the Commander X16 support Unicode? I doubt it, but it would be a good feature.

• 
  @digitaljestin Жыл бұрын

  @@OpenGL4ever It's PETSCII, but you absolutely have the ability to substitute your own character set, so I suppose the answer is "yes" in a round about way. Don't even think about it as a character set, but rather as 8x8 graphical tiles that are burned into the ROM and have some convenient kernal routines for placing into VRAM. I don't think the limited ROM space could handle the full Unicode standard.

• 
  @OpenGL4ever Жыл бұрын

  @@digitaljestin Thank you for the information.

• 
  @TheUtuber999 Жыл бұрын

  Thanks for the instruction. No offense, but would recommend moving the mic away from your keyboard because the volume is about the same as your voice. Either that or invest in a quiet one with scissor keys, or record the video without audio and narrate over it while editing.

• 
  @digitaljestin Жыл бұрын

  I record the screen capture with the mic pointed at the keyboard (an Unicomp with buckling springs) specifically to capture it. The voice overs are done in a completely separate take. In other words, I mixed it all together to make sure the keyboard sounds exactly as it does :)

• 
  @TheUtuber999 Жыл бұрын

  @@digitaljestin Nice way to grow a channel. Bravo.

• 
  @digitaljestin Жыл бұрын

  @@TheUtuber999 to be honest, I'm not really trying to grow a channel. I like making videos about X16 topics that I feel need more instruction (like my own tools), but I keep telling myself each video is the last. I'll do a second part to this one, but then probably no more until I find another topic that needs attention.

• 
  @OpenGL4ever Жыл бұрын

  @@digitaljestin I personally like the keyboard typing sound in the background.

• 
  @TheUtuber9998 ай бұрын

  @@OpenGL4ever You probably also like nails on a chalkboard. Don't encourage him.

• 
  @TheUtuber999 Жыл бұрын

  Appreciate the mini-tutorial! In the second example, I just added RTS underneath BNE PRINT-LOOP and deleted RTS under the END label, so as to avoid the final BRA END instruction. Is it safe to assume BRA is not backwards-compatible with legacy 6502 assembly? I also noticed that if you exit back to Basic, then re-launch Codex, it will only show the first line of code... whereas you can then jump into MON and see the code you wrote earlier, and can invoke it from Basic using SYS $8000. Cool stuff and hope it evolves further in future code releases.

• 
  @BobSellers6502 Жыл бұрын

  Oh! Forgot to make the comment I was actually going to make... and it's about the Makefile! I like the way your makefile is super simple... people stsrting with make REALLY need to see just bog simple makefiles instead of the excuses for complexity a lot of people use. (People that do that? STOP! Get help.) anyway, you should mention that TABS must be used instead of spaces to start a subsequent line in a makefile, a lot of editors default to using spaces instead and it's easy to stand there scratching your head at the error message saying "It LOOKS exactly like what I was supposed to type!" Also, and this is a nit... make doesn't execute the all: one by default, it executes the first one by default, which, by convention is named all. Cl65 runs the assembler first to build the .asm file... creating a .o file, then runs the linker to convert that into the .PRG file. You could have done the whole thing with just one rule that does 3 things: all: rm hello.o cl65 -t cx16 -o HELLO.PRG main.asm x16emu -prg HELLO.PRG -run -scale 2 There's no reason the clean: the .PRG, but adding a clean to delete the .o left over from the compile step would be cool. I like to burn the .o files on the outset just to force a full rebuild every time... it's not like even the biggest assembly program with a big pile of .o files is going to take more than a few milliseconds to compile and link on a modern machine. Yeah, as you can imagine, I'm a lot of fun at parties.

• 
  @OpenGL4ever Жыл бұрын

  The complexity in a Makefile is required if you want have that Makefile usable on different system. The Makefile in the video is only usable on Linux and similar operating systems, but not on Windows. On windows you need del to delete files, not rm. And if you take that into account, the complexity of your makefile automatically increases. And later you probably want have many asm files, not just one. And with these collection of asm files you want to build one program. You could use the star operator of course, but if you don't want to build every object file from scratch again, you need a more smart solution than a star operator.

• 
  @BobSellers6502 Жыл бұрын

  Well. This is passing strange... I had noted in the video that you are using the .literal control command. I had never even heard of that one, but assumed it would just bypass the -t cx16 configuration switch and treat the data as a .byte sized array of chars, literally interpreted. (I.E. from ASCII.) as opposed to interpreting it from PETSCII. According to the docs, that's exactly what it does! So I tried it myself! I certainly hate PETCSII and would prefer not to go near it... but no! The assembler barfed it out as non existent. Is it version locked? The version in the repo the apt command uses is v2.18 Are you using a more recent one? It works fine if you use the .byte control command and just use lower case characters (Which will translate to upper case as PETSCII normal mode doesn't have shifted chars, so the unshifted ones get translated to shifted by -t cx16.) Normally, I prefer to bypass the bios hooks and send characters directly to VERA, but of course, for that, PETSCII wants to see the normal characters (Upper case when in BASIC mode.) start at $01 for an "A" and go up from there. (Cue a meme picture of Professor Hulk in Avengers:End Game when he says "Time Travel!" but saying "PETSCII!" instead.) Heh. An entire video needs to be devoted to dealing with PETSCII. I don't think it's even possible to actually bypass PETSCII completely in the x16, it's just baked into the system too deeply.

• 
  @bleggett2911 ай бұрын

  I was having the same issue. get v2.19

• 
  @BobSellers6502 Жыл бұрын

  Nice! I would encourage anyone who wants to do this to do this first: Step 1) Put together a Linux machine to act as your dedicated development environment. Step 2) See step 1. It's just easier and more straight forward to use Linux for this. When you get a Commander X16 or whatnot, just put it next to your development system. I also have threatened to do some kind of "tutorial series" (Not out loud, of course.) Despite having loads of game dev experience, I would have been lost without Matt Heffernan's tutorial series on the 65c02. (The very one Jestin points out.) When I started out with programming, all I had was a TRS-80 model 1 at the most basic level (Level 1 basic, 4K RAM.) It wasn't even capable of doing assembly programming. I tried... even bought the cassette version of the "TRS-80 Editor Assembler" program, which apparently included a free bug that prevented you from properly saving anything to the cassette. But now? In the 21st Century? You can buy a cheap laptop at Walmart, or just get used stuff and install Linux on it. With that you can do anything you need... compiling to any system, create and edit art and sound, anything. All it takes is to have the patience to start slow and take tiny steps. As Sun Tzu says: "A journey of a thousand Li starts with the first step."

• 
  @chromosundrift Жыл бұрын

  My preferences are similar to yours, but honestly, for someone who has never done assembly programming OR linux, would you seriously recommend getting a linux machine to do it on? That's surely going to be more to learn, not less.

• 
  @digitaljestin Жыл бұрын

  @@chromosundrift Linux is by no means required, but I've seen people have a lot less trouble getting started on the X16 when they cross develop from Linux as opposed to Window or OSX. It's just more developer-friendly. Linux isn't hard to use at all, nor do I understand where this idea came from. People only have problems when they try to run software intended for other systems, and frankly, nobody should expect that. I think the above is solid advice. Just remember you don't have to take it. You just need a text editor, make, and CC65.

• 
  @curtisnewton895 Жыл бұрын

  although the project is impressive in term of work, what is the point of this ?. this is just nerd masturbation

• 
  @digitaljestin7 ай бұрын

  Is that a problem?

• 
  @edwinlundmark Жыл бұрын

  This was very, very well made and easy to follow! What a great resource! You should consider creating a 6502 assembly tutorial if you aren't planning that already.

• 
  @digitaljestin Жыл бұрын

  I don't know if I have what it takes for a full 6502 tutorial series. Anyways, there's already a great one here: kzread.info/head/PLPSrOWYluVLIJ1n-TsVb-BESL1tkSTRI_

• 
  @deterdamel7380 Жыл бұрын

  Will he deliver the Commander X16 now?

• 
  @digitaljestin Жыл бұрын

  People have already had them delivered, so I think the answer to that is already "yes".

• 
  @petermuller608 Жыл бұрын

  Nice tutorial!

• 
  @matthiasbreiter4177 Жыл бұрын

  No -Commod- erm, _Commander_ , without an impressive Christmas-Demo - loving it :)

• 
  @DailyCorvid Жыл бұрын

  So cool. I can't wait to get my hands on one of these. I am learning or relearning BASIC on the BBC model B and the Commodore 64 .... By the time the CX16 hits I shall be able to create biological humans in BASIC code. It's going to be so 1982 :) Oh yeah.

• 
  @digitaljestin Жыл бұрын

  Better get started on that weird science stuff...the first dev boards are already in the wild! If you haven't seen the new BASIC statements for audio, you're in for a treat! Although this video is about assembly, BASIC is going to a viable option for complex games on the X16.

• 
  @DailyCorvid Жыл бұрын

  @@digitaljestin I have seen no more than the 8BitGuy videos reveal, as I do not have a devboard. I'm sure it will be amazing though. I mean I was never one for complaining about BASIC being slow I always found it fine :)

• 
  @680x0 Жыл бұрын

  Is CODEX built into the latest version of the emulator? I mean, I suppose with the emulator, I can edit & assemble code outside and then just load the program when starting the emulator... but it seems like a fun way to try things out.

• 
  @digitaljestin Жыл бұрын

  It's in the r42 ROM, which should come with the r42 emulator. You should just be able to follow along with the video if you like.

• 
  @gurujoe75 Жыл бұрын

  SNES, Terranigma world map effect ..

• 
  @Dangerousdaze Жыл бұрын

  Thanks for the video. Extra props for the correct K&R form of "Hello, world!" :)

• 
  @digitaljestin Жыл бұрын

  Punctuation is important ;)

• 
  @BobSellers6502 Жыл бұрын

  Heh. CODEX needs some documentation. How do I set a breakpoint? I tried to use the BRK instruction, and that almost... sorta... did something... but nothing useful. I also can't load what I save. It seems to save, but says "Cannot load DBG information" or somesuch.

• 
  @digitaljestin Жыл бұрын

  There are some docs (sorry, I don't have the link handy), but they aren't great. They are also outdated. CodeX had to be sliced and diced into a plugin architecture in order to fit into a ROM bank. Unfortunately, this means a lot of functionality is missing unless you have those plugin files on the root of the SD card. I was kinda hoping this video would draw attention to these problems, and motivate a fix or two :)

• 
  @BobSellers6502 Жыл бұрын

  @@digitaljestin LOL. This explains why you glossed over the entire right hand side of the screen. And here I thought I would just swoop in, write some quick code to add some numbers, then step through it and show the results in watchpoints on the right. Well, the watchpoints work. Yeah, it needs some fixes! Riddle me this: Why use "ROM Banks" when you have a giant SDCard ready to stuff with apps? Yeah, yeah... I know, to get that "1980's experience." I was an adult in the 1980's, the computing experience wasn't that great, trust me. Well! It is what it is. I guess I'll look at the codex code some more, see if I can at least find where the program starts.

• 
  @digitaljestin Жыл бұрын

  @@BobSellers6502 yep, you guessed it. I think the idea behind the ROM bank is that it's always there. People may switch out SD cards all the time, so there's no guarantee on what's there. The Gen2 looks like it is going to be very cartridge focused, so it might make even more sense to ignore the SD card.

• 
  @tomwilson2112 Жыл бұрын

  This is a great video. CODEX has always been a little bit of a mystery to me, since it's kind of halfway between an assembler and a monitor. This video goes a long way toward demystifying that, showing its utility vs the Supermon monitor available with the MONITOR command. Again, great job!

• 
  @BobSellers6502 Жыл бұрын

  This is great! This is the kind of "gateway" experience people need to switch from BASIC to assembly. Once they outgrow this, the next step would be using a cross development computer and a good macro assembler like the cc65 suite.

• 
  @digitaljestin Жыл бұрын

  I've been thinking about doing a video on that as well. The X16 project had been so exciting lately that there's so much to talk about.

• 
  @digitaljestin Жыл бұрын

  I've recently done just that: kzread.info/dash/bejne/iGaqqcuCoae-m6Q.html

• 
  @slithymatt Жыл бұрын

  Great video, Jestin!

• 
  @Adiee5Priv Жыл бұрын

  9:35 you can resize it by offset in the `Select` tab

• 
  @brunch1572 Жыл бұрын

  Your setup is really amazing. I have a few questions. Some older Pokemon games along with other old RPGs use grid-based movement, not the jerky type like you spoke of in regards to Petscii Robots, but with smooth transitions between tiles. Each 16 x 16 tile is either fully traversable or fully not. Would a movement system like this work with your tools? Would it simplify things and would the simpler collision "save space"? You mentioned the size of your maps were determined by the tiles stored in VRam I believe. Is it possible to swap out tiles between scene changes? I'm also very curious about the color capabilities of the Vera. I believe you mentioned a 256 color mode but I have read that the Vera has 2 layers. Is the second layer sacrificed to get 256 colors on the main layer? Are there 16 colors per tile/palette and 16 palettes like the SNES? I noticed your character sprite displayed behind the treetops. Is this the second layer, or maybe some kind of Y sorting? I believe you said you were displaying in 2x size, does this mean your game shown is running at 320 x 240? Sorry for the barrage and nice work whether you can answer or not.

• 
  @digitaljestin Жыл бұрын

  Wow, that's a lot of questions. Let me try to get to them. You absolutely could have tile based collisions with smooth animations into the tiles. The tools I'm using to generate the tiles and the maps would work for this. You'd just designate every tile as collideable or not either with automapping like I'm doing, or something simpler like keeping all tiles that collide above or below a certain index in your tileset. When it comes to my pixel-level collisions, it costs more CPU than it does memory. I wouldn't be able to pull it off if the X16 wasn't 8mhz. Swapping tiles in your map is certainly something you can do. My approach is the simplest, which I get away with because of how much VRAM the VERA has. Older systems would require tile swapping for something like this. No, you don't sacrifice layers for more colors. You have those layers no matter what, but VRAM is still your limitation. For example, both my layers share the same tileset. I wouldn't have enough VRAM for them to each have their own, so my tiles need to work for both layers. I could sacrifice a layer and its tile map in order to free up VRAM, and that could allow me to increase the size of the game map, but then the player couldn't walk behind anything. In 8bpp mode, you can have 256 different colors on a single tile...but it costs you VRAM. My 16x16 tiles each take up a full 256 bytes of VRAM, and I have 256 of them. Half of my VRAM is just tiles, and the other half has to have 2 layers worth of maps, my character set, and some other 1-off sprites that aren't in my shared tileset. I'm really abusing how much VRAM the VERA has. The tree effect is indeed the second layer. There would be less VRAM-expensive ways to achieve this effect, but with my CPU spinning on collisions, I'd rather just burn the VRAM. And yes, my game is running in 320x240 mode. It actually can run in 640x480 mode, but the player would see too much of the map at once and the character is too small. I prefer 320x240.

• 
  @brunch1572 Жыл бұрын

  @@digitaljestin Thanks very much for taking the time to answer all my questions. I now have have a few more. I have been working on a retro game for a while now and have limited myself to 4 colors per tile, like the NES but with a bigger color palette to choose from. You said the 8bpp allows 256 colors per tile. Is there a video mode that would allow for 4 colors per tile? Also, is there one for 16 colors per tile? 256 colors per 16 x 16 tile is massive overkill for me which is why I ask. You said you have both layers share the same tileset and would not have enough VRAM for each of them to have their own. Could you have one layer have the tiles you are not supposed to overlap, for instance the tree trunks, and have the other layer have only the tiles that are supposed to overlap the player, for instance the tree tops? Or would that not help anything? Oh and I also like the idea of keeping colliding tiles at a different index and I love 320 x 240. Thanks!

• 
  @digitaljestin Жыл бұрын

  @@brunch1572 First, I highly recommend you read through the VERA docs, where most of your questions are answered: github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md So yes, you can use 4 colors (2 bits per pixel, or 2bpp) as well as 4bpp. There's even two 1bpp modes, but the tile map is a bit different different. You in no way have to go my route and use 8bpp, which is quite wasteful, but goes to show just how amazing the VERA is. You could use one layer for collideable tiles and one layer for free tiles, but I don't think it would really give you anything. There are no interrupts for determining collisions with the tilemaps, so you'd still have to compare against something read from either RAM or VRAM. I went with RAM, so it could be completely independent of which tile or color I'm using on a certain part of the map (see the section of the video on collision overrides). If you want tile-level collisions with no additional memory usage, you can read the tile ID from the tile map in the VERA. However, I have to warn you that reading and writing to the VERA's VRAM is best done in bulk, and is not well suited to looking up a single value. See the docs on how the VERA's data registers work, and you'll understand. That's another reason why I just have a separate collision map in main memory, where it's much easier to read the exact value I need in order to determine collisions. If you are developing a game, I also recommend checking out www.commanderx16.com/ and joining the forums and discord. There's a lot of people there who can help guide you and answer your questions. They've certainly helped me!

• 
  @OpenGL4ever Жыл бұрын

  @@brunch1572 If you use only 4 colors, you definitely should use the CGA color palette for retro reasons. So cyan, magenta, black and grey. Or if you select palette 2 black, green, red and yellow. You also should use dithering.

• 
  @brunch1572 Жыл бұрын

  @@OpenGL4ever Thank you for your comment. What I meant about the 4 colors was more like how the NES does things. 4 colors per sprite or background tile (really 3 counting transparency for sprites or background color with tiles), but from a selection of 50-something total colors. I have been working on an RPG in Godot for a little over a year, and have settled on 4 colors per background tile (one color dedicated to transparent if applicable) and 8 colors per sprite (again with one color dedicated to transparent, which is obviously used much more often than with background tiles). This is all from a total custom palette of 256 colors. So if the X16 ever comes out, I will probably go with the 16 colors per sprite/tile mode with 256 simultaneous colors on screen to be able to directly port all art assets. Incidentally, this mode is extremely similar to the SNES which allows 16 different palettes of 16 colors each.

• 
  @earthsteward70 Жыл бұрын

  Would make a pretty dope effect for a racing game or a flight sim!

• 
  @digitaljestin Жыл бұрын

  It might, but you'd have to be clever about it. The scaling on the VERA happens on the whole screen, not per layer, so any sprites would be scaled as well. That's why I kept the sleigh above the horizon.

• 
  @earthsteward70 Жыл бұрын

  @@digitaljestin oh that does sound like a real pain in the ass. Oh well, pallete swapping can still produce an adequate effect for games.

• 
  @ltva878111 ай бұрын

  FX update incoming, it would allow for smth like this