TS Forum

Black_Cat wrote:Очень сомнительный критерий

din - это ШД в цикле М1, так что все ок.

---

Ну и да, я не весь верилог привел, а лишь то что спрашивали.
Остальной код можно было посмотреть самостоятельно.

TS-Labs wrote:так что все ок

не знаю что для тебя ок, если корректное автоматическое переключение 128/512 сделать принципиально невозможно, и если программы написанные в соответствии со всеми современными рекомендациями WoS о том как правильно юзать out(#fd), a для ZX128, у тебя не будут корректно определять память.

Докажи или отъебись.

Ну смотри, пусть одна программа юзает по всем современным правилам две процедуры обращения к #7FFD. При этом одна процедура юзает короткую адресацию, а вторая полную:
1) В соответствии с рекомендациями WoS для ZX128, при короткой адресации #7FFD с помощью out(#fd), a надо выставлять D7=0, D6=1, что у тебя автоматически приведёт к записи в страницу 8+n, хотя для ZX128 имелась ввиду страница n.
2) Теперь, опять же в соответствии с рекомендациями WoS при полной адресации #7FFD, для ZX128 надо выставлять D7, D6=0 (хотя конечно можно выставить что угодно), при этом и в ZX128 и у тебя мы попадаем на страницу n.

Вывод: Для ZX128 программа будет работать корректно, обращаясь всегда к одной и той же странице n, а у тебя программа будет обращаться к разным страницам со всеми вытекающими последствиями .

P.S. Кстати, в Фениксе такая программа будет работать корректно

В режиме 128K Lock=Auto, при А=#50 out (#fd),a включится 0-я страница.

Sergey78 wrote:В режиме 128K Lock=Auto, при А=#50 out (#fd),a включится 0-я страница.

А если программе не нужен SOS48, и A=#40?

Black_Cat wrote:A=#40

С #C000 - страница 0, с 0 - Basic128.

Обоже... Не дошло даже со второго раза.
Итак:
m1_lock128 <= !(din[7] ^ din[6]); // думал догадаешься, ан-нет

Смотрим ПОЛНЫЙ код:
reg m1_lock128;
always @(posedge clk)
if (opfetch)
m1_lock128 <= !(din[7] ^ din[6]);

assign opfetch = memrd && m1;
assign memrd = mreq && rd;
assign mreq = !mreq_n && rfsh_n;
assign rd = !rd_n;

Дальше разжевывать?

---

Вообще, напоминает ситуацию с олонием, который доебался до меня за этот нещасный лок128, чо вы все доебались до этого уютного лока128???
И тоже злостно не парсил верилог.

---

Короче, приведи опкоды перечисленных тобой инструкций, посмотри на биты 6/7 опкодов, подставь в лог. функцию и уже успокойся наконец.

Sergey78 wrote:С #C000 - страница 0, с 0 - Basic128.

Т.е. ты хочешь сказать, что в режиме Авто при короткой адресации всегда включается 128к?
А как же тогда будут работать родные пентовые софты, юзающие короткую адресацию свыше 128к, при D7=0, D6=1? Они тоже будут пытаться разместить 256к инфы в 128к памяти?

---

TS-Labs wrote:Дальше разжевывать?

Всё это конечно хорошо, не смотря на то, что я в этом не шарю , но коллизия состоит в другом, а именно, что короткая адресация с D7=0, D6=1 в софте ZX128 обозначает обращение к странице n #7FFD, а в софте Пента та же самая команда обозначает обращение к странице 8+n . И как вы их собираетесь различать, если это одна и та же команда, но в одном случае адресуется 128к, а в другом 256к?

Black_Cat wrote:я в этом не шарю

Начнешь шарить - получишь ответ.

TS-Labs wrote:Начнешь шарить - получишь ответ.

