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

[GriV]

кто нибудь этим занимался?
Я имею в виду заставить два спектрума работать в связке.
Тут в ФИДО-эхе пролетел вопрос - нужно ли использование эхотага? Я туда пробовал тыркнуть развить тему, да почему то форум руганулся на недостаток прав. но вопрос не в этом.
Вопрос вот в чём - все спектрумы имеют почти не используемый (в данное время) порт магнитофона - EAR и SPK биты - на ввод и на вывод. Чисто технически можно на достаточно большой скорости [для стандартных портов скорость известна, для магнитофонного же её конечно надо подбирать, но вполне очевидно что это будет не низкая скорость, вполне возможно что до нескольких килобайт в секунду, правда при полной загрузке обеих связываемых станций] связывать по этим портам (а кроме них, есть немало спекков с параллельным и последовательными портами) два спектрума (можно сделать и большее количество, но там реализация трудоёмкая - возникает необходимость в контроллере транзакций - отдельной вычислительной системе) - а так как у них производительность в принципе одна и та же, то использовав связку спектрумов можно удвоить производительность почти нахаляву. Собственно халява то в чём заключается: пусть имеет 1 спетрум более менее продвинутый (скажем, HDD, FDD, AY 256К и т.д.) и имеется достаточно старый, но работоспособный ZX-48K. И даже если его нет, наверняка можно либо в качестве подарка забрать у кого-нить из знакомых старенький но вполне работоспособный ZX-48K (на крайняк там даже 16К хватит; если же даже такого нет, дайте объявление о покупке сразу желающие найдутся).
Тогда подключив по одному из портов (магнитофонный, параллельный/последовательный) такой "маленький" спектрум, можно зафигарить два-в-одном производительность.
А для чего может быть нужна такая производительность?
Например, музяку музярить на одном (полноценный обсчёт для цифрового музона скажем) в то время как другой комп рисует графику.
Или распараллеливать математические вычисления (обсчёт сложных вычислений для трёхмерных демонстрашек например).
Ну и т.д.
В том смысле что для чего связать спектрумы - это найдётся. А вот практически пробовал ли кто это делать?

P.S. не имеется в виду что оба спектрума работают с одной памятью с одним экраном и т.д. Имеется в виду два дискретных спектрума которые работают в кластере, выполняя одну и ту же задачу в связке.

[jtn]

пусть имеет 1 спетрум более менее продвинутый (скажем, HDD, FDD, AY 256К и т.д.) и имеется достаточно старый, но работоспособный ZX-48K.
именно так и было. на первом загружалась прога, жался магик и снапшотом передавалось на второй. ну и в сетевые игры тоже игрались

[GriV]

именно так и было. на первом загружалась прога, жался магик и снапшотом передавалось на второй. ну и в сетевые игры тоже игрались

Гаа, замечательно тока где это было??? И при чём здесь магик? имеется в виду взаимодействие по клиент-серверной модели, причём здесь разделение идёт на уровне программы, то же, о чём ты пишешь несколько другое.

[jerri]

а с какой скоростью планируешь передавать? всетаки не RS 232

[GriV]

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

Конкретно пример: вся информаиця передаётся побайтово, 10 бит (+2 бита чётности), на стороне передатчика проблем с распознаванием почти нет, на стороне приёмника нужно делать по видимому 3-5 замеров, т.о. 3-5 команд In A,(#FE) со всей обвеской

Конкретно:

IN A,(254) ;+11 тактов
ADD A,D ; D=#40, бит нужный переходит в CY
LD A,E ; E=0
ADD A,B ;+12 тактов, в B хранится счётчик одинаковых замеров = 1
LD B,A ; +4 такта
итого 5*27=135 тактов (для 5 разовой проверки передачи 1 бита)

;в конце конечно же проверка уровня

LD A,B
CP 4 ; допускается 1 сбой, т.е. 4 одинаковых измерения
JR NC,BIT1 ; получился бит = 1
CP 2
JR C,BIT0 ; получился бит = 0

ERROR: END

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

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

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

[CHRV]

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

[ASDT]

"заставить два спектрума работать в связке"
А зачем? Какая может быть задача для такой связки?

[fan]

Всё выше описанное напоминает связку спека и GS ;) (дал бы кто разборчивую фотуку GS с двух сторон) . Остается лиш прилипить ко второму спеку SounDrive и слегка разогнать , вот вам почти что GS :D Да и обычный ковокс (лучше стерео) смотрелся бы уже не плохо :v2_clapp:
Для полного счастья остаётся только ПЗУшку подправить , чтоб автоматом необходимые начальные данные принимать и запускать. И предусмотреть возможность её отключения , чтоб можно было задействовать всю память.

