Разработка эмулятора ЮТ88

grindars · Post by **grindars** » 17 Nov 2007 08:00

И на retro.bip.ru образ ЮТ88 битый... потестил чексуммы - не совпадают, + некорректный опкод

b2m · Post by **b2m** » 18 Nov 2007 08:30

HardWareMan wrote:
b2m wrote:Почти то-же самое, что и RK,RKR, только синхробайты перед КС.

Адрес первого байта (2 байта, старший байт первый)
Адрес последнего байта -- // --
Данные
Синхробайты (00 00 E6)
Контрольная сумма -- // --
Кстати, да: у "Спеца" контрольная сумма без синхробайта и сразу за данными, а вот у "Ориона" - с синхробайтом.

PS Исправил - запарился.

У "Спеца", в отличие от остальных, ещё и адреса в другом формате - младший байт первый.

grindars wrote:И как я понимаю, эти данные обрабатывает сам монитор? что ж тогда он бред выдает? (потестил Emu80 под Wine - работает)

Ну, как бы, не совсем так. Если ты перехватываешь процедуру чтения байта, то это твоя задача - подождать синхробайта, т.к. на входе она имеет в A максимальное количество бит, которое будет считывать. Обычно A=8, но если нужен поиск синхробайта, то A=0FFh, и считывание продолжается до тех пор, пока не придёт байт 0E6h, после чего считается байт данных.

grindars wrote:И на retro.bip.ru образ ЮТ88 битый... потестил чексуммы - не совпадают, + некорректный опкод

У меня на 100% совпадает файл монитора с тем, что там в тексте выложено (MonitorF.txt). Фонт - действительно битый, точнее - ошибки распознавания, например вместо тройки русская буква З. Ну и других полно, если просмотреть в графике.

HardWareMan · Post by **HardWareMan** » 18 Nov 2007 09:35

b2m wrote:
HardWareMan wrote:
b2m wrote:Почти то-же самое, что и RK,RKR, только синхробайты перед КС.

Адрес первого байта (2 байта, старший байт первый)
Адрес последнего байта -- // --
Данные
Синхробайты (00 00 E6)
Контрольная сумма -- // --
Кстати, да: у "Спеца" контрольная сумма без синхробайта и сразу за данными, а вот у "Ориона" - с синхробайтом.

PS Исправил - запарился.
У "Спеца", в отличие от остальных, ещё и адреса в другом формате - младший байт первый.

Угу.

b2m wrote:
grindars wrote:И как я понимаю, эти данные обрабатывает сам монитор? что ж тогда он бред выдает? (потестил Emu80 под Wine - работает)
Ну, как бы, не совсем так. Если ты перехватываешь процедуру чтения байта, то это твоя задача - подождать синхробайта, т.к. на входе она имеет в A максимальное количество бит, которое будет считывать. Обычно A=8, но если нужен поиск синхробайта, то A=0FFh, и считывание продолжается до тех пор, пока не придёт байт 0E6h, после чего считается байт данных.

На самом деле достаточно взвести бит D7. Для этого используется команда перехода JP/JM. Если бит взведен, то процедура чтения байта проверяет совпадение принятого байта на 0хЕ6 или 0х19 после каждого принятого бита, дополнительно восстанавливая счетчик бит. Если был принят 0хЕ6, то в переменную маски заносится 0х00 и счетчик бит устанавливается на 0х08, после чего переходит на начало подпрограммы вызывая прием байта. Если был принят 0х19, то в маску записывается 0xFF. На выходе из подпрограммы полученные данные XORятся со значением маски. Это происходит из-за того, что в даном случае кодирование информации идет по фазе, что может дать как прямой, так и инверсный вариант приема данных. При частотном методе кодирования (как в Спектруме) этого не наблюдается, т.к. бит кодирует длительность периода а не фаза.

grindars · Post by **grindars** » 19 Nov 2007 02:42

Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.

HardWareMan · Post by **HardWareMan** » 19 Nov 2007 03:37

grindars wrote:Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.

А ты фазу меняешь? Ты привязал ко времени эмуляции (чтобы относительно проца скорость "воспроизведения" была нормальной)?

b2m · Post by **b2m** » 19 Nov 2007 06:47

grindars wrote:Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.

Потенциальных вопросов может быть несколько:
- какой длинны начальная синхропоследовательность?
- каково её содержание?
- сколько тактов процессора длится "полубит"?
- в каком порядке идут биты (старший или младший бит идёт первым)?

grindars · Post by **grindars** » 19 Nov 2007 07:14

b2m wrote:
grindars wrote:Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.
Потенциальных вопросов может быть несколько:
- какой длинны начальная синхропоследовательность?
- каково её содержание?
- сколько тактов процессора длится "полубит"?
- в каком порядке идут биты (старший или младший бит идёт первым)?

- первые 20 чтений
- 0xFF
- каждое чтение сменяется
- старший первый

b2m · Post by **b2m** » 19 Nov 2007 07:45

grindars wrote:- первые 20 чтений

В реале - 256 байт, можно и короче, но не настолько (2,5 байта это очень мало).