Ответ я знал заранее и без верилога , и ответ состоит в том, что эта задача принципиально не решаема автоматически аппаратными методами , т.е. коллизия неизбежна, хотя ты это почему-то не можешь понять . И проблема тут именно в том, что Пент юзает D6 для расширения памяти при короткой адресации #7ffd. Для Пента проблема решается только принудительным переключением режимов 128/512 через другой порт, при том дефолтно должен быть включен именно режим 128к. К сожалению должен согласиться с тобой, что тому, кто сделал в #EFF7 по умолчанию включенный режим over 128k надо оторвать руки, (т.к. всё равно они у него из жопы , и то же самое и про дефолтно включенный режим турбо в #EFF7), что делает этот порт бессмысленным.

Слушай, я этот режим собираюсь вообще выпилить нахер.
Юзер должен выбирать, что будет доступно через порт 7ффд - 128 или 512, как это было в классические времена. Толька раньше это было тумблерами, а щас в сетапе.
Чем плох режим авто? Тем, что софт о нем не знает. Если софт проводит тест памяти через out (c), о получает 512к, когда же потом он адресует его через out(fd), он получает фейл 128к. Ну и нахуй такое щастье?
Мне реально хватает ситуаций, когда приходится по 100 раз проверять софты на всевозможных конфигурациях, защелках памяти, вплоть до замены процессоров (потому что какой то мудак решил сделать защиту от эмулятора в 1990 году, основанную на баге процессора, в результате процы пофиксали, а эмуляторы стали совершеннее, и софт работает только в эмуле, а не работает на реальном железе). И лишняя угадайка не нужна.

BC, ты список софта глючного выложи в студию. Я лично только 1 знаю, которых нафиг никому не нужен.

Болек, список я соберу при случае. Но точно помню, что такое попадалось.

Подскажите люди добрый, не дайте сойти с ума.
Какие значения нужно записать в MemConfig и в Page0
что бы вернуть стандартную конфигурацию rom ?
Сначала записываю
di
ld bc,MemConfig
ld a,%00001010
out (c),a
На Page0 манипулирую, как мне там надо
Потом хочу вернуть все назад, делаю
ld bc,MemConfig
ld a,%00000001
out (c),a
ei
и все - крах - в Page0 одни FF

Может в Page0 нужно что то запистаь ? или в MemConfig не %00000001 ?

%00001010 - это странная комбинация: включеная рама и маппинг на 4 банка, но разрешена запись. Для использования просто банка рамы лучше писать %00001110, тогда по 0000 просто будет пага озу из Паге0.
%00000001 - это ПЗУ бейсика48. Но при этом в Паге0 таки должен быть 0, иначе выберется другой банк в ПЗУ.

Вот пример:
В мемконфиг записали %00000001, по идее должна выбраться сраница ПЗУ 3. Однако если в Паге0 записано значение 4-7, выберется страница 7. Если 28-31 - страница 31.

Спасиб - при Паге0 = 0 все заработало.
но я так понял что это принудительно перевело бейсик в 48?
А как же восстановить ту пзу, которая действительно была до этого?

Восстановить никак.
Порты на чтение - это небольшая роскошь для пентевовского чипа

Господа, я рад, что мне удалось слегка порвать ваши шаблоны, и вы наконец прониклись . И так, подитожим что мы имеем в сухом остатке:

1) При использовании короткой адресации порта #7FFD командой out(#fd), a с установленными старшими разрядами аккумулятора D7=0, D6=1 невозможно определить к какой странице обращается программа - к n, или к 8+n, т.к. конечный результат определяется только архитектурой компьютера. Т.е. в компьютере с ОЗУ 128к обращение произойдёт к странице n, а в комьютере с ОЗУ по стандарту Pentagon512 обращение произойдёт к странице 8+n;
2) Такой дуализм приводит к коллизиям, если совместно с короткой адресацией #7FFD применяется полная адресация.

