Rev 364 | Blame | Compare with Previous | Last modification | View Log | Download
---=== общая инфа ===---1. в недооси запускается СЕРВЕР играния аигрека.Сервер в смысле что он сначала ждёт коннекта на ойпи недооси и наопределенном порту. Как соединение открылось (кто-то приконнектился),начинается игра того, что приходит. Как только соединение закрывается, всеаигреки затыкаются и софт начинает ждать следующего соединения.2. пц шлёт дамп регистров (в простейшем случае). В ответ пц получаетсинхронизацию (каждый инт от спектрума приходит пакет синхронизации) иодновременно -- квитанцию о том, что какой-то конкретный пакет уже проигран(если было требование от пц послать квитанцию)3. Как расширить на проигрывание диги, в т.ч. совместно с 50гц музыкой -- покахз.4. Предполагается, что и пц, и спектрум шлют пакеты (группы пакетов) при помощиTCP_NODELAY. При этом всё равно присутствующая буферизация допустима в каналепц->спектрум, но недопустима в канале спектрум->пц (т.е. пц должен разгребатьвсё пришедшее сразу и без задержек, а спектрум может выгребать пакеты по 1штуке за инт).5. Разбор пришедших данных, объединение их в пакеты и проч. осуществляетсяпобайтно, по порядку пришедших байт. При этом следует учитывать, что границапакетов протокола не соответствует границам пакетов TCP-IP.---=== Основы протокола ===---TCP-ПОРТ, который слушает сервер на спектруме -- 16729 (0x4159, соотвeтствуеткодам символов 'A' и 'Y')Общий формат пакетов.Каждый пакет начинается с байта, который определяет собственно тип пакета. Типыи номера пакетов, которые идут в каком-то одном направлении совершенноотличаются от типов и номеров пакетов в обратном направлении.Направление пакета помечается как ZX>> (zx->pc) или ZX<< (zx<-pc). Тип пакетапомечается байтом в hex или кратким описанием 1 словом.---=== Базовые пакеты ZX>> ===---00 ZX>> HELLOОписание:"Приветствие", посылаемое 1 раз сразу после открытия соединения.Формат:+01: байт, длина последующей строки (0..255 байт)+02.. -- строка символов указанной длины, НЕ zero-terminated.Примечание: это приветствие можно отображать на экране, но оно НЕ являетсяверсией или чем-то подобным, и может изменяться со временем либо рандомно дляодной и той же программы.01 ZX>> FRAMESYNCОписание:Посылается каждый frame int.Формат:+01..+04: счётчик в формате little-endian, каждая очередная посылка такогопакета инкрементирует посылаемый счётчик на 1. Начальное значение счётчика неопределено.02 ZX>> SYNCRPLYОписание:Посылается непосредственно после пакета 01 ZX>> , если в этом фрейме былазагрузка регистров в AY на основе пришедшего пакета ZX<< и одновременно былотребование послать квитанцию.Формат:+01..+04: байты, присланные в пакете ZX<< SYNCREQ.---=== Базовые пакеты ZX<< ===---00 ZX<< (SHUTUP)Описание:Выключить все источники звука и более ничего не делать. (не отменяет требованиепосылки синхронизации ZX>> FRAMESYNC ).Формат:[[дополнительные байты отсутствуют]]Примечание: может использоваться для (пере)синхронизации пц со спектрумом путёмпосылки кол-ва нулей большего, чем размер любого другого пакета ZX<< . Дляэффективной пересинхронизации желательно, чтоб zx мог распарсить таких пакетовнесколько (в идеале -- все, что накопились либо достаточно большое число) заодин фрейм.01 ZX<< DUMPОписание:проиграть в ближайший frame int данный дамп регистров в один AY/YM.Формат:+01..+14: байты, записываемые соответственно в регистры аигрека 0..13Примечание: !!!ВАЖНО!!! Если в регистр 13 (последний байт в дампе) записывается0xFF -- это означает, что в регистр 13 писать ВООБЩЕ НИЧЕГО НЕ НАДО.Данное требование связано с тем, что запись в регистр 13 аигрека имеет побочныйэффект в виде ПЕРЕЗАПУСКА огибающей. Т.к. это не нужно делать 50 раз в секунду,то по традиции величина FF обозначает отсутствие записи вообще.02 ZX<< SYNCREQОписание:Требование послать ZX>> SYNCRPLY после вывода в AY следующего в потоке пакетаZX<< DUMPФормат:+01..+04: байты, которые неизменными следует послать в пакете ZX>> SYNCRPLY.... пока всё ...