Jump to content

Prog8 language and compiler topic


desertfish
 Share

Recommended Posts

So it seems that Windows needs fiddling with the PATH and/or JAVA_HOME environment variables? I would have guessed (hoped?) that the JDK installation would take care of that.  Anyway, as long as java.exe can be found in your path you can just type "java -jar prog8compiler-7.5-all.jar <options>" on the command line.

Borgar's script is handy if you frequently use the same command line arguments. Personally I'd use an alias for that (which is done with doskey on windows I believe?), but there's always more than one way to skin a cat!

Happy programming

 

Link to comment
Share on other sites

On 12/12/2021 at 10:14 AM, desertfish said:

So it seems that Windows needs fiddling with the PATH and/or JAVA_HOME environment variables? I would have guessed (hoped?) that the JDK installation would take care of that.  Anyway, as long as java.exe can be found in your path you can just type "java -jar prog8compiler-7.5-all.jar <options>" on the command line.

Borgar's script is handy if you frequently use the same command line arguments. Personally I'd use an alias for that (which is done with doskey on windows I believe?), but there's always more than one way to skin a cat!

Happy programming

 

Yes well, after some difficulties with multiple versions of Java, SET-ing environment variables was not quite the thing. I can compile now, but lacking an r39 emulator, I can't do what I'd like to, as it requires floating point. No, I'm not going to build my own, this 'limbo' r39 issue has caused me and likely others too, a fair bit of aggravation....but not enough to figure out how to use another tool set that I will never use again! They should post version 39, how long has it been? There are plenty more numbers after that....40,41,42.....

Link to comment
Share on other sites

@yock1960 Yes this r39 limbo is really annoying, I'm sorry about that. When I made the decision to make prog8 r39 only I didn't think it would take this long for it to finalize.

Maybe this can be a solution for you though:

- use BOX16 the alternative emulator, it is built for r39 and includes a precompiled windows binary https://github.com/indigodarkwolf/box16/releases

- download ZeroByte's patched v39 kernal bin image from this topic https://www.commanderx16.com/forum/index.php?/topic/2064-r39-patched-kernal-to-fix-load-into-hiram-functionality  and install that as the rom.bin

Prog8 can launch box16 as the alternative emulator with -emu2 command line option.

Edited by desertfish
Link to comment
Share on other sites

Box16 uses OpenGL (Graphics Language) to speed up its display.  But, Microsoft doesn't support it.  The OpenGL driver is old, and doesn't work with some modern graphics chips.  There's no workaround.  Box16 runs, but we can't see what it does.

Edited by Greg King
Link to comment
Share on other sites

On 12/13/2021 at 11:43 AM, yock1960 said:

Well, I've downloaded the emulator and rom, but it must not be meant for me to use it. It opens a window....white and empty. Apparently there is something I don't understand about this.

Well, I don't see the white screen problem on any of my systems at home. My previous thought was that it might be a problem with the Intel drivers, not Microsoft, if you're running with an Intel graphics card (on-board with the motherboard, or certain laptops, or something like that). It's also been suggested that multi-display systems may have issues. I could see that, especially if the displays output from different video cards, but I do develop on a multi-display system (different outputs on the same RTX 2080 card) and Box16 has no trouble having the window dragged between the two displays on that system.

If there's no rom.bin, it should immediately exit after printing an error message to the console output. That console window probably closes too quickly to be read if you just double-click on box16.exe. If you're using the r38 rom.bin, instead of a build of the latest ROM source code on Github, then it should open and sit on a blue screen, but at least with the various UI elements like the menu bar at the top of the display.

With a white screen and no UI, my guess continues to be that OpenGL failed to initialize for some reason, and I have no real way to know what that reason is right now, though I suppose I should add some popups or something to indicate the failure, and log messages to a file that folks can then send me. In any event, I've tested it on as many modern-ish computers as I have (with respect, I have not tested it on my Windows 95 or 98 laptops, nor my 486 or older computers, as those are... "out of scope", please use Windows 10 or Windows 11).

Edited by StephenHorn
  • Like 1
Link to comment
Share on other sites

So, the laptop that I originally tried this on is an oem Windows 10, with Nvidia graphics...white screen window, with title bar, etc.. Next tried a Win7 laptop with on chip Intel graphic and then a self built desktop upgraded from Win7 to Win10 with on chip Intel graphics. Both of these machines failed to open the application, giving a 'can't proceed because VCRUNTIME140_1.dll was not found'. Guess I'll try and run this .dll down.

Edited by yock1960
Link to comment
Share on other sites

Don't "hunt" it down, it's dangerous to download random dlls from the internet. Instead install the Microsoft supplied runtime libraries https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170

It's a bit weird that you don't have these yet I thought they came via windows updates automatically, but hey.

  • Like 1
Link to comment
Share on other sites

On 12/13/2021 at 5:20 PM, desertfish said:

