УКНЦ загрузка через стык С2

[BlaireCas]

можете опробовать мою утилитку загрузки?

Ваша версия "почти прокатила" Выдало
Loading...
?UKNCMSN-F-Timeout

(я так понимаю просто после загрузчика шел payload и поэтому загрузчик-то полностью забросился, а вот сам файл уже недошел, тут похоже правда какая-то проблема с буферизацией и последние сколько-то байт у меня из винды недоходят)

[Alex_K]

Loading...
?UKNCMSN-F-Timeout

Ясно. Вот из-за USB-COM видно и вышло. Наверное тайм-аут надо увеличивать или убирать его.

А на каком файле, какого объёма?

[BlaireCas]

А на каком файле, какого объёма?

Файлик довольно простенький, 1024 байта (впрочем я разные пробовал).
TSTCLR.ZIP

[Alex_K]

Файлик довольно простенький, 1024 байта (впрочем я разные пробовал).
TSTCLR.ZIP

Попробуйте загрузить Замок Гоблинов, файл довольно большой, как раз хорош для теста.

- - - Добавлено - - -

Попробую увеличить тайм-аут, потом выложу новую версию.

[BlaireCas]

Попробую увеличить тайм-аут, потом выложу новую версию.

Похоже помогла вот такая шляпа под конец программки!

    ::Sleep(2000);
    ::FlushFileBuffers(hComPort);
    ::PurgeComm(hComPort, PURGE_RXCLEAR);
    ::PurgeComm(hComPort, PURGE_TXCLEAR);

Внимание! Sleep - важен перед flush. Точного значения сколько "спать" я не определил. Поставил на глаз.

(откуда узнал про sleep - нууу.. гуглением)

Кусок кода для линукса из stackoverflow

I think I figured it out. For some reason, I need to add a delay before flushing. These two lines added before returning fd seem to have done the trick:

sleep(2); //required to make flush work, for some reason
tcflush(fd,TCIOFLUSH);

--- оттуда-же ---


The cause of this problem lies in using a USB serial port. If you use a regular serial port, you will not have this problem.

Most USB serial port drivers don't support flushing properly, probably because there's no way of knowing if there's still data in the internal shift register, FIFO or in the USB subsystem.

See also Greg's reply to a similar problem reported earlier here.

Your sleep may cure the problem, but it's only a work-around. Unfortunately there is no solution other than using a regular serial port.

[свернуть]

[Hunta]

Можно в начале расскоментировать .asect и .=0, после строчки PPUEND: добавить

	.BLKB	^O<1000>-.

И собрать командой

link/nobitmap/stack:0/top:1000 TSTCLR

1000 из .BLKB ^O<1000>-. должна быть синхронизирована с 1000 из /top:1000

- - - Добавлено - - -

tcflush (и по идее FlushFileBuffers) - это НЕ ОЖИДАНИЕ передачи всего буфера, а его СБРОС

"tcflush() — Flush input or output on a terminal

Flushes input data that has been received by the system but not read by an application.

Flushes output data that has been written by an application but not sent to the terminal."

И, похоже (Sleep(2000) намекает), проблема банальна - в буфере на com порт ещё есть что-то для передачи, а программа уже завершилась и windows СБРАСЫВАЕТ все буфера для COM порта или же это делают вот эти два вызова

::PurgeComm(hComPort, PURGE_RXCLEAR);
::PurgeComm(hComPort, PURGE_TXCLEAR);

если они были в первоначальном варианте

- - - Добавлено - - -

И ещё комментарий по тексту загружаемого. Если закомментить

	.asect
.=0

То программа будет собрана с адреса 1000 и при загрзуке её с адреса 0 работать, по идее, не будет - много абсолютных ссылок, типа:

	mov	#PPUSTA, R4		; run PPU code
...
PPMSG:	.word	PPARR			; address of beginning of array
...
PPSEN:	mov	#PPMSG, R0		; array address

[BlaireCas]

::PurgeComm(hComPort, PURGE_RXCLEAR);
::PurgeComm(hComPort, PURGE_TXCLEAR);

если они были в первоначальном варианте

Не Это "мое" уже дополнение. В первоначальном варианте просто было закрытие файла порта да и все. (::CloseHandle(hComPort)
Это я уже развлекаюсь так-сказать. Но sleep действительно помог.

[Hunta]

Но sleep действительно помог.

С его помощью идёт ожидание в лоб завершения процесса передачи. Теперь понятно, почему 512 нулей в конце так же помогли - забили буфер windows и/или com порта, а пока оно пыхтит в процесс переноса их от проги в буфер - нужная инфа (первый 512 байт) гарантированно ушли в УК-НЦ

[BlaireCas]

::PurgeComm(hComPort, PURGE_RXCLEAR);
::PurgeComm(hComPort, PURGE_TXCLEAR);

если они были в первоначальном варианте

Не Это "мое" уже дополнение. В первоначальном варианте просто было закрытие файла порта да и все. (::CloseHandle(hComPort)
Это я уже развлекаюсь так-сказать. Но sleep действительно помог.

Если закомментить

Оно собственно и закомменчено для РТ-11. Савка-то работает для системы.
Если раскомментить - то это вариант для загрузки по адресу 0, там правда чет с ПП накосячено, но это мелочи, код в него грузится и даже исполняется.

[Hunta]

В общем, надо разбираться с Windows API - как ДОЖДАТЬСЯ опустошения буфера. По хорошему - и Windows и COM порта, так как я не уверен, что Windows не сбрасывает COM порт, если программа, которая его использовала - вызвала функция закрытия хендла com порта или не завершилась.

И понятно, почему и у Патрона и у меня всё работает - и там и там приложение класса Сервер - то есть они не завершают свою работу после передачи чего-либо