Вобщем идея интересная (особенно в свете дороговизны новых железяк) :v2_cheer:
Но использовать патефонный порт лучше не надо :v2_scare:

[GriV]

"заставить два спектрума работать в связке"
А зачем? Какая может быть задача для такой связки?

Читайте повнимательней пожалуйста, выше всё написано...

[GriV]

Всё выше описанное напоминает связку спека и GS ;) (дал бы кто разборчивую фотуку GS с двух сторон) . Остается лиш прилипить ко второму спеку SounDrive и слегка разогнать , вот вам почти что GS :D Да и обычный ковокс (лучше стерео) смотрелся бы уже не плохо :v2_clapp:
Для полного счастья остаётся только ПЗУшку подправить , чтоб автоматом необходимые начальные данные принимать и запускать. И предусмотреть возможность её отключения , чтоб можно было задействовать всю память.

Вобщем идея интересная (особенно в свете дороговизны новых железяк) :v2_cheer:
Но использовать патефонный порт лучше не надо :v2_scare:

Только нет у меня дома GS-ки и нет дома разгона, к тому же всё равно это позволит парк старых уже машин задействовать а не лепить новые... Чисто утилитарный так сказать аргумент... Да и бог с ним, с портом, не в нём дело, дело в кластере создаваемом...

[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. Под пояснениями я предполагаю конкретный алгоритм

[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 <[email protected]>
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 сантиметров.

[GriV]

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

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


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

Нет, такой метод не сойдёт, хотя конечно вариант ;)))
Я предлагал неразборные и несвязанные спектрумы, которые только через внешние порты рубают друг на друга
Насчёт 115200 и 38400 я точно скажу, что такое будет конечно работать, но как ты сам правильно заметил, работать на пределе - коррекция ошибок и прочее выполняется не на лету, да и связать два именно спектрума так достаточно сложно - сказывается отсутствие буферов и т.д.
Хотя конечно чтото новое в этих алгоритмах я нашёл - способ синхронизации например - по фронту.

[AlexCrush]

Я думаю, что в итогевопрос выливается в противостояние скорость vs простота устройства связи :-). Если нужна большая скорость и малое использование процессора - можно сделать и DMA контроллер с нормальным приемником-передатчиком RS-232. Но это сложно. На мой взгляд слишком сложно.
Самый простой метод связи имеется уже встроенный - просто соединить крест-накрест магнитофонные разъемы двух спеков. Но это медленно. Слишком.

Оптимальное решение - где то посредине.

По-моему, неплохой метод - сдвиговый регистр, который преобразовывал бы отправляемый байт в последовательность бит (ну и наоборот при приеме). Это снизило бы загрузку спека. Этакий преобразователь LPT->RS232. Ведь по LPT соединять компы - изврат... а если они в разных комнатах? сколько проводов то нужно будет...

Были когда-то идеи сделать подобное устр-во с буфером на микроконтроллере. Только соединять хотел speccy <-> PC для организации хранения большого кол-ва данных типа винта. Но эту идею постигла участь многих других - она осталась только идеей.


Хотя конечно чтото новое в этих алгоритмах я нашёл - способ синхронизации например - по фронту.
Дык у меня тоже синхронизация по фронту :-) а заодно и по спаду тоже

[James DiGreze]

Самым оптимальным будет реализация Ethernet 802.3 10base-t, но это относится к железу, а также сложно и дорого в реализации... Есть готовые решения типа moxa nport-4511 и подобные, которые реализуют переход сред доступа RS232C<->Ethernet. Стоимость подобного девайса ~5000рубликов. Сам RS232C реализован в контроллере Камиля Каримова (см. раздел "Железо"). Остается только описать протокол работы с nport'ом, и написать программы реализации как для nport'а, так и для спека... В результате получим нехилый девайс, к тому же стандартный! Вот только кто за такие деньги будет это себе приобретать... Проще действительно купить ПК, вставить в него сетевушку за 200рэ, и соединить со спектрумом по тому же RS232 и пользоваться благами цивилизации ;)

[GriV]

в стоимости решения дело - если так наворачивать, то слишком круто получается

Если же не наворачивать, то будет просто два маг. порта, которые есть и не надо ничего добавлять.

Хотя конечно с точки зрения программы мороки слишком много...

[James DiGreze]

Хотя конечно с точки зрения программы мороки слишком много...
Мороки будет в любом случае много... Имхо, стоит обратить свой взор на сетевые решения из разряда embedded... Там есть протоколы для 8-и битных процессоров, и линий связи до 100м точно, а может и больше, и связи до 10-20 устройств (читай кампутиров). Набираете в гугле такие страшные названия, типа: CAN, 1-,2-wire...