borgar Posted June 5 Share Posted June 5 Yes indeed. I have tested this and had no problems importing and drawing a screen from binary input. Many thanks. 2 Quote Link to comment Share on other sites More sharing options...
desertfish Posted June 7 Author Share Posted June 7 (edited) ... unfortunately another asm symbol scope issue now cropped up. I'm not done yet Edited June 12 by desertfish Quote Link to comment Share on other sites More sharing options...
desertfish Posted June 23 Author Share Posted June 23 (edited) 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? Edited June 23 by desertfish Quote Link to comment Share on other sites More sharing options...
Scott Robison Posted June 23 Share Posted June 23 I've not looked at your project to know how possible this would be, but are the differences so onerous that you really can't do #3? Or even #4: Have the runtime select v38 or v39 based on the ROM version at runtime? I know, it's really easy to say "why not" when you have no idea what the code looks like. Quote Link to comment Share on other sites More sharing options...
desertfish Posted June 23 Author Share Posted June 23 (edited) 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. Edited June 23 by desertfish Quote Link to comment Share on other sites More sharing options...
Snickers11001001 Posted June 24 Share Posted June 24 11 hours ago, desertfish said: Which option would you choose and why? Make it work how YOU want it to work. Each of your options has some headaches (for you and for users) but since the major changes in R39 (banking, rom routines that live somewhere else) are probably important for your software, bottom line is you have to decide how much dev time you want to spend targeting an emulator version (and maintaining a parallel code-path for it) to service an emulator/rom version that we know will not be what comes out as the X16 hardware or any future official emulator release. Its true that there's a bit of a disconnect right now, with the 'docs' all being r39 but the official downloadable emulator release at r38, but I suspect behind the scenes there are goings on that probably represent a good reason there hasn't been an official r39 release as yet. If you target r39 then even if they make some tweaks (whether as part of a release or due to feedback when they ship hardware for beta testing) you can adapt and roll with it. If you target r38, then you know you're developing toward a dead-end and will have to retool for r39 eventually anyway. It seems to me that anyone with the chops to use this particular piece of software (which probably doesn't include me at present although I hope to have the time to play with it later this summer) will be able to make or get their hands on an R39 build during the time (which may be shorter or longer, who knows) before an official r39 release. 1 Quote Link to comment Share on other sites More sharing options...
borgar Posted June 24 Share Posted June 24 Right now I'm fine with 1. I'm basically not going to require the new functionality in the near future so the new compiler work with the old emulator for me. Quote Link to comment Share on other sites More sharing options...
BruceMcF Posted June 24 Share Posted June 24 (edited) The thing about backward compatibility ... it's backward compatibility with a version of the prototype that is not going ahead to production. I'm not a prog8 user, SO this doesn't count as a user request, but to my mind, either Micheal Steil just has something taking his time right now, and he'll push a new revision when he has time to do the house keeping, or else is occupied with Kernel development, and the next revision will incorporate additional new ROM code. In either case, reverting to the previous revision is making a change that is on a countdown to needing to be changed back. So I'd ADVISE against it, but that's just advice, it has no standing as a user request. Edited June 24 by BruceMcF Quote Link to comment Share on other sites More sharing options...
desertfish Posted June 24 Author Share Posted June 24 (edited) 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 Edited June 24 by desertfish Quote Link to comment Share on other sites More sharing options...
desertfish Posted June 25 Author Share Posted June 25 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. 2 Quote Link to comment Share on other sites More sharing options...
desertfish Posted October 13 Author Share Posted October 13 (edited) after a long wait, Prog8 7.1 (beta version) has just been released. https://github.com/irmen/prog8/releases/tag/v7.1-beta Most of the changes this time are internal to improve code quality and testability. But several important bugfixes and enhancements have also been made. One thing to mention now is that the ``%target`` directive has been removed, the compilation target is set on the command line options. A full list of changes will be published on the 7.1 final release. In the meantime, here is the changes list since 7.0 https://github.com/irmen/prog8/compare/v7.0...master Edited October 13 by desertfish 4 Quote Link to comment Share on other sites More sharing options...
Ju+Te Posted October 13 Share Posted October 13 Wow, this looks like a really good programming environment! Much more structured and high-level than pure assembler language - approximately that what I had dreamed of. And, as a Java developer by heart, I also like how it is made. 1 Quote Link to comment Share on other sites More sharing options...
desertfish Posted October 24 Author Share Posted October 24 Version 7.1 of the Prog8 compiler has just been released https://github.com/irmen/prog8/releases/tag/version7.1 Documentation is here https://prog8.readthedocs.io Here's a list of the changes: - removed %target directive because it was too confusing for what little it did. Just use -target command line option. - non-asmsub subroutines can no longer be inlined because the way this worked was not reliable - internal code refactoring to improve testability and reliability - several error/warning message improvements - added support for secondary alternative emulator to launch, with '-emu2' option (box16 in case of commanderX16) - fixes for various issues related to different output path - %asmbinary path related assembler bug fixed - float[] array initializer bug fixed - fixed some assembler bugs in swapping values with swap() - fixed bug in palette.set_color - fixed bug in optimizer that sometimes removed subroutines that were referenced, causing assembler crash - some other miscellaneous bugfixes and improvements. Quote Link to comment Share on other sites More sharing options...
Ju+Te Posted October 24 Share Posted October 24 How to use different source code files? Is it possible to declare some library code parts as public (visible to the outside) while others remain private (only visible from the library's code)? Quote Link to comment Share on other sites More sharing options...
desertfish Posted October 24 Author Share Posted October 24 Everything is public in Prog8, there's no concept of private accessibility. You can use scoping to structure your code though (modules, blocks, subroutines). Quote Link to comment Share on other sites More sharing options...
desertfish Posted November 6 Author Share Posted November 6 (edited) Version 7.2 of the Prog8 compiler has just been released https://github.com/irmen/prog8/releases/tag/v7.2 Documentation is here https://prog8.readthedocs.io This is mainly a version with performance optimizations. Various parts of the code generator now create faster code, and sometimes also smaller code. Depending on your source code, you can observe pretty significant gains in resulting program size (tens to hundreds of bytes smaller). Other fixes: PETSCII block drawing character mapping was updated to now correctly separate certain box line characters Fixed type casting errors related to certain const propagation str is now allowed as a parameter type in subroutines (it is passed by reference/address) compiler no longer crashes when an input file doesn't exist gradle builds now automatically run installDist task after build updated to Kotlin 1.5.31 Edited November 6 by desertfish 3 Quote Link to comment Share on other sites More sharing options...
borgar Posted November 8 Share Posted November 8 Very nice. My only currently working project (https://www.commanderx16.com/forum/index.php?/files/file/182-petaxian/) still compiles and run fine though there is no reason to rebuild and upload yet. I have made the Git project public (https://github.com/cyborgar/Petaxian) in case anyone want to look at a bit larger Prog8 code example compared to the mostly smaller examples coming with the compiler. I have organized code in multiple files/modules. Though there is no code protection this does require explicit references when crossing modules and that helps a lot with visibility. I have (slowly) started on another clone game (this one is going to copy liberally from Llamasoft's Gridrunner) but I've just gotten started. I'm going to focus on getting it to work on C64 before I'll probably port it to CX16. 3 Quote Link to comment Share on other sites More sharing options...
desertfish Posted November 10 Author Share Posted November 10 (edited) For comparison Petaxian compiled with prog8 7.0: 19639 bytes Petaxian compiled with prog8 7.2: 19405 bytes 234 bytes of overhead removed update: Petaxian compiled with prog8 7.3: 19258 bytes another 147 bytes of overhead removed by producing more efficient code Edited November 14 by desertfish 2 Quote Link to comment Share on other sites More sharing options...
desertfish Posted November 14 Author Share Posted November 14 (edited) Version 7.3 has just been released https://github.com/irmen/prog8/releases/tag/v7.3 Docs are here as always https://prog8.readthedocs.io/ More improvements in generated code efficiency, resulting in smaller code that runs faster. (see the post above this one for an indication of savings you might see) Also added a few small new quality of life features. fixed operator not priority: it is now higher prio than and/or/xor ! fixed division of signed bytes by 2 added new cos and sin builtin functions cosr8 sinr8 cosr16 sinr16, and also their unsigned valued siblings. These make it easier to deal with arcs of degrees 0-359 rather than 0-255 of the existing trig functions. added signed versions of the cx16 virtual registers: r0s - r15s including the L and H byte variants of them. less temporary variables generated and used more optimizations to expression evaluations compiler no longer uses cx16 R15 virtual register as tempvar unit tests now use KoTest as test framework. Edited November 14 by desertfish 1 Quote Link to comment Share on other sites More sharing options...
desertfish Posted November 16 Author Share Posted November 16 (edited) While I was boasting about the reduced code size of the compiled Petaxian game, I now discovered that a bug has crept in in 7.3 that now makes the sound glitch out on the C64 build of Petaxian. I will investigate and fix this soon, hopefully. Weirdly enough the game still works fine with sound on the X16 build. update: found the bug and fixed it for 7.4, there was a new optimizer added that was too aggressive in removing double-stores Edited November 18 by desertfish 1 Quote Link to comment Share on other sites More sharing options...
desertfish Posted Tuesday at 10:00 PM Author Share Posted Tuesday at 10:00 PM (edited) Version 7.4.1 has been released https://github.com/irmen/prog8/releases/tag/v7.4.1 Documentation as always here https://prog8.readthedocs.io Even more improvements in generated code efficiency, resulting in smaller code that runs faster. improved code generation. optimizer is now smarter about accesses to memory mapped IO that shouldn't be optimized away performance improvements in the compiler itself, updated to Kotlin 1.6 fixed some illegal instructions in the conv module on c64 target other bugfixes documentation improvements Edited Wednesday at 08:46 PM by desertfish quick fix for broken function call argument count check 3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.