одно дело пользователям в старые компьютеры, которые итак еле дышат, лезть с паяльником, и совсем другое дело - просто воткнутся в стандартные пару разъемов - кемпстон и tape
можно читать полубайт и ждать следующего, а можно считать несколько полубайтов влет и потом уже синхрануться
в общем, куда-то припаиваться - не дело, если можно этого избежать
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Тут у меня есть несколько возражений:Сообщение от char
Первое - совместимость и наличие разъёмов.
У меня на двух спектрумах в детстве разъёмы Tape не совпадали: пришлось перепаивать чтобы грузится с одним шнурком от магнитофона.
У оригинального спектрума джеки вроде были, а у тех что с кассетой шли вообще не было разъёма Tape. Кемпстона, кстати на одном моём компе вообще не было.
Второе - питание и его гальваноразвязка
Для одной "микросхемы" городить гальваноразвязанное питание - это как-то не по людски.
Года два назад подключал как-то свой ПК к телеку по HDMI. Не показывает.
Думаю всё, писец, смертоубийство, спалил материнку или разъём в телеке.
Оказалось, что в разных розетках у меня разные фазы. На HDMI почему-то не выведена земля, а "земли" на разных фазах у импульсных источников питания получаются разными и более того - ползут относительно друг друга.
То есть нужно гарантировать чтобы хоть у одного устройства (у спектрума или у нашей схемы) а лучше у обоих сразу будет гальваноразвязка от сети. Иначе маловероятны, но вполне возможны пиротехнические эффекты.
Третье - конденсаторы в цепях Tape.
Во первых они нам срежут постоянку, а во вторых сильно понизят скорость. Да и длинные провода в разъём кемпстон могут повлиять на ВЧ.
Так что разъём Tape превращает проект в бессмыслецу.
Синхранутся можно когда мы примерно знаем период синхронизации. Почитайте ветку про состязательную и несостязательную оперативу. Я вот с удивлением узнал, что четырёхтактовая инструкция при определённых условиях запросто может до 10 тактов растянутся. Так что первый полубайт мы примем правильно, второй полубайт со смещением до 50% (думаю тут угадать реально), А вот третий приём уже не гарантируется. С четвёртым же - наверняка пролетите.
PS. И ещё раз напоминаю:
Устройство задумывается как максимально простое. Не ставится задачи загрузится за полсекунды. Пусть загрузка программы будет происходить не за 5 секунд, а за 8 или даже 10. Зато четыре раза ткнуть паяльником и приклеить термоклеем ардуинку.
Те кто любит спектрум и впадает в бешенство, если игра грузится дольше полсекунды - тот давно уже сидит на спектруме-мутанте с процом частотой в 20 мегагерц или даже зашитым в ПЛИС и работающим до 100 мегагерц.
зато с масками проблем нет и с записью в память
в общем, может выглядеть как-то так, навскидку
ld c,#10
load:
dup <на сколько байт подряд хватит наглости>
in a,(#1f)
rld
inc de ;not used, just for time, maybe
in a,(#1f)
rld
inc hl
edup
ld e,a
wait:
in a,(#1f)
xor e
and c
jp z,wait
jp load
зачем два раза rld? первый нибл просто пишем ld (hl),a
Прихожу без разрешения, сею смерть и разрушение...
потому как два rld подряд дадут полноценный байт записанный в (hl)
;hl=start
;bc=length
ld d,#10
load:
dup <на сколько байт подряд хватит наглости>
in a,(#1f)
rld
dec bc
in a,(#1f)
rld
inc hl
edup
ld e,a
wait:
in a,(#1f)
xor e
and d
jp z,wait
ld a,b
or c
jp nz,load
- - - Добавлено - - -
а, в смысле так:
in a,(#1f)
ld (hl),a
dec bc
in a,(#1f)
rld
inc hl
но синхримся же, так что лучше два rld, все же
И сравниваем что предложил krt17
59 тактов против 191. Разница в 3 раза.
Добиваем сюда синхронизацию. Добиваем сюда контрольную сумму. Учитываем задержки при чтении с флешки.
И получаем разницу в полтора-два раза.
Спрашивается, нафига козе баян?
В 2 раза усложняем схему, рискуем коротким замыканием через кемпстон-джойстик... и ускоряемся всего ничего.
Из дополнительных проводков я считаю, что полезен будет сигнал IORQ - по нему засинхронизироваться можно.
Поверьте, последовательная схема с синхронизацией по IORQ будет быстрее чем кемпстон-вариант с синхронизацией по пятому биту. Особенно это проявится в состязательной памяти (если процедуру хранить в буфере принтера)
как-то криво такты считаешь, на самом деле 58 (с одним rld) против 197 ~3.4 раза
(если ниблы отдавать неравномерно - retm не нужна и 53 такта ~3.7 раза)
однократно перед запуском пакета - задаём через сколько тактов начать и на сколько байт развёрнут цикл приёма
на весь пакет, после передачи, необязательно
буферить
в 3+
Прихожу без разрешения, сею смерть и разрушение...
Считаю с округлениемИ ошибся всего на один такт. Для любителя не видящего спектрум с прошлого века - неплохо.
Про контрольную сумму:
Её в любом случае считать. И лучше не простым XOR. Ну или хотя бы двумя вариантами.
Это сразу 10+ тактов на байт, а то и все 30.
Какая разница как это обозвать: чтение с флешки или чтение с флешки в буфер? Оно всё равно одно и то же.
В любом случае ардуинка не может отдать больше чем прочитает, а на прочтение нужно время.
Мы просто про разные вещи говорим: я говорю про суммарное время загрузки программы (программу надо поделить на "сектора", прочитать с флешки, загрузить в спектрум, сверить контрольные суммы, и запустить наконец), а вы про время загрузки одного байта.
Т.е. если считать общее время, то значительная часть операций у обоих алгоритмов будет одинаковая. Соответственно если какая-нить хня будет занимать 5% в однобитном решении, то она вырастет до 5*3.7 = 18.5 % в четырёхбитном. И будет уже не 3+, а уже 3-
Ну и даже если соглашусь с вами: если время загрузки игры - 8 секунд в последовательном режиме и 3 секунды в параллельном, но надо отключать нормальнозамкнутый джойстик. А в игре - управления с кемпстона. Вопрос - кто быстрее начнёт в эту игру играть и у кого быстрее сломается разьём?
И вообще не понимаю, почему так привязались к этому кемпстону. Он даже не во всех клонах присутствует.
Кроме того, почему-то вы не учитываете человеческий фактор. У меня вон на SSD винда грузится чуть больше 8 секунд. И я с пеной у рта не критикую микрософт, что можно было бы грузится за две секунды. На спектруме люди привыкли к тёплому ламповому ожиданию загрузки. Пока выберешь программу, пока отхлебнёшь кофе - глядишь уже всё загрузилось. Кстати, для унификации предполагалось что программы будут предварительно сжиматься упаковщиком, а при запуске - распаковываться. Это ещё 2-5 секунд, так что выбор будет между 10-13 и 5-8 секундами... короче экономия на спичках.
Ну и когда нормально вся система в целом заработает - то можно будет поиграться с вариантами. Вдруг окажется что большинство программ можно будет за 5 секунд загружать последовательно, зачем тогда ускорять если даже джойстик в руки взять и откинутся на спинку стула не успеешь? Как бы с дисковода дольше грузились и что-то никто его в окно не выкинул с криками - убью тормоза
не надо нихера отключать-переключать, коробочка один раз втыкается в комп, обычный джойстик в коробочку, коробочка работает как параллельный джойстик, можно кнопку autofire даж добавить и т.д. вплоть до прохожденийНу и даже если соглашусь с вами: если время загрузки игры - 8 секунд в последовательном режиме и 3 секунды в параллельном, но надо отключать нормальнозамкнутый джойстик. А в игре - управления с кемпстона. Вопрос - кто быстрее начнёт в эту игру играть и у кого быстрее сломается разьём?
в честь чего так обязательно-то в любом? не мафон небось! как опцию для параноиков разве что
причём считать можно как раз в то "время, которое нужно ардуинке на прочтение" очередного блока
не нутришь потенциала для запиляторов
кемпстон-хаб!
Прихожу без разрешения, сею смерть и разрушение...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
