konamiman / msx Goto Github PK

Abovementioned applications call BDOS functions (CALL 0005h) with networking BIOS in the CPU bank 1. For normal operation, including abort routine when CTRL-STOP is pressed on user input routine, CPU bank 1 must contain TPA RAM. Please redesign applications to turn TPA RAM on when calling any of BDOS functions, or use far calls (RST 30h) to access networking BIOS.

Reported by KDL while he was testing SM-X UNAPI package.

He observes that if you have RAMHLPR.COM installed and an UNAPI loaded, if you go to BASIC and try to use KANJI by typing CALL KANJI2, the computer will deadlock.

I've confirmed the same behavior on BlueMSX emulator using Obsonet and Internestor Lite.

I have a little trouble understanding the following:

"- Almacenamiento de diversos programas BASIC en la memoria mapeada, con
posibilidad de pasar de uno a otro sin perder las variables."

Does it mean that programs can be just called from one another(without loosing variables), or you can literally use GOTO to any line in a different BASIC program, loaded into mapped RAM?

Current english translation doesn't make things clearer.

I believe the issue is in line 530 where you have:

while(seconds > SECS_IN_MINUTE)

Changing it to:

while(seconds >= SECS_IN_MINUTE)

Will add an extra minute when seconds are multiples of 60, instead of having MM:60, which the MSX-DOS won't accept as a valid parameter.

Re: https://github.com/Konamiman/MSX/blob/master/SRC/SDCC/crt0-msxdos/crt0msx_msxdos_advanced.asm

I thought you would be interested to know that your extended crt0 that passes command line arguments works very nicely on CP/M as well as MSX! I like the way you move the code to make way for the arguments...

However do you have ideas on how to reduce the size of the executable? (SDCC seems very keen on putting something at 8000H and I don't know how to get it to move it).

Using your MSX crt0 with the following test program gives an executable file of ~32K bytes.

#include <stdio.h>
#include "bdos.h"
#include "putchar.h" 

int main(char** argv, int argc)
{
   int i_count;
   
   for (i_count = 0; i_count < argc; i_count++)
   {
      puts(argv[i_count]);
   }
   return 0;
}

sdcc -mz80 --no-std-crt0 crt0.rel bdos.rel test.c 

Thanks

Hello, :)

Im testing the NeXTor DOS in a MSX1 Canon V20, the interfaces used is:

Sunrise CF, Sunrise IDE clone and Roukie Drive

All this tested with a memory expansiom connected in the slot two, the Sony,s HBM-512 with 512KB of DRAM.

In this situation always same error occurs, the canon v-20 keep freezes in a black screen.

All the hardware works well in othes MSx2, 2+ and TR.

It seems that NeXTor does not detect or initialize correctly the RAM expansion?

Thanks!

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.

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

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

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

2. 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!

Hi, got this idea from Louthrax and his SFTP ftp program.

In order to get better performance, his program pre-allocate the entire file size when it is known. I've tested a similar approach by doing the following operations after HGET create the file:

• Seek to the known length -1
• Write 1 byte
• Call _ENSURE (DosCall 0x46)
• Seek back to 0 from file beginning

The difference is really good by just doing that, HGET to a local HTTP server in the same network, using an UNAPI for a WiFi device I'm working on, go from downloading the file at about 4KB/s to 8KB/s (can get 17KB/s over FTP using your FTP client in ASM and 29KB/s using Louthrax SFTP client).

On one hand you lose the possibility of recovering a failed transfer in case of power or network failure as the file size will be pre-allocated, on the other hand you get a really good boost (tested using KDL OCM 3.7.1 w/ Nextor) in performance. Perhaps this could be implemented as a command line switch, where you give-up download resuming ability in favor of fast transfers.

So this is a suggestion to allow better performance using HGET to transfer files. :-)

Just in case you get interested on it, I've made a simple implementation (no switch, so if file size is known and file is being created, it will pre-allocate) that I used to test, the file is available:

https://drive.google.com/file/d/1OVpocVsMYCLIuO_2zWFRw9Ijhoewqaag/view?usp=sharing

When using INL with a network device connected to a vlan/bridged router (most of the modern WAN/LAN routers) arp responses are not being forwarded correctly as they are perceived by the router as vlan tagged frames.

The issue can be reproduced with a networked MSX to any Linux based AP connected to an internet provider router (example ASUS RT-AC5300, ASUS RT-AC66U, etc) and using INL to ping the gateway address defined on the bridged vlan. You can ping any device on the vlan, except for the gateway IP as all ARP responses sent to the router in unicast are dropped.

Here is what happens with a PC on the network trying to ping the router.

PC
17:06:25.047007 04:92:26:69:71:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.201 tell 192.168.0.1, length 28
        0x0000:  0001 0800 0604 0001 0492 2669 7160 c0a8  ..........&iq`..
        0x0010:  0001 0000 0000 0000 c0a8 00c9            ............
17:06:25.049611 00:91:9e:e6:e5:38 > 04:92:26:69:71:60, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.201 is-at 00:91:9e:e6:e5:38, **length 46**
        0x0000:  0001 0800 0604 0002 0091 9ee6 e538 c0a8  .............8..
        0x0010:  00c9 0492 2669 7160 c0a8 0001 0000 0000  ....&iq`........
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

The ARP response is 46 bytes in size. Everything works ok.

Here is what happens with an MSX with INL pinging the router.

MSX
15:51:11.997014 04:92:26:69:71:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.243 tell 192.168.0.1, length 28
        0x0000:  0001 0800 0604 0001 0492 2669 7160 c0a8  ..........&iq`..
        0x0010:  0001 0000 0000 0000 c0a8 00f3            ............
15:51:12.007186 35:65:e4:24:08:40 > 04:92:26:69:71:60, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.243 is-at 35:65:e4:24:08:40, **length 50**
        0x0000:  0001 0800 0604 0002 3565 e424 0840 c0a8  ........5e.$.@..
        0x0010:  00f3 0492 2669 7160 c0a8 0001 0101 0600  ....&iq`........
        0x0020:  7542 6be7 013b 8000 0000 0000 0000 0000  uBk..;..........
        0x0030:  0000    

The ARP response is 50 bytes in size when it should be 46 like the PC. Because it is 50 bytes in size, the router thinks it is a tagged frame and, as the vlan id is undefined, it drops the frame.

From the ARP documentation:
If the ARP message is to be sent in an untagged frame then the frame overhead itself is 18 bytes. That would result in a frame of 28+18=46 bytes without padding. Additional 18 bytes of padding are necessary in this case to bloat the frame to the 64 byte length.
If the ARP message is to be sent in an 802.1Q-tagged frame then the frame overhead is 22 bytes, resulting in the total frame size of 28+22=50 bytes. In this case, the padding needs to be 14 bytes long.

Apparently INL.COM that creates ARP responses needs a fix to generate a 46 bytes ARP response instead of 50 bytes. Where 22 is added should be 18 according to the documentation.

This issue has been raised by KDL while he was testing SM-X WiFi features.

According to his tests, SNTP.COM doesn't finish with CR/LF on the last line, so when you execute in a batch file, the next command output from the batch file will start after the last character written by SNTP instead of starting in a new line.

Today I tried out NPLAYER with NestorBASIC, it works really nice with my FM-PAK and Music Module but it showed OPL4: No even with DalSoRi R2 installed. I double checked with vgmplay (after quiting to Basic and going to Nextor) that DalSoRi was working fine.