А теперь о сути - то, что вопрос не решаем аппаратно, не значит что он не решаем вообще . Но решение лежит не в аппаратной плоскости, а в плоскости стандартизации . Предлагаю обратиться к опыту коллег с WoS, решивших в своё время вопрос о стандартизации использования в софте короткой адресации порта #7FFD. Напомню суть их решения: раньше кодеры, при использовании out(#fd), a выставляли D6 аккумулятора как бог на душу положит, что приводило к конфликтам с многочисленными клонами, в т.ч. с ZX Spectrum +3. Поэтому они установили стандарт использования out(#fd), a , жёстко определяющий для старших разрядов аккумулятора D7=0, D6=1. Таким образом весь софт, не удовлетворявший этому стандарту становился нелегитимным и подлежал переделке . И они таки его переделывали, в т.ч. и наши Пентовые демки .
Теперь вернёмся к нашим баранам . Как справедливо заметил noleg, софта приводящего к коллизиям довольно таки мало, а значит стандартизация этого вопроса не приведёт к очень большим проблемам и затратам. Полагаю, основная масса софта, использующего out(#fd), a - это программы требующие быстрой перерисовки экрана методом копирования информации со страниц устанавливаемых в окно CPU3 на страницу 5. Собственно, на более быстром переключении страниц с помощью короткой адресации #7FFD в окне CPU3 и происходит экономия времени. Теперь, собсно, о сути предлагаемого стандарта:

1) Целью данного стандарта является разрешение вопроса безконфликтного исполнения программ использующих out(#fd), a на компьютерах с моделью памяти ZX128 и Pentagon512.
2) Суть стандарта состоит в:
- запрете использования в связанных процедурах разных способов адресации #7FFD. Связанными процедурами при этом считаются процедуры, предполагающие использование одних и тех же страниц памяти в окне CPU3;
- запрете использования при видеовыводе любой другой страницы кроме 5;
- запрете обращения к странице 5 через окно CPU3 посредством out(#fd), a.

Как видите, правила соглашения вполне естественны для программ использующих out(#fd), a. Такое соглашение полностью исключит коллизии, возникающие из-за связанного обращения к #7FFD с помощью короткой и полной адресации.


Теперь о выводах, которые следуют из такого стандарта:

1) В клоне Pentagon512 отпадает необходимость в переключении размера ОЗУ 512k/128k для программ совместимых с ZX128;
2) Программы для ZX128, использующие out(#fd), a не могут размещаться одной непрерывной областью в памяти Pentagon512, в связи с чем, при использовании в Pentagon512 RAM-диска, необходима корректировка его драйвера для изменения используемых им страниц на 0, 1, 3, 4, 6, 7, 10, 13, 16-31*;
3) Программы для Pentagon512, соответствующие этому стандарту могут исполняться расширенными ZX Spectrum 128 использующими наиболее простой способ расширения памяти с помощью внешних устройств, подключаемых к краевому разъёму, и отключением внутренней памяти, используемой исключительно CPU, что значительно расширяет аудиторию потребителей таких программ.


* Дополнительное соглашение:

1) В связи с неизбежностью переделки драйвера RAM-диска, предлагаю заодно поменять весовые коэффициенты старших разрядов #7FFD:

A17'=D7 #7FFD
A18'=D6 #7FFD

Таким образом в новой нумерации RAM-диск 384k будет использовать страницы: 0, 1, 3, 4, 6, 7, 8-15, 18, 21, 24-31;

2) Принять в качестве кроссплатформенного стандарта для программ объёмом 256k, стандарт, уже используемый в ZXM-Phoenix, и позволяющий исполнять без переделки программы на платформах SKAY(ZXM-Phoenix), KAY, Pentagon512:

A14'=D0 #7FFD
A15'=D1 #7FFD
A16'=D2 #7FFD
A17'=D7 #7FFD

В этом случае для Pentagon512 RAM-диск 256k будет использовать страницы: 8-15, 24-31;

...И животноводство!

я все еще жду список софта

Ага.

noleg wrote: все еще жду список софта

А я все еще жду внятного объяснения использования цвета для тайлов и др.

Медицина бессильна.