Связь двух спектрумов

[AlexCrush]

получается 2 кбайта в секунду пиковая способность

Вопрос остался: кто нибудь в таком виде соединял 2 спектрума?

Я так соединял 2 спектрума. Переделывал игру LastBattle (не могу выложить т.к. все на дискетах где то, вряд ли смогу найти.... блин). Только для связи использовались не магнитофонные порты т.к. там стоят на входе всякие цепочки, отрезающие частоты выше 5 кГц примерно. Использовался порт кемпстон джойстика (бит 0 - на вход есс-но) и порт принтера (тоже 0 бит на передачу, номер порта не стандартный). Достигнута скорость около 4 кб/сек. Передача осуществлялась блоками по 256 байт с контрольными суммами с повторной передачей в случае ошибки (были версии, снижающие скорость передачи в случае повторных ошибок). Работало очень даже прикольно, очень не хватало только защитных таймеров - если связь рвется (у меня иногда рвался провод - там посреди провода была стыковка разъемами джек3.5) где-то посреди передачи байта то все зависает.

Принцип работы: Стороны изначально знают кто приемник, кто передатчик на ближайшее время. Приемник ждет стартового бита от передатчика. Получив его начинает формировать цепочку 01010101010 на своем выходе. При каждой смене уровня передатчик выставляет на своем выходе следующий бит данных, а приемник его считывает.

Т.к. на втором компе не было дискогрыза то в качестве начальной загрузки использовалась фича: входной провод был подключен еще и на магнитофонный вход. Сначала грузился мелкий загрузчик стандартным методом (на передающей стороне была копия процедуры 1218 с изменненным портом). Затем этот загрузчик уже юзал описанный протокол и загружал основной код ласт-баттла.

P.S. нашел какие-то исходники приемника/передатчика которые вроде как раз там и использовал. См. аттачмент (CP866)

[AlexCrush]

распараллеливать математические вычисления (обсчёт сложных вычислений для трёхмерных демонстрашек например).

Думаю это реализуемо только для паралельных портов или при использовании аппаратных приемников/передатчиков. И вот почему:
Передача/прием занимают процессор полностью причем надолго (думаю 1.5 секундная пауза для передачи одного экрана неприемлема в демонтсрашке/экране). Хотя возможно найдутся умельцы...

[Kirill Frolov (500:812/1.507)]

FromNet:

Hемедленно нажми на RESET, Григорьев Валерий!

On Fri, 28 Oct 05 19:34:26 +0400, Григорьев Валерий wrote:

я думаю можно передавать со скоростями (имеется в виду последовательная
передача по порту магнитофона) около 1-2 кб в секунду. Т.о. 48 КБ спектрум
целиком может быть залит сами можете посчитать за какое время

Zhavoronkov Sergejj -- 115200 delal. Ja ogranichilsja na urovne 38400.

; около 160 тактов на 1 бит, частота передачи = 20 кгц, делим на 10 =
количестов бит, получается 2 кбайта в секунду пиковая способность, если провод
хороший и порты чистые не наводят сами на себя шумы )

:-O

При наличии (как у меня в балтике) ппоследовательного порта всё проще конечно
же...
Вопрос остался: кто нибудь в таком виде соединял 2 спектрума?

Spectrum and PC cherez COM-port.

[Kirill Frolov (500:812/1.507)]

FromNet:

Hемедленно нажми на RESET, Чунин Роман!

On Fri, 28 Oct 05 21:53:57 +0400, Чунин Роман wrote:

КАИ можно через LPT соединять!

Scorpion tozhe mozhno.

Tol'ko skorpion prakticheski uzhe imeet programmnyjj RS232.

[GriV]

Думаю это реализуемо только для паралельных портов или при использовании аппаратных приемников/передатчиков. И вот почему:
Передача/прием занимают процессор полностью причем надолго (думаю 1.5 секундная пауза для передачи одного экрана неприемлема в демонтсрашке/экране). Хотя возможно найдутся умельцы...

