Jump to content

desertfish

Members
  • Posts

    598
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by desertfish

  1. No worries! There's nobody waiting for us I'm quite curious how that would turn out to be. !
  2. Nice man, impressive. I used to have a breadbin C64 then a C64-ii then an Amiga500 and finally an A4000 but these have all been sold off back in the day to get some money back for poor kid me to purchase the next upgrade
  3. You must live in a Tardis to be able to store that many things Are they all connected/working?
  4. desertfish

    Rogue Forest

    I like the fog of war a lot, very impressively done However I'm finding the game impossibly difficult. Even after picking up an axe, and being able to hit a minotaur with it for about 40 each hit, i didn't survive the battle. Usually because I am surrounded by other monsters too eventually. Unclear if this is because I'm bad at the game or that there may be a problem with the monster's HP or not, I don't know, but I've tried 5 times with the same result. Finally it seems the monsters are able to attack me diagonally, while my hero can only fight horizontally or vertically. This makes it unfair when surrounded by enemies you cannot hit! All in all lots of potential but not really playable for me as it is right now. Will be glad to retry an updated version to adjust my rating hopefully!
  5. It should be way way faster than basic. Some micro benchmarks comparing several languages (including raw assembly) is here https://github.com/KarolS/millfork-benchmarks/tree/master/6502
  6. I've just released Prog8 4.5 with a bunch of improvements and bugfixes. This version is required to compile the TextElite game correctly. Yeah version 1.0 of my text-elite space trader sim conversion is done! It can be found in the Download section under Games! @SerErris all planets, their descriptions and properties, and trade markets are procedurally generated like in the original
  7. desertfish

    TextElite

    Version 1.2

    90 downloads

    Imagine yourself, commander Jameson, in the cockpit of the Cobra MK-III with 100 Cr. in your bank and stationed on Lave, one of the more well known colonized planets. You're setting out to be a master trader and to get rich by exploiting commodity markets across the galaxy! This simulation engine is very faithful to the original procedural universe algorithms found in the actual Elite game. There are 8 galaxies to explore, each containing 256 totally different inhabited planets that you can travel to. Each planet is named, has certain government types and inhabiting species, and you can read a short description that characterizes the planet and what it is famous or notorious for. Of course every planet has a commodity trade market, and you have to exploit the various supplies or shortages and price differences to make your fortune! A simple navigation star map of the local cluster and full galaxy is also available. You can save and reload your progress to continue at a later time. Source code here https://github.com/irmen/prog8/blob/master/examples/textelite.p8 Written in Prog8, converted from original C source code obtained from http://www.elitehomepage.org/text/index.htm (this game can also run on the C-64 if you recompile it for that machine target)
  8. TextElite View File Imagine yourself, commander Jameson, in the cockpit of the Cobra MK-III with 100 Cr. in your bank and stationed on Lave, one of the more well known colonized planets. You're setting out to be a master trader and to get rich by exploiting commodity markets across the galaxy! This simulation engine is very faithful to the original procedural universe algorithms found in the actual Elite game. There are 8 galaxies to explore, each containing 256 totally different inhabited planets that you can travel to. Each planet is named, has certain government types and inhabiting species, and you can read a short description that characterizes the planet and what it is famous or notorious for. Of course every planet has a commodity trade market, and you have to exploit the various supplies or shortages and price differences to make your fortune! A simple navigation star map of the local cluster and full galaxy is also available. You can save and reload your progress to continue at a later time. Source code here https://github.com/irmen/prog8/blob/master/examples/textelite.p8 Written in Prog8, converted from original C source code obtained from http://www.elitehomepage.org/text/index.htm (this game can also run on the C-64 if you recompile it for that machine target) Submitter desertfish Submitted 10/11/20 Category Games  
  9. While there seems to be somewhat of a Kotlin target for Antlr, I went with the default Java target and mapped that to Kotlin classes myself. The translation of Antlr's generated AST classes into my own Kotlin AST classes is done mostly via the extension methods principle taken from https://tomassetti.me/parse-tree-abstract-syntax-tree/ In the end, I need my own custom AST Node classes anyway, so I *think* the current solution is adequate and having a native kotlin output from the parser generator doesn't give much extra benefits.
  10. .... or it provides "16 times the detail" as other retro platforms ... ? Oh wait that was supposed to be something else.
  11. I think both of your questions are answered at the same time: The assembly code starts at $080d (2061 decimal) so that it leaves enough room to put a tiny one liner basic program before it, starting at the usual $0801. The basic program is just 10 SYS 2061 -- so when you type RUN , the first thing basic does is doing the SYS into the assembly routine starting at 2061 that then takes over
  12. that looks like a useful article for when I'm actually ready to start using the more advanced features of the cx16, bookmarked
  13. @Greg KingOh man, the flashback I used that exact feature. Could play games on the C64 while the two drives were copying a stack of floppies. It was amazing
  14. Here's a sneak preview of my conversion of text-elite so far. While building it I've been adapting the prog8 compiler itself too to fix bugs and add features to make it possible to implement all this. Seems like the procedural galaxy generation is all working -- next up the actual market and trading simulation.
  15. I don't have a preference for one or the other simply due to the fact that I am not knowledgeable enough about parser generators to know the differences How would Prog8's grammar look like in a LALR 1 definition? (as compared to the current prog8.g4 spec) Why would it be preferable? I've chosen Antlr because that looked to be a high performance, well supported, and broadly used parser generator for Java (and thus, Kotlin). I'm open for alternative better solutions though. The parser is in its own project, so you could make another one next to it. The biggest effort would be the mapping into the Ast nodes that the rest of the compiler uses. And perhaps dealing with parser errors.
  16. Thank you again Stefan, CLALL looks like a convenient routine indeed. I can't imagine -for now- situations where I would be dealing with multiple open files at the same time, so I should be safe with that.
  17. Hmm, why is that? I was thinking if we do that, channel #1 would no longer refer to the io channel that we opened earlier?
  18. Well look at that. With Stefan's help I managed to make a program that displays the directory of the disk in drive 8. (without overwriting the program) It works on both the C-64 and the CommanderX16. It cleanly deals with I/O errors and you can abort it by pressing RUN/STOP. Fantastic!! Prog8 source code: %import textio %import syslib %option no_sysinit %zeropage basicsafe ; This example shows the directory contents of disk drive 8. ; Note: this program is compatible with C64 and CX16. main { sub start() { txt.print("directory of disk drive #8:\n\n") diskdir(8) } sub diskdir(ubyte drivenumber) { c64.SETNAM(1, "$") c64.SETLFS(1, drivenumber, 0) void c64.OPEN() ; open 1,8,0,"$" if_cs goto io_error void c64.CHKIN(1) ; use #1 as input channel if_cs goto io_error repeat 4 { void c64.CHRIN() ; skip the 4 prologue bytes } ; while not key pressed / EOF encountered, read data. ubyte status = c64.READST() while not status { txt.print_uw(mkword(c64.CHRIN(), c64.CHRIN())) txt.chrout(' ') ubyte @zp char do { char = c64.CHRIN() txt.chrout(char) } until char==0 txt.chrout('\n') repeat 2 { void c64.CHRIN() ; skip 2 bytes } status = c64.READST() c64.STOP() if_nz break } io_error: status = c64.READST() c64.CLOSE(1) c64.CLRCHN() ; restore default i/o devices if status and status != 64 { ; 64=end of file txt.print("\ni/o error, status: ") txt.print_ub(status) txt.chrout('\n') } } }
  19. Am I allowed to self promote? https://prog8.readthedocs.io/ cross-compiler for in-development "Prog8" language targeting 6502 machines C64 and CommanderX16
  20. What Ender says. <-- this is what you should see on the screen when typing that particular sequence
  21. Are you thinking about a pixel paint program in the spirit of the Sprite Editor that's available in the download section? Or more like a full screen bitmap paint tool such as the (rudimentary) Argis paint that's also in the downloads? Also it would be amazing if somehow the program could use IFF ILBM as bitmap storage format? So we can read/write those Deluxe Paint images from the Amiga era (I don't recall if there is a IFF chunk for images that are not composed of separate bit planes) edit: on second thought, using IFF is perhaps not the smartest idea for image storage format in the current times... also I suspect we'll likely end up defining our own chunks which kinda defeats the purpose for interoperability... maybe PNGs... (uncompressed? or are we able to do zip compression?)
  22. Disclaimer: I'm far from a compiler writer expert. That said, I know that the execution model of C and C-like languages depend on calling subroutines, that have their own variables including the subroutine's parameters. These are usually allocated on the stack or dynamically in the global memory heap. So that for every call to a subroutine, a new "frame" is created to contain those variables, and that "frame" is freed once the subroutine returns to its caller. This ensures the subroutine has its own private piece of memory for its own variables to work with and that it doesn't clobber variables elsewhere in the program. That mechanism doesn't exist in Basic. All basics I know have only a pool of global variables and a subroutine is no more than a gosub to a different line in the program -- all variables are shared across the whole program. The latter is much easier for the 6502 cpu to deal with because it has only very few registers and instructions and very limited instructions to handle the stack. So compilers for C-like languages have to jump through quite a few hoops to create that stack based execution model for their programs. Which I think is what is causing the biggest problems for those compilers. So yeah I agree that compiled basic can potentially be faster than compiled C however this will heavily depend on the code itself too. Some things are very awkward to express in basic as well and will likely result in massively inefficient assembly code even when compiled.... edit: for Prog8 (which is more or less a C-like language) I'm struggling with that stack based execution model too. In an attempt to optimize the generated code Prog8 has a limitation on how the variables and parameters for subroutines are allocated (namely: only once, statically placed in memory somewhere). With that we loose the ability to write recursive function calls unfortunately.
×
×
  • Create New...

Important Information

Please review our Terms of Use