Сообщение от goodboy
Да https://zx-pk.ru/threads/22237-vopro...l=1#post995859
Да https://zx-pk.ru/threads/22237-vopro...l=1#post995859
Скрытый текст
Profi v5.03/1024k/палитра/FDD3,5""/FDD5,25"/HDD/XT-Keyb/Covox
Pentagon-1024 sl v 1.4 upgrade #EFF7 Gluk RTC
ZXM-Phoenix 1024k
ATM Turbo 2+ v7.10 512k
HIMAC HR42.04 48K
HIMAC 128
Ленинград 1[свернуть]
Без SD карт отображается Splash, затем попытка найти и примонтировать SD карты и ошибка загрузки файла ESXDOS.SYS. Т.е. как на картинке ниже, которую я "нарисовал" взяв за основу нормальную загрузку DivMMC (лень доставать фотоаппарат, легче нарисовать).
- - - Добавлено - - -
На форуме есть один человек, который все это проделывал, но DivMMC так и не заработал. Не знаю как сейчас но, во всяком случае, в момент нашей последней беседы не заработал.
Последний раз редактировалось r3d; 10.11.2020 в 00:10.
valerium (10.11.2020)
Да, такую картинку получил, один раз...Картинку "нарисовал" на основе нормальной загрузки DivMMC.
- - - Добавлено - - -
На форуме есть один человек, который все это проделывал, но DivMMC так и не заработал. Не знаю как сейчас но, во всяком случае, в момент нашей последней беседы не заработал.
И всё опять виснетМного читал, и Z80 надо хороший
И ПЗУ фирменное... Куча неСовместимостей
Под "хорошим Z80" подразумевается наличие действующего /M1 и нормальный запуск с перегруженной другими входами линией CLK ?Да, такую картинку получил, один раз...
И всё опять виснет
И ПЗУ фирменное... Куча неСовместимостей
Запускаемся на штатной частоте 3,5мгц - тут все без бубна должно быть..
А на фотографиях того, что реально работает, вижу китайские перешлифованные "Zilog-и", которых уже и я несколько штук пробовал. Впрочем, у них у всех был живой /M1 и если запускались, то по остальному их поведению никаких отличий от NEC и русского 1858вм1 найти не сумел...
Чем отличается фирменное ПЗУ - имеется в виду прошивка или микросхема по быстродействию там другая ?
Пока из подтверждений работы divmmc на русских машинах я видел только этот пентагон в ролике выше - и речь, конечно, не про то, как в нем выключить BDI.
Накачал сейчас схемы разных испанских клонов на мелкоте, где есть divmmc, надо будет на досуге в них поглазеть, поискать отличия.
Неглубоко подумав могу только предположить элементную базу - например то, что наша 555/1533-я серия имеет какие-то резко иные задержки распространения и из-за этого фронты каких-нибудь сигналов выборки приходят "невовремя" для divmmc. Например, второе ПЗУ уже выбрано, а первое еще не успело отключиться (сам понимаю, что этот пример плохой, т к внутреннее ПЗУ отключается без участия внутренних цепей выборки).
Может еще какие идеи есть ?
В телеграмму нашёл людей: Пишут, что U880 как
у меня, работать не будет... А в ПЗУ точки входа могут
быть изменены
Про процессор - это странно, т к проблема коснулась бы всех клонов, ныне собираемых - плохие процессоры бы все были упомянуты в faq-ах и за столько лет divide/mmc мы бы про это услышали.В телеграмму нашёл людей: Пишут, что U880 как
у меня, работать не будет... А в ПЗУ точки входа могут
быть изменены
Про ПЗУ.. ну точек входа там всего несколько, некоторые неизменяемые (reset, im1, и т п), остальные можно проверить. Меня больше интересует 'зона выхода' - это адреса 1ffa-1fff, там должны быть nop-ы и ret, переход туда используется для возврата из пзушного кода esxdos в родное пзу. Их посмотрю на своих прошивках вечером.
Но ведь штатное ПЗУ 1982 года и не особо патчили, разве его сильно много версий ? А еще проще найти то пзу 48к, с которым это работает там, где работает, и прошить именно его.
Но есть одно маленькое НО: все новые арлекины и прочие клоны с divmmc ведь не имеют требований прошивать строго фирменное ПЗУ, на них работает все подряд. Или про это не так ?
Вот тема про недосовместимость 128го ПЗУ с div* и его особенности. Но про 48к там ничего нет.
А вот то, что выложено как "исходники ESXDOS 0.8.5", правда не авторские, а те же самые дизассемблированные, которые именуются "UnoDOS3" здесь, только без правок в названиях и копирайтах. И с теми же самыми комментариями.
Выложено камрадом Antonio Villena, однако внутри он упоминает, что авторство не его и автор-дизассемблер желает оставаться в тени.
https://sourceforge.net/p/emuscripto...AD/tree/esxdos
Что касается хороших и плохих процессоров
В том же форуме упоминается то, что divmmc+esxdos работает нормально на всех CMOS, и то, что оригинальные машины имели в основном (или все) процессоры NMOS. Только какие выводы делать - непонятно, ибо на оригиналах с NMOS, как мы знаем, все работает.
Не удержался и тестом, взятым из вышеупомянутого форума протестил имеющиеся дома процессоры на предмет CMOS/NMOS.
Это были: 1858ВМ1 в черном пластике, NEC (не запомнил всю маркировку) и 4 шт китайских "бритых" Zilog-а Z84С0020PEC (шлифованных) с алика.
Тест выглядит вот так,
Суть мне его непонятна - читаем "нечто" в аккумулятор из порта бордюра/магнитофона и пишем в тот же порт регистр флагов (в следующей итерации). Содержимое флагов почему-то будет разным в зависимости от считанного (?) на NMOS и CMOS процессорах.Код:di L001 ld bc,00feh out (c),f in a,(c) jr L001
Во всех случах кроме одного тест показал черный бордюр (NMOS), один китаец показал белый бордюр (CMOS) - внешне его корпус ничем не отличался от собратьев.
/M1 посмотрел просто тестером - при работе ни у одного из них не болтается в статичном состоянии и взлетает в единицу, близкую в +5в, если удерживать reset (осциллографом лезть поленился).
Ложка дегтя: кроме разного бордюра больше никакой разницы я не узрел, esxdos не работает совершенно одинаково на всем, что у меня есть, в т.ч на этом "как бы CMOS".
Последний раз редактировалось valerium; 12.11.2020 в 22:36.
Хорошие и плохие, скорее всего, имеется ввиду нагрузочная способность. И, по-моему, она выше именно у CMOS.
Потому что у фирменных шины не такие разветвленные как у наших клонов соответственно и нагрузка на шины CPU меньше.
P.S. У меня на Harlequin один или даже пара CPU, уже не помню, работают менее устойчиво и я предположил, что это именно из-за нагрузки на шины CPU (как известно Harlequin как и наши клоны сделан на рассыпухе). И эта неустойчивость в работе чаще переходящая в полную неработоспособность, причем уже на всех у меня имеющихся CPU, проявляется еще больше при использовании расширителя ZX шины (ZX Backplane).
Последний раз редактировалось r3d; 13.11.2020 в 01:36.
у тебя дизасм неправильный,
#ED71 ; это недокументированная команда out (c),0 !!!
на `новых` процах она пишет в порт #FF
...............
в коде divIDE/MMC именно эта команда не используется.
Последний раз редактировалось goodboy; 14.11.2020 в 22:58.
Эксперимент номер N (фиг его упомнит, какой). Все тот же Ленин и ремейк DivMMC на EPM7128.
Скачал на https://velesoft.speccy.cz/zx/divide/divide-soft.htm тестовую прошивку TESTROM3 в исполнении для ПЗУ DivIDE, размер 8К (живого кода там много меньше, конечно). Она прошивается в ПЗУ платы (в моем случае DivMMC, но я шил программатором) и позволяет по выбранной клавише запускать тесты памяти, а также tape tester (wtf? по факту он просто экран циклически красит-стирает), но самое ценное - по клавише 1 он должен переходить в штатное ПЗУ, коим я пока сделал basic48k - это живой пример map/unmap ROM, который я хотел понять и протеститить.
Ценность заключается в том, что возврат выполняется через перехватываемую логикой DivMMC "exit area" в адресах 1ff8-1fff, ниже опишу, как именно, но у меня этого НЕ ПРОИСХОДИТ. Сигнал ROMCS остается в единице, все снова возвращается тестовое ПЗУ в ожидание клавиши. Хотя вроде бы все условия выполняются.
Теперь для тех, кто любит головоломки, кусок этого самого теста:
(остальных прошу извинить, писанины много)
Теперь смотрим, что должно произойти с ROMCS (исходник CPLD Mario Prato, на котором все и основано)Код:;опрос клавиатуры 05b8 dbfe in a,(0feh) 05ba 2f cpl 05bb e61f and 1fh 05bd b3 or e 05be cb67 bit 4,a 05c0 c2ec05 jp nz,05ech 05c3 cb5f bit 3,a 05c5 c22006 jp nz,0620h 05c8 cb57 bit 2,a 05ca c25f06 jp nz,065fh 05cd cb4f bit 1,a 05cf c2a906 jp nz,06a9h 05d2 cb47 bit 0,a ;бит D0 05d4 c22f07 jp nz,072fh ;если он не 0, то нажата клавиша 1 (или Q,A,CS,0,P,Enter,Space) - переходим на возврат в штатное ПЗУ ... 072f 210040 ld hl,4000h ;готовим параметры дл LDIR, чтоб затереть память (зачем ее затирать ?) 0732 110140 ld de,4001h 0735 3e04 ld a,04h 0737 01fd1f ld bc,1ffdh ;пишем в порт конфигурации +3 страницу ПЗУ=1 073a ed79 out (c),a 073c 3e10 ld a,10h 073e 01fd7f ld bc,7ffdh ; и порт конфигурации 128к страницу ОЗУ=0, экран 0, ПЗУ=1 0741 ed79 out (c),a 0743 01ffbf ld bc,0bfffh 0746 75 ld (hl),l 0747 edb0 ldir ;выполняем-таки зачистку всех 48к ОЗУ 0749 f3 di ;запрещаем прерывания, чтоб не было перехода по IM1 074a 210100 ld hl,0001h ;подготавливаем в HL адрес перехода = 0001h 074d c3f91f jp 1ff9h ;переходим в exit area ... 1ff8 c9 ret 1ff9 e9 jp (hl) ;вот сюда мы переходим, отсюда читается 1-байтный опкод и сразу должен отключиться маппинг ПЗУ DivMMC 1ffa c7 rst 00h ;а поскольку переход выполняется не в адрес автоматического маппирования 0000, а в 0001, то это не ловится DivMMC 1ffb c7 rst 00h ;и должен выполняться штатный ROM48k 1ffc c7 rst 00h 1ffd c7 rst 00h 1ffe c7 rst 00h 1fff c7 rst 00h
Только в причинно-следственном порядке, а не так, как положено в VHDL:
То есть все условия для сброса romcs в 0 вроде бы есть, а он не сбрасывается.Код:process(divideio,poweron) begin if poweron ='0' then -- по включению bank <= "000000"; mapram <= '0'; -- сбрасываются в 0 conmem и mapram conmem <= '0'; elsif rising_edge(divideio) then bank(5 downto 0) <= D(5 downto 0); mapram <= D(6) or mapram; conmem <= D(7); end if; end process; -- условие входа в exit area map1F00 <= '0' when A(15 downto 3) = "0001111111111" else '1'; -- 1ff8 - 1fff -- линия ROMCS формируется по выражению ниже, я подписал значения подусловий для ситуации, если перемычка EPROM установлена (штатный режим, eprom=0) romcs <= '1' when ((automap and not eprom) or (automap and mapram) or conmem )='1' else '0' ; -- ? =1 =0 =0 -- после сброса ничего не менялось в регистре конфигурации DivMMC: -- conmem=0, mapram=0 и перемычка стоит (not eprom)=0, в итоге все зависит от automap -- а automap формируется вот тут: process(mreq) begin if falling_edge(mreq) then if m1='0' then -- ***** -- условие маппирования памяти mapcond складывается из условий -- входа в адрес перехвата mapterm (0000h, 0008h, 0038h и т д) в нашем случаен =0 и когда идем в exit area, и когда переходим в 0001h -- входа в зону адресов триггера TRDOS (в нашем случае =0) -- входа в exit area 1fxx и своего прошлого состояние -- у нас при входе в exit area mapcond сбросится, т к в этой зоне map1F00 будет =0 mapcond <= mapterm or map3DXX or (mapcond and map1F00); -- вместе с ним должен сброситься в 0 и automap, т.е. условие зоны TRDOS =0 automap <= mapcond or map3DXX; -- а вместе с ним должен обнулиться и ROMCS (смю выше), т к automap был единственным меняющимся условием end if; end if; end process;
А меняться составляющий его automap должен по спаду mreq и m1=0 (выше отмечено *****)
То, что /MREQ работает корректно, я не сомневаюсь.
Тогда что, все пакостит /M1 ?????
Сигнал на линии /M1 процессора вроде есть. Тестил на NEC D780C, 1858ВМ1 и китайских Zilog-ах.
У меня есть только аналоговый осциллограф и нет анализатора, поэтому для проверки запустил вечный цикл вида
L0001 JR L0001
и посмотрел 27-ю ногу процессора
Амплитуда около 3в, период где-то 3,5 мкс, длительность 0,6 мкс. Это 1858ВМ1.
Может ли это быть недостаточно живым поведением /M1 ?
И если кто-то дочитал это до конца (или может разбирал работу DivMMC/DivIDE раньше) - респект уже за это ))) - ткните носом, куда копать дальше?
Последний раз редактировалось valerium; 14.11.2020 в 22:36.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием