|
Pentagon by Northwood
|
|
| Black_Cat | Дата: Среда, 01.07.2020, 16:12 | Сообщение # 1 |
 Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| 1. Сигналы DOS/, IODOS/ для NemoBus v.1.2
Цепи DOS/, DOS на выходе DD29 идущие на дешифрацию портов разорвать, и в разрыв врезать схему. Цепи, идущие на выборку ПЗУ оставить как есть.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Black_Cat | Дата: Четверг, 26.11.2020, 02:16 | Сообщение # 261 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата Northwood (  ) Бррр, этого в моём Спектруме не будет категорически, я уже объяснял, почему. Зачем тормозить абсолютно все порты, когда можно не тормозить, к примеру, жёсткий диск и получить максимум скорости чтения и записи ? Зачем тормозить порты переключения памяти ? Даже вейт для AY в Турбо-режимах я сделал опционально, потому что одни модели AY прекрасно работают в Турбо-режимах без вейта, другие нет. И поэтому я ввёл элементы DD107 (ЛА2) и DD108.2 (ЛН1), чтобы вейтить только выбранные порты, которые действительно в этом нуждаются.
О каком торможении ты говоришь мне не понятно. У тебя во всех сигналах на входе ЛА2 был замешан IORQG/, я убал IORQG/ из некоторых для убыстрения оных, и подмешал его в этом узле. В результате, генерация вейта какой у тебя была, такой и осталась, за исключением исправленной твоей ошибки с вейтом на #DFFD.
Цитата Northwood ( ) Но лучше всего, перед тем как делать это упрощение, проверить это на практике, не будут ли портиться данные на HDD, особенно в случае нестабильной ШД.
Даже странно читать такое. На NemoIDE постоянно и непрерывно генерятся HCS0/ HCS1/, т.к. это адресные линии, и абсолютно не важно что там на шине данных - в Z-состоянии там тем более хрен знает что творится. И конкретно, по заявлению, что надо всё проверять паяльником :) . Такое говорят только ламеры, ибо это ламеры проверяют паяльником, а специалисты паяльником токо подтверждают свои расчёты. Разница между специалистом и ламером в том, что первый, в отличие от второго знает какой должен быть результат. Если "специалист" не понимает какой ожидается результат, то какой же это специалист? Так что будь аккуратней в выражениях, и не уподобляйся некоторым общим знакомым с zx.pk :) .
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Northwood | Дата: Четверг, 26.11.2020, 03:14 | Сообщение # 262 |
 80h