Согласен, здесь правда уже грили что два спекка соединяли со скоростью 112 кбит, это конечно очень круто. Но не в этом дело, а в том, что такой вариант кластеризации не использовался совсем.
Если изначально брать схему стандартного спекка, а они почти все были с кемпстон-портами, то в случае полного делегирования функций можно использовать второй (более слабый) спектрум как функциональный придаток (изначально отвергая его активное участие в процессе - на него просто передаётся информация, а он уж её крутит вертит как надо).
В кемпстон порт выдаётся сразу 5 бит информации (здесь не совсем ясно, может быть там нас самом деле используется 8 сигнальных линий, однако у классического джойстика оправшивается только 5), плюс 1 бит по линии магнитофона. Здесь вариантов очень много, однако скорость будет в разы повышена, по сравнения с тем вариантом который я предлагал выше.

Насчёт программы, которая загружала второй комп. Честное слово, ни за что бы так не догадался, очень хороший вариант. Я всё таки предполагал или зашивать в ПЗУ код управления либо использовать магнитофон для базовой загрузки.

[GriV]

Zhavoronkov Sergejj -- 115200 delal. Ja ogranichilsja na urovne 38400.

Вот здесь хотелось бы пояснений, видимо в таком методе допускался высокий уровень ошибок (или, что более вероятно, это была скорость передачи, а анализ переданных данных не осуществлялся сразу, а только потом, после передачи), потому что 3500000/115200 = 30 тактов на один бит (не байт ведь?), при том что минимальная команда чтения порта 12 тактов. Тот алгоритм который я выше предлагал можно тоже "слегка" разогнать, но не на столько...

P.S. Под пояснениями я предполагаю конкретный алгоритм

[Advertiser]

[GriV]

Согласен, здесь правда уже грили что два спекка соединяли со скоростью 112 кбит, это конечно очень круто. Но не в этом дело, а в том, что такой вариант кластеризации не использовался совсем.
Если изначально брать схему стандартного спекка, а они почти все были с кемпстон-портами, то в случае полного делегирования функций можно использовать второй (более слабый) спектрум как функциональный придаток (изначально отвергая его активное участие в процессе - на него просто передаётся информация, а он уж её крутит вертит как надо).
В кемпстон порт выдаётся сразу 5 бит информации (здесь не совсем ясно, может быть там нас самом деле используется 8 сигнальных линий, однако у классического джойстика оправшивается только 5), плюс 1 бит по линии магнитофона. Здесь вариантов очень много, однако скорость будет в разы повышена, по сравнения с тем вариантом который я предлагал выше.

Насчёт программы, которая загружала второй комп. Честное слово, ни за что бы так не догадался, очень хороший вариант. Я всё таки предполагал или зашивать в ПЗУ код управления либо использовать магнитофон для базовой загрузки.

Самому себя цитировать нехорошо, но всё же...
Можно в качестве канала передачи использовать клавиатурные порты, их там уйма просто...

[bob5024]

Самому себя цитировать нехорошо, но всё же...
Можно в качестве канала передачи использовать клавиатурные порты, их там уйма просто...

Самый правильный подход - спаять котроллер RS232 by Kamil Karimov

Там даже буфер на 126 байт есть.

[Kirill Frolov (500:812/1.507)]

Hемедленно нажми на RESET, Григорьев Валерий!

On Mon, 31 Oct 05 17:35:56 +0300, Григорьев Валерий wrote:

Hello, All

Вот здесь хотелось бы пояснений, видимо в таком методе допускался высокий
уровень ошибок (или, что более вероятно, это была скорость передачи, а анализ
переданных данных не осуществлялся сразу, а только потом, после передачи),
потому что 3500000/115200 = 30 тактов на один бит (не байт ведь?), при том что
минимальная команда чтения порта 12 тактов. Тот алгоритм который я выше
предлагал можно тоже "слегка" разогнать, но не на столько...

