Jump to content

geek504

Members
  • Content Count

    53
  • Joined

  • Last visited

Community Reputation

33 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think I'll start with the grammar file... just gotta find it. I hope it's emacs-friendly (they do have a Kotlin major-mode available). Edit: It is... I was thinking of using them as "use-once and throw away", i.e. used as a mechanism to transfer paramenters to functions, and once in the function routine, the function copies the value into its local static memory reserved for these paramenters. In this manner, the calling program does not need to know the address of the static memory of the paramenters of any function (but needs to know how many parameters and of which type). Passing objects is also possible if used to pass a pointer to the object. Does Prog8 support pointers? Supporting both the C64 and X16 was a negative point for me. It adds more complexity than is needed especially since they have different design. If we focused just on X16 (or make a fork) things would progress much faster. Trust me, when the X16 comes out, I will never ever touch a C64 again!
  2. That is a great idea and one of the things that should be used and abused! I have been thinking about NOT starting yet another 6502 BASIC compiler but instead HELP out with Prog8! Gives me a reason to learn yet another programming language (actually two... Kotlin and Prog8). After Googling Kotlin I read that it drastically reduces boilerplate code which was the big reason why I kept Java away from me with a ten-foot pole! I hope to be able to sift through your code without getting bamboozled...
  3. That explains the lack of information on the Net! I had first assumed that you created this language which led me to decide to write a compiler based on a true and tested BASIC dialect. I wouldn't need to re-invent anything, just code away the implementations. Analyzing Prog8 I can see how it is a blend of many different ideas so implementing it wouldn't present much problems... but still involve some thinking! Feel free to add simple Prog8 source along with the generated assembly code in your Prog8 thread... I love analyzing compiled code and see how efficient or how to improve efficiency!
  4. Yea, it occurred to me too! Honestly I have never heard of Prog8 and actually I thought it was invented by you! Couldn't find much on Google... anyways I know BASIC quite well and the grammar is already done for C64 BASIC V2. I am also old-school UNIX programmer so I am much more comfortable with Flex/Bison (lex/yacc) and C. I also don't feel like patching up cc65. We can definitely exchange ideas!
  5. Doesn't exist yet... since I don't expect the compiler to be compliant to C-standards, I am thinking about writing my own (yet another) BASIC compiler akin to BASIC Boss but with more improvements. The only difference is that this one will be custom-made for the X16 and its improvements. I'll borrow many ideas from Woz's Integer BASIC, add HTAB/VTAB (or LOCATE) et al. With a BASIC compiler I won't need to bother the X16 devs for C64 BASIC improvements.
  6. I use vim too... I don't discriminate I use nano and pico to edit unix config files when I'm too lazy to install vim. I reserve emacs for *real* development All I need now is a console-based X16/6502 debugger... I am seriously considering converting my Apple ][ text-only emulator into such debugger... xdb
  7. After fiddling around with Atom and VSCode I reverted back to my trusty old emacs (both Windows and Linux). I did not like installing Cygwin nor Mingw so I installed Debian WSL and got my nice bash with all the useful tools. cc65 is a nice debian package and I can run the X16 emulator from my Windows installation just fine. I use Makefile from within emacs and version control with the old diff & patch tools. Slim and quick. I also came to an epiphany... I don't actually like cc65 due to its C-stack implementation. It causes inefficient code.
  8. Err... what videos? My config.cson didn't need the use of * file-types as per the instruction of the * language-65asm package: Also you mentioned: In that case, Atom might as well be Emacs with syntax highligting...
  9. Yeah, I am having problems getting SharpNinja extension to work smoothly if at all... it's really old. I am now trying to setup Atom like Matt says below: So I revert to Matt and ask... what's your setup like? Config files, workspace, hotkeys, build process, etc.
  10. Found two bugs in your game... #1: D7-D5 (Black move) became a White pawn. #2: E7xF6 This pawn capture came out of nowhere, there wasn't any pawn on E7... and took my Bishop for free! But alas, that didn't matter... the final position: Thank you for a good game of chess!
  11. So, (monochrome SVGA) 800x600x1bpp = (800 pixels / 8 pixels-per-byte) * 600 lines = 60,000 bytes is possible? Also, (monochrome XGA) 1024x768x1bpp = 98,304 bytes? Also, (monochrome WXGA+) 1280x800x1bpp = 128,000 bytes?
  12. I had no idea you could create different screen resolutions other the ones provided by the SCREEN command, i.e. mode $80 320x200x256 and $81 640x480x16!
  13. I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...
  14. Gotcha! But I think we don't have enough VRAM for two 320x200x256 buffers... that's why SlithyMatt did 2 pages with 16 colors each. Edit: DOH! 4bpp = 16 colors... I should go get my coffee... I'm going to start some assembly coding and would like to ask: What workflow are you guys following? Which assembler? What steps to get the binary file inside the emulator? etc. I think my way is just too slow...
  15. Gotcha! I just did a cursory view at the SCREEN function and only saw this: Mode Description Comment $00 40x30 text $01 80x30 text (currently unsupported) $02 80x60 text $80 320x200@256c 40x25 text $81 640x400@16c (currently unsupported) I expected other "modes" to be already pre-defined and not for the user to set it up manually...
×
×
  • Create New...

Important Information

Please review our Terms of Use