Konamiman
Problem in crt0msx_msxdos_advanced, in new versions of SDCC
Note: Translated with google translator. At the end in Spanish.
Hello, Lider! ;)
I have been testing the development of MSXDOS applications with SDCC for some time and I ran into a problem when compiling the startup that you developed. I suppose it must be because of some change in the most current versions of the SDCC. When compiling the application with your crt0 there are two cases:
Note: I have made the tests on a computer with win7, SDCC 3.6.0 and hex2bin 2.5. I tested the result in blueMSX under MSX-DOS v1.
- when the value of the data-loc is equal to zero. The compilation does not give errors, but the hex2bin generates several "Overlapped record detected" and the result when executing it does not work.
hex2bin v2.5, Copyright (C) 2017 Jacques Pelletier & contributors
Allocate_Memory_and_Rewind:
Lowest address: 00000100
Highest address: 000003C0
Starting address: 00000100
Max Length: 705
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Binary file start = 00000100
Records start = 00000100
Highest address = 000003C0
Pad Byte = FF
- when the value of the data-loc is greater than 0. The compilation does not give errors, hex2bin generates the Overlapped but returns a binary that exceeds its size, resulting from the subtraction of the initial address with the address given to the data- loc (in the test with data-loc = 0xC000 the binary is 48K !!). The resulting binary does not work either.
Allocate_Memory_and_Rewind:
Lowest address: 00000100
Highest address: 0000C003
Starting address: 00000100
Max Length: 48900
Overlapped record detected
Overlapped record det.......
....
Binary file start = 00000100
Records start = 00000100
Highest address = 0000C003
Pad Byte = FF
I have been observing the code of the startup and commenting the lines related to the "HEAP" is solved, but not knowing how the parts of the crt work, I do not know if this can cause a failure in some case.
;--- Step 3: Call the "main" function
; push de
; ld de,#_HEAP_start
; ld (_heap_top),de
; pop de
call _main
.area _DATA
;_heap_top::
; .dw 0
I understand that this code was designed for the case that the data-loc was 0, indicate where the end of the application is located. Right?
I think (sorry I can not affirm it), which is due to the fact that the data _heap_top added to the DATA area, which in the compilation is defined in the address given in the data-loc, causes a file to be generated up to that address. I do not know if it is correct and it solves a lack of the previous versions of the SDCC, or a failure of the latest versions.
In the CRT tests without this code, I have observed in the .map files, where it places the DATA area and it seems to do it correctly in both cases.
On the other hand I have seen that in the init a call is made to the gsinit routine that contains nothing (a ret). What purpose does this call have?
If you need it, I can send you the test code that I used.
Regards!
Hola!
Hace un tiempo que estoy probando el desarrollo de aplicaciones MSXDOS con SDCC y me encontré con un problema al compilar el startup que desarrollaste. Supongo que debe de ser por algún cambio de las versiones más actuales del SDCC. Al compilar la aplicación con tu crt0 se dan dos casos:
Nota: Las pruebas las he realizado en un ordenador con win7, SDCC 3.6.0 y hex2bin 2.5. El resultado lo he probado en blueMSX bajo MSX-DOS v1.
- cuando el valor del data-loc es igual a cero. La compilación no da errores, pero el hex2bin genera varios "Overlapped record detected" y el resultante al ejecutarlo no funciona.
hex2bin v2.5, Copyright (C) 2017 Jacques Pelletier & contributors
Allocate_Memory_and_Rewind:
Lowest address: 00000100
Highest address: 000003C0
Starting address: 00000100
Max Length: 705
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Binary file start = 00000100
Records start = 00000100
Highest address = 000003C0
Pad Byte = FF
- cuando el valor del data-loc es mayor que 0. La compilación no da errores, hex2bin genera los Overlapped pero devuelve un binario que se excede de su tamaño, resultante de la resta de la dirección inicial con la dirección dada al data-loc (en la prueba con data-loc = 0xC000 el binario es de 48K!!). El binario resultante tampoco funciona.
Allocate_Memory_and_Rewind:
Lowest address: 00000100
Highest address: 0000C003
Starting address: 00000100
Max Length: 48900
Overlapped record detected
Overlapped record detec...
....
Binary file start = 00000100
Records start = 00000100
Highest address = 0000C003
Pad Byte = FF
He estado observando el código del startup y comentando las lineas relacionadas con el "HEAP" se soluciona, pero al no saber como funcionan las partes del crt, desconozco si esto puede provocar algún fallo en algún caso.
;--- Step 3: Call the "main" function
; push de
; ld de,#_HEAP_start
; ld (_heap_top),de
; pop de
call _main
.area _DATA
;_heap_top::
; .dw 0
Entiendo que este código estaba pensado para el caso de que el data-loc fuera 0, indicar donde se encuentra el final de la aplicación. ¿correcto?
Pienso (siento no poder afirmarlo), que es debido a que el dato _heap_top añadido al área DATA, que en la compilación se define en la dirección dada en el data-loc, provoca que se genere un fichero hasta esa dirección. No se si es correcto y soluciona una carencia de las versiones anteriores del SDCC, o un fallo de las últimas versiones.
En las pruebas del CRT sin este código, he observado en los ficheros .map, donde sitúa el area DATA y parece realizarlo correctamente en ambos casos.
Por otro lado he visto que en el init se hace una llamada a la rutina gsinit que no contiene nada (un ret). ¿Que propósito tiene esta llamada?
Si lo necesitas te puedo mandar el código de pruebas que he utilizado.
Saludos!