Don't "hunt" it down, it's dangerous to download random dlls from the internet. Instead install the Microsoft supplied runtime libraries https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170

It's a bit weird that you don't have these yet I thought they came via windows updates automatically, but hey.

Well, what I meant was to figure out what it was...which I did, downloaded the redistributable on the desktop and was rewarded with the clean white screen. Intel graphics incompatibility I guess, but it's working on one machine anyway!

Link to comment
Share on other sites

I know that an IDE for Prog8 is being worked on, but for the time being, if anyone is interested, Relaunch64 works, except that you need to name your source files .asm and add the -out /dir command option to the 'run' script, to send the output files to another directory to prevent your source from being overwritten. I had hoped there was a way to open any text file, but it's limited to .asm only. One could modify the source to allow this, but that's beyond me currently. A really talented and determined individual could even create additional Quick Reference tabs specific to the CX16, to add to the nice ones that already exist for the C64!

Link to comment
Share on other sites

That's great news that you can coax other editors that you like into using prog8 as well, but it really does sound unfortunate (and a bit silly, in my opinion) that relaunch64 only accepts .asm files.

What other tools are people using to code in prog8?

Personally, I'm using IntelliJ IDEA. Here's me working on my image viewer program:

image.thumb.png.7c54e5951657e20b34f21b9792d53927.png

Link to comment
Share on other sites

So, just dipping my toes into the water, writing the ubiquitous Hello World program, but outputting to 640x480x4 hires mode. I can see that I'm going to need to print out Borgar's code to get more example code to peruse, this in addition to the Prog8 manual and various library sources. After a few errors, I got the program working, but I have a warning that, while it doesn't hurt anything, I have no clue how to properly code:

keyp = c64.GETIN()

to avoid the warning. 

Also, I'd like to use, I guess cx16.enter_basic() to gracefully exit the program, but don't know how to pass...and what to pass...@Pc!

Oh and in the GFX2 source for the text() sub, you may want to note that the screen code 'string' requires a terminating null....seems obvious....but to an even ranker novice than I...

   

Link to comment
Share on other sites

@yock1960 there are many examples included in prog8 that you can study https://github.com/irmen/prog8/tree/master/examples

all strings in prog8 should be 0 terminated which is hopefully documented in the manual , if not or unclear please let me know. Note that strings declared in prog8 are automatically 0 terminated .

returning to basic is just exiting from the start() routine.  You’ll have to set zeropage use to basic safe though. Read the manual I about the %zeropage directive, or study some examples to see how it’s done! Good luck 

Edited by desertfish
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Is there anything different going on 'under the hood' as far as the mouse is concerned? As part of learning to code in Prog8, I've been working on porting my fractal explorer from assembly, but I just can't seem to be able to read the mouse buttons. I've got the assembly version working under R39 & Box16, so I know the code works...but even inlining it refuses to work from Prog8. I'm out of ideas!

Link to comment
Share on other sites

No, prog8 itself has no idea about the mouse. It just compiles to assembly code that is run....

I do know that there was a weird thing going on when reading the *joystick* though. See https://github.com/commanderx16/x16-rom/issues/203

Basically the default IRQ handler can mess up the results  from the joystick_get() kernal routine.

I have not yet worked with the mouse on the x16, but perhaps there is something similar going on?   If not, all I can say is compare the resulting assembly code from prog8 to your own code and try to discover where the difference occurs.   The easiest way to do this is by making a minimal reproduction program

Link to comment
Share on other sites

I think this must be a similar issue....and very strange, since as I say, my assembly code works as expected and I essentially inlined that code into the Prog8 source. I've added some 'unnecessary' instructions and have at least gotten it to react to button presses, but the x&y positions returned are garbage. 

Link to comment
Share on other sites

Yeah, I guess many people are using CC65, but as it doesn't natively support floating point (last I checked), I've never considered using it. Syntax is similar to many high level languages, so no issues there, other than what I personally would have with anything else...speaking as a non formally trained programmer. Other than my own bone-headed errors, I'm satisfied with my progress in porting the fractal program as a 'learning Prog8' task. Doing that program in assembly, which was a learning task in itself, took 4 months, albeit switching from the framebuffer routines, in order to use the entire screen, added some extra time at the end. This should go much faster. So far, the only thing that has caused me any heartache, is the limit on array size, which I worked around, by using multiple arrays...but it's a bit ugly. I could probably do an inline assembly routine....maybe...haven't thought about it too much...it's not a time critical part of the program and I'm trying to do as much as possible in Prog8 anyway. I would be happy if compiling generated the assembly listing from 64tass....a little thing...but it would keep me from having to load/assemble the .asm file again in order to get it. This will do a nice job as a replacement for Slang, which I used to do some BASIC porting for the C64 and CX16 back in early 2020, but floating point was broken for the CX16.  More feedback as it occurs to me!

Link to comment
Share on other sites

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.

Edited by desertfish
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use