А еще гигаскринить можно. Пора начинать уже писать демо для ЦЦ.
Вид для печати
А еще гигаскринить можно. Пора начинать уже писать демо для ЦЦ.
Взглянул пзу Ocean-250 с сайта AZmastera и у меня создалось впечатление, что это или шутка/прикол или пзу (очень) плохо считалось. Или это некий набросок, который не работал.
Мне тоже так показалось. Но в целом ничего не говорит против версии, что это действительно был вариант "Океана" (часть хотя бы).
Пара слов про доступ к дополнительной памяти и про 512 Кб.
Приземленная часть.
Для удобного использования дополнительной памяти нужны 2 основные функции: возможность обмениваться с ней данными и возможность запускать находящийся там код.
ПЗУ океана частично (в пределах 64 Кб допОЗУ) реализует функцию обмена. Сравнительно просто можно расширить доступную память до максимума, вызывая пзушные процедуры с обходом ущербного формирования содержимого порта 0C1h. А вот для запуска кода в допОЗУ штатных возможностей нет.
Дальше фэнтезийная часть. Что могли бы сделать разработчики. Как минимум - разместить в пзу нормальные процедуры обмена и запуска.
Как максимум - разработать удобную систему управления памятью.
Если не сильно отрываться от земли, то они могли сделать очень простую вещь - зафиксировать часть озу 8000-FFFF нулевой страницы и запретить ее переключение. При этом младшими битами порта 0C1h выбиралась бы только страница для диапазона 0000-7FFF. Пользуясь "островом стабильности" 8000-FFFF можно было бы и размещать там любые специализированные процедуры обмена (в т.ч. удобный и быстрый обмен с дополнительной страницей видео), и передавать управление в другие страницы.
Для этого нужно было подавать на КП12 вместо A16-A18 следующие (A16)-(A18):
_A15=not A15
(A16)=A16 and _A15
(A17)=A17 and _A15
(A18)=A18 and _A15
Учитывая, сколько авторы всего наворотили в океане, отсутствие такого или подобного диспетчера можно объяснить скорее непродуманностью, а не желанием упростить схему.
В emu для увеличения памяти до 512 Кб нужно в разделе mem : Memory {
поменять строку
size=20000
на
size=80000
Также прилагаю "фэнтезийный" конфиг, в котором озу переключается только в дипазоне 0000-7FFF. ДОС и монитор реагируют на такое изменение спокойно, т.к. они доступаются к допОЗУ только в этом диапазоне.
Про исполнение кода из переключаемых банков в то время вряд ли задумывались, стандарт MSX только-только появился.
Вот еще интересно, как предполагалось использовать управление банками ПЗУ. Тоже вроде бы хороший задел, но никаких следов софта или документации :(
Могу отметить положительный момент - пока что вижу, что дос и монитор обращаются к допОЗУ только через стандартные процедуры. А значит в принципе организация памяти может быть практически любая (в разумных пределах), главное чтобы про нее знали процедуры обмена.
Про ПЗУ вижу на схеме, что если не брать в расчет перемычки, то просто можно выбрать одну из 4х страниц пзу. С перемычками все усложняется, не разбирался.
Перейду сюда, чтобы не оффтопить в теме про тетрис.
Вот wav, который построил emu, который запускал я.Цитата:
Сообщение от tnt23
Вложение 68427
Нетленку вслепую сделать сложно, пока не могу.Цитата:
Сообщение от tnt23
- - - Добавлено - - -
Насчет выгрузки в wav с реала. Если получится загрузить emuшный wav, то лучше такой рам-диск и выгрузить. Если не получится - тогда желательно что-нибудь содержательное все же записать на рам-диск, чтобы не пустота была.
Ввести через магнитофонный вход ничего не получается. Подозреваю, что входная схема возбуждается, т.к. в отсутствие входного сигнала на ноге DD78-20 присутствует меандр с частотой 2.5КГц, а на ноге -21 прямоугольный сигнал с заваленным задним фронтом и той же частотой.
А что с выгрузкой, или пока не пробовал?
Вчера выгрузил пустой файл размером 1 блок (в CP/M, командами SAVE 1 POPS и WRITE POPS), но не смог пришпилить полученный WAV по причине большого размера. Сегодня вечером сделаю.Цитата:
Сообщение от ivagor
А в чем причина интереса к записи на ленту?
tnt23, спасибо, что попробовал. Рам диск с пустым файлом наверно не стоит записывать. Или загрузить в океан через RS-232 какой-нибудь файлик или в мониторе хотя бы пару байт изменить на ненулевые перед сохранением на рам-диск.
Интерес к магнитофонному обмену океана связан с его нестандартностью, b2m для загрузки даже какой-то хитрый фильтр приделал, интересно, как он сработает с реальным wavом.
Даже те номиналы что указаны как исправленные в последующих журналах не верные. Правильные номиналы конденсаторов фильтров в цепях чтения записи на магнитофон придется подбирать опытным путем, кстати и схему узла записи и чтения тоже можно немного доработать. По аналогии с Ленинградом.Цитата:
Сообщение от tnt23
Да я не прочь бы попробовать и с неправильными. Беда в том, что на выходе первого же каскада имеем устойчивую генерацию 2.5КГц, и я не знаю, правильно это или нет.Цитата:
Сообщение от perestoronin
Вот вчерашний файл (записан из CP/M командой WRITE): http://sensi.org/~tnt23/ok240/pops.wavЦитата:
Сообщение от ivagor
К сожалению wav с реала в emu не прочитался. Пробовал и левый канал и правый и вместе.
Зато я узнал, что в dos можно грузить отдельные файлы. Тот файл, который я выложил ранее, выгружен из монитора, это рам-диск целиком. Попробовал выгрузить из доса и потом загрузить (тот же IBASIC) - получилось, только странное завершение загрузки, почему-то сам не переходит к приглашению доса, пришлось нажать Ctrl+C. После этого файл запускается с рам диска.
Возможно, неточно эмулируется или вообще не поддерживается межблочный промежуток (на ППА для магнитофонного входа есть 2 входа, один для детектора пауз, второй собственно для потока бит).Цитата:
Сообщение от ivagor
У меня насчет ожидания доса после загрузки файла появилась идея. Появилась она вчера после выключения компа, поэтому на практике я ее пока не проверил. Возможно это сделано для удобства загрузки нескольких файлов подряд, ближе к вечеру проверю.
Команда READ в CP/M выходит из ожидания по ESC, кстати.
Идея оказалось правильной, дос действительно ждет загрузки следующих файлов. Т.е. можно загрузить несколько файлов подряд, а когда все - пользователь жмет esc или ctrl+c.
Вопрос совместимости реала с эмулем по-прежнему открыт? (как минимум в сторону от реала к эмулю, в реал мне не загрузить пока ничего)
Вопрос открыт. Если посмотреть на wav с реала, то видны предполагаемые проблемы. После паузы уровень зашкаливает и средняя точка уезжает. Можно попробовать вытащить это обработкой (пока не особо хочу), можно попробовать выключить какую-нибудь примочку на звуковухе (если запись была через микрофонный, то лучше попробовать через линейный, отключить ару, если есть такая возможность, включить фильтрацию DC, если есть такая возможность). Еще один очень специфический вариант - сделать свою выгрузку почти в родном формате, но с дополнительным пилотом в начале, чтобы уровни пришли в чувство (тоже пока не хочу, но если кто сделает, то я только за).
Ок, я ленился и писал с реала в микрофонный вход близлежавшего неттопа. Устыдяся, достану с полки Zoom R8 и сделаю студийную запись.
Замыканий нет линий узла чтения на цифровые выходы ? Может вкралась ошибка в разводку ?Цитата:
Сообщение от tnt23
Узел чтения может собрать на макетке и отладить отдельно от платы ? Деталей в нем немного.
ОУ какой в узле чтения использован ? Если не тот что по схеме, то потребуется подбор резисторов и довешивание конденсаторов, чтобы убрать паразитную генерацию.
Студийному монитору — студийный магнитофон.Цитата:
Сообщение от tnt23
Нужно проверять. Хорошо бы кто-нибудь из коллег уже собрал свою реплику, а то не успеваю все ;)Цитата:
Сообщение от perestoronin
Вот эта мысль меня тоже посещала, но пока не оформилась в действие.Цитата:
Сообщение от perestoronin
Вроде такой же, 544УД2, только не уверен, А или Б.Цитата:
Сообщение от perestoronin
1. Прочитал в МПСиС 1986/4, С. 78, что
"Программы обмена с бытовым магнитофоном, входящие в состав Монитора 240.2, используют два формата записи: стандартный (скорость передачи 500 бод) и высокой плотности записи с фазоимпульсным кодированием (6000 бод)."
Чисто из спортивного интереса - как в мониторе или досе записать (или прочитать) со стандартной скоростью? И где в пзу соответствующие процедуры?
2. В дополнение к теме про регенерацию. После прочтения МПСиС 1986/4, С. 75 у меня создалось впечатление, что в океане, в отличие от вектора, можно абузить скролл для частичного ограничения регенерации. Правда полезных применений у этой возможности не вижу.
Эту булочку здесь (чуть ли не в этом самом топике даже) долго и печально жевали. Пришли к выводу, что никакими 6000 бодами в прошивках, которыми мы располагаем, не пахнет, и все, что мы сегодня можем записывать-считывать, является обычным стандартным 500-бодовым писком.Цитата:
Сообщение от ivagor
Совершенно не согласен.Цитата:
Сообщение от tnt23
1. Возьмем для примера выложенный IBASIC из доса. Длительность информационной части там чуть больше 16 секунд, за это время передается 8 килобайт. Средняя скорость более 4000 бит/секунду.
2. Возьмем рам-диск с IBASICом, выгруженный из монитора. Длительность информационной части примерно 97 секунд, 64 килобайта, средняя скорость 5400 бит/секунду. Вероятно скорость здесь выше из-за того, что 5/6 файла, в отличие от п.1. составляют нули.
Полученные средние скорости меньше реальных скоростей передачи, т.к. в файле есть паузы и служебная информация. Вполне верю, что низкоуровневая скорость передачи может достигать и 6000 бит.
А вот как записать или прочитать со скоростью 500 бит/секунду я не знаю.
Минуточку, это все выгрузка, сделанная на эмуляторе? Для чистоты эксперимента мне, видимо, следует взять выложенный IBASIC и сохранить его из доса на реале.Цитата:
Сообщение от ivagor
Тоже руки тянутся да грошей нема заказать основные платки.Цитата:
Сообщение от tnt23
Если бы кто-то заказал из Китая, я бы себе парочку выкупил (в зеленой маске) в Москве.
Я умею заказывать только в местных лавочках, а в них надо, чтобы видимость приемлемой цены получилась, заказывать столько плат, что с ними потом на барахолке висеть пятилетку или дольше.
Потому я лучше на хвост кому-нибудь более шустрому припаду.
Но только с зеленой маской, а не красной или тем более голубой ) Да и белые и черные тоже ни к чему - на них дорожки плохо просматриваются а на белых и синих канифоль некрасиво смотрится
- - - Добавлено - - -
Эти прошиваются статическим электричеством очень легко и склонны к паразитной генерации.Цитата:
Сообщение от tnt23
ivagor, вот два вава: файл длиной 2560 байт, записанный из CP/M командой WRITE, и весь кваз (подозреваю, что 64Кбайт), выгруженный из Монитора командой W.
1. http://sensi.org/~tnt23/ok240/ok240file.zip
2. http://sensi.org/~tnt23/ok240/ok240disk.zip
Писалось в моно режиме с дискретизацией 44.1КГц, уровень записи был выставлен чуть менее 0дБ.
Вложение 68498
Спасибо за файлы, но я уже когда их посмотрел в audacity, стало понятно, что в emu они не загрузятся. Вероятно это работа АРУ звуковухи. Нерилтаймовый декодер таких файлов умные люди скорее всего сделать могут, а вот чтобы в эмулятор грузить с использованием стандартного софта - это значительно более сложная задача.
Но скорость можно оценить:
ok240file.WAV - примерно 3600 бит/секунду
ok240disk.WAV - примерно 4480 бит/секунду
Это явно не 500 бит/секунду.
По поводу обмана ару могут быть разные варианты. У меня такая идея - если это ару звуковухи, то можно в один канал подать синусоиду или меандр с диапазоном сигнала примерно соответствующим установившемуся сигналу океана, а в другой канал собственно писать океанский сигнал. Не призываю это делать, но способы есть, может и более простые и правильные.
Вряд ли звуковуха (портастудия для записи музыкальных инструментов) имеет какую-то авторегулировку по входу. Так что скорее всего мы имеем почти не искаженную трактом звукозаписи картину вытекающих из Океана магнитоданных.
Факт - при записи океан в цифре выдает 3 возможных уровня: "средний", "положительный", "отрицательный". Значит то, что мы видим в wave - это результат работы или тракта воспроизведения океана, или тракта записи звуковухи или их комбинации. Тракт океана без устройства оцифровки проверить не получится, зато (при большом желании) можно проверить тракт записи звуковухи. Или как я предложил в предыдущем посте или даже без океанского сигнала просто подать на звуковуху после молчания сигнал с постоянной амплитудой и посмотреть, как он оцифруется, особенно начало.
Прочитал значительную часть этой темы и призадумался. Оказалось, что нет даже единства и согласия насчет уровней, которые выдает океанский магнитофонный цап. Причем разница не только в предполагаемых уровнях, но и в направлении нумерации. Имеет смысл посмотреть амплитудную характеристику этого цапа, для чего можно записать с него пилу.
Попробую сначала просто записать прямоугольник на 1 или 10 килогерц.
Подумал, что лучше сделать не специализированный генератор пилы, а более общий вариант с возможностью задания произвольного сигнала. Хотя сам использовал на данный момент только тишину и пилу. tnt23, попробуй, если будет время. Исходник с комментариями прилагается. После запуска пауза 2 секунды, потом пила с высокой частотой, потом пауза 1 секунда и т.д. Общее время менее полминуты.
Как вариант ?Цитата:
Сообщение от ivagor
https://ru.wikipedia.org/wiki/HDB3
ivagor, запись тут: http://sensi.org/~tnt23/ok240/tapdac.zip
На картинке: вверху выход "Океана" после конденсатора (на разъеме), внизу - до конденсатора.
Вложение 68528
"Кто виноват и в чем секрет"
Попробовал отсортировать уровни для реала, но не уверен, что получилось полностью правильно. И еще этот конденсатор.