Цитата:
Сообщение от goodboy
Да https://zx-pk.ru/threads/22237-vopro...l=1#post995859
Вид для печати
Цитата:
Сообщение от goodboy
Да https://zx-pk.ru/threads/22237-vopro...l=1#post995859
Без SD карт отображается Splash, затем попытка найти и примонтировать SD карты и ошибка загрузки файла ESXDOS.SYS. Т.е. как на картинке ниже, которую я "нарисовал" взяв за основу нормальную загрузку DivMMC (лень доставать фотоаппарат, легче нарисовать).Цитата:
Сообщение от valerium
https://pic.maxiol.com/thumbs2/16049...dosload02s.jpg
- - - Добавлено - - -
На форуме есть один человек, который все это проделывал, но DivMMC так и не заработал. Не знаю как сейчас но, во всяком случае, в момент нашей последней беседы не заработал.Цитата:
Сообщение от goodboy
Да, такую картинку получил, один раз...Цитата:
Сообщение от r3d
И всё опять виснет:( Много читал, и Z80 надо хороший
И ПЗУ фирменное... Куча неСовместимостей:((
Под "хорошим Z80" подразумевается наличие действующего /M1 и нормальный запуск с перегруженной другими входами линией CLK ?Цитата:
Сообщение от Котя
Запускаемся на штатной частоте 3,5мгц - тут все без бубна должно быть..
А на фотографиях того, что реально работает, вижу китайские перешлифованные "Zilog-и", которых уже и я несколько штук пробовал. Впрочем, у них у всех был живой /M1 и если запускались, то по остальному их поведению никаких отличий от NEC и русского 1858вм1 найти не сумел...
Чем отличается фирменное ПЗУ - имеется в виду прошивка или микросхема по быстродействию там другая ?
Пока из подтверждений работы divmmc на русских машинах я видел только этот пентагон в ролике выше - и речь, конечно, не про то, как в нем выключить BDI.
Накачал сейчас схемы разных испанских клонов на мелкоте, где есть divmmc, надо будет на досуге в них поглазеть, поискать отличия.
Неглубоко подумав могу только предположить элементную базу - например то, что наша 555/1533-я серия имеет какие-то резко иные задержки распространения и из-за этого фронты каких-нибудь сигналов выборки приходят "невовремя" для divmmc. Например, второе ПЗУ уже выбрано, а первое еще не успело отключиться (сам понимаю, что этот пример плохой, т к внутреннее ПЗУ отключается без участия внутренних цепей выборки).
Может еще какие идеи есть ?
В телеграмму нашёл людей: Пишут, что U880 какЦитата:
Сообщение от valerium
у меня, работать не будет... А в ПЗУ точки входа могут
быть изменены:( Надо пересчитывать коды...
Про процессор - это странно, т к проблема коснулась бы всех клонов, ныне собираемых - плохие процессоры бы все были упомянуты в faq-ах и за столько лет divide/mmc мы бы про это услышали.Цитата:
Сообщение от Котя
Про ПЗУ.. ну точек входа там всего несколько, некоторые неизменяемые (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".
Хорошие и плохие, скорее всего, имеется ввиду нагрузочная способность. И, по-моему, она выше именно у CMOS.Цитата:
Сообщение от valerium
Потому что у фирменных шины не такие разветвленные как у наших клонов соответственно и нагрузка на шины CPU меньше.Цитата:
Сообщение от valerium
P.S. У меня на Harlequin один или даже пара CPU, уже не помню, работают менее устойчиво и я предположил, что это именно из-за нагрузки на шины CPU (как известно Harlequin как и наши клоны сделан на рассыпухе). И эта неустойчивость в работе чаще переходящая в полную неработоспособность, причем уже на всех у меня имеющихся CPU, проявляется еще больше при использовании расширителя ZX шины (ZX Backplane).
у тебя дизасм неправильный,Цитата:
Сообщение от valerium
#ED71 ; это недокументированная команда out (c),0 !!!
на `новых` процах она пишет в порт #FF
...............
в коде divIDE/MMC именно эта команда не используется.
Эксперимент номер 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-ю ногу процессора
Вложение 73928Вложение 73929
Амплитуда около 3в, период где-то 3,5 мкс, длительность 0,6 мкс. Это 1858ВМ1.
Может ли это быть недостаточно живым поведением /M1 ?
И если кто-то дочитал это до конца (или может разбирал работу DivMMC/DivIDE раньше) - респект уже за это ))) - ткните носом, куда копать дальше?
Файл testrom3_8kb_for_divide.romЦитата:
Сообщение от valerium
Я только только изучаю, но пришла мысль
заменить в прошивке второй (00 01 02 .. или 1,2,3 третий) байт с #F9 на #FA
00.C3.F9.1F.FF.FF
00.C3.FA.1F.FF.FF.....
Возможно я вообще ничего не понимаю, но мысль пришла такая (возможно я дико ошибаюсь)
- - - Добавлено - - -
Вот этот момент не очень понятенЦитата:
Сообщение от valerium
где же храниться , на какой адрес он указывает рег. SP ?
* ну это просто мысли вслух
В смысле сменить точку перехода в exit area на 1FFA, про это речь ?Цитата:
Сообщение от USERHOME
Тогда при переходе по этому адресу по идее отключится ПЗУ DivMMC, но там выполнится RST 0 и это приведет к переходу по адресу 0000, на который опять сработает ловушка для automap и внешнее ПЗУ тут же включится обратно.Код: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
Суть хитрости, сделанной здесь - в том, чтоб зайти в штатное ПЗУ не с 0000, а с 0001.
Собственно, переход-то в этой тестовой прошивке написан правильно (иначе б не был выпущен релиз), вопрос в том, где у меня железо не соответствует ))
А здесь нам SP уже не важен. К этому моменту нет ни одного незавершенного вызова, из которого надо RET-ом вернуться по адресу в стеке. Дальше выполняется LDIR (и ему не нужен стек), а потом просто JP. Поэтому ни стек, ни указатель стека уже не будут использоваться до инициализации штатного ROM.Цитата:
Сообщение от USERHOME
Попробуйте туда записатьЦитата:
Сообщение от valerium
NOP
JP 0001 (вместо RST)
- - - Добавлено - - -
Либо PUSH HLЦитата:
Сообщение от valerium
и RET (но это испортит ячейки памяти, но для теста можно)
- - - Добавлено - - -
Какой нибудь сигнал WAIT для Z80 ....Цитата:
Сообщение от valerium
Это не пройдет. Суть этого перехода в выполнении однобайтной команды из области выхода (exit area).Цитата:
Сообщение от USERHOME
jp (hl) - однобайтный, операндов у опкода нету, поэтому как только он считывается, ПЗУ переключается и процессор независимо от содержимого памяти отрабатывает jp - ставит IP равным HL, где у нас заготовлен адрес перехода 0001.
Если так сделать, то как только будет из памяти по адресу 1ffa выбран NOP, должна смениться страница ПЗУ и следующая команда будет выбираться по адресу 1ffb уже из штатного ПЗУ. Да, интересно проверить, произойдет ли это, но мы это вряд ли успеем увидеть, т к непонтно, куда нас там в штатном ROM48 занесет
В Ленине WAIT-ом удлиняются обращения к ОЗУ выше адреса 4000h, а при работе с памятью DivMMC в нижних адресах и всеми адресами перехвата триггер D9.1 не будет защелкиваться (A14=A15=0). Так что по идее тоже не должно никак влиять.Цитата:
Какой нибудь сигнал WAIT для Z80 ....
Но вот тоже подозреваю, что мешает побочный эффект в схемотехнических решениях Ленина (задержка распространения какого-то промежуточного сигнала, например). Периодически и возвращаюсь к этому поиску.
Попробуйте установить принудительно SP меньше #4000 и проверитьЦитата:
Сообщение от valerium
Не доходит до меня никак.Цитата:
Сообщение от USERHOME
Перенести стек ниже 4000h (и выше 1fff, там в это время страница озу DivMMC), засунуть на вершину стека адрес возврата 0001, потом выполнить переход на 1ff8, где у нас ret ? Так сразу после выборки из памяти этого ret должна переключиться страница ОЗУ divmmc на штатное ПЗУ. И если все отработает правильно, то sp будет смотреть куда-то в ПЗУ rom48, а что вынется из стека, как адрес перехода - неизвестно (какие-то 2 байта штатного ПЗУ). Ну только если оно зависнет или сбросится с другими спецэффектами.. допустим, а какой из этого вывод?
действительно похоже на перевод.Цитата:
Сообщение от valerium
вот ещё один вариант
"Memory mapping could be invoked manually (by setting CONMEM), or automatically
(CPU has fetched opcode form an entry-point). Automatic mapping is active
only if EPROM/EEPROM is present (jumper EPROM is closed) or bit MAPRAM is set.
Automatic mapping occurs at the begining of refresh cycle after fetching
opcodes (M1 cycle) from 0000h, 0008h, 0038h, 0066h, 04c6h and 0562h. It's
also mapped instantly (100ns after /MREQ of that fetch is falling down) after
executing opcode from area 3d00..3dffh. Memory is automatically disconnected in
refresh cycle of the instruction fetch from so called off-area, which is
1ff8-1fffh.
The one-instruction delay could be used to distinguish between nested calls to
the same place. For such trick you will place different instruction at the
entrypoint address, than is in original ZX ROM. So the first call wil execute
original instruction, but subsequent one will jump to another code, because
divIDE memory was already mapped, with its changed opcode. It's great for 100%
avoidance of nested NMI, which cannot be implemented using pure combinatorial
hardware workaround. It allows divIDE to use INT for timing, when divIDE code is
performed (external calls will map later divIDE off and continue in #38h
original service, but nested INTs can jump to another work, and mapping off is
of course undesirable there)."
небольшие отличия от текста в посту№68 есть
ROM48 установит стек в нужное положение, если запретить прерывание (как раз DI в 0000 адресе) и переход будет на адрес 0001Цитата:
Сообщение от valerium
DI никакого отношения к стеку не имеет.Цитата:
Сообщение от USERHOME
ROM48 заведет стек в нужном ему положении ПОСЛЕ того, как начнет исполняться с адреса 0001. А чтобы он вообще начал это делать, надо ДО этого осуществить переход по этому адресу, если это делать через стек в адресах 2000-4000, то в том месте, куда мы записали адрес перехода 0001 сразу после выборки из памяти опкода ret (но еще до собственно перехода) окажется совсем другая память, это будет само ПЗУ48. И вместо адреса 0001 у нас ддя перехода из стека вынется какой-то мусор и по нему произойдет переход вместо 0001. Короче, сломается все.
Я про это не говорилЦитата:
Сообщение от valerium
Есть DI , есть HL,1, есть переход на 0001
(DI находится по 0000 в ROM48, 2 раза DI не надо конечно же)
Если Вы сделали ранее (а в ROM IDE есть) DI то смело можно переходить на 0001, вот о чём речь
и попробовать изменить пару байт в ROM IDE тоже никто не мешает, а заодно и проверить результат
1. SP (где-то вместо LDIR)
2. NOP (дополнительный холостой цикл) и JP (HL)
3. SP на RAM и PUSH HL (без зануления памяти LDIR) и RET
4. censored Я бы ещё и LD A,1 и OUT (254), A (Шину адреса "пошевелить" для теста, перед JP (HL) ...)
Что-то не сумел я понять, что при этом должно получиться ((Цитата:
Сообщение от USERHOME
Сам тест не использует ОЗУ и не использует стек для своей работы. Для его работы менять указатель стека бессмысленно, а при переходе в ROM48 он все равно будет установлен туда, куда его инитит ROM48. Для перехода к адресу 0001 использовать стек тоже нет смысла, т к для адресов ниже 4000h надо исхитряться с подстановкой в адреса импровизированного стека в ROM48 нужной константы, а адрес перехода можно передать в регистре HL и переход выполнить однобайтной операцией jp (HL).
Я пока добился следующего: раз прерывания запрещены, то я HALTом попробовал сделать импровизированные брейкпойнты - ставил HALT по адресу 0001 в ROM48 при неизменном тесте testrom3 (ничего не изменилось - страница ROM48 не включалась и проц на эту инструкцию не попадал), а также в exit area в ПЗУ divmmc по адресу 1FFA, куда мы попадаем по нажатию клавиши 1 - по идее после чтения этого опкода должно измениться значение automap на 0 и должен переключиться romcs из 1 в 0 для включения штатного ПЗУ. Эта точка останова работала, но romcs остается единичным.
Либо все-таки /M1 не работает как надо, либо криво отрабатывает условие формирования romcs. Пока копаюсь дальше.
Добился.
Был досадный косяк в (недо)пайке линии A11 на ПЛИС, при том, что всей на памяти она была заведена и каким-то чудом даже тесты ОЗУ проходили.
Но из-за нее не отрабатывало условие для exit area:
А все остальные идеи с /M1 оказались глупостями.Код:map1F00 <= '0' when A(15 downto 3) = "0001111111111" else '1';
-- ^
Ну зато научился и опробовал способ все это дебажить при помощи доп.индикации и тестовой кнопки, добавляя описание обработки нужных линий (vhdl).
Сейчас управление страницами памяти работает нормально - входы в ПЗУ divmmc через зоны automap и выходы через exit area, причем даже на Ленине.
Помимо этого мне удалось добыть вторую 7128 и запустить одновременно Sizif-128 - припаял zxbus и подключался в т.ч. к нему, теперь будет, на чем сравнить.
Разумеется, нижний ПЗУшный кусок esxdos при старте после сплэша не находит карту с хвостом esxdos (файл esxdos.sys), т.к. карта еще пока не подключена - это вопрос грядущих выходных.
Запустил, однако.
На Ленине. Причем только на Ленине, а на Sizif128, где вчера я видел сплэш ESXDOS, почему-то нет даже его - возможно из-за того, что версию 0.8.5 сменил на 0.8.8.
Тактовую подавал напрямую с 6 ноги процессора прямо на вход ПЛИС без триггеров шмидта и других формирователей, прошивка ПЛИС сейчас от Mario Prato без каких-либо изменений, только пересобранная под EPM7128.
Вложение 73989Вложение 73987Вложение 73988
Попробую потом еще поиграть с автономным генератором, вроде как такое возможно.
Схемы толком нету, надо будет ее отрисовать по-человечьи - если вдруг кто заинтересуется или захочет довести до ума.
Все было совсем не так. Версия ESXDOS не имела значения, а повлияло то, что кроме него я свою дебаговую прошивку CPLD сменил на "некопанную" первоначальную.Цитата:
Сообщение от valerium
Сейчас нормально пускается и на ленине, и на sizif128, и даже на втором ленине (который Веста).
Поэтому пришлось в первоначальную прошивку CPLD внести одну незначительную, как я вначале думал, правку.
Это проверка уровня сброса (/RESET) и при его активности - обнуление конфигурационного регистра divmmc.
Что это и зачем это.Код:...
process(divideio,poweron)
begin
-- if poweron ='0' then -- исходно было вот так
if poweron ='0' or reset = '0' then -- тут добавил условие проверки уровня reset
bank <= "000000";
mapram <= '0';
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;
...
У DivIDE, а значит и у DivMMC есть бит mapram в конфигурационном регистре (порт E3h), он отвечает за маппирование третьей страницы ОЗУ DivMMC в качестве подмены его ПЗУ. При включении питания, пока poweron активен (кондер заряжается), все биты конфигурации обнуляются и включается страница ПЗУ, где у нас esxdos, например. Но можно в третью страницу ОЗУ загрузить нечто альтернативное и использовать это вместо ПЗУ - но эту настройку (mapram=1) изменить нельзя до выключения, т.к. сброс mapram в 0 возможен только по активности poweron. Сделано видимо для того, чтобы подмена ПЗУ (друга версия esxdos, например), давала стартовать себя при нажатии сброса и не слетала обратно на ПЗУ.
Теперь пытаюсь разобраться, почему в некоторых случаях это криво работает.
По какой-то причине не отрабатывает условие сброса по poweron=0, а когда стартует процессор, у нас в регистре конфигурации находится мусор и включена непонятна какая страница ПЗУ/ОЗУ. Спек рисует зюки и не стартует.
Импульс /RESET в спеке заметно длиннее poweron в DivMMC (формируются RC-цепочками) - при примерно одинаковом R у нас C отличается на 3 порядка (10 нф в DivMMC и ~10мкф в обычных схемах сброса спека). Возможно, что нужно было удлинить poweron.
В исправленном варианте прошивки CPLD сброс регистра конфигурации DivMMC сбрасывается при активном /RESET и к старту DivMMC включается нужная страница ПЗУ. Теперь при этом нельзя залить ОЗУ DivMMC подмененным кодом и поставить его вместо ПЗУ на сброс - но я не могу придумать, зачем мне такое было бы нужно применить. Поэтому пока потестирую этот костыль.
Не исключено что причина распространенного незапуска divmmc на русских клонах именно в этом.
Я потом попробую поправить прошивку в xilinx-версии платы, которую раньше так и не смог запустить, не исключено, что и она заработает.
Еще один эксперимент - вместо процессорного CLK на CPLD подавал 4МГц с отдельного генератора. DivMMC работает, карта читается. Так что в той статье на Tynemouth (этот пост, правда ссылка там, кажется, уже неактуальна) была правда - можно использовать отдельный генератор на 3,9-4,2Мгц.
Так что для работы divmmc вместо всех доделок по коррекции штатного CLK можно просто собрать генератор на трех TTL-инверторах. На 4,0Мгц проверил.
Дошли руки до схемы, подсобрал все в архив с исходниками.
Вложение 74047
Добрый день. Рад, что у вас все получилось. Я тоже решил вернуться к запуску DivMMC (nanoSD от Павла на Xilinx) на своем ленине-2. Подправил код, как вы рекомендовали (добавил условие по reset и добавил этот сигнал в процесс в список чувствительности вместе с сигналами divideio,poweron). Ну и .... никаких изменений, как был матрас или мусор, так и остался. У меня вопрос, будет ли работать DivMMC без сигнала CLK? И можно ли вместо ПЗУ с Exdos поставить, к примеру тест 128 Ханонова? Мне как то нужно проверить, что DivMMC стартует. И если нет, на что нужно обратить внимание.
Я тоже пытался это проделать на той плате sdnano, но тоже мимо. Собственно, у меня там явно какой-то косяк с cpld, т к при снятой перемычке eprom никакая память divmmc не должна мапиться и должно включаться родное пзу, чего не происходит. Сама cpld видится и шьется, пайку уже всю перепроверил, вплоть до того, что прозванивал все линии от ног cpld до разъема и памяти Буду пытаться снять cpld, если сильно пострадает плата (а белую маску, плавно переходящую в горело-коричневую от нагрева феном я видеть не хотел бы), то может попробую собрать еще экземпляр.Цитата:
Сообщение от julbu
Тест Хахонова прошить можно и я это делал (где-то выше в переписке мелькало). Но если там матрас, то это значит, что просто не выбрано никакое пзу и хоть с каким его содержимым будет матрас.
Сигнал clk нужен для тактирования чтения карты памяти. А маппинг озу и пзу в нем не нуждается никак. Над этой частью схемы можно пока голову не ломать.
У тебя тоже плата с двойным вариантом установки пзу - dip и sop ? может в ней какая ошибка есть - перемычка между переходными отверстиями или еще что ? Просто то, что люди собирали и работало, это было на более ранней ревизии платы (где был перекрест входа и выхода sd-карты)
Да, плата с белой маской на два варианта ПЗУ. Я на ней менял CPLD ничего не изменилось. При включении загорается ненадолго светодиод слева (который рядом с кнопкой reset), потом тухнет, причем это нестабильно раз от раза. За все время тестов, один раз загрузился наполовину экран Exsdos и все зависло. Она там ни с чем не может конфликтовать? У меня ленинград-2 с расширением до 128к. Буду проверять на непропай-замыкания. Будет время попробую ваш 5 вольтовый вариант повторить, детали все есть. Других мыслей нет.Цитата:
Сообщение от valerium
Нестабильно оно включается в esxdos потому, что весьма редко регистр конфигурации divmmc оказывается в том состоянии, когда с нулевых адресов включено его пзу (это случайно происходит). И почему-то не сбрасывается, как должен. Но хотя бы иногда это было - это плюс.Цитата:
Сообщение от julbu
А мусор на экране бывает тогда, когда перед стартом процессора вместо пзу в нижние адреса мапятся случайные страницы озу divmmc, они могут оказываться в весьма пестром состоянии.
Конфликтовать в пустом ленине эта плата ни с чем не должна, это тоже где-то страницами выше уже проверяли. Регистр конфигурации 7ffdh в esxdos первым делом настраивается на основное пзу 48к, нулевой экран (основной) и нулевую страницу озу - это тоже продумано.
Насколько я увидел из экспериментов, у меня было дело в кривом состоянии регистра конфигурации divmmc e3h после включения, когда активность сигнала /poweron короткая, а /reset у z80 значительно более длинный. Почему его надо сбрасывать по активному /reset и почему мало сброса по /poweron -я сам не могу понять.
Есть возможность прошить пзу вне платы ? Прошей в него testrom3 (см. сообщения на пару страниц выше) и посмотри, стартует или нет. В нем тесты памяти разные и тест выхода из пзу divmmc по кнопке 1.
А вообще вместо патча прошивки можно просто подать /reset на оба входа cpld - и reset, и poweron, тогда все должно корректно сбрасываться просто по кнопке сброса ленина - это если все остальное работает правильно, проверь, если есть возможность.
Попробовал, ситуация не изменилась. Впрочем сама плата nanosd уже в таком состоянии (несколько раз перепаивал компоненты), что вполне возможно уже сама неработоспособна. В общем буду на монтажке делать 5в версию, в DIPe, чтобы можно было поэкспериментировать. Если получиться, попробую еще одну nanosd собрать (я две штуки покупал).Цитата:
Сообщение от valerium
Забавный тест. я тут сегодня весь вечер хожу кругами, zx128 не стартует. Или вообще чОрный экран, или с 20-го раза полосатый экран и бордюр какой нить). Думал уж вообще не работает ничего (но растр есть). Залил этот тест, так он работает, на всех кнопках цифрах, но по "1" в бейсик не вываливается, возвращается обратно на полосатый экран. Ну хоть что-то осмысленное.Цитата:
Сообщение от valerium
Я достал свою плату на Xilinx, еще раз протыкал всю пайку, промазал ноги ПЛИСки пастой и прогрел.Цитата:
Сообщение от julbu
Что имеем сейчас: спек стартует, но всегда сбрасывается в свое ПЗУ. Если при этом с "ленты" загрузить divramka, то он бодро и успешно тестирует все 512к ОЗУ.
Потом я сдуру решил перепрошить ПЗУшку с прошивочной тапки esxdos... В общем, прошивка как бы выполнилась, но в ПЗУ какая-то хрень, с ней ничего не заработало, в плате на Альтере она тоже не работает.
Взял другую ПЗУху, прошил testrom3 - не стартует. Все так же падает в бейсик, видимо не отрабатывает ловушка для перехвата адреса 0000h. Адресные линии на ПЛИС все проверил на два раза. Прошивку ПЛИС оригинальную заливал - без толку. Значит буду ковырять неоригинальную.
Посмотрел осциллографом тактовые импульсы, которые мы получаем после одновибратора и триггера Шмидта... страх и ужас, шум, какие-то длиннющие иголки, вылезающие далеко за 5в после переключений. Потом подам тактовую с Z80 напрямую. Ну в общем... квест продолжается =)
Зона выхода не срабатывает, не отключает automap. Как дело обстоит с /m1 на процессоре ? Ну и адресные ноги проверять надо, особенно старшие (a9 и выше - раз тест запускается и работает, значит нижние полкилобайта ПЗУ попали на свое место)Цитата:
Сообщение от zebest
Тааа))) тут вообще интересно все))Это проект цельно в ксайлинке. Автор оного сделал две версии. zx48 работает идеально, особенно тайминги zx48 экрана, всяким следующим далеко до этого. Ну и дивММС прекрасно работает. Претензий ноль. Ну и его же проект zx128. Модулей много измененных, в т.ч. и маппер, и SPI и другие модули. Ну захотелось емуу, чО. При запуске и экран черный , и бордюр, синхра есть. И все. х.з. работало оно у него, но раз выложил - то видимо да?? Вот и пришлось тест этот подкидывать, причем в 48-м он работает несколько иначе, но по "1" точно в ОС вываливается.
а в 128-м тест работает, но несколько иначе, а по "1" вижу типа сброс, красные вертикальные пунктирные линии, как положено, и а5 в этот тест.
тесты на кнопках от 1 до 0 все как бы работают, но иначе, чем в 48м варианте. Поэтомуу чешу репу второй день. Занятно., но и занимательно.
upd/ Придумал/ Сейчас диззи-тест вместо 128й ROM подкину, посмотрю, куда вывалиЦЦа.
upd2: ну да, вываливается во вторую четверть, Spellbound:v2_confu:, что наверняка правильно, ибо 48й бейсик во второй половине 128го. Все чудесатее и чудесатее.
так это целиком отдельная fpga-шная реализация спека ? тогда надо в ее исходники divmmc смотреть, иначе только запутаем друг друга.
esxdos в 48м режиме-то работает ?
Кто-нибудь знает, какие подводные камни могут быть при втыкании DivMMC в разъем Скорпиона 256?
Очередная попытка прикрутить DivMMC к Ленинграду-1 и Sizif-128. Пока имеем старт Exsdos и сброс в бейсик 48.
При тесте Divramka почему то, каждый второй блок памяти - сбой.
На SD карте все нужные папки есть, память точно исправна. Никто с похожим не сталкивался?
Вложение 75285
Вложение 75284
а разве он не так должен себя вести? сброс в 48 бейсик, в нем после этого сброса становятся доступны команды DIVMMC. или можно дернуть за NMI - откроется список файлов на флешке.Цитата:
Сообщение от julbu
у меня было что-то подобное - когда в плиске налажал, но у меня совсем другой расклад, память используется основная на плате ленинграда (верхние 128к).Цитата:
При тесте Divramka почему то, каждый второй блок памяти - сбой.
На SD карте все нужные папки есть, память точно исправна. Никто с похожим не сталкивался?
сигналы выбора банков памяти с плис до микросхему ОЗУ доходят? на 0/1 никто не залип?
Карта не детектится. Причем не файловая система на ней, а даже само устройство. Она как подключена, вход/выход данных не перепутаны ? (тут были такие платы).Цитата:
Сообщение от julbu
Тактовая частота откуда подается на плиску и какая ?
У меня чтение работало нестабильно при 3,5 мгц с процессора (badapple.tap, которым я тестирую стабильность, часто сбоил в случайном месте), я попробовал поиграть с внешним генератором. И перепробовал кучу кварцев, в общем в частотах от 3,6864мгц и до 20мгц (выше свободного кварца не было, но думаю, что предел бы не был достигнут) карта читалась прекрасно и сбоев чтения не было. Так что тактировать чтение SD лучше частотой, _выше_ процессорной (видимо потому что на 16 битовых сдвигов по spi в esxdos выделена "пауза" в 16 NOP-ов, правда по какой причине их иногда может не хватать, я не разобрался).
По поводу полосатого теста - очень похоже на проблему в младших линиях адреса банка, как тут правильно сказали. Я бы начал с проверки bank0 и bank1.
да, эт я протупил что там еррор выдается...Цитата:
Сообщение от valerium
16 NOPов - это 64 такта 3.5МГц. даже с учетом тормознутости SPI порта в оригинальном DIVMMC - это 32 битовых сдвига. тут скорее дело в другом - для чтения секторов используется команда INIR, и вот там следующий байт должен успеть задвинуться в регистр до следующего сигнала /RD. думаю узкое место здесь, но такты считать лениво. я просто подал туда 14МГц.Цитата:
У меня чтение работало нестабильно при 3,5 мгц с процессора (badapple.tap, которым я тестирую стабильность, часто сбоил в случайном месте), я попробовал поиграть с внешним генератором. И перепробовал кучу кварцев, в общем в частотах от 3,6864мгц и до 20мгц (выше свободного кварца не было, но думаю, что предел бы не был достигнут) карта читалась прекрасно и сбоев чтения не было. Так что тактировать чтение SD лучше частотой, _выше_ процессорной (видимо потому что на 16 битовых сдвигов по spi в esxdos выделена "пауза" в 16 NOP-ов, правда по какой причине их иногда может не хватать, я не разобрался).
и кстати еще момент - карты MMC эта железяка несмотря на название - не поддерживает. просто не видит. вряд ли кому актуально, но все же...