Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 04/26/22 in all areas

  1. The activity here on the forums has been increased as of late, and the Discord server is particularly active. Anyone not participating there may not be aware of the rapid advancements that are going on with the recent collaborations there. Overall, I'd have to say that things are starting to feel much more positive with the X16 project and community, and I just wanted to take a moment to recognize a few individuals who I think have really helped make this happen. A huge thanks to M. Steil for getting the Github Repo active again and being so approachable for patches and PRs to improve the kernal and emulator. Thanks to Tom, Scott, and all of the others who have picked up the ball in maintaining this website and forums! Thanks to Frank for opensourcing the VERA code - this has helped the emulator/kernal devs tremendously, and has even helped identify and patch a bug in the FPGA's sprite rendering Wavicle and Jeffrey H. have both been producing their own home-brew X16-on-a-breadboard projects, which have also helped in the general debugging of issues and brought new insights to the community and dev team. There are many others active on the Discord, and it's quite an upbeat place to be these days, and I just wanted to share my excitement for the state of the union, so to speak.
    10 points
  2. https://github.com/commanderx16/x16-emulator/releases
    10 points
  3. https://github.com/commanderx16/x16-emulator/releases
    9 points
  4. I created a pair of tools that I've been using to create and edit tile sets, tile maps, and bitmaps for the Commander X16 (or anything else that uses the VERA). The purpose of these tools is to allow you to use GIMP and Tiled for creating your graphics. The first tool is a GIMP export plugin that can output VERA compatible tile sets and bitmaps. This eliminates the need for post processing like is needed when exporting a raw indexed file that the GIMP does out of the box. It can also go a step further by generating a Tiled tile set file (*.tsx) that can be used to draw tile maps. Best of all, the plugin supports non-interactive mode, meaning it can be called from a command line or makefile, treating your GIMP project file (*xcf) as a source for your resources. https://github.com/jestin/gimp-vera-tileset-plugin The second tool is a command line converter from Tiled's tile map file format (*.tmx) to a VERA compatible tile map file. This is also intended to be called from a makefile, so you can just edit your maps in Tiled and rebuild. I've figured out a simple way to use Tiled's automapping feature in combination with a command line argument in my converter to generate collision maps based on the layers you export. These collision maps wouldn't load into the VERA, but rather the Commander X16's main memory, and you'd have to write the code to make use of them in your game. However, once all that is complete, collisions (as well as map interactions) become a by product of your map design. https://github.com/jestin/tmx2vera I've created a quick demonstration video of these tools, so you can get a feel for what they offer: To keep it short, I didn't go into collision maps, but I'll likely create a follow up video to cover that topic in depth.
    8 points
  5. Hi all, I recently started a retro-style FPGA-based computer project and Blog. I have decided to use VERA as the graphics controller for this project. I thought it relevant to post here. Here is the latest Blog post: https://epsilon537.github.io/boxlambda/graphics-and-sound/ Cheers, Epsilon.
    6 points
  6. When programming in assembly language, quite often you will need to do calculations that would normally require floating point math. Those subroutines are available, the same ones that BASIC uses, but they are very slow. And if you're programming in assembly, you're doing so because it's much faster than BASIC, so using those routines can defeat the purpose, particularly if you need to do a lot of such calculations. Ideally in assembly language you want to have most of your variables consisting of single bytes, not the four used for floating point. It's having to move all those bytes around and doing calculations involving all of them that makes the floating point subroutines slow. And if you're going for speed, you can make a tradeoff: increased speed at the expense of accuracy. A function involving a single byte can just be a lookup table. Over the last several years I have developed a number of lookup tables and subroutines that enable some very fast math on the 6502 and now 65c02. Inspired by @svenvandevelde's question about ATAN2, I decided to compile many of them into a single 8kb file that can be loaded into banked RAM. I have other such routines and lookup tables, but I decided to just include those that would most likely be useful to the broadest range of applications. These lookup tables and functions will work on all revisions of the X16 emulator, and indeed will work on any 65c02 system as long as the file is loaded at $A000. The functions are all called through JMP redirects in page BF, and those JMP table locations will not change if I do revisions on the code. I'm pretty sure I killed all the bugs, but some might have slipped through. I'll be using further posts in this thread as sort of a user guide, but attached to this post is the file FASTMATH.BIN (the lookup tables and functions) and a text file containing the BASIC program that made all of the lookup tables (but don't copy and paste it into the emulator or it will overwrite FASTMATH.BIN). When using FASTMATH.BIN, you must use a relocated load to put it into banked RAM, otherwise it will load into memory at $7000 and won't work. Or you could load it into its default location at $7000 and just copy it up into the RAM bank of your choice. This software is released under an MIT license, meaning you can use it freely for any purpose, commercial or non-commercial, as long as you leave the MIT license in there (it's located at $BF7F). And please, these functions are all just approximations accurate to about 1%, so don't use the software for controlling a nuclear power plant or medical equipment. maketables.txt FASTMATH.BIN
    6 points
  7. A lot of the ML routines that we can access with the SYS command actually require the Accumulator, X, Y, or flags to be set to specific values. As it turns out, the BASIC SYS command actually has a way to pre-load these values into the CPU registers, as well as a way to read these back after the routine exits. These values are stored in $30C-30F, like this: 780/$30C: Accumulator 781/7$30D: X register 782/$30E: Y register 783/$30F: Status Register/Flags So if you wanted to call a routine like PLOT, which moves the cursor to column Y and row X, you'd set the registers like this: POKE 781, 10 POKE 782, 5 POKE 783, 0 : REM Clear the flags SYS 65520 This will place the cursor on row 10, column 5. Or, if you wanted to read the cursor position, you can set the carry flag: POKE 783,1 SYS 65520 X = PEEK(781) Y=PEEK(782) And yes - the X and Y are backward. The X register stores the row and Y stores the column. It probably has something to do with certain addressing modes only being available to the X register and others only being available to the Y register... Of course, the Commander has the LOCATE command, but if you're coding for BASIC 2 (C64, PET, etc), then this is the way to directly position the cursor. Another one that I find useful is the "stuff the keyboard" API: This will print the appropriate commands, then position the cursor so that two presses of the RETURN key loads and runs the next program. And since the keyboard buffer conveniently has two CRs in it, your next program will run. Here's the output (assuming F$(C) is TREK.PRG):
    5 points
  8. Wow I really like the look of the new 80x30 display mode. This is what I fondly remember from my Commodore 128 days.
    5 points
  9. I'm trying out release candidates before publishing the final r41 release. This is RC3: http://www.pagetable.com/docs/tmp/x16emu_linux-r41_rc3.zip http://www.pagetable.com/docs/tmp/x16emu_mac-r41_rc3.zip http://www.pagetable.com/docs/tmp/x16emu_win-r41_rc3.zip Please test and report issues here. The final version will be released within a week. Release notes: KERNAL keyboard added 16 more keyboard layouts (28 total) Default layout is now Macintosh US "keymap" API to activate a built-in keyboard layout custom keyboard layouts can be loaded from disk (to $0:$A000) Caps key behaves as expected support for Shift+AltGr combinations support for dead keys (e.g. ^ + e = ê) PgUp/PgDown, End, Menu and Del generate PETSCII codes Numpad support Shift+Alt toggles between charsets (like C64) Editor: "End" will position cursor on last line VERA source/target support for memory_fill, memory_copy, memory_crc, memory_decompress [with PG Lewis] fixed headerless load for verify/VRAM cases [Mike Ketchen] don't reset screen colors on mode switch BASIC: BLOAD, BVLOAD and BVERIFY commands for header-less loading [ZeroByteOrg] KEYMAP command to change keyboard layout support DOS8..DOS31 (and A=9:DOSA etc.) to switch default device MOUSE and SCREEN accept -1 as argument (was: $FF) Changed auto-boot filename from AUTOBOOT.X16* to AUTOBOOT.X16 Monitor: fixed RMB/SMB disassembly Emulator: allow apps to intercept Cmd/Win, Menu and Caps-Lock keys fixed -prg with -sdcard fixed loading from host filesystem (length reporting by MACPTR on EOI) macOS: support for older versions like Catalina (10.15)
    4 points
  10. Another shout-out to @StephenHornfor the excellent Box16 emulator - it's a god-send for me in my sound debugging endeavors.
    4 points
  11. Yes. @Michael Steil deserves a medal for his hard work, and @Frank van den Hoef single-handedly revitalized the project when he open-sourced VERA. The fact that we're seeing homebrew breadboard implementations is simply amazing!
    4 points
  12. The 'FPGA-ness' of the computer sits at the center of this project. I would like to build a machine where it's doable and fun to mess around both on the software side and the hardware side. On PC, a developer is typically limited to application space. You have to code against a bunch of APIs that other people have cooked up. On the Commander X16, you get to control the entire machine, from software. BoxLambda takes that one step further by letting you create or modify both software and hardware. So, the lofty goal is to remove the great software-hardware divide . There are not that many people with skills in both domains, but I'm sure there is interest, especially among bare-metal assembly level programmers that want to drill down just a bit further into the machine. On the other hand, building a computer simply for the joy of doing so is certainly a big part of it
    4 points
  13. tl;dr: no. GeckOS is as close as you're likely to get. Long version: No. Modern Linux (or more correctly, modern POSIX) is far too complex to run on an 8-bit CPU like the 6502. Even the first version of Linux was designed for 386/486 PCs and uses the native multitasking features of those CPUs. So porting Linux itself in any meaningful sense is simply impossible. However, Linux is a clone of the UNIX operating system, developed by AT&T. If you extend that question to "can you port UNIX to the 6502", everyone will point at GeckOS. While GeckOS is not UNIX, either, it is designed to be as much like UNIX as you are likely to get on an 8-bit computer. https://en.wikipedia.org/wiki/GeckOS So the question becomes: can you port GeckOS to the Commander X16? Absolutely. One of of the bright points of the X16's design is the decision to stick with the Commodore style KERNAL, which allows software to be fairly easily ported between Commodore-like systems. Well designed software can even be ported to non-Commodore platforms, like BBC Micro, Atari, or Apple, by modifying the I/O routines to fit the BIOS of the platform in question.
    3 points
  14. "I love the retina display on this phone!" "But, but ... that's NOT a retina display at all!" "OK, to be fair, it's a retina display given MY retinas. YMMV."
    3 points
  15. Sorry... I looked this up on one of the Commodore 64 Wikis, which didn't spell it out very clearly, so I got the order wrong. I've fixed the Wiki entry and my examples above (with screen shots showing actual code and program runs). https://www.c64-wiki.com/wiki/SYS#Passing_parameters_via_registers
    3 points
  16. It's from Gulliver's Travels. The two Lilliputian factions at war were the big endians and the little endians. The dispute was over which end of a soft-boiled egg was the correct one to crack into. Thus a little endian starts at the little end, and a big endian starts at the big end. That's how the terminology works for byte order. You start eating at the big or little end of the value.
    3 points
  17. Thanks. It's basically just a menu screen and init code right now. I like these kinds of turn-based, casual games, and I want to finish this one, since I wasted hours on a version of this on the Palm Pilot back in 1998 or so. I know what I want to do with it, but it'll be a bit before I get back to it. I've just got too many irons in the fire, and Commander programming has been at the bottom of the list - but is rising, now that the emulator is moving forward. Michael has been knocking away a lot of rough edges in terms of usability, and I'm pretty excited about that.
    3 points
  18. Yeah that looks pretty good, I should probably change my text-elite trader program to use this screen mode as well. Square fonts just doesn't read nearly as well as tall fonts....
    3 points
  19. https://www.pagetable.com/docs/tmp/x16emu_linux-r41_rc3.zip https://www.pagetable.com/docs/tmp/x16emu_mac-r41_rc3.zip https://www.pagetable.com/docs/tmp/x16emu_win-r41_rc3.zip
    3 points
  20. The discussion above prompted me to check the behavior of my File based Assembler and yup, it failed to assemble LDA $0024,Y as well thinking it is LDA $24,Y which is an unexisting addressing mode. This has now been fixed, but was an interesting case!
    3 points
  21. Yes. Building memory managers is a fascinating subject. How to make it fast, achieve requirements, small code base, use memory efficient, avoid long loops, easy to use etc ... There are tons of "examples" on the internet and github using C on 32/64 bit machines and using the operating system brk on unix or memory allocation using win 32 api. However, on a naked cx16 in 8 bits architecture this topic gets a whole other dimension. You need to manage the addressing in memory yourself without operating system support! Then add to that the VRAM and BRAM banking and segmentation, and you have a problem domain that is extremely interesting to solve.
    3 points
  22. In the famous words of the Neutral homeworld's ambassador: I have no strong feelings one way or the other.
    3 points
  23. Hi all, I'm a software engineer, retro computer enthusiast, and FPGA hobbyist from Belgium. I used to be part of the demo scene, first on the C64, then on PC. Both a long time ago. I've been lurking on the X16 forums for a while and finally found a reason to post. I started an FPGA project using VERA. I posted it in the Maker forum. My interests are not limited to VERA. The Commander X16 itself is a great source of inspiration to me and I hope it turns into a real, shipping product in the not-too-distant future. Cheers, Epsilon.
    3 points
  24. @Frank van den Hoef, I want to sincerely thank you for opening up the Vera code. I am building my own X16 compatible machine, but took a few other different design choices for myself. In my free time over the past few months I have been working on my own 'Vera' and only got as far as a scrolling text console with Bitmap layer under. It's a lot of work and still not totally satisfied with my results. I am currently taking the liberty of porting your work over to an Artix 7 that is currently driving my HDMI directly. Once I have the video working I'll likely move on tto some of your other features. I hope others make use of your work, but just know I will be and have my own fully functional machine.
    3 points
  25. Yep! Thank you clarifying that. I believe that I've fixed the Verilog causing this and sent a PR to Frank for consideration. (https://github.com/fvdhoef/vera-module/pull/11) For all those not on Discord here are before (current VERA design) and after (VERA design w/ my sprite priority fix) photos rendered on real hardware (with hand-drawn red circled areas where sprites were hidden because the scoreboard background sprite was rendered on top of them):
    3 points
  26. I have another quick update for this thread on progress with the SD card issue: The short version is: I've never seen my "Breadboard16" fail to recognize an SD card as seen in the update video from last August. VERA will usually not come out of reset if an SD card is plugged in, but this is an electrical problem between the SD card SPI lines and the FPGA configuration flash SPI. (The v4 VERA fixed this by adding a digital switch that disconnects the SD card from the SPI bus until after the CDONE signal from the FPGA.) In fact, @Frank van den Hoef's VERA design and FAT32 code has been remarkably reliable (as long as files are named using only uppercase, that's a limitation of the original CBM code though). I've asked @Michael Steil about his SD card experience as well and he also has never encountered this issue. I livestreamed my youngest playing both FlappyX16 and Chase Vault on my Breadboard16 compatible hardware to a small audience on Discord tonight which included @ZeroByte (author of FlappyX16) and @SlithyMatt (author of Chase Vault) and we all learned a bit about the differences between the hardware and the emulator and flagged some interesting corner cases for follow up (notably that the emulator significantly overestimates the available work units for sprite rendering in the hardware). In any case, I've emailed David Murray about the details of his SD card because at this point I'm suspecting the problem is his card more than the X16 hardware or software. Hopefully it doesn't end up in his spam folder!
    3 points
  27. My problem is with Jonathan Swift, who probably coined the term "inflammable" too.
    2 points
  28. So funny story i bought the new atari vcs console. And i was a little underwhelmed with it as a gaming console its OS left alot to be desired... but it runs Linux very well. I actually currently work from home on my atari. Hahaha
    2 points
  29. Hey @Scott Robison Turns out, someone beat us to the punch... there's a device that does much of what we're talking about. It's a drive emulator and network interface, named "Meatloaf." https://github.com/idolpx/meatloaf
    2 points
  30. The CX16 includes the "stable development platform" philosophy inspired by 80s 8bit home computers like the VIC20 and C64 .. but it's not like there is "one true and proper approach" ... a variety of different projects each with their own coherent approach makes for a more interesting Vera ecosystem.
    2 points
  31. I've had my old C64, 1741 floppydrive and an old Samsung "portable" TV in the attick so to speak for, well something like 30 to 35 years. During the the Corona period I dragged this out and tested and unfortunately my C64 didn't work anymore. Got the Light Blue/Blue screen without any text so I guess it could one of the ROMs that are bad. However, I did get hold of another C64 a few years ago that I hadn't tested yet. I found out the old power supplies where untrustworthy so I didn't want to risk anything and it took me a while to get around to order a new. Well, now I have new powerbrick (ordered from here : https://www.c64psu.com/c64psu/43-1488-commodore-64-c64-psu-power-supply.html) and the other C64 works without any trouble so far. Even the 1741 workes fine. At least 4 of the 5 old floppies (with hrm, "backups") works. I still didn't have any way to get the game over to the C64 but after looking a bit only I ended up with a TapeCartSD solution (cheap, easy to use for non-disk images like prg files). So today I tested Petaxian on real hardware for the first time. I may have to make the game a bit harder since I beat this on first try even with the terrible joystic (none of the decent joystic I bought back then lasted very long as far as I remember). The screen quality of the TV wasn't great when it was new, and has probably not gotten any better in the last 35 years and the antenna output is pretty bad as well. I actually tested with a monitor I have that takes just about anything as input (including from antenna) and the picture quality was actually worse than the one in the CRT. I'll just have to order C64 to SCART plug. Those are pretty cheap.
    2 points
  32. It's the simplest way to build tooling, such as asset editors (tiles, sprites, levels, music), although it's not strictly necessary. Ultimately, all that is necessary is a BIOS with text and file I/O, plus a 5 command monitor program: Examine Memory, Modify Memory, Execute, Save, and Load. Everything else stems from that.
    2 points
  33. I'm not sure what the BASIC interpreter would be for - I don't know of any NES games that run on a layer of BASIC. Then again, I suppose there are cases where you could use BASIC as a tool to create resources (sprites, music?) for the eventual ML code to access. Having an ML interpreter right on an NES reminds me of using my PE6502 kit computer. It boots into WozMon, which is sort of a bare-minimum OS, but also has an ML assembler onboard called Krusader (link to the manual). Sine the 2A03 is 6502-based it may be possible to get Krusader onto our hypothetical keyboard-enabled NES. Development in 6502 assembly on a 6502 for that same 6502 is, in my opinion, a fun challenge. You need memory space for the source code, for the assembled version of the code, for any data the assembled version draws on (strings, etc.) and for Krusader itself, all in a single 64k address space; and it's up to the programmer to manage all that manually. Working on the PE6502, I found myself coding low-level utilities that let me do simple things like "create a new string and save it at a given memory address". Once that tool was tested and working, I could delete the source code for it to free up space but continue to use the assembled tool as I continued to work on the project. These additional constraints are not ideal, but that's kind of the point of taking on the challenge of developing on-system. And yes, we could get around the space constraints with RAM expansions (on our hypothetical NES, not on the PE6502). I'm not sure what @Cyber is up to, but good luck! It sounds like fun!
    2 points
  34. This is RC3: http://www.pagetable.com/docs/tmp/x16emu_linux-r41_rc3.zip http://www.pagetable.com/docs/tmp/x16emu_mac-r41_rc3.zip http://www.pagetable.com/docs/tmp/x16emu_win-r41_rc3.zip All ISO chars are now reachable. As a bonus, Shift+Alt+k produces the X16 logo (in ISO mode). If I didn't break anything, I'll release this as r41.
    2 points
  35. I've been thinking about spending some time away from Zsound and making an asembly version of the OPL->OPM music conversion routine so this program can have the background music playing. I could just make the Zsound tool convert OPL and then output as ZSM and let the demo use Zsound to play the ZSM, but I think it'd be cooler if the demo were to actually use the original game files (so if it ever gets finished as a game engine, it could use real maps produced by the modding community) I think a good way to do this would be instead of converting in real-time, convert the entire song at load time and store in memory as ZSM.... Is there currently any free space in banked ram for this, @Jeffrey?
    2 points
  36. If so I would add about 4kb more in tables and code and the remaining 4kb would echo the Kernel redirects and JSRFAR etc from bank 4.
    2 points
  37. A chap called George Foot went on a bit of a mission and upgraded the Ben Eater design to increase the resolution and connect it up to a breadboard in a way that's synchronized with the CPU. Video series is here if you're interested. Pretty enjoyable to watch people doing stuff like this
    2 points
  38. Its not the "drawing speed" per se -- VERA is extremely fast, and the BASIC PSET command is already a pretty fast pipe into VERA's api. No, its the math, parsing, and variable stores/fetches that are the speed road blocks here. The "EXP" function is especially nasty. Implementing a polynomial expansion in 6502 code is a tall order, and that's a large part of what's going on when BASIC evaluates the inverse log function. Still, there's always room in BASIC for some speedups. I took your code and added a command to reset the "TI" system timer variable at the very beginning, and to print elapsed TI (i.e., jiffies) right before the END command. Result, 4289 jiffies on R38. (I'm just back on this forum from being away for a while and haven't yet had time to play with any of the new releases... lots of new developments, though... quite exciting!). Anyway, just I played with it for about an hour and came up with the below. This revision does the exact same thing as your program, but takes only 2804 jiffies in R38... an approx. 35.5% time savings. As with all BASIC optimizations, its now obtuse, and opaque, and borderline unreadable. But that's the cost for making BASIC faster, alas. 1 TI=.:DIMX,I,Y,E,C:L=-0.001:M=150:N=80:DIM M(255),D(141):SCREEN$80:A=COS(.785) 2 FORI=1TO141:X=I-70:D(I)=X*X:NEXT 3 FORO=1TOMSTEP2.5:E=A*O:I=O-70:C=I*I:FORI=1TO141:X=I+E 4 Y=E+N*EXP(L*(C+D(I))):IFY>=M(X)THENM(X)=Y:PSETX,ABS(Y-M),5:NEXT:NEXT:GOTO6 5 NEXT:NEXT 6 PRINTTI:END See my thread in HOWTOs for an idea of what's going on here, but by and large what I did was eliminate intermediate variables, kicked that multiplication that calculates the square of 'D" which was done over and over (but with exactly the same results) within the inner loop into an initialization procedure that just keeps the figures in an array, initialized variables by order of use (focusing on the inner loop) and did various things to streamline the code for the BASIC parsing engine. Let me know if you have questions about anything in particular and I'd be happy to try and explain.
    2 points
  39. Well, my 3D design skills are not up to such a large task just yet, so I went with an old project enclosure I had lying around for now, but it works! Not the prettiest thing, but at least it's all self contained and I can call it done! For now... Once my skills have improved and I can actually design something that I like, I will move it all over. Right now this good old rectangle box and some hot glue will do the trick. More info: http://thisoldgeek.epizy.com/projects/atomicpi.htm
    2 points
  40. Digital audio recorder (bonus points if it does uncompressed linear PCM) MP3 player Smartphone Dedicated "tape emulator', such as Tapeuino. FPGA emulator, such as Ultimate II+ or Turbo Chameleon.
    2 points
  41. Thanks for all your input. Together with data I have from 2019, I have compiled the following list, in the order that F9 will cycle through them: 00020409 United States-International 00000809 United Kingdom 0000041D Swedish 00000407 German 00000406 Danish 00000410 Italian 00000415 Polish (Programmers) 00000414 Norwegian 0000040E Hungarian 0000040A Spanish 0000040B Finnish 00000416 Portuguese (Brazil ABNT) 00000405 Czech 00000411 Japanese 0000040C French 00000807 Swiss German 00010409 United States-Dvorak 00000425 Estonian 0000080C Belgian French 00001009 Canadian French 0000040F Icelandic 00000816 Portuguese 0000080A Latin American The ROM bank is still only 2/3 full. Who can think of other useful layouts? Any comments on the order? The Japanese layout doesn't seem to be too useful, since the ISO-8859-15 encoding can't map any of the Kana characters, so it's very close to a US keyboard, no?
    2 points
  42. Works as intended (same on the C64): In BASIC immediate mode, the APIs are verbose. Once you run a program, they are silent.
    2 points
  43. First one to make this code play Conway's Game of Life on an X16 gets a gold star: life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}
    2 points
  44. I have started a new podcast with some esteemed members of the X16 community: https://www.retrobrewhouse.com This first episode went live this morning, and features introductions to myself, @Scott Robison, @TomXP411, and @ZeroByte We talk about our backgrounds, the games and other projects we're working on, our first time programming back in the 8-bit era, and why we are still doing retro development today. From the website you can subscribe with your favorite podcast app, but if it's not linked there, search for "Retro Brewhouse" within your app. If you don't see it there, let me know (a reply to this topic would be fine!) and I'll make sure it gets added. FYI: I am trying to get it on iTunes and Pandora, and for some reason they take a long time to get podcasts into their stores, but many other major ones (Stitcher, Spotify, Amazon, etc) already have it.
    2 points
  45. I have uploaded version 3 of the vbcc distribution for 6502 targets at http://www.compilers.de/vbcc.html Major changes since last update: - several bug fixes - improved code generation - linker mask optimizations to reduce overhead of some library functions (still much room for improvement) - improved attribute checks for banking - C64 new features: + stdio functions allow file access on 1541 compatible drives - MEGA65 new features: + free license for commercial usage + code generator uses 32bit extensions + code generator uses HW multiplier + full automated banking support + ROM-less library enabling full use of the entire RAM + stdio functions allow reading of files on SD card - BBC new features: + stdio functions allow file access + full automated banking support for systems with sideways RAM + support for command line arguments + configuration for clean return after exit - CBM PET new features: + added as new target We are happy to announce that the Museum of Electronic Games & Art e.V. (http://www.m-e-g-a.org) has decided to sponsor the MEGA65 version of vbcc. This does not only help us to continue supporting and improving this port but it also allows us to relax the terms of use for the MEGA65 community. Everyone may now freely use vbcc to develop MEGA65 code for commercial as well as non-commercial usage (for details please refer to the license in the documentation). We thank MEGA e.V. for the confidence in vbcc and hope that this step will help in the creation of new software for the MEGA65.
    2 points
  46. Congratulations with the R40 release! Happy to see that the errors with the files and the mouse i had to report earlier have been resolved. I will flag these as resolved and close the open ticket on github. Have a look below, this is running on the CX16 R40 emulator (wip): Note that there seems to be an issue with the -prg parameter of the emulator, but i need to investigate it further. When I open up the emulator using the -prg option, i get this:
    2 points
  47. Frank has merged @Wavicle's PR so that's good news.
    2 points
  48. PhantomX16 View File PhantomX16 A remake of Phantom Slayer game that i used to play on a Dragon 32 back in the day. This game could really make you jump. I have used this as a learning exercise for 6502 assembly language and programming on the Commander X16. Sounds and graphics are faithful to the original game. Controls: Arrows for left/right/forward/backward. Space key to shoot. T key to transport ( If you can find it in the maze ) This works on R39 of the emulator. Enjoy! Submitter howardwp Submitted 04/28/22 Category Games
    2 points
  49. I would like to add that upon further investigation, we realized that it was not a sprite work units issue, but a sprite priority issue. Namely, the VERA code draws sprites with the opposite priority as stated in documentation and as implemented in the emulators. Documentation/Emu behavior: Sprite 0 on top of all sprites, then sprite 1, etc..... VERA verilog behavior: Sprite 127 is on top, then 126, etc....
    2 points
×
×
  • Create New...

Important Information

Please review our Terms of Use