nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 10:50



Reply to topic  [ 35 posts ]  Go to page Previous  1, 2, 3  Next
Разработка эмулятора ЮТ88 
Author Message
Writer

Joined: 14 Nov 2007 06:56
Posts: 11
Location: 83.167.105.95
Reply with quote
Post 
И на retro.bip.ru образ ЮТ88 битый... потестил чексуммы - не совпадают, + некорректный опкод


17 Nov 2007 08:00
Profile
Devil

Joined: 26 May 2003 06:57
Posts: 859
Reply with quote
Post 
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). Фонт - действительно битый, точнее - ошибки распознавания, например вместо тройки русская буква З. Ну и других полно, если просмотреть в графике.


18 Nov 2007 08:30
Profile WWW
Banned
User avatar

Joined: 20 Mar 2005 13:41
Posts: 2141
Location: От туда
Reply with quote
Post 
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ятся со значением маски. Это происходит из-за того, что в даном случае кодирование информации идет по фазе, что может дать как прямой, так и инверсный вариант приема данных. При частотном методе кодирования (как в Спектруме) этого не наблюдается, т.к. бит кодирует длительность периода а не фаза.


Last edited by HardWareMan on 05 Jan 2014 03:54, edited 1 time in total.



18 Nov 2007 09:35
Profile
Writer

Joined: 14 Nov 2007 06:56
Posts: 11
Location: 83.167.105.95
Reply with quote
Post 
Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.


19 Nov 2007 02:42
Profile
Banned
User avatar

Joined: 20 Mar 2005 13:41
Posts: 2141
Location: От туда
Reply with quote
Post 
grindars wrote:
Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.

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


Last edited by HardWareMan on 05 Jan 2014 03:54, edited 1 time in total.



19 Nov 2007 03:37
Profile
Devil

Joined: 26 May 2003 06:57
Posts: 859
Reply with quote
Post 
grindars wrote:
Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.

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


19 Nov 2007 06:47
Profile WWW
Writer

Joined: 14 Nov 2007 06:56
Posts: 11
Location: 83.167.105.95
Reply with quote
Post 
b2m wrote:
grindars wrote:
Я эмулирую не процедуру, а порт магнитофона! Посылаю побитно весь файл, каждый бит повторяю дважды - сначала оригинальный, потом инвертированный, и этот бит возвращаю в бите 0 порта.

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


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


19 Nov 2007 07:14
Profile
Devil

Joined: 26 May 2003 06:57
Posts: 859
Reply with quote
Post 
grindars wrote:
- первые 20 чтений

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

grindars wrote:
- 0xFF

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

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

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

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

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


19 Nov 2007 07:45
Profile WWW
Banned
User avatar

Joined: 20 Mar 2005 13:41
Posts: 2141
Location: От туда
Reply with quote
Post 
Если он дает 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 бод. Это слышно даже на слух, если сравнивать с тем же "Орионом" - частота ниже. При частотном кодировании все данные рассматриваются как единый поток бит и время, которое тратится на проверки, компенсируется. Поэтому у "Спектрума" звук ровный.


Last edited by HardWareMan on 05 Jan 2014 03:55, edited 1 time in total.



19 Nov 2007 08:24
Profile
Devil

Joined: 26 May 2003 06:57
Posts: 859
Reply with quote
Post 
HardWareMan wrote:
Именно поэтому, звук звучит не ровно, а как бы "с хрипцой".

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

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

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


19 Nov 2007 08:58
Profile WWW
Writer

Joined: 14 Nov 2007 06:56
Posts: 11
Location: 83.167.105.95
Reply with quote
Post 
А что к чему лучше привязывать - CPU ко времени, или "магнитофон" ко CPU?


19 Nov 2007 09:01
Profile
Devil

Joined: 26 May 2003 06:57
Posts: 859
Reply with quote
Post 
Я в своём эмуляторе всё привязывал к тактам процессора. А количество тактов, которое нужно сэмулировать - к реальному времени.


19 Nov 2007 09:04
Profile WWW
Writer

Joined: 14 Nov 2007 06:56
Posts: 11
Location: 83.167.105.95
Reply with quote
Post 
Ко времени привязать не так-то просто... в целевой оси вообще нет API для времени (есть правда uptime, но он в секундах :) )


19 Nov 2007 09:07
Profile
Banned
User avatar

Joined: 20 Mar 2005 13:41
Posts: 2141
Location: От туда
Reply with quote
Post 
b2m wrote:
HardWareMan wrote:
Именно поэтому, звук звучит не ровно, а как бы "с хрипцой".

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

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


Last edited by HardWareMan on 05 Jan 2014 03:55, edited 1 time in total.



19 Nov 2007 10:35
Profile
Devil

Joined: 26 May 2003 06:57
Posts: 859
Reply with quote
Post 
grindars wrote:
Ко времени привязать не так-то просто... в целевой оси вообще нет API для времени (есть правда uptime, но он в секундах :) )

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


19 Nov 2007 12:22
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 35 posts ]  Go to page Previous  1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.