Радио-86РК на 8088 (или 8086)
Moderator: Shaos
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re: Радио-86РК на 8088 (или 8086)
А если накидать в стек адрес перехода, и затем сделать RET?
-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Радио-86РК на 8088 (или 8086)
Будет возврат на адрес перехода... ньюансы - ближний, дальний накидать (RETn, RETf).PVV wrote:А если накидать в стек адрес перехода, и затем сделать RET?
iLavr
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Да, идея очень хорошая. Потому-что 8088 по CALL кладёт в стек абсолютный адрес. Сделал вот такой директиву G:PVV wrote:А если накидать в стек адрес перехода, и затем сделать RET ?
Code: Select all
DIR_G: XOR AX,AX ; в стек адрес FAR-возврата
PUSH AX
MOV BX,offset WARMST
PUSH BX
PUSH AX ; в стек адрес FAR-вызова
MOV BX,DS:[PAR_HL]
PUSH BX
RETF ; делаем FAR возврат и попадаем в ОЗУ
Сейчас возвраты из всех стандартных входов в ПЗУ - недалёкие по RET NEAR. Потому вызов стандартных входов ПЗУ по CALL FAR потребует переделки ПЗУ. А т.к все возвраты и из всех внутренних процедур близкие, то придётся для всех внешних входов в ПЗУ сделать такую конструкцию:
Code: Select all
MCOUT: CALL COUT_C
RETF
MCONIN: CALL CONIN
RETF
MHEX_A: CALL HEX_A
RETF
MSTAT: CALL STATUS
RETF
MMSSG: CALL MSSG
RETF
. . . . . .
- - - Добавлено - - -
Чуть позднее я сообразил, что CS не меняется и потому необязательно имитировать возврат из далёкого CALL, достаточно применить близкий RET. А т.к при имитации возврата из близкого CALL вывод в стек регистра CS не требуется, то это получается даже короче чем JMP FAR и не намного длиннее, чем CALL FAR.
Это работает потому-что по CALL процессор кладёт в стек абсолютный адрес, в то время как в командах JMP/CALL параметр адреса относительный (+/- 32767 от адреса следующей за CALL команды).
Таким образом использование RET удобнее, чем далёкие CALL/JMP. Вот теперь какая получилась директива G.
Code: Select all
DIR_G: MOV BX,offset WARMST ; в стек адрес возврата
PUSH BX
MOV BX,DS:[PAR_HL]
PUSH BX ; в стек адрес вызова
RET ; делаем возврат и попадаем в ОЗУ
Code: Select all
DIR_G: MOV BX,offset WARMST ; в стек адрес возврата
PUSH BX
MOV BX,DS:[PAR_HL]
JMP BX ; уход по адресу из PAR_HL
Написал макрокоманды для обоих этих случаев, где чётко видно, что вызов ПЗУ с помощью CALL BP короче.
Code: Select all
ROMCALL MACRO ADDR
LOCAL M1
MOV BP,offset M1
PUSH BP
MOV BP,ADDR
PUSH BP
RET
M1: ENDM
Code: Select all
ROMCALL MACRO ADDR
MOV BP,ADDR
CALL BP
ENDM
Можно сделать минимально-максимальную архитектуру ПЗУ. Тогда в сегменте 0 есть ПЗУ F800 с недалекими входами, а в последнем сегменте есть уже большое ПЗУ на 32 кб по адресу F000:8000, в котором можно иметь как уже всем привычные входы F8xx, так и подпрограммы аналогичные ROM-BIOS IBM PC, вызываемые по INT. Это даст возможность программы конвертированные от 8-ми разрядок прогонять в минимальной конфигурации, но и сохранит возможность адаптировать и использовать MSDOS или CP/M-86.
Таким образом, если ОЗУ больше, чем 64 кб, то в других сегментах (кроме последнего) нет ПЗУ. Аппаратно отключение ПЗУ достигается тем, что любой из адресов A16...A20 равный единице (что значит, что в CS число более 1000) отключает ПЗУ F800 минимальной конфигурации. А если все адреса A16...A20 равны 1, то в самых старших адресах памяти включается большой ROM-BIOS с размером минимум в 8 кб.
Для любительских целей и, чтобы не громоздить, не вижу необходимости использовать максимальную конфигурацию. Но иметь ОЗУ более, чем 64К полезно для создания внутреннего RAM-диска (чтобы не надо было "волочить" платку внешнего RAM-диска). При использования доп.ОЗУ только для VDISK-а достаточно ПЗУ F800 не выключать во всех сегментах (что кстати, не сокращает объём VDISK-а, т.к с помощью сегментных регистров DS и ES можно иметь доступ ко всему ОЗУ).
Кстати, похоже, в 86-тых ассемблерах запрещена адресная арифметика потому, что она работает только в минимальной архитектуре 64К. Тогда при вычислении адреса перехода, что делается прибавлением к текущему адресу $ смещения из команды CALL/JMP, если произойдёт переполнение за FFFF (или при отрицательном смещении за 0), то в реале адрес будет уже вне текущего сегмента, а при при 16-ти ричной арифметике при прибавлении к FFFF единицы возникает ноль, что адресует начало текущего сегмента.
В MASM с адресной арифметикой вообще всё погано. В TASM в режиме по умолчанию имитируется MASM, потому неразрешено выражение HIGH от адресов (например HIGH $), как и другая арифметика с адресами (а LOW почему-то работает). Но если перед строкой с оператором HIGH вставить псевдооператор IDEAL, то выражение вычисляется. После этой строки надо вставить строку MASM, чтобы вернуть режим, иначе из-за отсутствия строки .CODE выводится куча ошибок связанных с сегментами.
Для вывода сообщений при трансляции в ассемблере 86-го есть команды DISPLAY, что является примерным эквивалентом .PRINTX в нормальных ассемблерах (отличие в том, что ограничителем текста м.быть не любой символ, а обязательно двойные кавычки). Но от возможности выводить сообщения при трансляции нет никакой пользы из-за того что нет адресной арифметики.
Вот здесь версия РК-ПЗУ для 8088 с такой директивой G (где есть 20-ть свободных ячеек).
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re: Радио-86РК на 8088 (или 8086)
Схему сильно не причесал, очень много времени занимает вычисление глюков модели 8086.dll в протеусе
точно сказать сложно в чем дело, тк не понятно, какая именно команда выполняется процессором из-за наличия предвыборки данных, но похоже, проблема в том, что эта модель неверно выбирает из очереди данные, если они по нечетному адресу и путает местами байты четый-нечетный, и получается, что вместо записи байта данных пишется следующий байт. Вставкой команды nop, выравнивающей очередь, этот глюк не проявляется:
без nop перед этим:
MOV byte ptr [BX],27H
будет запись не 27H, а 8A... как то так. Отлавливать такие глюки оочень муторно.
Тем не менее функционирование дисплея с такой системой получилось, но без клавиатуры. Толи этот же глюк, толи ошибка у меня в схеме при обращении к ППА при преобразовании D[0..15] <-> XD[0..7] еще не разобрался.
Во вложении проект протеуса с 'притянутым за уши' монитором к модели и всеми инструментами для сборки.

Code: Select all
516 FA19 43 INC BX ; адрес VG_75+1
517 FA1A 90 nop
518 FA1B C6 07 27 MOV byte ptr [BX],27H ; start display commando
519
520 FA1E 8A 07 MOV AL,[BX] ; read status (это надо)
MOV byte ptr [BX],27H
будет запись не 27H, а 8A... как то так. Отлавливать такие глюки оочень муторно.
Тем не менее функционирование дисплея с такой системой получилось, но без клавиатуры. Толи этот же глюк, толи ошибка у меня в схеме при обращении к ППА при преобразовании D[0..15] <-> XD[0..7] еще не разобрался.
Во вложении проект протеуса с 'притянутым за уши' монитором к модели и всеми инструментами для сборки.
You do not have the required permissions to view the files attached to this post.
-
- Doomed
- Posts: 478
- Joined: 25 Aug 2009 07:02
- Location: Москва
Re:
Не совсем понятно, в какую сторону катится бочкаbarsik wrote: В MASM с адресной арифметикой вообще всё погано.

За 5 сек накидал:
Code: Select all
Microsoft (R) Macro Assembler Version 5.00 6/7/18 38:20:53
Page 1-1
.model tiny
0000 .code
1234 org 1234h
1234 start:
1234 B8 0032 mov ax, 50
1237 40 inc ax
1238 8B 0F mov cx, [bx]
123A BA 0006 mov dx, $-start
123D B0 09 mov al, low($-start)
123F B4 00 mov ah, high($-start)
1241 end start
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Вот здесь игра "ОХОТА НА УТОК". Ошибки исправлены и сделано, чтобы было сложнее играть (только самые ловкие смогут подстрелить 10 уток). Не знаю как в эмуляторе EMU указать имя файла для загрузки и автозапуска в командной строке. Потому для запуска надо выйти в отладчик, нажать ^L, ввести адресом загрузки число 0 и кликнуть ОК. В подкаталоге /Radio/Progs выбрать файл OXOTA.DAT. И закрыв окно отладчика ввести G<ВК>.
Спасибо за очень полезное сообщение. Скачаю MASM и буду пользоваться им, т.к вычислять расстояния между адресами просто необходимо, а TASM этого не может (а если и может, то я пока не знаю каким ключом это разрешить).
Движок данного сайта неверно обрабатывает табуляции, потому и надо их заменить на пробелы.
Т.к я всегда пользовался только TASM-ом, а в его описании постоянно указывают, что вот того-то и того-то в MASM нет или плохо, а в TASM улучшено, то естественно считать MASM плохим. Режим по умолчанию в нём это режим совместимости с MASM и там нет адресной арифметики, значит её нет и в MASM. Может в ранних версиях MASM она и есть или появляется по какому-либо ключу.Mixa64 wrote:Не совсем понятно, в какую сторону катится бочкаbarsik wrote: В MASM с адресной арифметикой вообще всё погано.
Спасибо за очень полезное сообщение. Скачаю MASM и буду пользоваться им, т.к вычислять расстояния между адресами просто необходимо, а TASM этого не может (а если и может, то я пока не знаю каким ключом это разрешить).
А потому-что надо пользоваться программистскими редакторами, а не убогими поделками в стиле блокнота. Лучше UltraEdit ничего нет. В нём есть функция "замена табуляций на пробелы". Вырезаете по ^C кусок из программы (чтобы исходник не уродовать), вставляете в новое пустое окно редактора и из вкладки Format удаляете табуляции.Mixa64 wrote:че-та табуляция съезжает
Движок данного сайта неверно обрабатывает табуляции, потому и надо их заменить на пробелы.
-
- Doomed
- Posts: 478
- Joined: 25 Aug 2009 07:02
- Location: Москва
Re:
Боюсь, что не (только) в ассемблерах дело, потому что мой пример TASM странслировал точно так же, 1:1.barsik wrote:Скачаю MASM и буду пользоваться им, т.к вычислять расстояния между адресами просто необходимо, а TASM этого не может (а если и может, то я пока не знаю каким ключом это разрешить).
Попробовал Ваш давний образец, где A1 equ $; ... ; LENGTH equ $-A1
Я ленив, поэтому вместо LENGTH набил LEN
Получилось так (заюзал TASM и LARGE MODEL для разнообразия):
Code: Select all
Turbo Assembler Version 2.5 06/08/18 22:17:21 Page 1
test.ASM
1 0000 .model large
2
3 0000 .code
4 org 1234h
5
6 1234 start:
7 1234 B8 0032 mov ax, 50
8
9 = TEST_TEXT:1237 A1 equ $
10
11 1237 40 inc ax
12 1238 8B 0F mov cx, [bx]
13 123A BA 0006 mov dx, $-start
14 123D B0 09 mov al, low($-start)
15 123F B4 00 mov ah, high($-start)
16
17 = 000A LEN equ $-a1
18
19 end start
Code: Select all
15 123F B4 00 mov ah, high($-start)
16
17 = 000A LENGTH equ $-a1
*Warning* test.ASM(17) Reserved word used as symbol: LENGTH
18
19 end start
Code: Select all
123F B4 00 mov ah, high($-start)
= 000A LENGTH equ $-a1
test.ASM(17): warning A4016: Reserved word used as symbol: LENGTH
1241 end start
(Попробовал, теперь не съезжает, но 30 дней evaluation.)barsik wrote:Лучше UltraEdit ничего нет.
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Вот самая простая программа для РК86 "Hello World" транслируемая в формат RKR. Чтобы получился RKR-формат надо вначале вставить заголовок с адресами и подогнать размер файла под удобный. Для этого нужна адресная арифметика.
Странслируйте это пожалуйста MASM-ом или TASM-ом. У меня не получается. Упрощённое задание сегментов с помощью оператора .MODEL я не использую (точнее только для простейших программок). Не думаю, что дело в том как задавать сегменты.
Полный текст здесь. Добавьте в этот каталог файл TASM.EXE и странслируйте.
PS. Надо чтобы при трансляции байты заголовка не затёрлись кодом после ORG 0. В нормальных ассемблерах всегда только один ORG, а для задания адреса трансляции не совпадающего с адресом загрузки кода используется .PHASE. А как это сделать в ассемблере 8086 я не представляю.
Для ассемблера надо поставить моноширинный фонт (лучше всего Lucida Console, кириллический, размер 16-17, OEM). Рамки и линии псевдографикой OEM будут отображаться (при OEM фонте), но рисовать их здесь нельзя, - их удобно рисовать в "Слово и Дело" Гутникова.
Я программирую для 8-ми разрядок и иногда для MSDOS и как-раз здесь без UltraEdit не обойтись. Он имеет не только всё, что надо для программиста, но и, являясь программой Windows, позволяет работать в альтернативной кодировке DOS (OEM), а когда надо прямо в редакторе перекодирует в Windows кодировку.
Для РК86 надо, чтобы тексты были в КОИ-7. А в КОИ-7 перекодировать могут только транскодеры для CP/M. Также и при написании программ в КОИ-8 с псевдографикой единственный вариант это АЛЬТ-кодировка, т.к в Windows-кодировке и UTF нет псевдографики. Я пишу в АЛЬТ-кодировке, а при трансляции для 8-ми разрядок в BAT-файл вставлена строка RECODE.COM FILE /A /K7 >> nul. Потому транслируется уже файл в кодировке КОИ-7 или КОИ-8, что и требуется. Никаких неудобство разница в кодировках не создаёт.
Недостаток старого UltraЕdit-а, что он не понимает UTF-кодировку (а некоторые сдуру её используют, причём для plain text-а, где достаточно любой 8-ми битовой кодировки).
Чтобы не напрягаться с кодировкой при вставке кусков с русскими буквами в посты, я использую редактор BRED3. Он при Paste в него кусков текста автоматически определяет входную кодировку и конвертирует как надо. Потому, чтобы вставить кусок текста, что в АЛЬТ-кодировке, я копирую в буфер кусок текста из UltraEdit, вставляю в пустое окно в BRED, маркирую всё по ^A и снова копирую в буфер по ^C и по ^V вставляю в сообщение в браузере. Это занимает 2 секунды.
Странслируйте это пожалуйста MASM-ом или TASM-ом. У меня не получается. Упрощённое задание сегментов с помощью оператора .MODEL я не использую (точнее только для простейших программок). Не думаю, что дело в том как задавать сегменты.
Code: Select all
.8086
include MACRO.INC
CGROUP GROUP TEXT
TEXT segment byte public 'CODE'
assume CS:CGROUP,DS:CGROUP,SS:CGROUP,ES:nothing
RABADR EQU 0
DB high RABADR
DB low RABADR
DB high RABADR+RAZMER-1
DB low RABADR+RAZMER-1
ORG RABADR
.msg THELLO
ROMJMP 0F800H
THELLO: DB 13,10,'Hello World !',0
rept 10H-($ and 0FH)
DB 255
endm
if $ gt 100H
display "Maximum code size over !"
endif
RAZMER EQU $-RABADR
HHH EQU high $
TEXT ENDS
END
PS. Надо чтобы при трансляции байты заголовка не затёрлись кодом после ORG 0. В нормальных ассемблерах всегда только один ORG, а для задания адреса трансляции не совпадающего с адресом загрузки кода используется .PHASE. А как это сделать в ассемблере 8086 я не представляю.
Сосем не обязательно последний UltraEdit (и это даже вредно). Достаточно и древнего 15...20-ти летней давности, например версий 8, 9 или 10, которые в кракнутом виде были на всех CD, продаваемых на рынках 20 лет назад и позднее. На Old-DOS.ru есть только версия 5, потому вот на всякий случай версия 9 (2002). Сразу надо кликнуть правой кнопкой на балке кнопок и в 'customize" добавить нужные кнопки и убрать неиспользуемые.Mixa64 wrote:30 дней evaluation
Для ассемблера надо поставить моноширинный фонт (лучше всего Lucida Console, кириллический, размер 16-17, OEM). Рамки и линии псевдографикой OEM будут отображаться (при OEM фонте), но рисовать их здесь нельзя, - их удобно рисовать в "Слово и Дело" Гутникова.
Я программирую для 8-ми разрядок и иногда для MSDOS и как-раз здесь без UltraEdit не обойтись. Он имеет не только всё, что надо для программиста, но и, являясь программой Windows, позволяет работать в альтернативной кодировке DOS (OEM), а когда надо прямо в редакторе перекодирует в Windows кодировку.
Для РК86 надо, чтобы тексты были в КОИ-7. А в КОИ-7 перекодировать могут только транскодеры для CP/M. Также и при написании программ в КОИ-8 с псевдографикой единственный вариант это АЛЬТ-кодировка, т.к в Windows-кодировке и UTF нет псевдографики. Я пишу в АЛЬТ-кодировке, а при трансляции для 8-ми разрядок в BAT-файл вставлена строка RECODE.COM FILE /A /K7 >> nul. Потому транслируется уже файл в кодировке КОИ-7 или КОИ-8, что и требуется. Никаких неудобство разница в кодировках не создаёт.
Недостаток старого UltraЕdit-а, что он не понимает UTF-кодировку (а некоторые сдуру её используют, причём для plain text-а, где достаточно любой 8-ми битовой кодировки).
Чтобы не напрягаться с кодировкой при вставке кусков с русскими буквами в посты, я использую редактор BRED3. Он при Paste в него кусков текста автоматически определяет входную кодировку и конвертирует как надо. Потому, чтобы вставить кусок текста, что в АЛЬТ-кодировке, я копирую в буфер кусок текста из UltraEdit, вставляю в пустое окно в BRED, маркирую всё по ^A и снова копирую в буфер по ^C и по ^V вставляю в сообщение в браузере. Это занимает 2 секунды.
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Конвертировал для процессора 8088 ещё одну простенькую игру ТЕНИС. На конверсию и отладку даже этой простой игры, не считая времени на получение исходника с помощью IDA ушло почти 3 часа.
Это из-за неправильного конвертора, который рассчитан на какой-то древний ассемблер из-за чего полученный исходник нуждается в ручной доработке. Если написать нормальный конвертор, после которого не нужна ручная доработка, то весь труд по конверсии корректных РК-программ будет состоять только из дизассемблирования.
А на конверсию редактора дампа РК86 ушло всего 15 минут, благодаря тому, что исходник был хорошего качества, время по сути ушло только на отладку из-за собственной ошибки.
Также конвертировал отладчик КР580 от ИРИШИ. Пришлось забить всё что относится к отладке - директивы P, U, T, G, X. Остались только директивы работы с памятью и встроенные мини-ассемблер и мини-дизассемблер для процессора КР580.
Автоматическая конверсия возможна только для корректных программ. К сожалению авторы программ для КР580 часто нагло используют само модификацию кода, что делает программу непригодной для автоматической конверсии. Особенно такой наглотой увлекались разработчики ОРИОНА, писавшие ПО для ORDOS. Такие программы не только очень сложно дизассемблировать, но и при конверсии их надо существенно переделывать. Также наглые команды OUT (они при КР580 без СК попадают в память), которые авторы программ применяли ради экономии всего одного байта, нуждаются в ручной переделке.
Но самая глупая наглота это когда программы лезут во внутренние нестандартные точки ПЗУ F800. Это часто делали авторы программ для РК86 и Микроши, несмотря на статьи в ж.РАДИО, где неоднократно указывалось, что так делать не надо. Это делалось лишь чтобы с'экономить 10-15 байтов на простейшей подпрограмме. Но из-за этого нельзя сменить ПЗУ F800 на более совершенную версию и невозможна автоматическая конверсия программ для других процессоров.
И автоматическая конверсия возможна только для той же самой архитектуры РК86 на процессоре 8086. Так что может быть и не стоит исправлять "кривую архитектуру" РК86, оставив адреса портов как есть. Можно "открыть" ОЗУ в области 8100...BFFF и возможно в области E100...FFFF тоже сделать ОЗУ (чтобы ROM-BIOS можно было загружать). Т.к размер конвертированных программ получается лишь на немного больше, чем в оригинале, а программы написанные специально для 8088 имеют размер даже меньше, чем полный аналог на КР580, то свободного ОЗУ в 48 кб хватит.
Сегодня ещё попробую конвертировать ещё несколько простеньких игр от РК86, а потом видимо стОит заняться написанием собственного конвертора исходников Z80 (с усечённой до КР580 системой команд) в исходник для процессора 8088. Результат будет лучше, если потратить больше времени на разработку инструментария, чем тупо заниматься совсем неинтересной и долгой ручной коррекцией исходников при которой энтузиазма надолго не хватит.
Вот здесь игра ТЕНИС и в дальнейшем сюда же я буду складывать другие программы для РК на процессоре 8088. Управление в игре - курсорные клавиши вверх-вниз а также клавиши <A> и <Z>. Адрес загрузки и старта с 0 (т.е при загрузке по ^L из отладчика надо указывать адрес 0). Для редактора дампа адрес загрузки 7000 (вводить 0x7000).
В этом же каталоге исходники, - там есть BAT-файлы, при запуске они создают в подкаталоге Radio/PROGS/ готовую программу. Учтите, что при трансляции файла не с 0, программа EXE2BIN заполняет начало файла нулями, потому надо блок нулей удалить из файла.
Это из-за неправильного конвертора, который рассчитан на какой-то древний ассемблер из-за чего полученный исходник нуждается в ручной доработке. Если написать нормальный конвертор, после которого не нужна ручная доработка, то весь труд по конверсии корректных РК-программ будет состоять только из дизассемблирования.
А на конверсию редактора дампа РК86 ушло всего 15 минут, благодаря тому, что исходник был хорошего качества, время по сути ушло только на отладку из-за собственной ошибки.
Также конвертировал отладчик КР580 от ИРИШИ. Пришлось забить всё что относится к отладке - директивы P, U, T, G, X. Остались только директивы работы с памятью и встроенные мини-ассемблер и мини-дизассемблер для процессора КР580.
Автоматическая конверсия возможна только для корректных программ. К сожалению авторы программ для КР580 часто нагло используют само модификацию кода, что делает программу непригодной для автоматической конверсии. Особенно такой наглотой увлекались разработчики ОРИОНА, писавшие ПО для ORDOS. Такие программы не только очень сложно дизассемблировать, но и при конверсии их надо существенно переделывать. Также наглые команды OUT (они при КР580 без СК попадают в память), которые авторы программ применяли ради экономии всего одного байта, нуждаются в ручной переделке.
Но самая глупая наглота это когда программы лезут во внутренние нестандартные точки ПЗУ F800. Это часто делали авторы программ для РК86 и Микроши, несмотря на статьи в ж.РАДИО, где неоднократно указывалось, что так делать не надо. Это делалось лишь чтобы с'экономить 10-15 байтов на простейшей подпрограмме. Но из-за этого нельзя сменить ПЗУ F800 на более совершенную версию и невозможна автоматическая конверсия программ для других процессоров.
И автоматическая конверсия возможна только для той же самой архитектуры РК86 на процессоре 8086. Так что может быть и не стоит исправлять "кривую архитектуру" РК86, оставив адреса портов как есть. Можно "открыть" ОЗУ в области 8100...BFFF и возможно в области E100...FFFF тоже сделать ОЗУ (чтобы ROM-BIOS можно было загружать). Т.к размер конвертированных программ получается лишь на немного больше, чем в оригинале, а программы написанные специально для 8088 имеют размер даже меньше, чем полный аналог на КР580, то свободного ОЗУ в 48 кб хватит.
Сегодня ещё попробую конвертировать ещё несколько простеньких игр от РК86, а потом видимо стОит заняться написанием собственного конвертора исходников Z80 (с усечённой до КР580 системой команд) в исходник для процессора 8088. Результат будет лучше, если потратить больше времени на разработку инструментария, чем тупо заниматься совсем неинтересной и долгой ручной коррекцией исходников при которой энтузиазма надолго не хватит.
Вот здесь игра ТЕНИС и в дальнейшем сюда же я буду складывать другие программы для РК на процессоре 8088. Управление в игре - курсорные клавиши вверх-вниз а также клавиши <A> и <Z>. Адрес загрузки и старта с 0 (т.е при загрузке по ^L из отладчика надо указывать адрес 0). Для редактора дампа адрес загрузки 7000 (вводить 0x7000).
В этом же каталоге исходники, - там есть BAT-файлы, при запуске они создают в подкаталоге Radio/PROGS/ готовую программу. Учтите, что при трансляции файла не с 0, программа EXE2BIN заполняет начало файла нулями, потому надо блок нулей удалить из файла.
Last edited by barsik on 10 Jun 2018 02:24, edited 8 times in total.
-
- Doomed
- Posts: 478
- Joined: 25 Aug 2009 07:02
- Location: Москва
Re:
В листинге от MASM есть перечисление символов и их типов. Я видел NEAR, L NEAR (назовем LABEL) и NUMBER. LABEL и NEAR что-то вроде указателя. Операции над этими типами как над числами или битовыми полями не определены или весьма ограничены. Но в рамках одного сегмента можно получить разность между NEAR или L NEAR, по сути это разность смещений и в результате получается число. С числом можно совершать привычные действия.barsik wrote:Вот самая простая программа для РК86 "Hello World" транслируемая в формат RKR. Чтобы получился RKR-формат надо вначале вставить заголовок с адресами и подогнать размер файла под удобный. Для этого нужна адресная арифметика.
Странслируйте это пожалуйста MASM-ом или TASM-ом. У меня не получается. Упрощённое задание сегментов с помощью оператора .MODEL я не использую (точнее только для простейших программок). Не думаю, что дело в том как задавать сегменты.
Этот оператор определяет символ RABADR тип NUMBER значение 0
Code: Select all
RABADR EQU 0
Code: Select all
RAZMER EQU $-RABADR
Вот так допустимо:
Code: Select all
DB high RABADR
DB low RABADR
DB high RABADR+RAZMER-1
DB low RABADR+RAZMER-1
ORG RABADR
L_RABADR:
...
RAZMER EQU $-L_RABADR
...
Last edited by Mixa64 on 09 Jun 2018 15:16, edited 1 time in total.
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re:
очень простым способом можно получить нарезку устройств не по 8КБ, а по 4КБ, как в нашем варианте, так и в оригинальном РК, если там используются сразу РУ5. Схема во вложении. Эта доработка не требует изменений в мониторе ни здесь ни в оригинале... так получаем 3 окна по 4КБ, можно включать ОЗУ.barsik wrote: Так что может быть и не стоит исправлять "кривую архитектуру" РК86, оставив адреса портов как есть. Можно "открыть" ОЗУ в области 8100...BFFF и возможно в области E100...FFFF тоже сделать ОЗУ (чтобы ROM-BIOS можно было загружать). Т.к размер конвертированных программ получается лишь на немного больше, чем в оригинале, а программы написанные специально для 8088 имеют размер даже меньше, чем полный аналог на КР580, то свободного ОЗУ в 48 кб хватит.
отрезать нули можно с помощью dd в linux и есть ее windows аналог - dd.exe. Она в архиве из моего предыдущего поста с инструментами для сборки монитора для 8086.barsik wrote: В этом же каталоге исходники, - там есть BAT-файлы, при запуске они создают в подкаталоге Radio/PROGS/ готовую программу. Учтите, что при трансляции файла не с 0, программа EXE2BIN заполняет начало файла нулями, потому надо блок нулей удалить из файла.
у меня вот вопрос появился, а звук у нас какой то будет? или на порт ВВ55 или, может ВИ53 поставим?
You do not have the required permissions to view the files attached to this post.
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Менять адреса БИС имеет смысл, если ОЗУ всего одна банка РУ5. Если же для программ есть дополнительный целый сегмент в 64, то можно и сохранить глупую архитектуру РК. В принципе, адреса портов вообще никого не волнуют, потому что для всех конвертированных программ для такого РК есть или будут исходники, где сменить 4 цифры (экран, ППА клав, ВГ75 и ВТ57) вообще не проблема. А т.к я ориентируюсь на ОЗУ в 128 кб, то проще сохранить адресацию хотя-бы порта клавиатуры.barsik wrote:может быть и не стоит исправлять "кривую архитектуру" РК86, оставив адреса портов как есть. Можно "открыть" ОЗУ в дырках между портами...
Я хотел бы сделать из РК машину на 8088 с тактом 10 МГЦ с целым свободным сегментом в 64 кб, чтобы можно было странслировать для неё мои эмуляторы РК86 и ОРИОНА (для эмуляции РК и ИРИШИ 10 МГЦ хватит, а вот ОРИОН будет тормозным), а затем написать для такой ЭВМ эмуляторы ИРИШИ, Специалиста, ЮТ88 и БК-010. Для вывода на экран я собираюсь использовать не ВГ75, а внешнюю плату графического адаптера от ИРИШИ. Которые у меня специально сохранены. Тормозные процессорные платы ИРИШИ за ненадобностью распаял ещё в 90-тые, а граф.адаптеры оставил специально чтобы сделать ИРИШУ на CPU 8088.
Для этих же целей может быть использован писишный адаптер CGA/EGA/VGA или Hercules (если удастся его найти), но это намного сложнее (и тормознее), т.к надо разобраться как такой адаптер инициализировать, ведь встроенное в адаптер расширение ROM-BIOS не использовать.
Вначале, т.к по трудозатратам это в 100 раз проще, использую плату РК86, а впоследствии спаяю полноценный модуль процессора в конструктиве ИРИШИ на 8086, т.к он скоростнее (чтобы этот модуль вставлялся в ИРИШУ вместо модуля КР580).
Уже можно начинать разработку и макетирование РК86 на 8088 в железе. Обидно, что никто не предлагает схемы установки 8088 в РК86. Сам я слабый аппаратчик, отчего придётся долго разбираться с этим и это может затянуться.
Самой оптимальной мне видится такая архитектура. Из соображений скорости ОЗУ лучше не на 565 РУ7, а на уже имеющейся РУ5/РУ3 и доп.ОЗУ на w24512. ПЗУ 27128 включено в самом старшем сегменте F000:C000, ниже БИС-ы РК86 в области 8000, как и в базовом РК, но с шагом в 256 байт. Ниже 8000 - ОЗУ 32 кб из РУ3/РУ5. Такая архитектура самого старшего сегмента, уже при наличии только базовых 32К, позволяет прогонять программы конвертированные от РК86, Микроши, Апогея и Партнёра. А если подключается внешний граф.адаптер, то он может занимать целый сегмент в 64 кб.
При этом экран и ППА клавиатуры остаются на стандартных местах, потому программы не меняющие режим ВГ75 (и потому не лезущие к ВТ57 и ВГ75) можно конвертировать автоматически. А в графических играх достаточно поменять только 2 цифры адресов БИС. Но в этом сегменте с РУ5 процессор будет работать медленно, т.к время доступа к ОЗУ и ПЗУ низко. Реальное быстродействие не превысит 2.5 МГЦ, даже если клок 8088 сделать высоким.
Потому и нужна вторая банка на скоростном статическом ОЗУ w24512 с которой процессор работает на максимальной скорости. Эти 64К могут стоять в начале памяти (CS=0000) и в этом сегменте все 64К - скоростное ОЗУ. Мой эмулятор ОРИОНА занимает все 64 кб (хотя без встроенного отладчика менее 32 кб).
Также в этом сегменте могут работать программы компьютера на 8088. Тогда на F800 грузятся только стандартные входы, которые доступны по CALL NEAR, а они уже переадресуют с помощью дальних вызовов ПЗУ 27128 в старшем сегменте памяти. Это позволит получить любительский компьютер на 8088 со сплошным ОЗУ в 62 кб и сравнительно высоким быстродействием (сколько потянет 8088), а не только даст возможность прогонять игры конвертированные от РК86.
У меня давно есть монитор-отладчик (8 кб), написанный в кодах 8086 (т.е его конвертировать не надо). Это монитор-отладчик из моего эмулятора ОРИОНА, написанного на ассемблере. Хотя в нём встроенные мини-ассемблер, мини-дизассемблер и команда G с остановами - для процессора Z80. Потому сейчас я немного изменяю конфиг эмулятора EMU. Меняются только адреса ПДП и ВГ75, а ПЗУ становится 16 кб, в нём, естественно сохранены входы РК86, но RAM-монитора от РК86 там уже нет, а есть более удобный RAM-монитор.
Так звук и так есть. Посмотрите исходник. Я вывожу звук в порт магнитофона на PC0. Бит вывода можно изменить (только PC0...PC3). Но с помощью PC3 эмулятор EMU включает альтернативный фонт (потому его трогать ни в коем случае нельзя). PC1 и PC2 свободны, но проще, как и в БК-010, выводить звук по биту вывода на магнитофон. Т.е - по биту PC0. Но если хотите можете изменить параметр SNDBYT в начале исходника. Также надо подобрать константы звуков BEEP и KLIK в соответствии со скоростью CPU.PVV wrote:у меня вот вопрос появился, а звук у нас какой-то будет? Или на порт ВВ55 или, может, ВИ53 поставим?
Если эмулятор EMU поддерживает 580 ВИ53, то нет проблем. Со стороны ROM-BIOS это требует только его инициализации по сбросу (иначе он при подаче питания начинает пищать как недорезанный). Для РК программ поддерживающих ВИ53 нет, а вот в Микроше все хорошие игры выводят звук через ВИ53. Если бы в области F800 было ОЗУ и туда можно было бы грузить ROM-BIOS Микроши, то можно было бы конвертировать и программы Микроши со звуком через ВИ53.
А если эмулятор EMU поддерживает AY-8912, то желательно применить его, т.к у меня уже более 25 лет лежит такой чип, всё ждёт часа, когда я его применю. Обидно, что он пропадает впустую, ведь он он стоил мне дорого (~5 USD) в начале 90-тых.
Спасибо. Это решает проблему формирования заголовков Tape-файлов с помощью HIGH. Но это не решает задачу заполнения памяти кодом до конкретного адреса или хотя бы выдачи предупреждений.Mixa64 wrote:если определить LABEL со значением RABADR, например, символ L_RABADR, то такая операция станет допустимой, тип RAZMER станет правильным и перестанет ругаться и в других местах, где встречается RAZMER.
Code: Select all
if $ ne 0FFF0H
display " Reset point FFF0 shifted !"
endif
Пока писал о ВИ53, натолкнулся на мысль о конверсии программ Микроши. Микроша отличается незначительно. Только перепутаны местами порты PA и PB и ПЗУ F800 другое. Менять порты придётся при конверсии программно. ПЗУ теоретически проще заменить аппаратно. Для управления ПЗУ можно задействовать свободные биты PC1 и PC2. Тогда на РФ2 напаивается панелька, куда вставляется второэтажная РФ2. И получаются две банки ПЗУ прокачиваемые в окне размером 2 кб (F800...FFFF).
Кроме того можно пойти и программным путём - дизассемблировать ПЗУ Микроши и разобраться в отличиях ПЗУ РК и Микроши. При этом придётся ещё дизассемблировать и изучить десяток игр Микроши, чтобы найти нестандартные внутренние точки внутри ПЗУ, куда нагло лезут малограмотные авторы, чтобы сохранить их в конвертированном ПЗУ по тем же адресам. Я с этим уже сталкивался, когда хотел адаптировать программу от Микроши. Но это всё-же намного сложнее при конверсии. При конверсии от РК86 думать и менять что-то не требуется. Главное правильно конвертировать и тогда всё работает. А если надо разбираться в логике и кое-где менять алгоритм, это уже намного сложнее.
Last edited by barsik on 11 Jun 2018 06:02, edited 2 times in total.
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re: Радио-86РК на 8088 (или 8086)
Звук, действительно, есть. Надо было просто регулятор громкости покрутить в +...
Установить 8088 вообще нет проблем, можно смотреть схему из протеуса на 8086 и выбросить из нее все, что относится к D[8..15]. Можно сделать просто плату-адаптер с 8088, ГФ84, 74ls573 2шт. на защелку A[0..15] и 74ls245 на D[0..7], с распиновкой как у ВМ80 и втыкаемой в панельку от ВМ80 базовой РК-86. Да, еще на этой плате инвертор нужен на /RD в DBIN(у ВМ80 он прямой). Все остальные цепи и сигналы подходят один в один. Таким образом 6 корпусов заменят один ВМ80...
Для меня интерес именно 8086 представляет, а с ним морока с преобразованием обращений 16и битного ЦП к 8и битным устройствам и 8и битного ДМА к 16и битному ОЗУ, но это единственное, что и представляет интерес в этой схеме. Да и модели 8088 в протеусе нет, нет возможности схему 'пощупать'
Эмулятор EMU поддерживает и ВИ53 и AY-8912, проблем нет, надо лишь с адресами портов определиться.
Касательно SRAM ОЗУ, можно его на плате-адаптере разместить, а ее /CS подключить на инверсный A16, будет второй сегмент памяти.
ПЗУ от Микроши и тп, можно ведь сегментные регистры так настраивать, что б при обращении попадать куда надо при размещении кода в любом месте ОЗУ.
Установить 8088 вообще нет проблем, можно смотреть схему из протеуса на 8086 и выбросить из нее все, что относится к D[8..15]. Можно сделать просто плату-адаптер с 8088, ГФ84, 74ls573 2шт. на защелку A[0..15] и 74ls245 на D[0..7], с распиновкой как у ВМ80 и втыкаемой в панельку от ВМ80 базовой РК-86. Да, еще на этой плате инвертор нужен на /RD в DBIN(у ВМ80 он прямой). Все остальные цепи и сигналы подходят один в один. Таким образом 6 корпусов заменят один ВМ80...
Для меня интерес именно 8086 представляет, а с ним морока с преобразованием обращений 16и битного ЦП к 8и битным устройствам и 8и битного ДМА к 16и битному ОЗУ, но это единственное, что и представляет интерес в этой схеме. Да и модели 8088 в протеусе нет, нет возможности схему 'пощупать'

