Просмотр полной версии : Вектор-06Ц: Эмуляция
Страницы :
1
2
3
4
5
6
[
7]
Improver
30.09.2024, 10:32
Забавное наблюдение по эмуляции процессора КР1821ВМ85А (он же i8085)... Вот такую картинку выдаёт программа clrspace (https://caglrc.cc/scalar/ware/768/) в эмуляторе EMU:
81328
А такую в эмуляторе VV:
81327
И та же программа на реале выглядит вот так, в нормальном режиме работы ПК-6128ц:
https://s1.hostingkartinok.com/uploads/thumbs/2024/09/c84f4596a559559f1474b3e878a0b365.png (https://hostingkartinok.com/show-image.php?id=c84f4596a559559f1474b3e878a0b365) https://i.ibb.co/nDVBqcF/IMG-20240930-normal.jpg (https://ibb.co/nDVBqcF)
Приведу вариант и в "ускоренном" режиме, хотя этот результат тут не имеет особого значения:
https://s1.hostingkartinok.com/uploads/thumbs/2024/09/71143fedb006bff6c481c8ac7727127b.png (https://hostingkartinok.com/show-image.php?id=71143fedb006bff6c481c8ac7727127b) https://i.ibb.co/28VDQdD/IMG-20240930-vtec.jpg (https://ibb.co/28VDQdD)
В то же время оба эмулятора и реал (в нормальном режиме) показывают одинаковые результаты в тесте vstvi53 (https://caglrc.cc/scalar/ware/908/). Сама программа clrspace, как я понимаю, имеет чёткое выравнивание по тактам процессора КР580ВМ80А и то, что картинка искажается на ВМ85, вроде, удивления не должно вызывать, но по факту имеем три разных варианта этих искажений. :)
Я бы поставил не на процессор, а на отличие в моменте прихода прерывания или каких-то других моментах связанных с разверткой. Эти особенности 6128 не тестировались.
- - - Добавлено - - -
Просто в качестве забавного факта. У меня есть версия clrspace, которая в emu выглядит как на приведенном фото реала. Но скорее всего это я ее (эту версию clrspace) испортил/модифицировал, и на реале она дала бы другую картинку.
Improver
30.09.2024, 11:21
Я бы поставил не на процессор, а на отличие в моменте прихода прерывания или каких-то других моментах связанных с разверткой.Кстати, да. Думаю, тут важны ещё циклы записи палитры и когда эта запись доступна, по отношению к моменту прерывания.
важны ещё циклы записи палитры и когда эта запись доступна
Может я путаю, но мне казалось, что у 6128 можно писать в РУ2 в любой момент, разве нет?
Improver
30.09.2024, 13:02
Может я путаю, но мне казалось, что у 6128 можно писать в РУ2 в любой момент, разве нет?Не совсем. Если запустить моделирование схемы ПК-6128ц, то там микросхемы К155РУ2 блокируются 8 раз на время ССИ перед КСИ и на 8 строк в конце сигнала КСИ, в это время палитру нельзя записать:
81331
Если ошибок в перерисовке схемы нет, то в реале было также, а в моей схеме (https://github.com/ImproverX/PK-6128c_PP) это было исправлено и запись палитры доступна в любой момент. А как запись палитры была реализована в эмуляторах -- не могу сказать...
А как запись палитры была реализована в эмуляторах -- не могу сказать...
В них даже для 06Ц зоны непрограммируемости не реализованы, кроме VV при включении соответствующей опции, вряд ли с 6128 ситуация лучше. Хотя помню, что по крайней мере в старых версиях Emu (скорее всего так и в новых) для 6128 была странность с непрограммируемостью палитры сразу после прерывания.
Вчера добавлял поддержку формата .cas в свой эмулятор. Добавлял, основываясь на анализе .cas-файлов, которые нашёл.
Всё уже работает (по-крайней мере - те .cas-файлы, которые нашёл - все нормально запускаются), но возможно что-то я упустил. Поэтому есть несколько вопросов:
1. В .cas-файлах могут храниться только Бейсик-программы? или могут быть и какие-то другие?
2. Формат .cas (как я его понял, основываясь на реверсе):
а) 0xD3,0xD3,0xD3,0xD3;
б) ASCII-имя_файла, завершающееся тремя 0x00 подряд;
в) 0x55[0 ... k байт. подряд], завершается 0xE6 (каково макс. возможное значение k?);
г) 0xD3,0xD3,0xD3,0x00;
д) тело_программы [1...n байт];
е) 2 байта контрольной суммы.
Всё ли правильно?
И особенно интересен пункт "в": Может ли вместо 0xE6 быть его инверсия =0x19? И если да - тогда все байты после неё нужно инвертировать?
В тех .cas-файлах, что удалось найти, везде только 0xE6.
Improver
30.09.2024, 14:24
1. В .cas-файлах могут храниться только Бейсик-программы? или могут быть и какие-то другие?В этом формате могут храниться файлы Бейсика, записанные по команде CSAVE, BSAVE и файлы Монитора-отладчика.
2. Формат .cas (как я его понял, основываясь на реверсе):
...
Всё ли правильно?
Там примерно так должно быть:
Формат CSAVE в CAS следующий:
- 4 байта 0D3h
- имя (до 127 байт)
- 3 байта 0h
- заголовок 768 байт 55h
- синхробайт 0E6h
- 3 байта 0D3h
- байт 0h
- байты файла ==========
- 3 байта 0h
- младший байт контр. суммы всех байтов файла без переноса
- старший байт контр. суммы всех байтов файла без переноса
Формат BSAVE в CAS следующий:
- 4 байта 0D2h
- имя (до 127 байт);
- 3 байта 0h
- заголовок 256 байт 0h
- синхробайт 0E6h
- ст., мл. байт адреса начала;
- ст., мл. байт адреса конца;
- байты файла ==========
- 1 байт контр. сумма всех байтов файла без переноса
Формат Монитора-отладчика совпадает с BSAVE, только имя файла ограничено до 11 байт.
Некое описание форматов Вектора я собрал вот тут (https://github.com/ImproverX/RW-player/blob/main/Formats.txt), если что...
Ok. Значит я правильно разобрал .cas-формат. И всегда только 0E6h. Без инверсии.
- байты файла ==========
- 3 байта 0hВот тут неясность: Я считал, что эти 3 байта 0 - входят в тело файла. И их туда включаю. В Бейсике (который в базовой поставке, v2.5 вроде) есть две ячейки в памяти, в которых хранится начало и конец программы в ОЗУ. И, если исходя из их содержимого вычислить размер программы, то он будет включать в себя эти 3 хвостовых 0.
У меня в эмуляторе так описаны ячейки Бейсика:
enum {BASIC_PRG_CSUM = 0x4015, BASIC_PRG_START = 0x4043, BASIC_PRG_END = 0x4045};
Эти: BASIC_PRG_START, BASIC_PRG_END.
Формат BSAVE в CAS следующий:
- 4 байта 0D2h
- имя (до 127 байт);
- 3 байта 0h
- заголовок 256 байт 0h
- синхробайт 0E6h
- ст., мл. байт адреса начала;
- ст., мл. байт адреса конца;
- байты файла ==========
- 1 байт контр. сумма всех байтов файла без переноса
Формат Монитора-отладчика совпадает с BSAVE, только имя файла ограничено до 11 байт.
Некое описание форматов Вектора я собрал вот тут (https://github.com/ImproverX/RW-player/blob/main/Formats.txt), если что...
Вот за это - Большое Спасибо! Получается, что .cas может содержать не только Бейсик-программы, но и в кодах. И что по содержимому их можно различать. Добавлю в свой эмулятор это.
Improver
30.09.2024, 16:08
Вот тут неясность: Я считал, что эти 3 байта 0 - входят в тело файла. И их туда включаю. В Бейсике (который в базовой поставке, v2.5 вроде) есть две ячейки в памяти, в которых хранится начало и конец программы в ОЗУ. И, если исходя из их содержимого вычислить размер программы, то он будет включать в себя эти 3 хвостовых 0.Возможно и так, по крайней мере я в скетче ардуино-плеера заремил вывод этих трёх нулей, пометив, что они должны быть в файле BAS... Но в любом случае, без нулей в конце программы Бейсик будет выдавать ошибку, поэтому пометил этот момент в формате вывода.
- - - Добавлено - - -
И всегда только 0E6h. Без инверсии.Да.
Похоже - у "Virtual Vector" сносит крышу, если в Бейсике в команде BSAVE указать начальный адрес больше конечного. Пишет в файл какой-то мусор.
В VV 7.15 в конфиге z80 c тактовой 12 МГц тест (https://caglrc.cc/scalar/ware/908/) при запусках/перезапусках может каждый раз выдавать разные странные результаты. При 3 и 6 МГц нормально.
В Emu ошибка в конфиге Vector06c-Z80.cfg
Если включено обращение стеком к квазу и приходит прерывание, то адрес возврата запишется в основную память, не в кваз.
Improver
13.10.2025, 18:19
В Emu ошибка в конфиге Vector06c-Z80.cfg
Если включено обращение стеком к квазу и приходит прерывание, то адрес возврата запишется в основную память, не в кваз.Может наоборот, это правильная эмуляция установки процессора Z80 на Вектор? Там же, вроде, в большинстве вариантов подключения только PUSH/POP/XTHL выдавали сигал СТЕК...
Если это дань аутентичности, то для consistency и ret должен читать из памяти, а не из кваза.
В VV 7.15 в конфиге z80 c тактовой 12 МГц тест (https://caglrc.cc/scalar/ware/908/) при запусках/перезапусках может каждый раз выдавать разные странные результаты. При 3 и 6 МГц нормально.
Тут вопрос еще в том, на какой частоте должен работать таймер при разгоне проца, на половинной от ЦПУ, или на фиксированной? Проблема с тестом происходит из за того, что при частоте ЦПУ свыше 6 МГц таймер начинает делать пропуски относительно ЦПУ и пропуски эти сделаны по принципу - после каждой команды ЦПУ выполняем обработку таймера, или пропускаем, и все бы ничего, но команды ЦПУ имеют разную длину по тактам поэтому и торможение получается не очень равномерное. Можно сделать, чтобы таймер после 6МГц тоже разгонялся вместе с СПУ, тогда все будет стабильно работать.
У меня нет сомнений или вопросов по поводу таймера в клонах вектора, частота таймера фиксированная 1.5 МГц (кроме кристы 2), тем более советские ВИ53 просто не тянут 3 МГц. Во всех известных высокочастотных векторах (реализации в FPGA и турбо+) используется этот подход, в турбо+ дополнительно проц тормозится при обращении к старым микросхемам, чтобы они успевали.
Если в современном клоне вектора предполагается использование микросхем таймера способных работать на более высоких частотах или реализация в FPGA, то эти более высокие частоты должны переключаться явным образом (вероятно через какой-нибудь порт). Примеров такого на данный момент не знаю.
- - - Добавлено - - -
Ситуация с таймером аналогична AY, его же частоту не увеличивают при увеличении частоты проца. А таймер в векторе тоже звуковое устройство.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot