Jump to content

desertfish

Members
  • Posts

    693
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by desertfish

  1. I didn't know the C64 had Bomberman clones! Never played nor seen it back in the days, would have liked to though
  2. Prog8 7.0 has just been released. https://github.com/irmen/prog8/releases/tag/v7.0 Major changes and improvements since the previous release: CommanderX16 target: we now target the upcoming "V39" of the cx16 emulator and roms. Read the info box in the manual for more details https://prog8.readthedocs.io/en/latest/index.html#required-additional-tools the struct language feature has been removed. Rewrite any struct-uses as just the separate variables. improved random number generators. string encoding and string interning bug fixes various compiler crashes fixed %asminclude fixed (scopelabel argument removed as well) repeat loop code gen optimized some more fixed various assembly symbol scoping issues documentation improvements streamlined the grammar definition and improved some parse errors fixed warnings in gradle build scripts, updated some libraries and Kotlin runtime version.
  3. SIDs are an extremely good form of data compression
  4. Yeah I was thinking Tetris too but that originated in Russia, not Japan
  5. Seems like keeping the V39 (only) looks to be the best way forward, I'm happy with that. And @borgar makes a good point; if you don't actually use the parts that have changed your program still runs fine on v38. I'll make sure this is clear in the documentation too
  6. For this assembler I'm assuming we have enough memory to a) store all source text files in memory simultaneously b) store the resulting machine code program in memory c) have enough memory for the parsing and symbol table (the assembling process itself). It's a 2-pass assembler so I think it should be possible to avoid having to use the stack of open files during the reads themselves. I think we could just read the files sequentially when the assembler encounters include instructions in phase 1. And use the stack only in phase 2 where actual machine code is generated. This would reduce some complexity in the disk io routines (although the multi-file support across banked ram pages is still going to have to happen, rather than using one contiguous chunk of vera memory for storing the single source file currently)
  7. Good questions. There's no runtime though: prog8 compiles down to machine code in the end, and while doing so it makes various assumptions about the target platform (cpu type, memory mapped i/o registers, and rom routine locations). For example the memory locations of the floating point routines in rom -which prog8 uses for its float types- have changed between v38 and v39 roms and this will make compiled programs crash when run on the other rom version. So basically, allowing for a compiler switch more or less requires introducing a third target machine definition in the compiler something which is pretty involved and is potentially going to duplicate a lot of code and library files. Apart from that, on the discord it was correctly pointed out that it would also introduce the expectation of backward compatibility, which is complexity that I'm not wanting to go for.
  8. Ok wow Any idea about the quality of the program's code that it produces? Maybe eventually using llvm with all its advanced code optimizations as a backend for Prog8 isn't totally impossible...
  9. I guess in practice we have max 8 then as the keyboard and screen are already taken as default input and output io channels. Still who's going to program on the cx16 and use that many files in a project? (famous last words)
  10. Poll. I'm contemplating reverting the Cx16 V39 changes that I have already made in Prog8, for the upcoming 7.0 release -- because the actual release of an official v39 emulator+roms is taking way longer than I anticipated. keep v39 support in Prog8 as it is. You're targeting v39 already and can run it with a custom build of the emulator+roms as they are now on github revert back to v38 support because that is still the official cx16 release (and put the v39 changes back in once the official cx16 release is there) make it selectable via a command line switch Which option would you choose and why?
  11. @Stefan that file stack tracking the line number count is a solid idea. @Scott Robison 10 files should be enough (tm) I'm glad to learn it is actually possible to keep multiple files open and read from each of them. However maybe this isn't even necessary if we keep track of any import statements encountered along the way and executing them after the file they occur in has been fully read. Allowing multiple open files at the same time would also require changing prog8's diskio routines -- they assume a single open file channel (hardcoded)
  12. I would like to add a source and binary file including mechanism to the assembler, but that requires a total rewrite of the file I/O logic, to deal with multiple sources rather than one contiguous block of memory. I also have no idea yet how to keep track of what file the currently parsed source line is coming from, if you're jumping between files due to includes.
  13. So you already have an interrupt handler? so just do the vsync processing in there, why even wait for a vsync elsewhere?
  14. wait... how did you manage that vertical wave effect??? I tried something like that but couldn't get the vera to do what i wanted with the vertical scaling register
  15. ... unfortunately another asm symbol scope issue now cropped up. I'm not done yet
  16. I believe the assembly symbol scoping issue has been resolved.
  17. Yeah okay, so we have several issues with assembly symbol name scoping in the code generator. This is now on top of the list of the remaining things to fix for the final 7.0 release
  18. hm, that looks like a scoping bug in the compiler. I'll see if I can fix that. In the meantime, can you try to replace &rawdata with &main.rawdata ?
  19. Yeah it didn't matter much. I suspect it is taking a lot of overhead somewhere to pickle/unpickle the data passed between the processes. And indeed, switching to multiprocessing.pool.ThreadPool didn't improve things. I see no obvious big improvements to the code as-is. But I think it would be worthwhile to investigate what happens if you split the problem up differently. Rather than dividing it over the tokens to search for, I suggest trying an approach where you split up the source image in strips of 8 pixels high and process each strip in a worker process. So one worker processes one line of characters. I realize this will require quite a bit of rewriting...
  20. Hey, great stuff! Yeah multiprocessing can be a bit iffy, it could be that much time is spent passing the data set across different processes to work on it, and passing the results back. To avoid this, multi threading could help, but then you're sometimes constrained by Python's Global interpreter lock. I want to take a look at your code and see if I can tweak it a bit to make it faster! (for reference it runs in 5 minutes 30 seconds on my Ryzen 2700x)
  21. I've just released a new 7.0-beta2 version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta2 This version will likely be very close to the final 7.0 release because I'm not considering adding or changing anything new from now on (except bug fixes). Some of the most important fixes/changes since the previous beta release: string encoding and string interning bug fixes various compiler crashes fixed %asminclude fixed (scopelabel argument removed as well) repeat loop code gen optimized some more Once again: the CommanderX16 target targets the upcoming "V39" of the cx16 emulator and roms. Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator (although if you're not using floating point and bank switching, they will likely still work) Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.
×
×
  • Create New...

Important Information

Please review our Terms of Use