Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/05/21 in all areas

  1. I branched the cc65 repo and started changing the cx16 lib. It now works with Invaderz and Brixx and both would now run on R39. In case anyone wants to check it out: https://github.com/AndyMt/cc65 I'll do some more testing myself before creating a pull request.
    3 points
  2. Version 1.0.0

    20 downloads

    What is double PETSCII? What is PETSCII you may ask first. PETSCII is the extended commodore text character set. This character set has been designed in such a way that it would enable simple graphics on the screen. Which would make it easy for would be programmers on the system, to make card games and so on. However easy to use, it is not easy to create very nice graphics with it.... But... This has changed somewhat. If you search for PETSCII art, you see people are trying to get cooler and cooler graphics out of PETSCII. Double Petscii is using the Commander 16's native graphics modes to overlay two layers of PETSCII graphics. This demo is an experiment in how that may be used. Tech info: -It was made with the cc65, in C. -The PETSCII mode used is lores text mode, with two layers. (40x30 chars) -All colors are standard colors. -1 Color is used as a color to be sacrificed for non black transparency, so there are 15 colors to work with, not 16. -Pictures drawn in hyperpetscii petscii online drawing program. https://hyperpyxel.com/?p=229
    2 points
  3. LORES DOUBLE PETSCII DEMO View File What is double PETSCII? What is PETSCII you may ask first. PETSCII is the extended commodore text character set. This character set has been designed in such a way that it would enable simple graphics on the screen. Which would make it easy for would be programmers on the system, to make card games and so on. However easy to use, it is not easy to create very nice graphics with it.... But... This has changed somewhat. If you search for PETSCII art, you see people are trying to get cooler and cooler graphics out of PETSCII. Double Petscii is using the Commander 16's native graphics modes to overlay two layers of PETSCII graphics. This demo is an experiment in how that may be used. Tech info: -It was made with the cc65, in C. -The PETSCII mode used is lores text mode, with two layers. (40x30 chars) -All colors are standard colors. -1 Color is used as a color to be sacrificed for non black transparency, so there are 15 colors to work with, not 16. -Pictures drawn in hyperpetscii petscii online drawing program. https://hyperpyxel.com/?p=229 Submitter CursorKeys Submitted 04/05/21 Category Demos  
    2 points
  4. Yup, this is the cause of the problem. I'll try to fix it in the parser. EDIT: fixed , the source file loader now normalizes all line endings to just '\n' and I've simplified the parser grammar to just deal with Unix line endings.
    2 points
  5. I wrote a series of blog posts/articles on Commander X16 architecture and coding. I have started with focus on beginners and then slowly moved to more advanced topics and techniques. First I tackle smaller chunks and use simple examples to show the topic in practice. After enough new knowledge is covered I write a complete game to utilize several of the techniques to illustrate how it all comes together so each new complete project is more complex than the one before. I do cover only Commander X16 specific so I recommend reading Commodore C64 BASIC tutorials and guides. Please note that the games and most examples are written with a goal to be as clearly readable and understandable so there is very little source code optimizations. Snake Game This game is written in very clean BASIC with very little trickery so not much special Commander X16 knowledge is required. We do VPOKE directly into video memory so only understanding of fundamentals is required. Recommended reading VERA Overview Topics Covered in Game Analyzing the game itself is a great way to learn basics like: How to structure source code (outer loops, game loop) What is Game loop Use of Data structure like multiple Arrays How to read Joystick, Keyboard How to use VPOKE to “talk to” VERA Video RAM organization and using colors Writing to certain location on the screen Using PETSCII control characters to display messages and title screen GOTO Crazy Snake Tutorial GOTO Download Tetris Clone This game introduces some more advanced features of Commander X16 and we have to take a bit more care of how to use data structures and optimize some parts of the game to make it playable. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Colors and Palettes Topics Covered in Game Tetris clone requires us to improve on pretty much all parts of the snake game structure: We have additional loops outside and inside game loop Advanced game collisions based on screen state Pre-calculate relative positions of four segments of each tetromino Customize color palette Customize tiles (characters) Speed increase per level Adding sound to the game GOTO Crazy Tetrominoes Tutorial GOTO Download Boulder Dash style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. We have to pay close attention to timings, synchronizing scrolling and animation, take care of different types of collisions, etc. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Simplest Sound Effects Library for BASIC Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Two phase approach to development Full color mode Full screen scrolling Two layer graphics Scrollable playfield Static HUD Animated full color sprites 256 color title screen in graphics mode Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset Sprite Sheet Fonts Sound effects library Title screen GOTO Crazy Boulders Tutorial GOTO Download Lunar Lander style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. Due to pixel perfect collision detection requirement we had to use small machine code routine. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Music Player Library for BASIC Programs Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Integration of machine code, Assembly source code is available Full color mode 256 Color Title screen Two layer graphics Bitmap background Tile based HUD Full color sprites Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset - fonts Sprite Sheet Background music Title screen GOTO Crazy Lander Tutorial GOTO Download
    1 point
  6. cc64 X16 View File cc64 is a small-C compiler, written in Forth, targeting the 6502 CPU. It's hosted on the C64, on the C16 with 64k RAM, and now on the X16. Runtime targets are available for all 3 platforms, on each host, allowing cross-compilation. The code lives at https://github.com/pzembrod/cc64. It's licensed under the 2-clause BSD license: https://github.com/pzembrod/cc64/blob/master/COPYING See https://github.com/pzembrod/cc64/blob/master/Usage.md for usage. See https://github.com/pzembrod/cc64/blob/master/C-lang-subset.md for details about the supported subset of C. Released under the 3 clause BSD license. Submitter pzembrod Submitted 01/19/21 Category Dev Tools  
    1 point
  7. Version 1.3.0

    272 downloads

    Raycaster demo (written in c and assembly) This version is a big improvement in performance: it now runs at 10+ fps! I am quite happy with the speed. The demo plays quite nicely now. See below description of version 1.3.0 for details. --- This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster. Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! This is how it looks now: Speed improvements in 1.3.0: Now running at 10+ fps! - Using zero page addresses for pretty much all my variables - Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication - Inlined the fast multipliers, so less copying of values, no jsr and rts - Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done) - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused - Cleaned up the main loop and several other parts - Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) New in this version 1.2.0: - draw functions have been ported to assembly. Much faster! - dda casting functions have been ported to assembly. Much faster! - drawing textures! - automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel) - automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel) - using joystick controls (you can use arrow keys and alt to control, you can hold down keys) - a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup) - changed the map to look like the first level in Wolfenstein 3D - added a border around the render area, just like Wolfenstein 3D Usage Unpack the zip. Make sure you have the .BIN files in the same folder as the source files. To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3 To run: x16emu.exe -prg RAY.PRG -run To play: up - move forwards down - move backwards left - turn left right - turn right alt-left - strafe left alt-right - strafe right To debug: p - turn on log screen o - turn off log screen t - turn on test ray l - rotate test ray left j - rotate test ray right Known issues (1.2.0) - Sometimes there is a corner of a wall not drawn correctly - Since there is no real V-sync you get "shearing" in the screen (requires double buffering) Next up: - Lots of speed improvements - Lots of cleanup of code (its messy now) - Add a time-per-frame indicator (using a vsync interrupt counter) - Mooaarr wall-textures! - Double buffer to prevent shearing - Show a map on the screen - Bigger map (limit is now 16x16) - Opening doors - Add (scaled) "sprites" - Lamps (scaled) hanging from ceiling - Stats in lower part, gun visible - AI, enemies Having fun! Jeffrey
    1 point
  8. Version 1.0.0

    105 downloads

    I played this game with my friends in grade school on the PET. Though unable to find the original, I found a stripped-down VIC-20 version -- which showed me the program's essential structure -- and the later 1986 version by Commodore, mainly designed for the Commodore 64. I used both to create this version, which retains the original algorithms, and tries to emulate the older PET version. It uses very little X16-specific code -- exactly, SCREEN and COLOR. It relies on the 40 x 25 screen, and it uses just about all 25 of those rows. The rest is all PETSCII and BASIC 2.
    1 point
  9. You don't. You can use the host file system for most applications, especially if you are just loading the entire file into RAM or VRAM. It is artificially fast, but that can be beneficial for speeding up your development process.
    1 point
  10. You should be able to read back the values once you've set them. That's the caveat though, you can't read them unless you've set them. Ie, you can't read the default palette. (Imho this should be set on startup by the kernel on startup...) Just checked, and the following does return $0f for both 'lda's. lda #$11 sta ADDRx_H lda #$fa sta ADDRx_M stz ADDRx_L lda #$0f sta DATA0 sta DATA0 lda #$11 sta ADDRx_H lda #$fa sta ADDRx_M stz ADDRx_L stp lda DATA0 lda DATA0
    1 point
    What (TomXP411) said! Amazing! Thanks so much for this. Looking forward to hammering on it, and to see how far it will take the system.
    1 point
  11. Added a Kernal/ROM version check. Will only run on R37 and R38, as well as on custom ROMs on your own risk. This is in preparation for the upcoming R39 on which the current game won't work.
    1 point
  12. Well, hello folks. Thanks for all the great work. I got started: https://rosettacode.org/mw/index.php?title=Mandelbrot_set&diff=prev&oldid=329606#Commander_X16_BASIC
    1 point
  13. Yes, I found the assembly version in the demos but the fun was making my own in basic for some Sunday evening nostalgia points!
    1 point
  14. I feel your pain on the desk space issue... I do like the shelf idea, was thinking of modifying my desk and adding a shelf to store all my electronic parts and tools. Right now I setup and old TV tray next to my desk to work on, but have no real space for all my "stuff" when not I'm not using it. Especially since I recently picked up an Arduino Uno and have subsequently been teaching myself how to use/program it, and that has led me to taking on several projects. (Will post about those later.) If I had known Arduino's were so easy to learn/use, I would have picked them up a long time ago. This was day one, about an hour after the first package arrived. haha Basically, I have what I need the most sitting around/under my desk, in a cubby-hole on my desk, or in a few storage containers. Thinking of modifying the cubby to hold more. I just more space and time. EDIT: I can't believe I missed your LED clock, I built the same one and have it attached to my top monitor. I also wish I had a real C64 on my desk. Oh, and I guess I "Couldn't Make Head or Tail" of Nord and Bert. haha
    1 point
  15. Yup, that's essentially what I'm doing, just using just switched out the logic in the SPLD to trigger the clock pin on the latch on the falling edge.
    1 point
  16. DANG IT!!! Found the last issue, Labeled the RW pin RWB in on the main sheet and RW in the logic sheet. Had to run a bodge from the RW input on my PAL to RWB net and now the board runs stable at 15Mhz!! woot!! Already started the 2nd revision with a few other enhancements like an LED array to show activity on the devices. It will be helpful when running slow and a cool light display when running full out.
    1 point
  17. Hello folks. I have been watching the YouTube videos with interest and I am looking forward to seeing the project come to fruition. I started using a (borrowed) ZX80 - although a friend's father was building something from a kit he got from the US and we were allowed to gaze at it a year or so earlier - then a rented (from the nascent local computer club) ZX Spectrum before getting my own Dragon 32. I then settled onto a Tatung Einstein TC01 (after brief stints with borrowed BBC and an Apple II). The D32 and the TC01 went with me to Uni where I studied Computer Science. They were both put to good use; the Dragon 32 with a MACE assembler coupled to a D5 development board kit used in operating system and architecture dev labs and the Einstein used write assignments and to develop software before transfer to the Uni's Unix systems (this meant I could do a lot more studying at my digs). Fast forward 30 years through time with Microsoft, IBM, Cap Gemini and freelancing, and I am still in the software industry (though now as an associate director). Those early machines did me proud! That original Dragon 32 is still working (plus another Dragon that I am refurbishing with a DragonPlus kit) with an SDCard interface, a working TC01 (with a Gotek) and a TC01 awaiting refurbishment. That D5 kit is still in the loft and I ought to dig it out. Not to mention all the PCs, RPis, NodeMCUs and other HA bits and bobs I have kicking around. I still get a kick out of programming (though it is a hobby nowadays) and those early games, and I am looking forward to getting hold of a Commander X16. Cheers, Chris.
    1 point
  18. OK, I read his post a few more times. On my initial readthrough, I thought he was saying the bug was in the garbage collection itself. On a few re-reads it seems he's saying that (a) on system initiation, basic zeros out the high byte of the "last temporary string" pointer but not the low one; and (b) the string operations themselves have a behavior that he claims in a corner case causes a fault, which he suggests is due to an optimization where the most recently used discarded string doesn't have its backpointer changed to include a garbage flag. But the more I reread his post the more confused I get. I'm not an expert on Commodore basic string management, but I don't think that there are back pointers in the VIC or C64 string heaps. On C64, which is what the CX16 BASIC is built off of, this statement in his post seems incorrect: " This starts at top of screen memory and copies all strings, which do not carry the garbage flag, to adjacent addresses, skipping the garbage strings." There aren't garbage flags or backpointers in Basic 2.0 along with the strings in the string heap. That's the reason GC on the C64 is not good: See: https://www.c64-wiki.com/wiki/Garbage_Collection#Garbage_collection_in_C64_BASIC.
    1 point
  19. And you're going to bolt it down to the table it sits on, right?
    1 point
  20. Oh, yeah; don't let me give you the impression that Java is bad. It just wasn't the right tool at that moment in time for that specific job.
    1 point
  21. I remember the emergence of Java. And Java is still a heavy language. But, there are even more piggy languages out there. So sloppy. However, I cannot honestly diss Java; it kept my career alive for the past 20+ years. And, also honestly, I do appreciate interpreted/bytecode languages. But yeah, C rocks. I’m writing my current X16 game in C, and that makes me happy.
    1 point
  22. Putting in the better GC of C128 would not help since the bug is also in C128: "I found this bug in all versions of Commodore BASIC, that I investigated, VIC-20, C64, C128, C65, MEGA65." https://c65gs.blogspot.com/2021/03/guest-post-from-bitshifter-fixing.html
    1 point
  23. You reminded me of a story... I spent the first 12 years of my career doing digital design as well as writing all the low level code for our designs. That was true for everyone in my office. Later as we scaled up production, we ultimately had to cave and hire a small team of software engineers to handle things like GUIs (what? No command line??) and interfaces to systems/infrastructure outside of our control. Up to that point, C was about as high level as we EEs got, but these fellows showed up wanting to use this new, cool language called Java. We all hissed and shook or heads, but they forged ahead and got something working. Unfortunately, it only worked about a fifth of the speed it needed to. Sometimes it's best NOT to use the latest and greatest. Java was a total pig at that time. LOL
    1 point
  24. Small update, relative to progress anyway, but Command Tracker has now been updated to work with the latest emulator/rom (r39) which includes the changes to how banks are handled and such. There were two bugs where I was doing an unsafe lda ("lda 0") which worked previously since the value at $00 happened to be 0 but could now have data in it (namely the current page of himem). I'm still having some visual artifacts I didn't see before, specifically with the active pattern scrolling stuff. But since that may get removed (perhaps only temporarily) I wasn't going to worry about that too much.
    1 point
  25. I've made an upgrade to my physical desktop. When I bought a new Audio Interface recently, my desktop simply became too cluttered, so I built myself a small custom shelving unit out of some spare boards and other pieces of wood from my woodshop. (I am NOT a skilled woodworker at all, and the 'spare bits' were mostly from things I'd butchered.) Front: Sonicware Liven 8Bit Warps (a synth). C=64 to the left. Bottom: the new audio interface, a TASCAM US_4x4HR. Works well but I don't like the physical case design. Takes up real estate, won't sit flat - it's permanently tilted backwards by two non-removable front feet. This was what prompted me to make the shelves. Floor 2: 1530 Datassette for the C=64. At left, the PE6502 kit computer in the Apple-wood stand I made for it. Floors 3 and 4: Region 1 (US) and Region 3 (Korea) DVD players. The computer they're connected to has a built-in Region 2 (Japan). Top: Cheap (Amazon Basics) speaker. I have a used hi-fi for music, but usually YouTube videos and the like sound best on a small speaker like this. Also, the first thing I ever soldered, a digital clock kit. Still works! For Christmas I bought my mother a book on how to crochet cacti and succulents. She then made me the two cactus friends in the pot at left. I've named them Nord & Bert.
    1 point
  26. Wow small world, midlands UK too :) -I'm on the hunt for a pre-order of the chickenlips edition, I mean Commander X16 :D
    1 point
  27. This is an unnecessarily critical and inaccurate comment, and isn’t the first time. It is not the tone we want for our forums. Please moderate your future comments before posting. I and others work extremely hard to keep the FAQ up to date and strongly dispute that “obsolete info is the norm around here”. In fact I do not believe there is one piece of obsolete info in the FAQ. And the FAQ is the single point that we send everyone to for the latest info. We are consistent about that. We cannot control somebody outside the core team mentioning to you something that they saw in a video by Kevin, and that person you chatted to labelling it an official announcement. Criticising a team who are working for free for not copying every thing that is said in a video into the already extensive FAQ is unreasonable. Michael is also not done with the new emulator version or the GitHub. You need to be more patient. The physical prototype will always be ahead of the GitHub. You also cite a wiki but as I have mentioned before, and as is clearly stated in the wiki itself, it is not official and we do not run the wiki. Would you prefer we have the fans who do run it take it down permanently if it does not meet your requirements? Finally please remember that this product has not even been released yet, nor have we taken a penny from anybody for it. We are offering unprecedented behind-the-scenes access to the development, which I don’t think has ever been done to this extent before even crowdfunding commences. Criticising us because we do not meet your high (and erroneous) standards will not be tolerated further. This thread has also run its course, with some unfriendly moments before today, so I hope everybody can just take a breath and perhaps move onto a different topic. Thank you for your understating.
    1 point
  28. Well, set in stone unless there is a show stopper problem. I would indeed expect a wave of FAQ updates after the Kernel gets updated to the "Rev kind of 3.0" board. [1] You get to the point where it is "arguing over taste". And if my recollection is accurate about what was said by one or another team member in Facebook discussion, it's not really possible to fault anybody for not seeing it, since searching Facebook comments is pretty useless ... and Facebook likes it that way, they don't want to be an archive of old conversations, they want an endless supply of new chatter. [2] For me, the start of the snowball rolling on sound was when they dropped the AY3's. AFAIU, the AY3's are not new-old stock or pulls, they are clones (used in dirt cheap toys, etc., because at a certain volume using an existing design is cheaper than redesign). If 98%-99% of the pulls test good and there is good experience with the pulls that test out, but that applies at random to both the YM2151 and the watchamacallit SAA1099's, then that's 96%-98% of pairs of chips that test good. I reckon a combination of an AY3' and a YM2151's would have had a better shot at withstanding the siren call of the video chip contributor who wants it to be (AFAIR hearing recounted) a video & audio chip. For the SD card, If Commodore 8bit era system designers were in some weird time machine scenario targeting SD cards, I reckon they'd do the same thing ... make a dedicated SD mode 0 SPI circuit, and put it in the chip with the fastest internal clock, which would have been the dot clock in the video chip. Building the correct 8bit single shot serial shift register with overflow to support the exact mode of SPI you need is just easier than a general purpose SPI master, and working off the dot clock beats working off Phi2 with a stick. I therefore have about as much trouble getting upset about accessing the SD card with an SPI circuit on Vera as I do about using an ATtiny84 in the power regulation / NMI front panel switch selection circuit.
    1 point
  29. After doing a bit more research on Commodore BASIC, I am concerned that a program like this: will not work. The reason is that Commodore BASIC tokenizes keywords as they are typed in, converting a string such as "PRINT" into a single byte. The strings of characters that make up keywords are meaningless to BASIC when injected directly into memory, therefore bypassing the tokenizer; doing so will cause a syntax error. Due to the space saved when a program is tokenized, programs are saved and loaded in this form. As a result, BASIC does not scan for keywords while loading a program. The issue is that the GRAPHIC keyword would not be recognized by the tokenizer of the X16, and would be preserved as a string of characters when the program is saved. When loaded on a C128, there would be a syntax error on line 40. To make this approach work, you would either need to re-tokenize the program before running it, or use a custom tokenizer that understands the keywords of all Commodore systems.
    1 point
  30. Version 1.0.0

    491 downloads

    Boulder Dash style game written in Commander X16 BASIC for learning purposes. Link to detailed description and access to source code on my blog: https://www.8bitcoding.com/p/crazy-boulder.html
    1 point
  31. Maybe it's a minimal 6502 + VERA implemented in FPGA that he used when originally designing the VERA before there were real X-16 dev boards?
    1 point
  32. Version 0.1

    28 downloads

    This demo shows the full 4096 color palette of the X16 by using the raster line interrupt. The matrix is 64x64 colors. Due to limitations of available CPU cycles I had to add black gaps in between the lines. But I still thought it to be nice to look at. And it works in the Web-Emulator.
    1 point
  33. Thanks for the thumbs up. What you are describing is some thing we discussed and debated at great length internally about six months ago. Long story short that is likely what the phase 2 design will be as I showed in the video. The case is less tall but may still allow for a right angle expansion card inside, and possibly and external expansion card adapter to allow for cards to sit outside the machine, like those C64 cartridge port expansions. [emoji106] Perifractic, X16 Visual Designer http://youtube.com/perifractic
    1 point
    Well, this is a paradigm changer! Now we can compile C code directly on the Commander, no need for external compilers.
    1 point
  34. For me, it's a feature that is best implemented as an expansion card (or maybe through the user port?); otherwise feature creep will increase cost and make the X16 ship a lot later. Besides, the added complexity means troubleshooting and support get trickier, so it's better to have a simpler platform at first and get it right. However, I would say guidelines on how to create APIs for the X16 and expansion cards could be enough to ensure different implementations of ESP32-base expansion boards behave well together and with software that will use them. Having clear guidelines will also spur hardware development for the X16, which would be nice.
    1 point
  35. This page is kind-of a placeholder for my questions and discoveries as I learn CMDR-DOS. Read the (current) Directory DOS"$" Make and Remove a Subdirectory DOS"MD:dirname" DOS"RD:dirname" Change Directory DOS"CD:dirname" DOS"CD:.." (to go up one level) Scratch (delete) Files DOS"S:filename" DOS"S:file1,file2,file3,..." DOS"S//dirname/:filename" Copy and Concatenate Files DOS"C:newfile=oldfile" DOS"C:newfile=oldfile1,oldfile2,oldfile3,..." Rename a File DOS"R:newname=oldname" Lock Files DOS"L:file1,file2,file3..." Creating a file in a subdirectory 10 DOS"MD:MY-DIR-001" 20 OPEN1,8,2,"//MY-DIR-001/:MY-FILE-1234,P,W" 30 PRINT#1,"HELLO, WORLD!" 40 CLOSE 1 50 OPEN 1,8,2,"//MY-DIR-001/:MY-FILE-1234" 60 INPUT#1,A$ 70 CLOSE 1
    1 point
  36. A good place to start would be to take a look here: https://github.com/commanderx16/x16-rom/blob/master/dos/README.md You could also take a look at this dos unit test here for some good examples: https://github.com/commanderx16/x16-rom/blob/master/test/dos.bas
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use