desertfish

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

you can always poke a short assembly routine into ram somewhere and SYS to it to do the tight loop, if you want to speed up things?

color gradients View File Early Amiga-demoscene inspired raster bars with color gradients. The color gradients are randomly generated. Written in Prog8 with a bit of inline assembly. Source code is available here https://github.com/irmen/prog8/blob/master/examples/cx16/colorbars.p8 Submitter desertfish Submitted 10/04/21 Category Demos  

that's a bold statement, and I strongly disagree with it. But let's leave it at this.

@TomXP411 you can use "mypy" with type annotations to statically check for types in your Python source code. It's still not enforced, but can catch many object type related mistakes at compile/build time.

Can you paste it in ascii here as well so i can run it easily myself? Thanks!

There's also the 16 pseudo-registers (r0 - r15) located in zeropage ($02 - $21) that you can use to pass data to and from assembly, I suppose.

Doesn't sound healthy for the drive

I did this for Dungeon Master, Dungeon Master 2, Eye of the Beholder 1,2 and 3, and Black Crypt. The spinner tiles were HELL.

wow!

I didn't know the C64 had Bomberman clones! Never played nor seen it back in the days, would have liked to though

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.

SIDs are an extremely good form of data compression

Yeah I was thinking Tetris too but that originated in Russia, not Japan

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

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)

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.

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...

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)

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?

@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)

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.

So you already have an interrupt handler? so just do the vsync processing in there, why even wait for a vsync elsewhere?