Эмулятор EMU поддерживает и ВИ53 и AY-8912, проблем нет, надо лишь с адресами портов определиться.
Касательно SRAM ОЗУ, можно его на плате-адаптере разместить, а ее /CS подключить на инверсный A16, будет второй сегмент памяти.
ПЗУ от Микроши и тп, можно ведь сегментные регистры так настраивать, что б при обращении попадать куда надо при размещении кода в любом месте ОЗУ.
-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Радио-86РК на 8088 (или 8086)
Если вы пошарите поиском по форуму, то этот вопрос уже давно и квалифицированно разобрали -PVV wrote:Для меня интерес именно 8086 представляет, а с ним морока с преобразованием обращений 16и битного ЦП к 8и битным устройствам и 8и битного ДМА к 16и битному ОЗУ, но это единственное, что и представляет интерес в этой схеме.
про "перестановщик байт" и прочее.
Кстати, ставил я в древние времена в "Искру-1030.М" (она на 8086 как раз) свою плату с 4-мя
параллельными адаптерами типа ВВ55 - всё было довольно несложно и никакой мороки не было.
iLavr
-
- Doomed
- Posts: 478
- Joined: 25 Aug 2009 07:02
- Location: Москва
Re:
(поправил свой пост, скорректировал рассуждения про типы, было не совсем точно)barsik wrote:barsik wrote:Спасибо. Это решает проблему формирования заголовков Tape-файлов. Но как решить задачу заполнения памяти кодом до конкретного адреса ?Mixa64 wrote:если определить LABEL со значением RABADR, например, символ L_RABADR, то такая операция станет допустимой, тип RAZMER станет правильным и перестанет ругаться и в других местах, где встречается RAZMER.
Возможно, в начале сегмента, там где смещение 0, надо сгенерить L NEAR со значением 0, которое потом везде вычитать из $, получая таким образом NUMBER, с которым можно проводить всяческие операции.
Например,
Code: Select all
.8086
include MACRO.INC
CGROUP GROUP TEXT
TEXT segment byte public 'CODE'
assume CS:CGROUP,DS:CGROUP,SS:CGROUP,ES:nothing
SEG_BASE:
RABADR EQU 0
DB high RABADR
DB low RABADR
DB high (RABADR+RAZMER-1)
DB low (RABADR+RAZMER-1)
ORG RABADR
.msg THELLO
ROMJMP 0F800H
THELLO: DB 13,10,'Hello World !',0
rept 10H-(($-SEG_BASE) and 0FH)
DB 255
endm
if ($-SEG_BASE) gt 100H
display "Maximum code size over !"
endif
RAZMER EQU ($-SEG_BASE)-RABADR
HHH EQU high ($-SEG_BASE)
TEXT ENDS
END
Еще я заметил, что выражение для операторов high или low нужно брать в скобки, иначе результат почему-то получается неверным.
DB high RABADR+RAZMER-1 порождает 1D, что на самом деле low от 001Dh, а DB high (RABADR+RAZMER-1) дает 00, что верно. Приоритет операций тут ни при чем, потому что low и high по правилу применяются после арифметики, здесь какой-то необъяснимый пока эффект.