nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 20 Nov 2018 13:37



Reply to topic  [ 166 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11, 12  Next
Радио-86РК на 8088 (или 8086) 
Author Message
Maniac

Joined: 12 Feb 2016 14:39
Posts: 299
Reply with quote
А если накидать в стек адрес перехода, и затем сделать RET?


07 Jun 2018 07:43
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
PVV wrote:
А если накидать в стек адрес перехода, и затем сделать RET?

Будет возврат на адрес перехода... ньюансы - ближний, дальний накидать (RETn, RETf).

_________________
iLavr


07 Jun 2018 09:56
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 248
Location: Россия
Reply with quote
Post 
PVV wrote:
А если накидать в стек адрес перехода, и затем сделать RET ?
Да, идея очень хорошая. Потому-что 8088 по CALL кладёт в стек абсолютный адрес. Сделал вот такой директиву G:
Code:
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 возврат и попадаем в ОЗУ

Это с'экономило 16 байтов потому-что команды PUSH однобайтовые. Хотя всё-равно такой трюк на 3 байта длиннее, чем обычный JMP FAR. Значит можно таким же трюком заменяющим CALL FAR из области ОЗУ с 0 вызывать входы в ПЗУ F800.

Сейчас возвраты из всех стандартных входов в ПЗУ - недалёкие по RET NEAR. Потому вызов стандартных входов ПЗУ по CALL FAR потребует переделки ПЗУ. А т.к все возвраты и из всех внутренних процедур близкие, то придётся для всех внешних входов в ПЗУ сделать такую конструкцию:
Code:
MCOUT:  CALL    COUT_C
        RETF

MCONIN: CALL    CONIN
        RETF

MHEX_A: CALL    HEX_A
        RETF

MSTAT:  CALL    STATUS
        RETF

MMSSG:  CALL    MSSG
        RETF
        . . . . . .


Расход в 4 байта на каждый из 17 входов - всего 68 байтов. Для этого в ПЗУ 2 кб уже не найти свободного места, как ни оптимизируй. Придётся выкинуть одну или несколько директив.

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

Чуть позднее я сообразил, что CS не меняется и потому необязательно имитировать возврат из далёкого CALL, достаточно применить близкий RET. А т.к при имитации возврата из близкого CALL вывод в стек регистра CS не требуется, то это получается даже короче чем JMP FAR и не намного длиннее, чем CALL FAR.

Это работает потому-что по CALL процессор кладёт в стек абсолютный адрес, в то время как в командах JMP/CALL параметр адреса относительный (+/- 32767 от адреса следующей за CALL команды).

Таким образом использование RET удобнее, чем далёкие CALL/JMP. Вот теперь какая получилась директива G.
Code:
DIR_G:  MOV     BX,offset WARMST        ; в стек адрес возврата
        PUSH    BX
        MOV     BX,DS:[PAR_HL]
        PUSH    BX                      ; в стек адрес вызова
        RET                             ; делаем возврат и попадаем в ОЗУ


Кстати по длине кода это одинаково с таким вариантом:
Code:
DIR_G:  MOV     BX,offset WARMST        ; в стек адрес возврата
        PUSH    BX
        MOV     BX,DS:[PAR_HL]
        JMP     BX                      ; уход по адресу из PAR_HL

Надо подумать, делать-ли входы в ПЗУ по CALL FAR или по CALL NEAR. Во-первых, не ясно как в TASM делать CALL FAR на адреса вне кода (т.к их надо как-то объявлять типа extrn absolute, чтобы линковщик не ругался). Во-вторых, выяснилось, что NEAR входы ПЗУ F800 прекрасно вызываются как способом с помощью RET, так и с помощью конструкции MOV BP,ADDR : CALL BP.

Написал макрокоманды для обоих этих случаев, где чётко видно, что вызов ПЗУ с помощью CALL BP короче.
Code:
ROMCALL MACRO   ADDR
        LOCAL   M1
        MOV     BP,offset M1
        PUSH    BP
        MOV     BP,ADDR
        PUSH    BP
        RET
M1:     ENDM


Code:
ROMCALL MACRO   ADDR
        MOV     BP,ADDR
        CALL    BP
        ENDM


Используя для вызова подпрограмм ПЗУ слово ROMCALL вместо CALL, программирование ничуть не сложнее, чем при использовании дальних CALL. С другой стороны для системы, где ОЗУ, как в IBM PC больше, чем 64 кб, ПЗУ должно стоять только в самом старшем сегменте, т.е иметь абсолютный адрес F000:F800. Тогда для вызовов ПЗУ должен использоваться только CALL FAR.

Можно сделать минимально-максимальную архитектуру ПЗУ. Тогда в сегменте 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-ть свободных ячеек).


