desertfish

damn, that is true! So we don't even have to drop down to 8 colors! Just use 16 colors (and make sure the image is cropped to 640x400 or so to still fit into Vram) Here's the 16 color 640x400 version of that woman's portrait image. The colors are a lot more pronounced already

Hi, I've been experimenting a bit with converting large true-color images to the x16. Long story short, for the hi-res screenmode (640x480 pixels) there's only enough VRAM to display very few colors. 8 to be precise. (if you use only 640x400 pixels, you can go up to 16) For the lo-res screenmode such few colors would result in pretty bad looking photos, but for the hi-res screenmode and with some careful color reduction and dithering, you can get pretty amazing results even with just eight colors: Note: these are not screen captures, these are just offline generated converted images that a little python script created from the truecolor source images. But at 640 x 480 with 8 colors from the 4096 color palette of the x16, they could be displayed as seen above. Here's the script x16paletteconv.py (The script assumes the source image has already been cropped and scaled to the correct resolution. I also tried using imagemagick's convert tool earlier but I couldn't make it to keep the correct color palette when reducing the number of colors, so I had to find a weird workaround as you can read in the python script's code comments)

if you're short of key combinations you could perhaps opt to make those lesser used functions as 2 key sequence or popup menu or something ?

Version 7.7.1 has been released that fixes a bunch of compiler crashes. https://github.com/irmen/prog8/releases/tag/v7.7.1

SASSY !

@borgarthe pipe was or is a bit experimental. It’s inspired by the pipe operator in f#. The implementation can perhaps be used later to serialize nested expressions, thereby avoiding the slow stack based approach. But it lacks some features to do this now

pokemon(address, value) Attempts to write a byte to a ROM at a location in machine language monitor bank. Doesn’t have anything to do with a certain video game. because writing to rom is not possible the function effectively does nothing and is implemented as such

Version 7.7 has been released! https://github.com/irmen/prog8/releases/tag/v7.7 Documentation here, as always https://prog8.readthedocs.io/ added pipe operator |> added new syntax for string encodings, and added iso: encoding on cx16: added txt.iso() to switch to iso charset added @requirezp flag on variables to force them in Zeropage added pokemon() function fix assembly <-> prog8 label referencing issue (labels in asm no longer start with underscore) less aggressive dead code (variables) removal fixed some type casting issues several small code gen optimizations fix broken code generated for certain equality comparison expressions several other bugfixes.

For more advanced text input and output I will recommend Jimmy's VTUI library. I think it's usable from basic as well --- but I haven't tried to be honest.

"are there any showstopper bugs in it" --> I'm not the person to qualify the bugs as showstopper ones or not, but yeah, there are quite a few nasty bugs in the current r39 ROM. I don't really know about the emulator.

Thanks to everyone spending their time and effort to keep this thing going and a nice place to be part of!

Version 7.6 has been released https://github.com/irmen/prog8/releases/tag/v7.6 Documentation as always here: https://prog8.readthedocs.io/ added in containment check operator, this enables things such as if xx in [1,2,3] ... or if '@' in email_address ... added experimental 'c128' compiler target to create programs for the Commodore-128 added a porting guide to the manual for efforts to port the language to other systems added -asmlist argument to also generate a listing file as output added -noreinit argument (experimental) to not create the reinitialization code for global variables. Can make programs smaller, but can also cause problems. returnvalue of diskio.load() (and similar routines) has changed meaning: it's now just the last load address +1 (same as regular kernal's LOAD routine returns) fixed position of @shared in variable declaration for array types be a bit less verbose in similar warnings several code generation optimizations several bugfixes

I have no idea what to look for @yock1960. You'll have to provide a small reproducible example that shows what prog8 code is running , what results it gives, and what results you expected...

For prog8 I'm using 64tass as the backend assembler , which uses a TurboAssembler derived syntax.

This was a very fun episode that I first honestly thought to be an April fools joke.

Here's a piece of code that adds two floating point numbers 1.11 and 1.22 and prints the result 2.33. Note that $7e/$7f are just 2 zero page locations free for user programs. lda #<float5_111 ldy #>float5_111 jsr floats.MOVFM lda #<float5_122 ldy #>float5_122 jsr floats.FADD jsr floats.FOUT sta $7e sty $7f ldy #0 _loop lda ($7e),y beq _done jsr c64.CHROUT iny bne _loop _done rts float5_111 .byte $81, $0e, $14, $7a, $e1 ; float 1.11 float5_122 .byte $81, $1c, $28, $f5, $c2 ; float 1.22 But this piece of your code above doesn't look correct too: L1: .byte "$87 $48 $00 $00 $00",0

for FOUT, 'fbuffr' is probably the name of the internal basic string buffer it uses. Don't try to access it directly, instead, use the fact that FOUT returns the address of it in the A and Y registers. Store that somewhere and read the characters using that pointer.

You'll have to make sure you're using the correct addresses of those kernal routines for the given emulator/rom revision you are using. They have changed from r38 to r39. It seems that you are using the r39 addresses on a r38 target? The documentation in the master branch of the github repo shows the r39 state of affairs. Here is the r38 one https://github.com/commanderx16/x16-rom/blob/r38/fplib/fplib.inc

What are you trying to accomplish? Isn’t it possible with fixed point math perhaps? In any case, prog8 for instance uses those kernal floating point routines for its float calculations. If you’re not familiar with assembly programming it will be a large hurdle to grasp how it works. But essentially it revolves around loading FAC1 and possibly FAC2 with aa value, calling one of the float math functions, and converting FAC1 (which will usually contain the result) back to a number or string somewhere. FAC1 and FAC2 are internal floating point variables stored somewhere in ram. It’s quite tedious to write this code by hand especially for complex calculations... i can add a tiny example that adds 2 numbers later if you really want to pursue this

It's hard to see in the image (blurry) but have you correctly terminated all strings by a 0 byte.

Perhaps you can make just one version that selects the appropriate banking addresses to be used based on the version of the rom it is running under?

the r39 rom adheres to the r39 state of the X16 , and so does box16. In r39 $00 and $01 are used for banking.

Rom source is on the same repository as the official emulator ; https://github.com/commanderx16/x16-rom/ master branch is the upcoming r39. You could also download the prebuilt one with LOAD fixes by ZeroByte, posted elsewhere on this forum recently.

Likely a OpenGL driver problem, make sure the emulator doesn't use Intel gfx but rather a discrete AMD or Nvidia graphics card with updated drivers

The array size limits are currently enforced because the code generator can only generate reasonable efficient code when it can use a single index register to get to the values. This means we can access 256 possible bytes in the array. Which in turn means an array of words can contain 128 values max and an array of floats 256/5=51 values max. What's your use case to have more than that number of values in an array? (a possible workaround is as you described: use more than one array. Or use a block of memory (see `memory()`) and access it via a pointer variable.) I'll see if I can get 64tass to produce a listing file as well when it assembles. edit: upcoming prog8 7.6 adds a "-asmlist" command line option to produce a listing file as well.