Порча Бейсика-48 в ОЗУ

[Максагор]

Народ! Где-то когда-то читал информацию, что если разместить образ ПЗУ Бейсика-48 в ОЗУ (например а статическом КЭШе или еще как), подключаемом по адресу #0000 вместо реального ПЗУ и сделать в нем RANDOMIZE USR 0 (или даже достаточно только команды NEW?), то там какие то несколько (5-6?) байт повреждаются? Киньте в меня информацией, где это описано. Интересно также знать, поправимо ли это через программное вмешательство в прошивку или ее ОЗУшый образ...

[SoftFelix]

Максагор, я с этим столкнулся, когда расширял Ленинград-1 до 1МБ на СИММ-30. Только у меня портились 5 байт в странице от #C000. Но, как мне очень прозрачно объяснили, это проделки калькулятора Басик48. В общем, можно почитать отсюда (http://zx-pk.ru/showthread.php?t=12678&page=2&p=279231&viewfull=1#post279231) и далее по топику и ещё вот тут (http://zx-pk.ru/showthread.php?t=1093&page=7&p=22964#post22964). Я бы сам хотел узнать об этой проблеме более подробно, т.к. в тот раз (при расширении памяти) почти ничего не понял.

[goodboy]

от команды NEW порчи не-будет.
запись в ROM происходит при работе встроенного калькулятора (при вычислении фактических значений чисел).

[Максагор]

от команды NEW порчи не-будет.
запись в ROM происходит при работе встроенного калькулятора (при вычислении фактических значений чисел).

Это лечится?

[goodboy]

"WRITE TO ROM (48 ROM-33FEh)

Not so much a bug as poor coding. The ROM tries to write four bytes starting at 0000h. On a real Spectrum there is usually no effect because you can't actually write to the ROM, but if a copy of the ROM is really in RAM (to give better compatibility on a +3 or +2A for instance), the 'ROM' could be overwritten."

[Максагор]

The ROM tries to write four bytes starting at 0000h.

Смысл вопроса: если мы имеем копию в ОЗУ, то можно ли "ручками" "малой кровью" (т.е. без перелопачивания половины образа ПЗУ) убрать "порчу" (или сместить ее в неиспользуемую часть образа прошивки - вроде бы там достаточно места, забитого байтами #FF). И если да, хотелось бы понять, какие подпрограммы эту "порчу" осуществляют...

[Alex Rider]

Про скроллинг посмотрю когда мозги посвежее будут. ЕМНИП (а сейчас очень даже ИП), первые 8 линий экрана невозбранно "выскролливаются" в ПЗУ. Про калькулятор:


33F7 SKIP-CONS AND A The subroutine returns if the
33F8 SKIP-NEXT RET Z parameter is zero, or when the
requested constant has been
reached.
PUSH AF Save the parameter.
PUSH DE Save the result pointer.
LD DE,+0000 The dummy address.
CALL 33C8,STK-CONST Perform imaginary stacking of
an expanded constant.
POP DE Restore the result pointer.
POP AF Restore the parameter.
DEC A Count the loops.
JR 33F8,SKIP-NEXT Jump back to consider the value
of the counter.

Суть примерно в том, что калькулятор использует процедуру распаковки упакованных констант для пропуска констант в таблице (они все разной длины). Распаковывает пропускаемые константы в ПЗУ с #0000. Самый простой способ лечения: "распаковывать" в какое-нибудь другое безобидное место (LD DE,+0000), кандидат на ненужное место - байты #ff с адреса #0013. Если важно не "писать" в ПЗУ совсем, я бы переписал таблицу констант с #32C5 в распакованном виде в свободные ячейки и переписал бы skip-cons целиком.
Кстати, процедура нехило так тормозит весь BASIC, ибо помещение констант (0, 1, 0.5, pi/2, 10) на стек используется весьма часто, а stk-const нифига не простая.

[balu_dark]

Максагор - глянь это http://zx-pk.ru/showthread.php?t=14379&p=350143&viewfull=1#post350143
Возможно поможет.

[Barmaley_m]

Тут правильно указали, что в бейсике есть два бага, один в процедуре скролла, а другой - в калькуляторе. Если их исправить - то память портиться не будет. Впервые я увидел фиксы в Орель-бейсике и скопировал их в bogobasic (http://zx-pk.ru/showthread.php?t=5434).

Вот фикс для ошибки скролла (синтаксис ассемблера ZEUS):


ORG #0E16
CALL SCRLK
ORG #38F6
SCRLK DEC A
BIT 6,D
JR Z,SCK1
LDIR
SCK1 ADD HL,BC
RET

Фикс для ошибки калькулятора


ORG #33DE
LD B,0
INC HL
INC D
DEC D
JP NZ,M3932
ADD HL,BC
LD A,1
NOP
M33EA EQU $
ORG #3932
M3932 ADD A,#50
LD (DE),A
LD A,5
SUB C
INC DE
LDIR
JP M33EA
Данные патчи можно сопоставить с дизассемблером бейсика (от Яна Логана), чтобы понять, что фиксится и как.

Последствия от обеих ошибок различные. Если ошибка калькулятора портит первые байты в ОЗУ, то ошибка скролла портит знакогенератор.

[SoftFelix]

Barmaley_m, а размер этих патчей позволит их интегрировать в прошивку BASIC_48 (или BASIC_48 от прошивки BASIC_128) без использования дополнительной памяти ПЗУ (свободные места и т.п.)?

[Barmaley_m]

SoftFelix, в BASIC48 без малейших сомнений влезет, туда еще вагон и маленькая тележка поместится. В BASIC_48_128 - не знаю. Но Андрей Гетало делал Bogobasic48_128, совместимый с прошивкой BASIC_128, со всеми функциями (в том числе и вышеприведенные патчи). Правда, Андрей при этом выкинул из BASIC_48_128 "лишний" код опроса дополнительных клавиш (keypad) и некоторые другие изменения. Подробностей я не знаю, могу только дать прошивку.

Невнимательно читал вопрос. Свободное место ПЗУ данными патчами используется, как это видно из моего предыдущего сообщения. Можно ли их оптимизировать, чтобы не требовалось использовать свободное место ПЗУ? Не знаю. Патчи писал не я (я их позаимствовал из Орель-бейсика). Вероятно, "в лоб" оптимизировать не удастся, а скорее всего придется оптимизировать патчи вместе с процедурами, которые ими затронуты. Некоторые места в бейсике подлежат оптимизации по размеру, хотя их и сочинили талантливые программисты, экономившие память. Взять хотя бы процедуру CIRCLE - очень неэффективная, и по скорости, и по размеру.

[balu_dark]

Тут http://zx-pk.ru/showthread.php?t=26018
Пример аппаратного фикса. Только для моделей не имеющих порт 15 - ставится обычная кнопка с фиксацией. Данный фикс - не мешает работе 128к расширения - потому как при работе 128к - задействовано окно с С000. И вообще - в 0 адреса никто не пишет при нормальной работе компьютера.

[Barmaley_m]

Аппаратный фикс всяко лучше. На самом деле множество программ ведет по этим адресам запись. Когда я пользовался теневым монитором на "Орель БК-08" - то часто страдал от того, что та или иная программа затирала монитор. В конце концов сделал себе запрет записи, когда по адресам 0000-3FFF включено ПЗУ или режим эмуляции ПЗУ. Сразу решилась куча проблем.

Тем не менее программный фикс бейсика, чтобы он не вел запись по адресам ПЗУ, представляет отдельный академический интерес.

[Максагор]

Аппаратный фикс всяко лучше. На самом деле множество программ ведет по этим адресам запись. Когда я пользовался теневым монитором на "Орель БК-08" - то часто страдал от того, что та или иная программа затирала монитор. В конце концов сделал себе запрет записи, когда по адресам 0000-3FFF включено ПЗУ или режим эмуляции ПЗУ. Сразу решилась куча проблем.

Тем не менее программный фикс бейсика, чтобы он не вел запись по адресам ПЗУ, представляет отдельный академический интерес.

Расположение бейсика в ОЗУ (а, соответственно, и устранение его затирания) полезно не для запуска из-под него кодовых программ и прочих игрушек на асме, которые там что-то портят, а ради самого бейсика и программ на бейсике, чтобы можно было бы его развивать и дорабатывать только для этого. Например, сделать версию для iS-DOS с внедрением команд работы с диском, версию для TASiS с поддержкой экранов и т.п. Первым этапом тут стоит как раз ликвидация порчи в ОЗУ.

[balu_dark]

Лечим порчу 5 ячеек по фотографии :) (c) Медицинская реклама :)