07 Jun 2018 11:02
Profile
Maniac

Joined: 12 Feb 2016 14:39
Posts: 299
Reply with quote
Схему сильно не причесал, очень много времени занимает вычисление глюков модели 8086.dll в протеусе :evil: точно сказать сложно в чем дело, тк не понятно, какая именно команда выполняется процессором из-за наличия предвыборки данных, но похоже, проблема в том, что эта модель неверно выбирает из очереди данные, если они по нечетному адресу и путает местами байты четый-нечетный, и получается, что вместо записи байта данных пишется следующий байт. Вставкой команды nop, выравнивающей очередь, этот глюк не проявляется:
Code:
    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 (это надо)

без nop перед этим:
MOV byte ptr [BX],27H
будет запись не 27H, а 8A... как то так. Отлавливать такие глюки оочень муторно.
Тем не менее функционирование дисплея с такой системой получилось, но без клавиатуры. Толи этот же глюк, толи ошибка у меня в схеме при обращении к ППА при преобразовании D[0..15] <-> XD[0..7] еще не разобрался.
Во вложении проект протеуса с 'притянутым за уши' монитором к модели и всеми инструментами для сборки.


Attachments:
rk8086_4.pdsprj.pdf [225.4 KiB]
Downloaded 10 times
RK8086_.zip [1.3 MiB]
Downloaded 11 times
08 Jun 2018 05:13
Profile
Doomed

Joined: 25 Aug 2009 08:02
Posts: 361
Location: Москва
Reply with quote
Post Re:
barsik wrote:
В MASM с адресной арифметикой вообще всё погано.

Не совсем понятно, в какую сторону катится бочка :)
За 5 сек накидал:
Code:
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

(че-та табуляция съезжает)


08 Jun 2018 05:40
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 248
Location: Россия
Reply with quote
Post 
Вот здесь игра "ОХОТА НА УТОК". Ошибки исправлены и сделано, чтобы было сложнее играть (только самые ловкие смогут подстрелить 10 уток). Не знаю как в эмуляторе EMU указать имя файла для загрузки и автозапуска в командной строке. Потому для запуска надо выйти в отладчик, нажать ^L, ввести адресом загрузки число 0 и кликнуть ОК. В подкаталоге /Radio/Progs выбрать файл OXOTA.DAT. И закрыв окно отладчика ввести G<ВК>.

Mixa64 wrote:
barsik wrote:
В MASM с адресной арифметикой вообще всё погано.
Не совсем понятно, в какую сторону катится бочка
Т.к я всегда пользовался только TASM-ом, а в его описании постоянно указывают, что вот того-то и того-то в MASM нет или плохо, а в TASM улучшено, то естественно считать MASM плохим. Режим по умолчанию в нём это режим совместимости с MASM и там нет адресной арифметики, значит её нет и в MASM. Может в ранних версиях MASM она и есть или появляется по какому-либо ключу.

Спасибо за очень полезное сообщение. Скачаю MASM и буду пользоваться им, т.к вычислять расстояния между адресами просто необходимо, а TASM этого не может (а если и может, то я пока не знаю каким ключом это разрешить).

Mixa64 wrote:
че-та табуляция съезжает
А потому-что надо пользоваться программистскими редакторами, а не убогими поделками в стиле блокнота. Лучше UltraEdit ничего нет. В нём есть функция "замена табуляций на пробелы". Вырезаете по ^C кусок из программы (чтобы исходник не уродовать), вставляете в новое пустое окно редактора и из вкладки Format удаляете табуляции.

