desertfish

Oh man I had this one, it was my very first "computer game" I think I was around 6 or 7 years old

Can't you just perform the division using FDIV rom routine?

Sounds to me as if copy-pasting that particular routine from the monitor is the way to go.... (personally I would prefer that over a suddenly crashing ROM because the monitor was modified and the routine is no longer on the hardcoded address)

well, it only classifies as self-modifying code if the code is modifying actual code If you keep a byte in between instructions just as a storage byte, it doesn't qualify IMO Now, if you're changing opcodes or (more often) the operand values for certain opcodes, then we're talking

No I don't use Kotlin for app development. I don't have time to learn mobile app development as well .... I do use Kotlin/JVM but only for desktop / cli applications .

Hi @sundown I'm a software developer as well for my day job. When I was a kid though, i *did* program the C-64 and later the Amiga on the assembly level. So I have some memories about how such machines with almost zero abstractions work. Nowadays my interest for those systems is rekindled because I'm developing my own "Prog8" programming language for C-64 and Cx16 - combining my interests in modern software development (in Kotlin, for this particular example) with the nitty gritty assembly low level stuff going on on the C64 and Cx16. I'm still very new on the Cx16 and there's much to learn and explore for me but I'm doing that with Prog8 and it is a lot of fun! It does consume a huge amount of free time hahaha

wow this looks impressive, have skidded around a bit in the in browser version but was struggling with the controls there. Scrolling is awesomely done and the rotating race car looks cool as well with detailed rotation going on!

For me it's perfectly fine if HEX$(255) -> FF and HEX$(65535) -> FFFF

I would like to see support for word values, to mirror the ability of the '$' and '%' prefixes to deal with words. However your argument about the actual real world usage of HEX$ and BIN$ are relevant too. I mostly need the full 16 bits when in an assembly environment, and we have the monitor for that.....

I looked at the disassembly for several other tokens and kinda played with it, i started by just copying the code from STR$ and went from there I believe. I don't understand basic's execution loop and things I just copied stuff from elsewhere until it worked...

I hope so, may be wise to mention this issue in the PR Anyway it's great we got something working

Hmm, was it because of the ROM size limitation that the 16-bit support had to be dropped? Very unfortunate.... Also I would have expected that using ".import byte_to_hex_ascii " would enable you to use the symbol rather than the absolute address but that doesn't work. I'm not familiar enough with the tool chain to come up with a possible solution for this. Is there someone else that can? I think referring to the absolute address of the function is quite brittle

Can you upload a the new version on this forum? I played the previous one with "try it now" in the browser and found that quite convenient

@JimmyDansbo I made a pull request on GitHub to your repository, with what I think should be a working HEX$ including the ability to accept numbers up to 65535 I think it should use the existing routines from the Monitor, but that gave me a 'symbol undefined' error during building of the rom... I dunno how to access it. Also I am not sure if this is even possible because it is in a different memory bank perhaps??? (I'm a bit unfamiliar with how that works still) So for now I simply copied the byte_to_hex_ascii routine from monitor.s almost verbatim into here

I'm intrigued I hope to find some time this weekend to spend on this issue!

@mrdoornbos can you post a picture?

first reaction is: look at how left$ is returning a string? (disclaimer: i have no idea at all how to look into the BASIC rom for how it executes certain tokens....)

I will certainly re-review this game shortly, seeing you're making a lot of improvements

Hey I was wondering about the lack of HEX$ and BIN$ myself as well so this is an iteresting topic to me! I would like to see if I can perhaps help you with this but I have zero experience with building a custom rom though right now. I don't know if that is difficult to set up?

@rje I tried the game and left a review with some issues I was having with it. They *could* be related to the game balance issue you mention above but it's not entirely clear to me. I wonder if you could help me with them or see if they make any sense at all or that I perhaps just don't "get" the game mechanics yet

Hmmm yeah the TextElite game I just uploaded does provide the planet generation and trading simulation however there’s nothing else as game play mechanics or motivators to keep the player engaged......

I've just released Prog8 4.6 with again a bunch of improvements and bugfixes. This version is required to compile the latest TextElite game correctly, as it provides the new diskio library module that takes care of loading and saving data.

V1.1 was just uploaded and it added save game support. You can save your progress and reload it at a later time to continue where you left off.

About the floating point math routines, yeah I gladly use the ROM for that. I happily assumed the Cx16 has a proper documented fixed jump table for them (https://github.com/commanderx16/x16-rom/blob/0ebe2ab1556a0c46df41e5894ccae9b776c8a6a7/fplib/fplib.inc) but perhaps this is still subject to change for newer ROM versions? I hope not On the C64 we jump straight into BASIC ROM somewhere... but these won't change anymore

Personally, I just wrote my own little strout routine that only uses the CHROUT kernal routine at its documented location. It's only a few instructions long. Any reason you really want to use basic's STROUT?