http://www.google.com/groups group:fido7.zx.spectrum

Newsgroups: fido7.zx.spectrum
From: Kirill Frolov <netmail@svs.ru>
X-Comment-To: Andrew V. Miheev
Subject: Re: 32bit SIMM'ы
Date: Sat, 27 Sep 2003 05:47:27 +0400

Hемедленно нажми на RESET, Andrew V. Miheev!

On Fri, 26 Sep 03 11:16:01 +0400, Andrew V. Miheev wrote:

У меня 38400. Модератор утверждает, что 115200. Я считаю, что это уже
на грани фантастики, ненадёжно.
Сам писал или что-то готовое использовал?

Идею взял у создателей ZX-TCP.

Где можно посмортреть реализацию?

Из моего письма:

=== cut here ===

Вот у меня на метке RXWAIT ловится передний фронт старт-бита. Момент
нужно определить достаточно точно, иначе к концу передачи байта
накопится ошибка в последних битах (там нужно выдержать ~5%, точно не
помню). Период квантования сигнала 20 тактов = 5.7мкс, в то время как
период передачи бита на скорости 115200 будет всего 8.6мкс. Меньше 20-и
тактов сделать нельзя уже (одна команда IN занимает 11 тактов). То есть
получается, что на 3.5Mhz Z80 в принципе не способен с достаточной
точностью поймать передний фронт старт-бита, а значит и провести битовую
синхронизацию. Ошибка получается в те самые 5.7мкс, а если к концу байта
поскладывать все погрешности получится полная ерунда вместо принятого
байта.

Код передатчика тривиальный, комментировать не буду.

Сырец (кусок драйвера) рассчитан на скорость 38400 бит/сек:

;--------------------------------------
; RS232 EMULATOR ZX-LINK
;