Движок данного сайта неверно обрабатывает табуляции, потому и надо их заменить на пробелы.


08 Jun 2018 10:36
Profile
Doomed

Joined: 25 Aug 2009 08:02
Posts: 361
Location: Москва
Reply with quote
Post Re:
barsik wrote:
Скачаю MASM и буду пользоваться им, т.к вычислять расстояния между адресами просто необходимо, а TASM этого не может (а если и может, то я пока не знаю каким ключом это разрешить).

Боюсь, что не (только) в ассемблерах дело, потому что мой пример TASM странслировал точно так же, 1:1.

Попробовал Ваш давний образец, где A1 equ $; ... ; LENGTH equ $-A1
Я ленив, поэтому вместо LENGTH набил LEN
Получилось так (заюзал TASM и LARGE MODEL для разнообразия):
Code:
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

Но если не полениться и впечатать LENGTH, то начинает ругаться, правда не на dissimilar values, а на использование служебного слова.

Code:
     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

и MASM:
Code:
 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 

barsik wrote:
Лучше UltraEdit ничего нет.

(Попробовал, теперь не съезжает, но 30 дней evaluation.)


08 Jun 2018 13:36
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 248
Location: Россия
Reply with quote
Post 
Вот самая простая программа для РК86 "Hello World" транслируемая в формат RKR. Чтобы получился RKR-формат надо вначале вставить заголовок с адресами и подогнать размер файла под удобный. Для этого нужна адресная арифметика.

Странслируйте это пожалуйста MASM-ом или TASM-ом. У меня не получается. Упрощённое задание сегментов с помощью оператора .MODEL я не использую (точнее только для простейших программок). Не думаю, что дело в том как задавать сегменты.

Code:
        .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
Полный текст здесь. Добавьте в этот каталог файл TASM.EXE и странслируйте.

PS. Надо чтобы при трансляции байты заголовка не затёрлись кодом после ORG 0. В нормальных ассемблерах всегда только один ORG, а для задания адреса трансляции не совпадающего с адресом загрузки кода используется .PHASE. А как это сделать в ассемблере 8086 я не представляю.

Mixa64 wrote:
30 дней evaluation
Сосем не обязательно последний UltraEdit (и это даже вредно). Достаточно и древнего 15...20-ти летней давности, например версий 8, 9 или 10, которые в кракнутом виде были на всех CD, продаваемых на рынках 20 лет назад и позднее. На Old-DOS.ru есть только версия 5, потому вот на всякий случай версия 9 (2002). Сразу надо кликнуть правой кнопкой на балке кнопок и в 'customize" добавить нужные кнопки и убрать неиспользуемые.

