Jump to content

sanny

Members
  • Content Count

    424
  • Joined

  • Last visited

Everything posted by sanny

  1. So what's the status? Is there an ETA for the cart?
  2. what exactly do you mean with "start"? How to start the program after it was compiled? Or what to write in the source code before instructions? Or how to define start address of program? Please be more specific... "NOT ENOUGH INFORMATION ERROR"...
  3. BCC probably works as it should, but INC doesn't change the carry flag...
  4. Just insert a "brk" instruction and tell your emulator to break when a brk instruction is executed.
  5. If you put uninitialized data into those segments you have to use #pragma bss-name. But why wouldn't you want to use the segments.s file?
  6. If you are accessing the memory area only with memcpy() it doesn't matter. If you are accessing single bytes, 1) gives better code. Because the symbol is absolute, and in case 2) you need a pointer. Compare 1) pmgmem[123]=4 and 2) *(unsigned char *)(PMGMEM + 123) = 4; For a "real" program I'm using 1), for a quick test program I'm using 2) most of the time.
  7. Hmm. Don't know. Don't know if it knows. Better would be to throw an error instead of just a warning. Need to check...
  8. ACK Since you seem to always just use one main.c file, it works for you. But if you happen to create another C file, like pmg.c, it will also include your header with a function definition. Since both main.c and pmg.c then declare a setupPMG() function (as an example), you will get an error when linking, since the linker sees two versions of the same function. Look at Wrathchild's rework of your code. He did it like it should be :-)
  9. I have to agree with Wrathchild. For a small/simple program it works. But you are going to get problems if your .h file with code is included into more than one C file. Then you'll get link errors, because the functions from the .h file are mulitple defined. Remember, you don't need to have just one main.c file, you can have multiple C files...
  10. See https://en.wikipedia.org/wiki/Diff#Unified_format In a nutshell, remove lines starting with "-" and add lines starting with "+". My post just shows the changes I did.
  11. With these diffs you can see the addresses of dlist_mem and scr_mem to be correct. --- test_dli.org/build.bat 2019-04-24 21:15:12.313302800 +0200 +++ test_dli/build.bat 2019-04-24 21:15:09.792907982 +0200 @@ -1,5 +1,5 @@ del testdli.xex -cl65 -t atari -l test_dli.asm -Osir main.c -o testdli.xex --mapfile testdli.map -C atari.cfg +cl65 -t atari -l test_dli.asm -Osir main.c -o testdli.xex --mapfile testdli.map -C atari.cfg -vm testdli.xex diff -ru test_dli.org/dlist.h test_dli/dlist.h --- test_dli.org/dlist.h 2019-04-24 21:14:14.779897100 +0200 +++ test_dli/dlist.h 2019-04-24 21:15:25.016976491 +0200 @@ -1,11 +1,11 @@ -#pragma data-name (push,"DLISTMEM") +#pragma bss-name (push,"DLISTMEM") unsigned char dlist_mem; -#pragma data-name (pop) +#pragma bss-name (pop) -#pragma data-name (push,"SCRMEM") +#pragma bss-name (push,"SCRMEM") unsigned char scr_mem; -#pragma data-name (pop) +#pragma bss-name (pop) unsigned char DisplayList[] = {
  12. Just using MEMORY should work as well. Overlapping with SYSCHKCHNK is not an issue, since it's just the first load chunk which checks available memory and aborts loading if the program doesn't fit. No problem if it's afterwards overwritten with parts of the main program.
  13. And, if you don't want to pre-populate, it's better to use 'file="";' instead of 'file=%O;'
  14. You didn't answer whether you want to pre-populate or not. If you just want to define the memory areas and not pre-populate them, the atari.cfg should work as well (as you posted, but you don't need the SEGMENT defines then). See https://cc65.github.io/doc/ld65.html#ss5.6 You should add "define=yes" to the memory definition, then there will be symbols "__<name>_START__" available. Use #pragma to put data into these memory areas (but as I think you don't want to pre-populate them). Then, for example, to set the DList address: extern unsigned char _DLIST_START__[]; ... OS.sdlst = _DLIST_START__; Untested...
  15. The MEMORY part of the cfg file is to fix the locations. The SEGMENT part can be used to pre-populate them, but that is optional. But your cfg file, as is, doesn't work. You need to create "chunk headers" for each part of memory you want to load independently from the MAIN chunk. See the MAINHDR memory area. So, if you don't know the format of Atari executable files, it's better to use the atari-xex.cfg instead of atari.cfg as starting point. With this config file, cc65 takes care about the details of the executable format. For each MEMORY definition if will automatically create an appropriate chunk header.
  16. Do you want to have these 3 memory areas pre-populated, or do you fill them at runtime?
  17. Hmm, just re-read the post, and OP was talking about 810. Sorry, I was somehow thinking about 850...
  18. I found this on my hard disk to send something to the serial port: 99 REM 01-JAN-2000 100 OPEN #1,13,0,"R1:" 110 XIO 36,#1,14,0,"R1:" 120 PRINT #1,"NEUES HALLO!";CHR$(13);CHR$(10) 130 CLOSE #1 It opens the port with 9600 baud (XIO "14" parameter), 8n1. Although the open specifies input+output (parameter "13" in OPEN), it doesn't start concurrent I/O. But I guess it worked, otherwise I wouldn't have kept it or fixed it to work. For input you have to start "concurrent mode" with XIO 40. See the 850 user's manual for more information. regards, chris
  19. If you're going to use a changed atrrdev.s it might be worth a try to increase the receive buffer size from 256 to 512, 1K, or maybe even more. See RECVBUF_SZ define. Maybe we can get 4800 baud working...
×
×
  • Create New...