Jump to content

JimmyDansbo

Members
  • Content Count

    96
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by JimmyDansbo

  1. Cool, do you have a code example?
  2. I agree. Now that some space has been freed, I will look into getting the byte_to_hex_ascii function back into the BASIC rom and I will tidy up the HEX$ and BIN$ functions as I had to jump through quite a lot of hoops to make the fit before.
  3. I believe I tried that without luck... ... Just tried it again, still no luck. in monitor.s: .export byte_to_hex_ascii in x16additions.s: .import byte_to_hex_ascii ... Still it does not recognize the name.
  4. Now that space is freed in the BASIC ROM page, I think it will actually be possible have the functions handle word values as well. Do you think it would be sufficient that HEX$ outputs a 4 byte string if the value is larger than 255 otherwise a 2 byte string? Or should it be something that you specify when calling i.e. something like HEX$(42, 1) returns 2A and HEX$(42, 2) returns 002A
  5. I don't think you can create Integer variables. They will always be floating point or strings. Your example would be String variable names are followd by a dollar sign. Of course you can not do counting on strings
  6. I managed to free up some space in the BASIC ROM page. https://github.com/JimmyDansbo/x16-rom/commit/a0470c136811ef56c6f3d5131bc9ffa1d254f9b6 @desertfish do you think we should try and go for handling word values as well as byte values?
  7. Yeah, it is a bit strange. You can read more about acme's handling of text (read conversion tables) here: https://sourceforge.net/p/acme-crossass/code-0/HEAD/tree/trunk/docs/AllPOs.txt#l165
  8. I have not done it personally, but my best bet is: Use !pet instead of !raw and only use lowercase letter in the names in the source code Ensure all your .bin files are all capital letters (i.e. TILES.BIN ...) It has something to do with the way acme converts ascii to petscii. When you use the !pet keyword, acme will subtract 32 from all bytes, meaning that 'a' ascii val 97 becomes 'A' ascii and petscii val 65. Next issue is that mac and linux (and the web emulator) are case sensitive so all your filenames need to use capital letters in order for your program to load them.
  9. Argh, I just tried compiling the new ROM with the PRERELEASE_VERSION set and then it is too large to fit in the 16KB ROM page
  10. @Johan Kårlin which version of acme are you using? Have you noticed that 0.97 was released back in august? https://sourceforge.net/projects/acme-crossass/files/win32/ (it supports the WAI opcode )
  11. I believe it is because the assets needs to be renamed to use all capital letters. At least, that solved it when I downloaded the game to try it out
  12. Yes indeed. How did you figure out that it was necessary to do pla twice before jmp'ing to strlit ?
  13. Yes, I think there might be a single byte available after these functions have been added as they are now. Also, I think that the functions will mostly be used to show output of peeks and vpeeks which are only a single byte anyway ? I totally agree, but I don't know how to be able to use the name either. I am thinking that ROM maintainer will let us know if I do a pull request
  14. I have now implemented both HEX$ and BIN$ and there is NO more room in the 16KB BASIC ROM page. I have had to change the functions to only accept a single byte and I have removed any preceding characters ('$' and '%'). Also it was necessary to to actually use the byte_to_hex_ascii function from the MONITOR code to make the functions fit in BASIC ROM. Please have a look and let me know if there is anything that should be changed or improved. Otherwise I will do a pull request against the official branch.
  15. If you look close to the top of the x16additions.s file https://github.com/JimmyDansbo/x16-rom/blob/1ab984f18aa5068af6be5368a997810fa1a4e666/basic/x16additions.s#L53 You can see how it goes about calling the monitor from BASIC. When the ROM is compiled, the monitor.sym file tells us that the byte_to_hex_ascii function has address $C829 so what we can do is this: I have tested it and it does work, however I think it adds a lot of overhead and if the code in monitor is changed, our $C829 constant needs to be changed.
  16. @desertfish That is great, I will look into if it is possible to just jump to the monitor code even though it is in another bank. Thanks
  17. Yeah, I have been looking at CHR$, STR$, LEFT$, RIGHT$ and MID$ I still can not get my head around how a string gets allocated, populated and returned correctly. The way it is done in CHR$ seems fairly simple, but when I try to allocate space for more than 1 byte, I get a type mismatch
  18. It is not too bad to setup the environment to build a custom rom, if you have a look at https://github.com/commanderx16/x16-rom the README.md tells you how to do it. I have actually managed to create the HEX$ keyword in ROM, now I just need to figure out how to return a string. Aparently I can not return a multi-byte string the same way as CHR$ returns a single-byte string You can follow my progress here: https://github.com/JimmyDansbo/x16-rom
  19. I have been trying to help the KERNAL development by creating the HEX$ and BIN$ BASIC commands/tokens, but I do not understand enough of the KERNAL source to actually figure out how to create a new command/token. Kan anyone point me in the right direction as to what I am missing? See my note on the issue here: https://github.com/commanderx16/x16-rom/issues/49#issuecomment-714964134 Thanks in advance
  20. No worries, I had not done any 6502 programming before I started developing for the Commander X16 either.
  21. That depends on what you mean by ASCII mode. If you want to ensure that you are in textmode, either 80x60 or 40x30 you can use the screen_set_mode call. https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#function-name-screen_set_mode If you actually want ASCII character set, the closest thing you will get is the ISO mode https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#iso-mode
  22. Just stumpled over this in the VERA Programmers Reference: "Since the VRAM contains random values at startup the values read back in the register area will not correspond to the actual values in the write-only registers until they are written to once." Source: https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md#vram-address-space-layout
  23. Heh, I had not actually thought about how close the name is to Ghost Busters
  24. I am not sure about the emulator, but I would expect RAM on physical hardware to contain random data on bootup. Unless the RAM is actually initialized at power on by some other hardware/software.
×
×
  • Create New...

Important Information

Please review our Terms of Use