Вид для печати
Народ! Где-то когда-то читал информацию, что если разместить образ ПЗУ Бейсика-48 в ОЗУ (например а статическом КЭШе или еще как), подключаемом по адресу #0000 вместо реального ПЗУ и сделать в нем RANDOMIZE USR 0 (или даже достаточно только команды NEW?), то там какие то несколько (5-6?) байт повреждаются? Киньте в меня информацией, где это описано. Интересно также знать, поправимо ли это через программное вмешательство в прошивку или ее ОЗУшый образ...
Максагор, я с этим столкнулся, когда расширял Ленинград-1 до 1МБ на СИММ-30. Только у меня портились 5 байт в странице от #C000. Но, как мне очень прозрачно объяснили, это проделки калькулятора Басик48. В общем, можно почитать отсюда и далее по топику и ещё вот тут. Я бы сам хотел узнать об этой проблеме более подробно, т.к. в тот раз (при расширении памяти) почти ничего не понял.
от команды 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."
Смысл вопроса: если мы имеем копию в ОЗУ, то можно ли "ручками" "малой кровью" (т.е. без перелопачивания половины образа ПЗУ) убрать "порчу" (или сместить ее в неиспользуемую часть образа прошивки - вроде бы там достаточно места, забитого байтами #FF). И если да, хотелось бы понять, какие подпрограммы эту "порчу" осуществляют...Цитата:
Сообщение от goodboy
Про скроллинг посмотрю когда мозги посвежее будут. ЕМНИП (а сейчас очень даже ИП), первые 8 линий экрананевозбранно"выскролливаются" в ПЗУ. Про калькулятор:
Суть примерно в том, что калькулятор использует процедуру распаковки упакованных констант для пропуска констант в таблице (они все разной длины). Распаковывает пропускаемые константы в ПЗУ с #0000. Самый простой способ лечения: "распаковывать" в какое-нибудь другое безобидное место (LD DE,+0000), кандидат на ненужное место - байты #ff с адреса #0013. Если важно не "писать" в ПЗУ совсем, я бы переписал таблицу констант с #32C5 в распакованном виде в свободные ячейки и переписал бы skip-cons целиком.Код: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.
Кстати, процедура нехило так тормозит весь BASIC, ибо помещение констант (0, 1, 0.5, pi/2, 10) на стек используется весьма часто, а stk-const нифига не простая.
Максагор - глянь это http://zx-pk.ru/showthread.php?t=143...l=1#post350143
Возможно поможет.
Тут правильно указали, что в бейсике есть два бага, один в процедуре скролла, а другой - в калькуляторе. Если их исправить - то память портиться не будет. Впервые я увидел фиксы в Орель-бейсике и скопировал их в bogobasic.
Вот фикс для ошибки скролла (синтаксис ассемблера 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
Последствия от обеих ошибок различные. Если ошибка калькулятора портит первые байты в ОЗУ, то ошибка скролла портит знакогенератор.
Barmaley_m, а размер этих патчей позволит их интегрировать в прошивку BASIC_48 (или BASIC_48 от прошивки BASIC_128) без использования дополнительной памяти ПЗУ (свободные места и т.п.)?
SoftFelix, в BASIC48 без малейших сомнений влезет, туда еще вагон и маленькая тележка поместится. В BASIC_48_128 - не знаю. Но Андрей Гетало делал Bogobasic48_128, совместимый с прошивкой BASIC_128, со всеми функциями (в том числе и вышеприведенные патчи). Правда, Андрей при этом выкинул из BASIC_48_128 "лишний" код опроса дополнительных клавиш (keypad) и некоторые другие изменения. Подробностей я не знаю, могу только дать прошивку.
Невнимательно читал вопрос. Свободное место ПЗУ данными патчами используется, как это видно из моего предыдущего сообщения. Можно ли их оптимизировать, чтобы не требовалось использовать свободное место ПЗУ? Не знаю. Патчи писал не я (я их позаимствовал из Орель-бейсика). Вероятно, "в лоб" оптимизировать не удастся, а скорее всего придется оптимизировать патчи вместе с процедурами, которые ими затронуты. Некоторые места в бейсике подлежат оптимизации по размеру, хотя их и сочинили талантливые программисты, экономившие память. Взять хотя бы процедуру CIRCLE - очень неэффективная, и по скорости, и по размеру.
Тут http://zx-pk.ru/showthread.php?t=26018
Пример аппаратного фикса. Только для моделей не имеющих порт 15 - ставится обычная кнопка с фиксацией. Данный фикс - не мешает работе 128к расширения - потому как при работе 128к - задействовано окно с С000. И вообще - в 0 адреса никто не пишет при нормальной работе компьютера.
Аппаратный фикс всяко лучше. На самом деле множество программ ведет по этим адресам запись. Когда я пользовался теневым монитором на "Орель БК-08" - то часто страдал от того, что та или иная программа затирала монитор. В конце концов сделал себе запрет записи, когда по адресам 0000-3FFF включено ПЗУ или режим эмуляции ПЗУ. Сразу решилась куча проблем.
Тем не менее программный фикс бейсика, чтобы он не вел запись по адресам ПЗУ, представляет отдельный академический интерес.
Расположение бейсика в ОЗУ (а, соответственно, и устранение его затирания) полезно не для запуска из-под него кодовых программ и прочих игрушек на асме, которые там что-то портят, а ради самого бейсика и программ на бейсике, чтобы можно было бы его развивать и дорабатывать только для этого. Например, сделать версию для iS-DOS с внедрением команд работы с диском, версию для TASiS с поддержкой экранов и т.п. Первым этапом тут стоит как раз ликвидация порчи в ОЗУ.Цитата:
Сообщение от Barmaley_m
Лечим порчу 5 ячеек по фотографии :) (c) Медицинская реклама :)
обычно бейсик расширяют путём перехвата ошибок (rst#8).Цитата:
Сообщение от Максагор
зачем что-то править в ПЗУ - непонятно
Я в курсе.Цитата:
Сообщение от goodboy
Как раз не в ПЗУ. )))Цитата:
Сообщение от goodboy
про замещение ПЗУ я понял.Цитата:
Сообщение от Максагор
вон с divIDE набираю в бейсике playwav, он распознаёт и запускает плагин.
а твои наработки получаются привязаны на конкретный комп и его расширения памяти
У меня пока не наработки, а идейки, под которые я веду предварительные исследования. Но да - это под TASiS - есть идея сделать подгружаемый в качестве плагина ядра системы доработанный и расширенный спектрум-бейсик. реализую я когда-нибудь это - пока не знаю. Буду накапливать информацию и изучать вопрос.Цитата:
Сообщение от goodboy
Это понятно. Я когда делал bogobasic - то именно так его и отлаживал. Все равно это ненадежно: вдруг баг, приводящий к сбою с перепахиванием памяти? Придется грузить бейсик заново.Цитата:
Сообщение от Максагор
В этой ситуации помогает режим эмуляции ПЗУ - это когда одна из страниц расширенного ОЗУ подключается по адресам 0000-3FFF, но запись в нее заблокирована. Тогда перепахивание памяти не страшно. Я это реализовал в своей схеме расширения и загружал обычно в режиме эмуляции стандартный бейсик Sinclair-82. При желании можно было использовать этот режим и для отладки новых модификаций прошивки бейсика-48, -128 или TR-DOS - только в те годы (1995+) я уже этим не занимался.
Лучше - аппаратный запрет записи в эту область ОЗУ при установке соответствующих флагов в портах расширения. И отлаживать можно, и в ПЗУ прошить можно, и сбои не страшны.Цитата:
Сообщение от Максагор