Группа: Пользователи
Сообщений: 131
Статус: Offline
| Цитата Black_Cat ( ) Даже странно читать такое. На NemoIDE постоянно и непрерывно генерятся HCS0/ HCS1/, т.к. это адресные линии, и абсолютно не важно что там на шине данных - в Z-состоянии там тем более хрен знает что творится. И конкретно, по заявлению, что надо всё проверять паяльником :) . Такое говорят только ламеры, ибо это ламеры проверяют паяльником, а специалисты паяльником токо подтверждают свои расчёты. Разница между специалистом и ламером в том, что первый, в отличие от второго знает какой должен быть результат. Если "специалист" не понимает какой ожидается результат, то какой же это специалист? Так что будь аккуратней в выражениях, и не уподобляйся некоторым общим знакомым с zx.pk :)
А ты поаккуратнее с ярлыками. Если ты всем несогласным направо и налево раздаёшь ярлыки "ламер", то не удивительно, что тебя забанили везде где только можно.
А теперь внимательно смотри оригинальную схему NemoIDE:
На первый ИД7, который ты заменил на ЛЛ1, на прямой разрешающий вход подаётся сигнал ~M1, который запрещает выходы ИД7 в цикле подтверждёния прерываний, устанавливая на всех выходах уровень 1, с одного из выходов берётся сигнал ~EBL. Неактивный сигнал ~EBL запрещает выходы АП6 и второй половинки АП5, переведя их в 3-е состояние, что блокирует прохождение ~CS0 и ~CS1 на IDE. Правда, эти сигналы проходят на IDE при обращении к ОЗУ в циклах чтения и записи данных и в цикле регенерации ОЗУ, которые генерирует процессор, а так же в циклах прямого доступа к ОЗУ картой расширения. Однако, сигналы чтения и записи на IDE не проходят, пока не будет выставлен активный сигнал ~IORQG.
Не смотря ни на что, будь у тебя 7 пядей во лбу, будь ты хоть ты 300 раз уверен,что схема будет работать как надо, схему критического узла без проверки на практике, нельзя выпускать в продакшн, потому что подводных камней ты можешь и не заметить независимо от звания "специалист", а ошибки с HDD могут обернуться безвозвратной потерей ценных данных, за что можно от пользователей получить по голове.
По-хорошему, проверять перед выпуском нужно абсолютно всё, но ввиду ограниченных ресурсов, это невозможно, но критические узлы проверить можно и крайне необходимо.
|
| |
| |
| Black_Cat | Дата: Четверг, 26.11.2020, 03:16 | Сообщение # 263 |
|
Координатор
Группа: Координаторы
Сообщений: 730
Статус: Offline
| Цитата И ты неверно используешь сигнал ~BUSAK. Это сигнал от процессора, который является подтверждением захвата шины в ответ за запрос по линии ~BUSRQ. Мы можем использовать сигнал ~BUSAK, формируемый процессором, но никто, кроме процессора, не имеет права выставлять туда свой сигнал, в том числе карта расширения. Поэтому назначение диода VD18 и резистора R9 остаётся загадкой.
:) Ну, на счёт неверно - это очень смелая заявка :) . Я бы скорее согласился с тем, что ты просто ленишься думать и читать мануалы, что более соответствует истине :) . Ты изначально использовал резисторы для развязки адресов с менеджера памяти от адресов с шины NemoBus, а я здесь показал тебе как это делается правильно, т.е. в соответствии с тем, как указано в мануале на NemoBus :) . Устройство, которое хочет подменить штатный менеджер памяти своим, без захвата шины, проверяет нет ли запроса на захват шины BUSRQ/, и если его нет, то обнуляет BUSAK/, тем самым переводя мультиплексоры менеджера памяти в Z-состояние, и выставляя на шину свои адреса. Таким образом, мультиплексоры своими выходами подключены к шине напрямую без резисторов, а резисторы тоже используются, но дальше - в схеме маскирования, развязывая адреса менеджеров памяти от адресов АВМ.
Добавлено (26.11.2020, 05:11)
---------------------------------------------
Цитата Northwood ( ) А ты поаккуратнее с ярлыками. Если ты всем несогласным направо и налево раздаёшь ярлыки "ламер", то не удивительно, что тебя забанили везде где только можно.
Я дал чёткое логическое определение отличия специалиста от ламера :) . Специалист, как и любой человек тоже имеет право ошибаться, но в отличие от ламера, он не имеет права не знать что он ожидает получить, иначе он не специалист. Ты не задумываясь повторил чушь, которой оправдывают свою безграмотность ламеры с zx.pk, а я тебя поправил на будущее. Ведь в этом и состоит моя задача как концептолога - помочь с нахождением ошибок. ВСЕХ! встреченных ошибок, которые могут помешать успешному результату. :) Здесь нет никакого оскорбления, только логика и констатация фактов.
А на счёт "забанели" - так это просто от бессилия этих людей противопоставить своё скудоумие, представленным мною логике и фактам :) . Если противостоять интеллектуально не позволяет скудоумие, то только и остаётся что банить :)
Цитата Northwood ( ) Неактивный сигнал ~EBL запрещает выходы АП6 и второй половинки АП5, переведя их в 3-е состояние, что блокирует прохождение ~CS0 и ~CS1 на IDE. Правда, эти сигналы проходят на IDE при обращении к ОЗУ в циклах чтения и записи данных и в цикле регенерации ОЗУ, которые генерирует процессор, а так же в циклах прямого доступа к ОЗУ картой расширения.
:) Ага, а ещё при обращении к куче других портов, т.е. при всех возможных случаях на шине :). И не смотря на то, что во всех этих случаях генерятся HCS0/ HCS1/, при отсутствии IOR/, IOW/ ни к каким "потерям данных" это не привело :) . Кароче, ты не смог аргументированно доказать возможность "потери данных" каким либо способом, т.е. высказанные тобою опасения беспочвенны и противоречат фактам :) .
Добавлено (26.11.2020, 06:02)
---------------------------------------------
Цитата Northwood ( ) У тебя при выставлении активного бита маски АВМ, соответствующий выход ЛП8 подключается к линии MEM_xx, которая идёт на слот NemoBUS
Твоя невнимательность :) , на шину NemoBus идут другие сигналы: *A14'-*A22'. Так что никаких ошибок там нет :) .
Добавлено (26.11.2020, 06:29)
---------------------------------------------
Цитата Northwood ( ) Этого не будет. Я не хочу разбивать память менее чем по 128 КБ
Я прелагаю тебе задаром, т.е. без увеличения количества корпусов, полноценный менеджер АВМ, а ты цепляешься за свой неполноценный костыльный. В чём логика?
Добавлено (30.11.2020, 05:55)
---------------------------------------------
Да, кстати, на счёт свободного места в ПЗУ. Точка входа включения ПЗУ Lprint III в ПЗУ SOS48 находится по адресу #0F0C. В ПЗУ SOS48 это подпрограмма обнаружения подключения принтера. По этому адресу находится команда in a,(#fb) подключающая ПЗУ Lprint III. Соответственно, этот адрес точки входа идентичен для обоих ПЗУ, как Lprint III, так и ПЗУ SOS48. Т.е. 2k ПЗУ Lprint III замещают собою область #0800-#0fff ПЗУ SOS48. Таким образом у тя в ПЗУ остаётся целых 14k свободного места в диапазонах адресов #0000-#07ff, и #1000-#3fff :) .Добавлено (03.12.2020, 11:24)
---------------------------------------------
Ты доку по управлению SRAM и ROM не начинал писать? Хотелось бы формализовать что у тебя в какой странице, и какая логика работы всего этого. А то намутил ты слишком много своего специфического, шо без тебя не разобраться по быстрому, да и доку всё равно рано или поздно писать придёцца.
"Трудно найти чёрную кошку в тёмной комнате.. ...особенно, если её там нет", "Forever!".
"Я никогда не причиняю им зла. Я говорю им правду, и они думают, что это - зло."
Гарри Трумэн
|
| |
| |
| Hazar | Дата: Четверг, 31.12.2020, 11:56 | Сообщение # 264 |
 80h