Для ассемблера надо поставить моноширинный фонт (лучше всего 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 секунды.


08 Jun 2018 14:53
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 248
Location: Россия
Reply with quote
Post 
Конвертировал для процессора 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 заполняет начало файла нулями, потому надо блок нулей удалить из файла.


Last edited by barsik on 10 Jun 2018 03:24, edited 8 times in total.



09 Jun 2018 03:39
Profile
Doomed

Joined: 25 Aug 2009 08:02
Posts: 361
Location: Москва
Reply with quote
Post Re:
barsik wrote:
Вот самая простая программа для РК86 "Hello World" транслируемая в формат RKR. Чтобы получился RKR-формат надо вначале вставить заголовок с адресами и подогнать размер файла под удобный. Для этого нужна адресная арифметика.

Странслируйте это пожалуйста MASM-ом или TASM-ом. У меня не получается. Упрощённое задание сегментов с помощью оператора .MODEL я не использую (точнее только для простейших программок). Не думаю, что дело в том как задавать сегменты.

В листинге от MASM есть перечисление символов и их типов. Я видел NEAR, L NEAR (назовем LABEL) и NUMBER. LABEL и NEAR что-то вроде указателя. Операции над этими типами как над числами или битовыми полями не определены или весьма ограничены. Но в рамках одного сегмента можно получить разность между NEAR или L NEAR, по сути это разность смещений и в результате получается число. С числом можно совершать привычные действия.

Этот оператор определяет символ RABADR тип NUMBER значение 0
Code:
RABADR  EQU     0


А здесь недопустимая операция, разность между LABEL и NUMBER
Code:
RAZMER  EQU     $-RABADR

Но если определить LABEL со значением RABADR, например, символ L_RABADR, то такая операция станет допустимой, тип RAZMER станет правильным и перестанет ругаться и в других местах, где встречается RAZMER.

Вот так допустимо:
Code:
        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 16:16, edited 1 time in total.



09 Jun 2018 03:42
Profile
Maniac

Joined: 12 Feb 2016 14:39
Posts: 299
Reply with quote
Post Re:
barsik wrote:
Так что может быть и не стоит исправлять "кривую архитектуру" РК86, оставив адреса портов как есть. Можно "открыть" ОЗУ в области 8100...BFFF и возможно в области E100...FFFF тоже сделать ОЗУ (чтобы ROM-BIOS можно было загружать). Т.к размер конвертированных программ получается лишь на немного больше, чем в оригинале, а программы написанные специально для 8088 имеют размер даже меньше, чем полный аналог на КР580, то свободного ОЗУ в 48 кб хватит.

очень простым способом можно получить нарезку устройств не по 8КБ, а по 4КБ, как в нашем варианте, так и в оригинальном РК, если там используются сразу РУ5. Схема во вложении. Эта доработка не требует изменений в мониторе ни здесь ни в оригинале... так получаем 3 окна по 4КБ, можно включать ОЗУ.

barsik wrote:
В этом же каталоге исходники, - там есть BAT-файлы, при запуске они создают в подкаталоге Radio/PROGS/ готовую программу. Учтите, что при трансляции файла не с 0, программа EXE2BIN заполняет начало файла нулями, потому надо блок нулей удалить из файла.

отрезать нули можно с помощью dd в linux и есть ее windows аналог - dd.exe. Она в архиве из моего предыдущего поста с инструментами для сборки монитора для 8086.

у меня вот вопрос появился, а звук у нас какой то будет? или на порт ВВ55 или, может ВИ53 поставим?


Attachments:
rk8086_5.pdsprj.pdf [147.78 KiB]
Downloaded 11 times
09 Jun 2018 06:06
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 248
Location: Россия
Reply with quote
Post 
barsik wrote:
может быть и не стоит исправлять "кривую архитектуру" РК86, оставив адреса портов как есть. Можно "открыть" ОЗУ в дырках между портами...

Менять адреса БИС имеет смысл, если ОЗУ всего одна банка РУ5. Если же для программ есть дополнительный целый сегмент в 64, то можно и сохранить глупую архитектуру РК. В принципе, адреса портов вообще никого не волнуют, потому что для всех конвертированных программ для такого РК есть или будут исходники, где сменить 4 цифры (экран, ППА клав, ВГ75 и ВТ57) вообще не проблема. А т.к я ориентируюсь на ОЗУ в 128 кб, то проще сохранить адресацию хотя-бы порта клавиатуры.

Я хотел бы сделать из РК машину на 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-монитор.

PVV wrote:
у меня вот вопрос появился, а звук у нас какой-то будет? Или на порт ВВ55 или, может, ВИ53 поставим?

Так звук и так есть. Посмотрите исходник. Я вывожу звук в порт магнитофона на PC0. Бит вывода можно изменить (только PC0...PC3). Но с помощью PC3 эмулятор EMU включает альтернативный фонт (потому его трогать ни в коем случае нельзя). PC1 и PC2 свободны, но проще, как и в БК-010, выводить звук по биту вывода на магнитофон. Т.е - по биту PC0. Но если хотите можете изменить параметр SNDBYT в начале исходника. Также надо подобрать константы звуков BEEP и KLIK в соответствии со скоростью CPU.

Если эмулятор EMU поддерживает 580 ВИ53, то нет проблем. Со стороны ROM-BIOS это требует только его инициализации по сбросу (иначе он при подаче питания начинает пищать как недорезанный). Для РК программ поддерживающих ВИ53 нет, а вот в Микроше все хорошие игры выводят звук через ВИ53. Если бы в области F800 было ОЗУ и туда можно было бы грузить ROM-BIOS Микроши, то можно было бы конвертировать и программы Микроши со звуком через ВИ53.

А если эмулятор EMU поддерживает AY-8912, то желательно применить его, т.к у меня уже более 25 лет лежит такой чип, всё ждёт часа, когда я его применю. Обидно, что он пропадает впустую, ведь он он стоил мне дорого (~5 USD) в начале 90-тых.

Mixa64 wrote:
если определить LABEL со значением RABADR, например, символ L_RABADR, то такая операция станет допустимой, тип RAZMER станет правильным и перестанет ругаться и в других местах, где встречается RAZMER.
Спасибо. Это решает проблему формирования заголовков Tape-файлов с помощью HIGH. Но это не решает задачу заполнения памяти кодом до конкретного адреса или хотя бы выдачи предупреждений.
Code:
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 07:02, edited 2 times in total.



09 Jun 2018 12:10
Profile
Maniac

Joined: 12 Feb 2016 14:39
Posts: 299
Reply with quote
Звук, действительно, есть. Надо было просто регулятор громкости покрутить в +...

Установить 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 в протеусе нет, нет возможности схему 'пощупать' :ebiggrin:

Эмулятор EMU поддерживает и ВИ53 и AY-8912, проблем нет, надо лишь с адресами портов определиться.

Касательно SRAM ОЗУ, можно его на плате-адаптере разместить, а ее /CS подключить на инверсный A16, будет второй сегмент памяти.

ПЗУ от Микроши и тп, можно ведь сегментные регистры так настраивать, что б при обращении попадать куда надо при размещении кода в любом месте ОЗУ.


09 Jun 2018 13:42
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
PVV wrote:
Для меня интерес именно 8086 представляет, а с ним морока с преобразованием обращений 16и битного ЦП к 8и битным устройствам и 8и битного ДМА к 16и битному ОЗУ, но это единственное, что и представляет интерес в этой схеме.

Если вы пошарите поиском по форуму, то этот вопрос уже давно и квалифицированно разобрали -
про "перестановщик байт" и прочее.

Кстати, ставил я в древние времена в "Искру-1030.М" (она на 8086 как раз) свою плату с 4-мя
параллельными адаптерами типа ВВ55 - всё было довольно несложно и никакой мороки не было.

_________________
iLavr


09 Jun 2018 14:32
Profile
Doomed

Joined: 25 Aug 2009 08:02
Posts: 361
Location: Москва
Reply with quote
Post Re:
barsik wrote:
barsik wrote:
Mixa64 wrote:
если определить LABEL со значением RABADR, например, символ L_RABADR, то такая операция станет допустимой, тип RAZMER станет правильным и перестанет ругаться и в других местах, где встречается RAZMER.
Спасибо. Это решает проблему формирования заголовков Tape-файлов. Но как решить задачу заполнения памяти кодом до конкретного адреса ?

(поправил свой пост, скорректировал рассуждения про типы, было не совсем точно)
Возможно, в начале сегмента, там где смещение 0, надо сгенерить L NEAR со значением 0, которое потом везде вычитать из $, получая таким образом NUMBER, с которым можно проводить всяческие операции.
Например,

Code:
        .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


Этот текст транслируется в задуманном направлении, странслируйте и посмотрите свой листинг. По сути, $ просто заменено на ($-SEG_BASE), возможно, это и есть решение.

Еще я заметил, что выражение для операторов high или low нужно брать в скобки, иначе результат почему-то получается неверным.
DB high RABADR+RAZMER-1 порождает 1D, что на самом деле low от 001Dh, а DB high (RABADR+RAZMER-1) дает 00, что верно. Приоритет операций тут ни при чем, потому что low и high по правилу применяются после арифметики, здесь какой-то необъяснимый пока эффект.


09 Jun 2018 16:38
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 166 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11, 12  Next

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.