@MSGID: 2:5020/830.590 6435e9f3
@REPLY: 2:463/1331.27 6435827e
@PID: GED-NSFW32 1.1.5-20090710
@CHRS: CP866 2
@TZUTC: 0200
@TID: hpt/w32-mvcdll 1.4.0-sta 16-02-06
Здpавствуй, Dmitry!

Вторник 11 Апреля 2023 18:50, ты писал(а) мне,

 AA>> Вторник 11 Апреля 2023 07:41, ты писал(а) мне,
 AA>>>>  Hо это всё присказка, а сказка в том, что
 AA>>>> сохраняется 17-битный адрес вроде как
 AA>>>> с "игнорированием" старшего бита:

 AA>>>> :10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00

 AA>>>> Собственно вопрос в том, а как на самом деле
 AA>>>> должен "выгядеть" 16-битный hex-файл с
 AA>>>> 17-ти и более битным адресным "пространством"?

 DO>>> А погуглить Intel HEX format? Да хоть Вики
 DO>>> https://en.wikipedia.org/wiki/Intel_HEX
 AA>> Да читал я...

 AA>> Hапример, Это, из твоей же ссылки:

 DO> Там в конце статьи еще написано про различные расширения формата от
 DO> разных фирм, может тут вообще что-то свое.
Да и это я читал. Уж не помню, где именно, но об этом пишут везде.
 DO> Я не "молодежь" но ни
 DO> перечисленных тобой в соседней мессаге имен не помню, ни программатора
 DO> этого никогда в глаза не видел (только название слышал), у меня свои
 DO> были. Что там авторы этого программатора начудили - бог их знает.
Странно.
Я _И_ на самом деле тебя помню в фидо с 1994-го или 1995-го года примерно.
 А про БиДиПро (ещё первой версии) Панченко писал, где-то примерно, в 1999-м.
Потом ещё было что-то о БиДиПро в РадиоХобби Сухова (и Торреса).
Hу Александра Торреса-то ты хоть помнишь?
 AA>>  "Физический адрес данных вычисляется путем добавления этого
 AA>> смещения к ранее установленному базовому адресу,
 AA>> что позволяет адресовать память за пределы 64-килобайтного
 AA>> ограничения 16-битных адресов."

 AA>> или Это:

 AA>>  "Количество байтов всегда равно 02, поле адреса (обычно 0000)
 AA>> игнорируется, а поле данных содержит 16-битный базовый адрес
 AA>> сегмента. Этот адрес умножается на 16 и добавляется к каждому
 AA>> последующему адресу записи данных для формирования начального
 AA>> адреса данных. Это позволяет адресовать до одного мегабайта
 AA>> (1048576 байт) адресного пространства."

 AA>> Hу и как с учётом этих фраз должны выглядеть эти 4
 AA>> последовательные строки?

 AA>> :10FFE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF21
 AA>> :10FFF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11
 AA>> :10000000EF7C42A3019A1FF06836F0898314F0D385
 AA>> :1000100003EFBC62EF92A8EFA762A3017ACCF007CE

 DO> Тут все записи типа 00, по идее, между ними и должна была быть запись
 DO> типа 04, например, а так, видимо просто обрезали старшие биты адреса и
 DO> пошли писать дальше.
Проблема в том, что основной софт (под ДОС) Алексей закончил в 2004-м, а ddl-ки
для 16-ти биток Олег написал в 2012-м. (Предыдущие были с ошибками.)
И как он тестировал (а он пришет, что делал это) мне непонятно.
 DO> Обычные утилиты для работы с Intel HEX такое
 DO> скорее всего корректно не обработают,
Hу дык...
 DO> но совсем не сложно написать свою, формат же примитивно прост.
Да я, разумеется всё это могу написать.
 Весь вопрос в том, а какой формат для 32Кх16, 64Кх16, 128Кх16,
256Кх16 распространён?
Или по другому. Другие программаторы 16-биток какие форматы едят?
Кстати, если бы это был 32Кх16 я бы наверное даже не заметил подвоха...
 DO> Hо на твой вопрос "как на самом деле
 DO> должен выглядеть этот файл" я тебе ответил - как написано в указанной
 DO> статье в Вики, или в куче других мест.
Еще раз.
Меня устроят 4 строки из реального файла.
А версий, как это может выглядеть, у меня у самого несколько.
Да и вики не акцентируя внимание на проблему 16-ти биток
скромно приводят примеры только для 8-биток.


С уважением - Andrej
--- Good luck!
 * Origin: Как я попал на этот курорт? (2:5020/830.590)
SEEN-BY: 50/109 221/6 240/1120 250/25 301/1 341/66
452/166 455/19 463/68
SEEN-BY: 467/888 4500/1 5000/111 5001/100 5005/33
49 5010/352 5015/42 46
SEEN-BY: 5019/40 5020/113 545 715 828 830 846 848
1042 4441 12000 5022/77 128
SEEN-BY: 5026/49 5029/32 5030/49 115 1081 5033/11
5049/6 5050/151 5052/4
SEEN-BY: 5053/51 5054/8 89 5058/104 108 5060/900
5064/56 5083/1 444 6055/7
SEEN-BY: 6090/1
@PATH: 5020/830 1042 4441