[goodboy]

полезно не для запуска из-под него кодовых программ и прочих игрушек на асме, которые там что-то портят, а ради самого бейсика и программ на бейсике, чтобы можно было бы его развивать и дорабатывать только для этого. Например, сделать версию для iS-DOS с внедрением команд работы с диском, версию для TASiS с поддержкой экранов и т.п.
обычно бейсик расширяют путём перехвата ошибок (rst#8).
зачем что-то править в ПЗУ - непонятно

[Максагор]

обычно бейсик расширяют путём перехвата ошибок (rst#8).

Я в курсе.


зачем что-то править в ПЗУ - непонятно

Как раз не в ПЗУ. )))

[goodboy]

Как раз не в ПЗУ. )))
про замещение ПЗУ я понял.

вон с divIDE набираю в бейсике playwav, он распознаёт и запускает плагин.
а твои наработки получаются привязаны на конкретный комп и его расширения памяти

[Максагор]

а твои наработки получаются привязаны на конкретный комп и его расширения памяти

У меня пока не наработки, а идейки, под которые я веду предварительные исследования. Но да - это под TASiS - есть идея сделать подгружаемый в качестве плагина ядра системы доработанный и расширенный спектрум-бейсик. реализую я когда-нибудь это - пока не знаю. Буду накапливать информацию и изучать вопрос.

[Barmaley_m]

Расположение бейсика в ОЗУ (а, соответственно, и устранение его затирания) полезно ... ради самого бейсика и программ на бейсике, чтобы можно было бы его развивать и дорабатывать
Это понятно. Я когда делал bogobasic - то именно так его и отлаживал. Все равно это ненадежно: вдруг баг, приводящий к сбою с перепахиванием памяти? Придется грузить бейсик заново.

В этой ситуации помогает режим эмуляции ПЗУ - это когда одна из страниц расширенного ОЗУ подключается по адресам 0000-3FFF, но запись в нее заблокирована. Тогда перепахивание памяти не страшно. Я это реализовал в своей схеме расширения и загружал обычно в режиме эмуляции стандартный бейсик Sinclair-82. При желании можно было использовать этот режим и для отладки новых модификаций прошивки бейсика-48, -128 или TR-DOS - только в те годы (1995+) я уже этим не занимался.

Например, сделать версию для iS-DOS с внедрением команд работы с диском, версию для TASiS с поддержкой экранов и т.п. Первым этапом тут стоит как раз ликвидация порчи в ОЗУ.
Лучше - аппаратный запрет записи в эту область ОЗУ при установке соответствующих флагов в портах расширения. И отлаживать можно, и в ПЗУ прошить можно, и сбои не страшны.