Jump to content

JimmyDansbo

Members
  • Content Count

    103
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by JimmyDansbo


  1. I started out with the Philips G7000 (Philips Videopac G7000), also known as the Magnavox Odyssey 2.

    I think we had 5 or 6 game cartridges for it and my parents had to connect it to the family TV whenever we were allowed to play on it.

    Later we got the Amstrad CPC464 which is actually my favorite because it is the first computer that I was able to write programs on. It had the monochrome green monitor and built-in tape drive.

    I spent many hours typing in basic programs, debugging and testing them out, but as I could not read english and had no one to help, I never learned how to save my programs to tape.

    In the end, the CPC646 was swapped out for a C64 as that is what all the other kids had and for some reason the C64 games were not working on the CPC464 😉

    I continued doing basic programs on the C64 and I actually learned to save my programs to tape, and even floppy.

    • Like 1

  2. I would say that LSR is the more correct of the two. Depending on your assembler, both should work without issues, but if you look at the reference for the CPUs, LSR command only takes up 1 byte of memory where LSR ZP and LSR Absolute take up 2 and 3 bytes respectively.

    To me that indicates, that that the LSR A is just to make the commands look alike.


  3. ROM will not be open...

    On 7/27/2020 at 9:04 AM, Perifractic said:

    No clone machines: The X16 code is years of combined work & includes protected Commodore I.P. that was hard to secure. Only our team have permission to use it in this way. The unreleased X16 is not open source, yet.


  4. 7 hours ago, desertfish said:

    Sounds to me as if copy-pasting that particular routine from the monitor is the way to go....

    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.

    • Thanks 1

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


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

     


  7. 2 minutes ago, desertfish said:

    Hmm, was it because of the ROM size limitation that the 16-bit support had to be dropped?

    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 ?

    3 minutes ago, desertfish said:

    I think referring to the absolute address of the function is quite brittle

    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 😉


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


  9. 6 hours ago, desertfish said:

    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)

    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:

    Quote

    jsr bjsrfar

    .word $C829

    .byte BANK_MONITOR

    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.

     


  10. 2 minutes ago, desertfish said:

    first reaction is: look at how left$  is returning a string?

    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 😞

×
×
  • Create New...

Important Information

Please review our Terms of Use