|
Pentagon by Northwood
|
|
| Black_Cat | Дата: Среда, 01.07.2020, 16:12 | Сообщение # 1 |
 Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| 1. Сигналы DOS/, IODOS/ для NemoBus v.1.2
Цепи DOS/, DOS на выходе DD29 идущие на дешифрацию портов разорвать, и в разрыв врезать схему. Цепи, идущие на выборку ПЗУ оставить как есть.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Суббота, 22.08.2020, 12:51 | Сообщение # 61 |
 80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat (  ) Я уже говорил об этом, что у некоторых авторов программ для Пента512 стоял тумблер, отключавший старшие адреса в дешифраторе #7FFD :) .
Такие программы, в которых при обращении к #7FFD выставляют A15=1, я даже не хочу учитывать. В топку их.
|
| |
| |
| Northwood | Дата: Суббота, 22.08.2020, 13:48 | Сообщение # 62 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Решил проблему с поддержкой программ, использующих 256 КБ ОЗУ по стандарту Пентагон через OUT(#FD),A.
Решение оказалось очень простое, мне понадобился всего 1 логический элемент ИЛИ.
1. На DD39.1 вместо сигнала ~P_7FFD я подал ~P_FD/7FFD, что обеспечит прохождение выборки порта на DD49 при короткой адресации.
2. На мультиплексоры DD31 и DD36 вместо A14 я подал сигнал A14 ИЛИ BLK_HRAM, сформированный на DD138.2 (ЛЛ1). Т.е. если используется полное обращение к порту #7FFD, то на A14 будет 1. Если используется OUT (#FD),A, то единица приходит от сигнала BLK_HRAM. Сигнал A15 в обоих случаях всегда будет = 0. Таким образом, обеспечивается корректная выборка D6 на A17' и D7=D5=0 на A18' и A19'.
Проги, где при обращении к порту #7FFD, выставляют A15=1, я не учитываю.
Сообщение отредактировал Northwood - Суббота, 22.08.2020, 13:58 |
| |
| |
| Black_Cat | Дата: Суббота, 22.08.2020, 13:58 | Сообщение # 63 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood ( ) Такие программы, в которых при обращении к #7FFD выставляют A15=1, я даже не хочу учитывать. В топку их.
Полностью согласен. Но возвращаясь к менеджеру, ты не прав, считая, что слишком много телодвижений перед запуском программы. Во-первых, в однозадачном режиме ни Скорповые/КАЕвские, ни Профийные, ни Пентовые512 проги этого не требуют и могут запускаться без установки маски (т.е. по умолчанию им будет доступно 2Мб). Эти телодвижения нужны токо либо если надо запустить более одной виртуальной машины, или если нужно ограничить память до 128к, или наоборот, включить AllRAM mode для юзания всех 4Мб, и для единиц программ, юзающих метр по D5 #7FFD. Юзание D5 #7FFD в качестве A15 - это безграмотное решение AloneCoder'а, и поддерживать его можно токо в виде исключения в однозадачном режиме AllRAM, иначе возникает коллизия при определении что значит включение этого разряда. В режиме AllRAM мы не ограничены старыми правилами, т.к. это новый режим, и под него ещё нет софта, поэтому мы можем для этого режима запретить спековскую защёлку и и тем самым избежать коллизии определения что значит разряд D5 #7FFD. Твой менеджер допускает такую коллизию. Сделай пожалуйста режим AllRAM, это не какое-то моё хотение, это стандарт работы объединённого менеджера, D5 #7FFD в качестве A15 как исключение должен быть доступен токо в этом режиме, иначе он всегда должен определяться как спековская защёлка. Ты боишься, что юзерам будет не достать 30pin 4Mb SIMM? Это кстати, вполне возможно, т.к. такие симы редкость. Дык мож продублировать разводку под что-то более доставаемое?
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Суббота, 22.08.2020, 14:40 | Сообщение # 64 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Ты боишься, что юзерам будет не достать 30pin 4Mb SIMM? Это кстати, вполне возможно, т.к. такие симы редкость. Дык мож продублировать разводку под что-то более доставаемое?
Эту проблему я давно решил. Не нужно делать две разводки и изготавливать разные варианты платы. На плате стоит джампер XJ4 для выбора ёмкости устанавливаемого модуля памяти. Если пользователь смог достать 4-метровый SIMM, то джампер должен быть разомкнут. В этом случае старший регенерирующий разряд видеоконтроллера V2/G и парный для него сигнал A10 процессора подаются на MA10 модуля SIMM в качестве адреса регенерируемой строки. А если устанавливаться будет 1-метровый SIMM, тогда джампер нужно замкнуть, в этом режиме будут доступны A17', A18' и A19', а сигналы V2/G и A10 и перекоммутируются на MA9 модуля SIMM в качестве адреса столбца. Такая коммутация обеспечивает правильную регенерацию 1- и 4-метровых модулей памяти, она опробована на тех и других модулях и работает в моём реальном Спектруме на частоте памяти 7 МГц.
Любой пользователь, который юзая 1-метровый SIMM, внезапно смог достать 4-метровый, сможет не меняя плату, заменить модуль и всё что ему будет нужно, это разомкнуть джампер XJ4.
Сообщение отредактировал Northwood - Суббота, 22.08.2020, 14:58 |
| |
| |
| Black_Cat | Дата: Суббота, 22.08.2020, 15:12 | Сообщение # 65 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood ( ) Любой пользователь, который юзая 1-метровый SIMM, внезапно смог достать 4-метровый, сможет не меняя плату, заменить модуль и всё что ему будет нужно, это разомкнуть джампер XJ4.
Да, но ведь именно из-за 1Мб симов ты держишься за D5 #7FFD на A19', т.к. в режиме AllRAM AloneCoder'овский метр назначен на A21', и соответственно размазан по всем 4Мб, и на метровом симе не будет работать. И тут токо два выхода - либо сразу сказать, что AloneCoder'овский метр поддерживается исключительно при 4Мб, или дополнительно доразвести более доставаемую память.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Black_Cat | Дата: Воскресенье, 23.08.2020, 12:52 | Сообщение # 66 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Неправильно реализовано чтение D5 #7FFD, должно читаться не FD_A19, а непосредственное значение D5 #7FFD. Так же не пойму зачем у тя сделано чтоб при отключении ПЗУ включался D5 #7FFD на A19'. Отключение ПЗУ никаким боком логически не связано с включением D5 #7FFD на A19', эти функции абсолютно независимы. И я рассмотрел возможность использования D5 #7FFD на A19', а не на A21' в режиме AllRAM - принципиально это не противоречит концепции этого режима, хотя схемотехника усложняется, и по прежнему надо иметь ввиду, что это однозадачный режим, и по своей сути такая возможность это костыль позволяющий юзать несколько существующих софтов под AloneCoder'овский метр, так что ни в коем случае не рекомендуется поддерживать софтово этот AloneCoder'овский метр. Соответственно, схему у тебя надо изменить с учётом, что режим AllRAM хоть и включается в сетапе, но портом маски адреса, а не твоим портом:
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Black_Cat | Дата: Воскресенье, 23.08.2020, 16:14 | Сообщение # 67 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Или с заменой ЛИ1+ЛЛ1 на ЛИ3:
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Black_Cat | Дата: Понедельник, 24.08.2020, 02:37 | Сообщение # 68 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Формирователь P_FD/7FFD/ сделан не оптимально, в нём зачем-то используется P_0FFD/, хотя если использовать A15, то задержка сигнала будет меньше на 7нс. :)
Ниже более экономичная схема блокировки AY:
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Вторник, 25.08.2020, 09:23 | Сообщение # 69 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Ниже более экономичная схема блокировки AY:
Плохой вариант, мой намного лучше. Ты не учёл того, что в ИД7 задержка сигнала значительно больше, чем в простых логических элементах. Если на DD58 подавать сигнал ~P_DFFD, который сам задерживается своей ИД7 и приходит с задержкой около 28 нс, то при обращении к порту #DFFD на AY будут проникать ложные сигналы длительностью 28 нс, что может привести к глюкам. Мой вариант оптимален в том плане, что оба сигнала - обращения к AY и сигнал блокировки задерживаются дешифратором ИД7, более того, блокировка задерживается чуть меньше, что гарантировано исключает вероятность прохождения хоть какого-нибудь ложного сигнала выборки AY. А то что при обращении к AY сигнал задержится на 6-7 нс больше, это не принципиально. Тем более, что большинство музыкальных сопроцессоров сами по себе тормознутые устройства и для некоторых из них в турбо-режимах требуется WAIT-ить процессор.
Например:
Самые быстрые музыкальные сопроцессоры, это Yamaha YM2149F, они прекрасно работают без никакого WAIT-а при тактовой частоте процессора 14 МГц.
Музыкальные сопроцессоры средней тормознутости, это AY-3-8910/12 фирмы Microchip и карта TurboSound-FM. Они прекрасно работают без никакого WAIT-а при тактовой частоте процессора 7 МГц, но требуют WAIT на 14 МГц.
Самые тормознутые, это AY-3-8910 фирмы GI. Они вообще отказываются работать даже при тактовой частоте процессора 7 МГц, если не используется WAIT при обращении к ним.
Добавлено (25.08.2020, 11:27)
---------------------------------------------
Цитата Black_Cat ( ) Формирователь P_FD/7FFD/ сделан не оптимально, в нём зачем-то используется P_0FFD/, хотя если использовать A15, то задержка сигнала будет меньше на 7нс. :)
Нельзя просто заменить сигнал ~P_0FFD на A15. Во-первых, при обращении к порту #7FFD, проверка A15 на 0 обязательное условие в любых режимах. В режиме жёсткой дешифрации должна добавляться проверка A14 на 1, поэтому если менять, то не на A15, а на инвертированный A14. Но и это решение не заработает, потому что ещё в обязательном порядке нужно проверять состояние A1 (в моём случае так же и A2), ~IORQG и ~M1. Если просто заменить ~P_0FFD на инвертированный A14, то всех этих проверок не будет. Более того, схема по моему принципу давно работает и показала отличные результате в Турбо-14 МГц - все тесты памяти, запущенные в цикле на несколько суток, не зафиксировали ни единой ошибки.
Сообщение отредактировал Northwood - Вторник, 25.08.2020, 11:28 |
| |
| |
| Black_Cat | Дата: Вторник, 25.08.2020, 11:47 | Сообщение # 70 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood ( ) Ты не учёл того, что в ИД7 задержка сигнала значительно больше, чем в простых логических элементах.
Без проблем! :) Твоё утверждение верно, т.к. всё торможение идёт за счёт IORQG/, который приходит позже всех. Но! Ты юзаешь схему с замешиванием RD/WR в самом конце, чтоб они не тормозили собою дешифрацию, но при этом IORQG/ почему-то замешиваешь в самом начале, что нивелирует весь смысл замешивания RD/WR в конце, т.к. WR/ полюбому приходит раньше IORQG/. Вот если бы ты вместо RD/WR в конце замешивал IORD/IOWR, то это дало бы ускорение относительно твоей теперешней схемы 28-7=21нс. И вот в этом случае моя схема будет эффективней твоей и по экономичности, и по быстродействию :)
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Вторник, 25.08.2020, 13:57 | Сообщение # 71 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Так же не пойму зачем у тя сделано чтоб при отключении ПЗУ включался D5 #7FFD на A19'. Отключение ПЗУ никаким боком логически не связано с включением D5 #7FFD на A19', эти функции абсолютно независимы.
Дык, ты же сам написал:
Цитата Black_Cat ( ) функционально D4 #DFFD = D0 #1FFD. Правда D4=1 #DFFD попутно отключает так же блокировку D5 #7FFD. Но т.к. для D0 #1FFD сейчас никакого ПО не существует, то вполне допустимо и ему присвоить такую функцию в этом клоне. Т.е. предлагаю добавить в схему так же мультиплексор на триггер D4 #DFFD = D0 #1FFD с блокировкой D5 #7FFD.
Могу убрать отключение блокировки D5 #7FFD с помощью D4 #DFFD и #D0 #1FFD, оставив эту функцию только для AllRAM. Это даже упростит схему.
Или ты имел ввиду другое - D4 #DFFD отключает только саму блокировку D5 #7FFD, то не подключает на D5 расширение ОЗУ ?
Добавлено (25.08.2020, 14:21)
---------------------------------------------
Ещё раз про многозадачность:
При сохранении "свёрнутой" задачи, для регистров процессора требуется:
IY, IX, (HL, DE, BC, AF) *2, IR - 11 регистровых пар по 2 байта = 22 байта.
Плюс состояние портов #1FFD, #DFFD, #7FFD - 3 байта, плюс системный порт - 1 или 2 байта, в зависимости от реализации.
Итого, на 1 задачу уходит 22 + 3 + 1 = 26 байт.
Если ограничить максимальное количество задач = 4, отдавая каждой задаче по 1 МБ, тогда на все задачи понадобится 26 * 4 = 104 байта. У меня была идея всё это сохранять в CMOS, но HM6818A со своими 64 байтами, из которых для произвольного использования доступно только 50, однозначно в пролёте. Микросхема Dallas с памятью 128 байт, из которых для произвольного использования доступно 114 байт, даёт надежды, но я не помню, сколько мне потребовалось байт для сохранения всех настроек BIOS, 114 - 104 = 10 байт, на сколько мне помнится, этого мало.
Если говорить про большое количество задач, тогда в любом случае CMOS в пролёте и всё придётся сохранять в ОЗУ, а значит максимальное количество задач будет на 1 меньше.
Но у меня ещё есть статическое ОЗУ ёмкостью 64 КБайт. Я могу использовать его 0-ю страницу для данных свёрнутых задач, это снимет какие-либо ограничения и позволит самим задачам отдавать все 4 МБ ОЗУ, но в этом режиме станет недоступно эмуляция ПЗУ "Gluk Reset Service".
Добавлено (25.08.2020, 14:26)
---------------------------------------------
P.s. Мы забыли про состояние порта #EFF7. В отличии от состояния бордюра - порта #FE, который если не восстанавливать, это не будет катастрофой, то состояние порта #EFF7 восстанавливать нужно обязательно, иначе задачи, используемые расширенные видеорежимы, после возвращения к ним, перестанут правильно отображаться на экране.
Т.е. нужен ещё один порт на чтение, для чтения #EFF7. Но предлагаю читать его не весь, а минимально необходимые 5 бит:
D0 - 16 Colors;
D1 - 512x192;
D3 - RomRam;
D5 - Multicolor;
D6 - 384x304.
Бит D7 предлагаю игнорировать, при восстановлении задачи выставлять его в 0. Таким образом, у нас остаются 3 бита, через которые можно будет читать состояние бордюра.
Сообщение отредактировал Northwood - Вторник, 25.08.2020, 14:31 |
| |
| |
| Black_Cat | Дата: Вторник, 25.08.2020, 16:13 | Сообщение # 72 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood ( ) Дык, ты же сам написал:
Блокировка и A19' это две независимые переменные, которые при сохранении состояния портов пишутся в разные ячейки памяти. То, что по D5 #7FFD можно будет получить доступ к A19' помимо D5 #1FFD в режиме AllRAM - это исключение, которое оговорено правилами этого режима, где в частности указано, что спековской блокировки в этом режиме не существует. Таким образом исключаются непонятки с назначением D5 #7FFD.
Цитата Northwood ( ) Но у меня ещё есть статическое ОЗУ ёмкостью 64 КБайт. Я могу использовать его 0-ю страницу для данных свёрнутых задач, это снимет какие-либо ограничения и позволит самим задачам отдавать все 4 МБ ОЗУ, но в этом режиме станет недоступно эмуляция ПЗУ "Gluk Reset Service".
Да, кэш - это лучший вариант, но давай это обсуждать по очереди, когда закончим с менеджером и дешифрацией.
Цитата Northwood ( ) P.s. Мы забыли про состояние порта #EFF7
:) Я ничего не забыл, до всего дойдёт его очередь :) .Поверь, здесь везде - копать и копать :)
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Вторник, 25.08.2020, 16:50 | Сообщение # 73 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Ну не везде копать. Схему синхро-генератора, включая формирователи синхросиеси, INTа, WAITа, схему расширенных видеорежимов, менять я точно не буду. Это проверенные узлы, которые у меня не сразу заработали как надо, но котораые работают сейчас без глюков, и их без тестирования на реальном железе применять нельзя. Коммутацию адресов ОЗУ я тоже менять не буду.
|
| |
| |
| Black_Cat | Дата: Вторник, 25.08.2020, 17:47 | Сообщение # 74 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood ( ) Коммутацию адресов ОЗУ я тоже менять не буду.
С ОЗУ вопрос был токо про AloneCoder'овский метр, и мы вроде пришли к консенсусу, что D5 #7FFD подключается к A19', но токо в режиме AllRAM. Сам сигнал AllRAM пока подвесим в воздух, он у нас следующий на очереди.
Цитата Northwood ( ) схему расширенных видеорежимов, менять я точно не буду
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Среда, 26.08.2020, 09:35 | Сообщение # 75 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Или с заменой ЛИ1+ЛЛ1 на ЛИ3:
Эту версию изменений принял, от себя добавил только замену TM9, формирующий сигналы FD_A17, FD_A18, FD_A19 и RR_1FDF на TM8, чтобы сразу получить инверсную версию ~RR_1FDF без применения элемента DD51:6.
Сегодня ближе к вечеру смогу заняться исправлением чтения D5 #7FFD.
Сообщение отредактировал Northwood - Среда, 26.08.2020, 09:40 |
| |
| |
| Black_Cat | Дата: Среда, 26.08.2020, 11:22 | Сообщение # 76 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Давай пока небольшими итерациями менять токо схему, а переразводку делать кумулятивно в самом конце.
Есть вопросы:
1) зачем в BLK_HRAM замешивать RAM_48? Не могу уловить логическую связь между RAM_48 и блокировкой A14 в мультиплексорах данных.
2) зачем вообще нужен WR_PHRAM, если достаточно WR/ и для DD49 и для #1FFD? К слову, #1FFD ни в Скорпе, ни в КАЕ не блокируется по D5 #7FFD, как и #DFFD в Профи.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Среда, 26.08.2020, 12:38 | Сообщение # 77 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Потому что, блокировку D5 я понял как тотальную блокировку всей расширенной памяти >48 КБ. Поэтому я и замещал сигналы Ram48 для одновременной блокировки всех портов расширения. И отдельно можно заблокировать расширение только выше 128 КБ.
|
| |
| |
| Black_Cat | Дата: Среда, 26.08.2020, 15:42 | Сообщение # 78 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood ( ) Поэтому я и замещал сигналы Ram48 для одновременной блокировки всех портов расширения.
Нет, в наших клонах это так не работает, блокирутся токо #7FFD.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Среда, 26.08.2020, 15:47 | Сообщение # 79 |
|
80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Нет, в наших клонах это так не работает, блокирутся токо #7FFD.
OK
Добавлено (26.08.2020, 15:52)
---------------------------------------------
Кстати, случайно на схеме после одного из последних изменений вкралась ошибка - лишнее соединение двух разных цепей, которые соединены не должны быть. Выход DD64 ЛА2 и выход DD53:2 ЛИ1. Не обращай внимания, сейчас эту досадную ошибку исправлю. Это вышло случайно при перетаскивании элементов на схеме.
Добавлено (26.08.2020, 16:37)
---------------------------------------------
Цитата Black_Cat ( ) зачем вообще нужен WR_PHRAM, если достаточно WR/ и для DD49 и для #1FFD?
~WR_PHRAM нужен для того, чтобы блокировать порты расширения памяти >128 КБ во время выполнении короткой адресации к портам через OUT (#FD),A. Но т.к. нужно сделать одно исключение - доступ к D6 #7FFD через OUT (#FD),A, то для этого случая нужно сделать исключение. Но просто убрать сигнал ~WR_PHRAM на DD49 нельзя, потому что этот триггер начнёт срабатывать в качестве порта #1FFD или #DFFD (при программировании AY) при выполнении команды OUT (#FD),A.
P.s. эту задачу уже решил.
Сообщение отредактировал Northwood - Среда, 26.08.2020, 17:31 |
| |
| |
| Black_Cat | Дата: Среда, 26.08.2020, 21:03 | Сообщение # 80 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| На буфер DD67 должен идти IORQG/, иначе будет конфликт с платами расширения. И на DD55 строб забыл.
И к слову, BLK_HRAM правильней называть PA16 (порт адрес 16), т.к. фактически добавляет 256 адресов портов по out(nn),a сверх 64к доступных по out©,a :) , и может использоваться в дешифрации наравне с другими адресами :)
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
|