; порт передатчика (это #1ffd на скопионе)

; максимальный размер буфера приёмника в байтах

; инициализация драйвера
ZXL_INI LD A,1
JR ZXL_CTL

; отключение драйвера
ZXL_OFF XOR A

; установка сигнала DCD
ZXL_CTL ;LD (ZXL_DCD),A
AND #01
RLCA
RLCA
LD (TXMASK),A
IN A,(#1F)
RLCA
RLCA
RLCA
AND #01
RET


; LINE SCAN возврващает BC=SIZE D=SPEED CY=NOTHING (стандарт драйвера MMD2.20)
; ожидание байтов от писюка заданное время
PUSH IX
PUSH IY
LD HL,RXMAX
LD DE,RXBYTE
PUSH DE
LD IX,(M_BUFF)
LD IY,TXMASK
LD BC,TXPORT
LD A,(TXMASK)
OR #20
OUT (C),A ; установка CTS для писюка -- разрешение передачи


RLA
RET C
IN A,(#FE) ; 25..34 ~40
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE) ; здесь происходит ожидание переднего
RLA ; фронта стартового бита
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
DEC D
JP NZ,RXWAIT ; +14
IN A,(#FE)
RLA
RET C
LD A,(TXMASK) ; тут таймаут истекает -- сброс CTS для ПЦ
LD E,A ; +17 ; и ожидание времени передачи "последнего" байта
IN A,(#FE) ; из буфера передатчика в ПЦ
RLA
RET C
OUT (C),E ; +12
IN A,(#FE)
RLA
RET C
LD D,#7 ; +7
IN A,(#FE)
RLA
RET C

RXWAIT1 IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
IN A,(#FE)
RLA
RET C
DEC D
JP NZ,RXWAIT1

; в течении заданного времени байтов от писюка не поступило

EX DE,HL
LD HL,RXMAX
OR A
SBC HL,DE
POP IY
POP IX
JR NZ,RXOK
LD BC,#0101
XOR A
INC A
SCF
RET

; успешное завершение (что-то принято)
LD B,H
LD C,L
XOR A
INC A
RET

; обнаружен передний фрон старт-бита!
RLA ; битового интервала
JR C,RXBYTE1 ; есть -> приём байта
DEC SP
DEC SP ; нет -> ложное срабатывание
JP RXWAIT

RXBYTE1 JR $+2
JR $+2
JR $+2
JR $+2
NOP
IN A,(#FE) ; B0 ; принимается первый бит
RLA
RR E
DEC HL
LD A,H
OR L
CP 1
SBC A,A
CPL
AND #20
OR (IY)
OUT (C), A ; тут отключается CTS при переполнении буфера
IN A,(#FE) ; B1
RLA
RR E
LD BC,RXBYTE
PUSH BC
LD BC,TXPORT
JR $+2
JR $+2
JR $+2
IN A,(#FE) ; B2
RLA
RR E
JR $+2
JR $+2
JR $+2
JR $+2
JR $+2
NOP
NOP
IN A,(#FE) ; B3
RLA
RR E
JR $+2
JR $+2
JR $+2
JR $+2
JR $+2
NOP
NOP
IN A,(#FE) ; B4
RLA
RR E
JR $+2
JR $+2
JR $+2
JR $+2
JR $+2
NOP
NOP
IN A,(#FE) ; B5
RLA
RR E
JR $+2
JR $+2
JR $+2
JR $+2
JR $+2
NOP
NOP
IN A,(#FE) ; B6
RLA
RR E
JR $+2
JR $+2
JR $+2
JR $+2
JR $+2
NOP
NOP
IN A,(#FE) ; B7
RLA
RR E
JR $+2
JR $+2
JR $+2
JR $+2
JR $+2
NOP
NOP
IN A,(#FE) ; B STOP ; последний стоп-бит
RLA
JR C,RXERR ; если стоп-бит не 0 -> ошибка
LD A,E
CPL
LD (IX),A
INC IX
JP RXNEXT ; приём следующего байта (ожидание старт-бита)

; произошла ошибка (сбой синхронизации) в приёмнике
OUT (C),A ; отключение CTS -- запрет передачи для ПЦ
JP RXEND ; возврат с индикацией ошибки



; SEND BLOCK IN MDMBUFF BC=SIZE

PUSH IX
LD E,C
LD D,B
LD IX,(M_BUFF)
LD BC,TXPORT

OR #08
OUT (C),A
LD A,(IX)
CPL
LD L,A
LD H,8
JR $+2
LD A,0

SBC A,A
AND #08
OR 0
OUT (C),A
JP $+3
JP $+3
JP $+3
LD A,0
DEC H
JR NZ,TXBIT

JR $+2
LD A,0
LD A,(TXMASK)
OUT (C),A
JR $+2
JR $+2
JR $+2
INC IX
DEC DE
LD A,D
OR E
JR NZ,TXBYTE

LD B,4
DJNZ $
POP IX
RET

К сожалению тут есть одна ошибка себя никак не проявляющая при
правильной работе ПЦ-шного COM-порта но потенциально очень опасная (как
всегда переполнение буфера). Ошибка там заключается в том, что после
заполнения приёмного буфера спектрум сбрасывает CTS чтобы писюк
прекратил передачу, после этого спектрум принимает последний байт
(сигнал CTS блокирует передачу следующего байта, но текущий уже начал
передаваться). Только вот в процессе приёма последнего байта спектрум
принимает никак не один байт, а сколько дадут. Больше одного обычно
писюк не даёт, но если будет давать то спектрум будет принимать до
победного конца. В данном случае критерием конца передачи для спектрума
служит длинный стоп-бит, то есть пауза в передаче в несколько битовых
интервалов. Я этот баг обязательно исправлю, сейчас просто уже лень...

=== cut here ===


А это из письма модератора, где у него 115200:

=== cut here===

Код пpиёмника на Z80 пpиведи!

Пожалуйста : ( в скобках pастактовка, частота 3.5 Мгц )

in A,(C) ; ждем стаpт-бит (12)
jp P,*-2 (10)
ld A,(0) ; задеpжка (13)

in A,(C) ; очеpедной бит (12)
rla
rr L ; пpинимаемый байт (8)
inc DE
( или dec DE, чеpез pаз ) (6)

... повтоpяется 8 pаз с чеpедованием inc dec

nop
nop
nop
in A,(C) ; стоп-бит
jp P,... ; нет ошибки

ошибка: ...

Код pаботает из ПЗУ. В том смысле, что из "быстpой" памяти.

Вот у меня на метке RXWAIT ловится пеpедний фpонт стаpт-бита.
Момент нужно опpеделить достаточно точно, иначе к концу пеpедачи байта
накопится ошибка в последних битах (там нужно выдеpжать ~5%, точно не
помню). Пеpиод квантования сигнала 20 тактов = 5.7мкс, в то вpемя как
пеpиод пеpедачи бита на скоpости 115200 будет всего 8.6мкс. Меньше 20-и
тактов сделать нельзя уже (одна команда IN занимает 11 тактов).

У меня 26 тактов на бит. Один такт пpи 3.5 Мгц pавен 0.2857 мксек.
0.2857 * 26 = 7.4282 мксек , у меня вот так получилось.

То есть получается, что
на 3.5Mhz Z80 в пpинципе не способен с достаточной точностью поймать
пеpедний фpонт стаpт-бита, а значит и пpовести битовую синхpонизацию.
Ошибка получается в те самые 5.7мкс, а если к концу байта поскладывать все
погpешности получится полная еpунда вместо пpинятого байта.

Почему-то pаботает. И ошибок нет. Интеpесно, почему ?

=== cut here ===

Я считаю, что 115200 это уже на той грани, где сегодня и на этой
машине работает, а завтра и на другой -- нeизвестно.

Он ещё и передавать в момент приёма не может. Так порт-же
асинхронный, никаких проблем. Для блокировки приёма в момент передачи
есть CTS.
Где? Расскажи подробнее про железо и софт.

Что где? Порт, полноценный в писюке или модеме. Другой неполноценный в
спектруме. Для нормальной работы одного полноценного достаточно.
Hеполноценный порт спектруме может вести приём или передачу строго в
определённый момент времени, а в остальное время он блокирует передачу в
писюке (модеме) сигналом CTS. Два спектрума связать так может быть
сложней -- они должны будут работать синхронно, один в передаче, другой
в приёме. Hо в Interface-1 это работало, там целая сеть спектрумов так
была организована.

Софт, для связи с писюком, я использовал MMD (Macro Modem) на
спектруме и его совместимый аналог для писюка. MMD -- это программа для
модемной связи спектрума (модемы свои, не писишные, с писишными не
совместимые). Туда-сюда передавались файлы и можно было давать команды
для писюка со спектрума и наоборот. Можно было линухом управлять со
спектрума.

Вот я и говорю -- программно проще оказывается. Хотя, для модема
лучше 580ВВ51 (можно одновременно буковки в терминале отрисовывать).
Для модема лучше родной Z80SIO.

Hе лучше. Он и программируется нестандартным/непривычным образом, и его
нужно где-то взять ещё. Программно лучше 16550A подходит, но его тоже
неоткуда взять, проще сразу уж писишную "мультикарту" прикрутить.

[Kirill Frolov (500:812/1.507)]

Hемедленно нажми на RESET, Григорьев Валерий!

On Mon, 31 Oct 05 17:35:56 +0300, Григорьев Валерий wrote:

Самому себя цитировать нехорошо, но всё же...
Можно в качестве канала передачи использовать клавиатурные порты, их там уйма
просто...

Можно соединить через ZX-BUS. Z80 умеет отдавать шину по запросу.
Можно соорудить схему для захвата шины одного компутера процессором
другого. И использовать чужую память. Ехто просто (если только ещё
засинхронизировать тактовую частоту). Hу провода, понятное дело, не
длиней 30 сантиметров.