grindars wrote:- 0xFF

В реале - 256 байт 0x00, затем один 0xE6

grindars wrote:- каждое чтение сменяется

Абсолютно неправильно. Чтение бита происходит следующим образом:
- ждём смену сигнала
- записываем бит (на что сменилось)
- ждём определённое время (зависит от константы записи)

Ожидание в третьем пункте должно пропускать смену сигнала в случае, когда два рядом стоящих бита имеют одинаковое значение.
Ожидание в первом пункте предполагает как минимум два чтения.

З.Ы. Может ты и добьёшься правильного результата, если смену сигнала будешь делать каждое второе чтение, но это всё равно неправильно...

HardWareMan · Post by **HardWareMan** » 19 Nov 2007 08:24

Если он дает 0xFF, то надо все инвертировать. Длительность бита при 1200 бод будет примерно 1/1200=0,833мс или 833мкс. Это будет 1666.66 тактов процессора при 2МГц (для специалиста). Выгружаем так: 256 байт 0х00, затем 0хЕ6, затем адреса, данные и кс. В общем, содержание ясно. А вот эмуляция бит должна быть такой:
Берем первый бит байта (начинаем с D7) и в зависимости от его состояния выставляем следующий уровень в порту:
0: 416,5мкс 0 / 416,5мкс 1
1: 416,5мкс 1 / 416,5мкс 0
Берем следующий бит и повторяем. Далее, когда выдано 8 бит (весь байт) есть одна особенность. Дело в том, что тайминги выдерживаются только внутри выгрузки байта, но когда мы выгрузили байт, в типовой программе выгрузки происходит следующее: Выгрузка байта, Увеличение адреса, Проверка на конец, Повтор если не конец. Так вот, все время, требуемое для действий Увеличение адреса, Проверка на конец, Повтор если не конец держится последний уровень, тем более, что обычно происходит вызов подпрограммы сравнения HL и DE. Это, конечно, компенсируется такими же задержками, присутствующими в программе загрузки - алгоритм одинаков, разница только в направлении. Именно поэтому, звук звучит не ровно, а как бы "с хрипцой". Это надо учитывать, иначе можно пролететь (хотя для 1200 у меня работало). И еще, не знаю как у остальных, но у "Спеца" выгрузка заметно медленее - примерно 1100 бод. Это слышно даже на слух, если сравнивать с тем же "Орионом" - частота ниже. При частотном кодировании все данные рассматриваются как единый поток бит и время, которое тратится на проверки, компенсируется. Поэтому у "Спектрума" звук ровный.

b2m · Post by **b2m** » 19 Nov 2007 08:58

HardWareMan wrote:Именно поэтому, звук звучит не ровно, а как бы "с хрипцой".

Нет, не поэтому. Начальный тон тоже выдаётся той-же процедурой, вместо подпрограммы сравнения BC и HL там стоит два раза XTHL (самая медленная команда, 5 циклов, 18 тактов), и звук при этом ровный. "Хрипота" появляется из-за того, что смодулированный записываемыми данными сигнал не является гармоничным (если это не нули или FF).

HardWareMan wrote:Это, конечно, компенсируется такими же задержками, присутствующими в программе загрузки

Достаточно точно компенсируется. В последнем бите задержка специально укорочена.

grindars · Post by **grindars** » 19 Nov 2007 09:01

А что к чему лучше привязывать - CPU ко времени, или "магнитофон" ко CPU?

b2m · Post by **b2m** » 19 Nov 2007 09:04

Я в своём эмуляторе всё привязывал к тактам процессора. А количество тактов, которое нужно сэмулировать - к реальному времени.

grindars · Post by **grindars** » 19 Nov 2007 09:07

Ко времени привязать не так-то просто... в целевой оси вообще нет API для времени (есть правда uptime, но он в секундах

)

HardWareMan · Post by **HardWareMan** » 19 Nov 2007 10:35

b2m wrote:
HardWareMan wrote:Именно поэтому, звук звучит не ровно, а как бы "с хрипцой".
Нет, не поэтому. Начальный тон тоже выдаётся той-же процедурой, вместо подпрограммы сравнения BC и HL там стоит два раза XTHL (самая медленная команда, 5 циклов, 18 тактов), и звук при этом ровный. "Хрипота" появляется из-за того, что смодулированный записываемыми данными сигнал не является гармоничным (если это не нули или FF).

Если ты не слышал, звук рванный даже на раккорде. Сравни как звучит пилоттон у Спектрума и выгрузеа 0х55 (0хАА) у Спеца.

b2m · Post by **b2m** » 19 Nov 2007 12:22

grindars wrote:Ко времени привязать не так-то просто... в целевой оси вообще нет API для времени (есть правда uptime, но он в секундах )

Ну ты же как-то эмулируешь, 50 раз в секунду по 40000 тактов, или как там. Это что за система такая? А даже если и в секундах, можно сравнивать время в эмулируемой системе и реальное время, и корректировать количество тактов в одном цикле эмуляции (который 50 раз в секунду выполняется, или как там у тебя).