Группа: Пользователи
Сообщений: 231
Статус: Offline
| Вот пытался осилить всю тему, не совсем понятно почему такая страсть все делать на мелкой логике .
Ну да ладно как мне видится корень проблемы не сколько как, какие порты использовать или там какие биты портов куда
заводить и в каком порядке мультиплексировать, а главная проблема рассматриваемого (менеджера памяти ) не в самом его
логическом исполнении а в страничном построении памяти (сам страничный метод не выгодно использовать при большом
количестве страниц ) .
То есть нужно искать решение как сохранить программную совместимость ( C Spectrum 128. 256. 1024) в исполнении
линейной памяти ( как показал опыт использования страничной памяти на IBM PC c последующим отказом в пользу линейной памяти)
Сравните длину и сложность кода менеджеров памяти (файлы EMM386.exe и Hi mem .sys )
Добавлено (31.12.2020, 12:04)
---------------------------------------------
Сейчас мне трудно представить как такое решение бы выглядело на мелкой логике, а вот при использовании
обычного \ых\ двоичного шифратора управляемого логикой ( то схема коммутирования банков памяти, логических страниц)
стала бы намного проще. Такое решение оптимально еще и потому что работающим программам и процессору не важно
логическое расположение кода программы ( то есть не важно в каком номере сегмента находится исполнимый код). Нужно
лишь обеспечить одинаковую логику менеджера (для записи и чтения) при этом номер логической страницы может быть любымДобавлено (01.01.2021, 12:01)
---------------------------------------------
шифратор применение
https://youtu.be/mDhHgKF835E
https://youtu.be/XJ5tRIhYETw
Spectrum жив в нашей душе навсегда
Сообщение отредактировал Hazar - Четверг, 31.12.2020, 12:53 |
| |
| |
|
