Просмотр полной версии : Очередной однобитный велосипед для спектрума
Настоящим постом никого не хочу обидеть. Даже больше того, восхищаюсь тем кто делает что-то для спектрума. Так что прошу не обращать внимание на некоторую резкость. И за многобукаф тоже извините.
Прочитал я несколько АКТУАЛЬНЫХ тем про устройства для спектрума и впал в уныние. Кто-то эмулирует магнитофон (http://zx-pk.ru/threads/25622-magnitofon-dlya-spektruma-na-atmega128/page8.html) , кто-то - хочет сделать ROM-диск (http://zx-pk.ru/threads/27326-flash-loader-dlya-zx-spectrum-a-i-leningrada.html), кто-то флоппи-эмулятор (http://zx-pk.ru/threads/26328-planiruyu-sdelat-fdd-emulyator-na-atmega8.html) и даже divIDE в продаже есть.
С одной стороны приятно понастальгировать. Но с другой - блин, чуваки, ну почему у вас такие сложные и дорогие схемы? Сейчас кризис, надо быть проще... Да, безусловно, схемы крутые. Но все они ограничены по своим возможностям: на виртуальный дисковод больше 800 кило не запишешь, с магнитофона быстро не загрузишься. DivIDE чуток получше, но даже у него есть ограничения на объём раздела... плюсом к нему надо докупать дорогую флешку которую в маленьких городах и не найдёшь...
В общем, предлагаю на обсуждение, следующую концепцию очередного велосипеда - внешнего устройства ввода вывода. Предупреждаю сразу что я её в железе реализовать не смогу по причине утери платы спектрума (корпус и клавиатура осталась, а плата потерялась при переезде). Но могу ответить на некоторые вопросы и оказать посильную консультацию по скайпу.
Сама идея состоит в том, что Z80 - это довольно быстрая штука. И он может битиками ворочать ОЧЕНЬ быстро. Для примера возьмём магнитофонный порт. Какая может быть максимальная скорость ввода информации, при условии что за синхронизацию отвечает внешнее устройство? Проверяем на "секторе" из 256 байт:
LD C,0 7
sector: LD b,8 7*256
byte: IN a,(254) 11*8*256
RLCA 4*8*256
RLCA 4*8*256
RRС d 8*8*256
DJNZ byte (13*7+8)*256
LD (hl),d 7*256
INC hl 6*256
DEC c 4*256
JR nz,sector 12*255+7
Итого у меня получилось - 102 402 такта на 256 байт, то есть 400 тактов на байт или 8.5 килобайт в секунду.
Получается Z80 сам, без никакой помощи, без турбирования, по двум *****м проводкам, парой дюжин команд за 5 секунд скачает полностью свою память (без картинки).
Но кто же даст нам такую скорость? Правильно - самый популярный ногодрыг - ардуина. Разумеется, втыкать её придётся не в разъём TapeIn / TapeOut, а припаивать на плату прямо на триггеры. Но припаять два сигнальных и два питательных проводка не проблема (TapeIn кстати нужно перерезать чтобы не спалить; или через переключатель подключить если планируется пользование магнитофона)
Только в ардуине ПЗУ всего ничего, но зато на ней без проблем работают картридеры microSD. Заодно ардуина возьмёт на себя всю заботу о FAT (или даже о FAT32).
Да, скорее всего заявленная скорость в 8.5 килобайт будет недостижима: Ардуине надо будет читать файл по секторам в свою небольшую память (Z80 в это время будет простаивать), дополнительно потребуется синхронизация в основном цикле. Проверку контрольной суммы тоже надо делать.
Но в любом случае, гарантированно будет не менее 5 килобайт в секунду.
Итак, как будет работать система с точки зрения пользователя?
1. На спектруме набираем LOAD "" и нажимаем <ENTER>
2. На ардуине нажимаем Reset - пошла загрузка драйвера (ардуинка отдаёт драйвер в магнитофонном режиме (http://zx-pk.ru/threads/25622-magnitofon-dlya-spektruma-na-atmega128/page8.html))
3. После загрузки мелкого драйвера (пара сотен байт в буфере принтера или UDG или даже в бейсик-переменной) у нас становится доступна флешка и загрузчик грузится с неё - показывает список файлов: выбирай любой и грузись.
Как под это дело адаптировать программы?
В комплекте драйвера будут функции DEF FN которые обеспечат загрузку и выгрузку кодовых блоков.
Адаптированию подлежат только программы в которых бейсик-загрузчики вида CLEAR 24000: LOAD "" CODE: RANDOMIZE USR xxx.
Для простоты можно все кодовые файлы пожать архиватором, разместить со стандартного адреса (24000) и сделать им автозапуск. И обозвать с расширением zxexe :)
Ну и самое вкусное - что это будет по цене?
По сайту наших китайских братьев ардуинка 130 руб, картридер - 40 руб, флешка microSD (минимально) от 100 рублей, но флешка как правило уже есть от старого телефона. Провод для прошивки тоже подойдёт от телефона.
P.S. На самом деле совсем уж правильно вместо ардуинки использовать esp8266. И все операции выполнять через wi-fi. Заодно и все образы программ выгрузить на спецсайт для спектрума - например http://zx.zx-pk.ru/ завести там каталоги для юзеров (с ограничением приватной части в мегабайт например). Тогда даже десяток пользователей с wi-fi за несколько дней наадаптируют сотню программ и разместят их в общий доступ.
Но про esp8266 я ничего сказать не могу: в руках её не держал, да и пробовать на ардуинке проще.
или 8.5 килобайт в секунду.
Что-то маловато.
Синклеровский ZX Interface 1 работал под контролем проца без всяких DMA и мог грузить данные с микродрайва со скоростью около 15 килобайт в секунду.
http://www.theregister.co.uk/Print/2013/03/13/feature_the_sinclair_zx_microdrive_story/
Правда там не два проводка. На двух проводках там работала локальная сеть, со скоростью 100кбит
https://regmedia.co.uk/2013/02/07/zxmd_3.jpg
Мое мнение по этому поводу такое, а что нам мешает загрузить через tapeIn образ TRD в рам диск? И дальше работать с ним так же как и все другие интерфейсы типа z-контроллера или Nemo-IDE? Фактически нужно только драйвер написать для этого дела... Можно пойти еще дальше, через TapeOut выдавать команды этому внешнему устройству... Но, здесь конечно же нужно всё хорошо обдумать, прежде чем начинать реализовывать, может быть выработать какой-то стандарт для начала...
blackmirror
28.02.2017, 22:32
Бука, чтобы грузить 15 КБайт/c по одному проводу нужно написать(или попробовать сгенерить) код вида:
RECV_BYTE: IN F,(BC)
JP NZ, X1
X0: IN F,(BC)
JP NZ, X01
X00: IN F,(BC)
JP NZ, X001
X000: IN F,(BC)
JP NZ, X0001
...
X0000000: IN F,(BC)
JP NZ, X00000001
X00000000: LD A,00000000b
JP SAVE_BYTE
X00000001: LD A,00000001b
JP SAVE_BYTE
X0000001: IN F,(BC)
JP NZ, X00000011
X00000010: LD A,00000010b
JP SAVE_BYTE
X00000011: LD A,00000011b
JP SAVE_BYTE
...
.l0
dup 8
in a,(#fe)
add c
rl e
edup
ld (hl),e
inc hl
djnz .l0
Это 15кб/c без извратов,а у топикстартера просто не рабочий код.
Если предположить что разрабатывается устройство для zx edge connector-а, то в схему такого устройства обычно ставят ROM (называют shadow rom) и порты и\или регистры отраженные на память в диапазоне 0-3fff, данного железа хватает чтобы читать\писать данные куда угодно (fdd, ide, mmc, serial т.д.). DivIDE, TRDOS, Interface1 все сделанны таким образом. Если чтото и делать то надо делать совместимым с существующими програмными интерфейсами (для того чтобы опять не переделывать загрущики...).
Если чтото и делать то надо делать совместимым с существующими програмными интерфейсами (для того чтобы опять не переделывать загрущики...).
Уже давно изобретен "велосипед", см https://sites.google.com/site/interface1bis/home
И на нашем форуме обсуждался не раз, ищите interface 1 bis
Вот с полпинка нашел инфу на русском: http://microsin.net/adminstuff/others/zx-spectrum-interface1bis.html
- - - Добавлено - - -
Правда дофига хотят - 44 евро...
Бука, чтобы грузить 15 КБайт/c по одному проводу нужно написать(или попробовать сгенерить) код вида:
RECV_BYTE: IN F,(BC)
JP NZ, X1
...
Можно было бы грузить около 15 килобайт, если бы:
1) команда IN F,(BC) устанавливала флаг не Z, но C
2) нужный бит порта попадал именно на нужный флаг
В своей программе можно использовать стек, можно полностью развернуть цикл... но смысла это не принесёт никакого.
Я хотел донести мысль, что главное не скорость, а простота. Я привёл кусок программы лишь для того чтобы показать, что ЛЮБАЯ программа для 48 спектрума загрузится за единицы секунд. Нет особого смысла грузить программу за 1 секунду, если выбор её через менюшку будет минимум за 10 секунд.
blackmirror
01.03.2017, 21:47
1) команда IN F,(BC) устанавливала флаг не Z, но C
2) нужный бит порта попадал именно на нужный флаг
Это 8-уровневое дерево ветвлений, в сумме на всех уровнях в нём 255 условных переходов, и 256 команд загрузки всевозможных значений байта на последнем уровне. Для него сойдёт любой флаг для которого есть условный переход. Но если 7й разряд не меняет своё значение, то код krt17 намного проще и короче. Также через TapeOut нужно передавать сигнал готовности к чтению байта, а в начале выдать синхросигнал для настройки скорости обмена, чтобы Z80 не подавился данными.
через кемпстон делай
Через кемпстон, к сожалению, нельзя:
- во первых некоторые клоны не имеют кемпстона.
- во вторых для синхронизации всё равно нужна обратка (в примере программы не показана)
- - - Добавлено - - -
Если предположить что разрабатывается устройство для zx edge connector-а, то в схему такого устройства обычно ставят ROM (называют shadow rom) и порты и\или регистры отраженные на память в диапазоне 0-3fff, данного железа хватает чтобы читать\писать данные куда угодно (fdd, ide, mmc, serial т.д.). DivIDE, TRDOS, Interface1 все сделанны таким образом. Если чтото и делать то надо делать совместимым с существующими програмными интерфейсами (для того чтобы опять не переделывать загрущики...).
Я не гуру. Я - велосипедист. Это фигня в первую очередь размышление для отечественных клонов у которых нет zx edge. Эдакий плохонький суррогат дисковода.
Это для того чтобы прочитал случайно чувачок, вспомнил детство, сходил в гараж, достал свой ленинград 1, припаял в него четыре проводка от ардуинки за 150 рублей и радовался жизни.
Если же передо мной маньяк спектрума, у которого FDD + IDE + MMC, то ему эта тема противопоказана: тот же divIDE гораздо быстрее, совместимее и уже есть в наличии.
Просто чувачок, вспомнивший детство, если увидит цену на divIDE и посчитает количество проводков которые надо ему припаять... и подумает что лучше купить пивка и не мучится ностальгией.
P.S. тема родилась как возможное решение проблемы загрузки бета-бейсика (http://zx-pk.ru/threads/27188-kakoj-sdelat-prostejshij-variant-zagruzki-iz-vneshnego-pzu.html) , а также сохранением программ на флешку.
Как бы если есть вариант проще и дешевле - рекомендуйте. И с чистой совестью похороним эту тему.
- - - Добавлено - - -
Уже давно изобретен "велосипед", см https://sites.google.com/site/interface1bis/home
Правда дофига хотят - 44 евро...
Дык вот именно, про то и речь. Ардуинка в 20 раз дешевле и если нет системного разъёма, то и паять в 20 раз легче.
А скорость загрузки - ну в 2-3 раза дольше :)
- - - Добавлено - - -
Это 8-уровневое дерево ветвлений, в сумме на всех уровнях в нём 255 условных переходов, и 256 команд загрузки всевозможных значений байта на последнем уровне. Для него сойдёт любой флаг для которого есть условный переход. Но если 7й разряд не меняет своё значение, то код krt17 намного проще и короче. Также через TapeOut нужно передавать сигнал готовности к чтению байта, а в начале выдать синхросигнал для настройки скорости обмена, чтобы Z80 не подавился данными.
Спасибо что подсказали про дерево ветвлений. Я практиковался в кодах Z80 только в прошлом веке, поэтому могу не увидеть некоторые особенности.
Просто в вашем случае получается очень приличный блок кода. Если этот код будет размещён во внешнем ПЗУ то размеры не критичны.
А изначальная задумка была в том, чтобы минимизировать вмешательство в схему спектрума (типа те кто способен припаять ПЗУ, могут припаять и другую схемку, которая в 20 раз быстрее).
Если же такой драйвер загружать в оперативу через LOAD "", то во первых это будет довольно чувствительно по времени, а во вторых - займёт драгоценную память, которой может не хватить при загрузке какой-то здоровой программы.
Соглашусь что код krt17 попроще и наверное стоит его взять за основу.
Ну или как компромисс: простой загрузчик загружает два варианта кода. Если есть возможность - пользуется быстрым но длинным, если нет возможности - пользуется медленным но коротким. В любом случае чтобы определить достаточность скорости надо сначала поэкспериментировать.
Про TapeOut не написал для краткости. Возможно им придётся дёргать не раз на байт а даже раз на бит. Ну или припаять ещё один проводок ардуинки на IORQ.
Пока ни устройства ни программы нет. Пока это просто задумка.
Lethargeek
01.03.2017, 22:58
Через кемпстон, к сожалению, нельзя:
- во первых некоторые клоны не имеют кемпстона.
- во вторых для синхронизации всё равно нужна обратка
через кемпстон (с вариантом выбора через синклер) зато можно же грузить сразу по 4-5 бит! а обратку через tapeout пустить отдельно :D
зачем обратка?
4 бита данных (полубайт), а пятым щелкать 0/1 для синхронизации
через кемпстон (с вариантом выбора через синклер) зато можно же грузить сразу по 4-5 бит! а обратку через tapeout пустить отдельно :D
До четырёх и пяти считать умею.
Но на самом деле это не ускорит в 4 раза:
- ардуинка не шибко быстрое устройство. Она должна ещё на флешку лазить за данными. В это время Z80 будет простаивать.
- у Z80 вроде не было команды "обменять нибблы", а значит придётся делать 4 сдвига. Исправлено - команда была. Но она тормозная и малость неудобная. Так что в нашем случае это как бы без разницы.
- непонятно что будет в старших битах - придётся выделять маской младшие.
- в примерах ещё я контрольную сумму не считаю, это тоже будет замедлением.
В общем, в два раза гарантированно ускорится, а может быть даже в три. Но это потребует увеличение количества проводков практически в 2 раза, это потребует хитрый штеккер или переключатель чтобы ардуинка не дай бог вошла в конфликт с джойстиком и коротнула (про нормально замкнутые джойстики не забываем)
Через синклер тоже может быть каша в дешифрации (здесь честно скажу я схему не рассматривал, могу ошибаться). Тоже не хочется чтобы случайно нажатая клавиша приводила к ошибке загрузки. Или даже более того - порче переданной команды (вместо найти файлы по маске *.* ардуинка получит команду удалить файлы по маске *.*)
Так что выигрыш с кемпстоном не большой (ну ускорим загрузку на 3 секунды), а проблем можно поиметь целую катушку.
Опять же чисто риторический вопрос - стали бы вы полчаса разбираться со схемой, чтобы сэкономить три секунды на загрузку?
P.S. Читал что в конце эпохи спектрума фирма Codemasters делала какой-то девайс для кемпстона. С помощью которого с CD-диска игры грузились гораздо быстрее... но думаю это не наш случай.
а теперь покури команды RLD и RRD ;)
зачем обратка?
4 бита данных (полубайт), а пятым щелкать 0/1 для синхронизации
Обратка нужна для скорости.
Если Z80 будет считать синхронизацию, то цикл синхронизации должен быть БОЛЬШЕ (наверное раза в два или даже три) чем цикл чтения из порта.
Если же Z80 будет тупо дёргать ногой "дай следующий байт", то синхронизироваться будет ардуинка, которая в разы быстрее.
Короче с обраткой в 2-3 раза быстрее и в несколько раз проще.
Да и в любом случае обратка нужна. Как вы объясните ардуинке что хотите поиграть в Dizzy?
одно дело пользователям в старые компьютеры, которые итак еле дышат, лезть с паяльником, и совсем другое дело - просто воткнутся в стандартные пару разъемов - кемпстон и tape
можно читать полубайт и ждать следующего, а можно считать несколько полубайтов влет и потом уже синхрануться
в общем, куда-то припаиваться - не дело, если можно этого избежать
а теперь покури команды RLD и RRD ;)
Покурил.
Признаю ошибку, команда есть в наборе Z80 (но народ жалуется что на некоторых клонах некорректно работает).
Но на итог это не повлияет: команда выполняется ажно 18 тактов.
Типа 4 раза сдвинуть аккумулятор - это 16 тактов :)
зато с масками проблем нет и с записью в память
в общем, может выглядеть как-то так, навскидку
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
Lethargeek
02.03.2017, 00:49
зачем два раза 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, все же
одно дело пользователям в старые компьютеры, которые итак еле дышат, лезть с паяльником, и совсем другое дело - просто воткнутся в стандартные пару разъемов - кемпстон и tape
в общем, куда-то припаиваться - не дело, если можно этого избежать
Тут у меня есть несколько возражений:
Первое - совместимость и наличие разъёмов.
У меня на двух спектрумах в детстве разъёмы Tape не совпадали: пришлось перепаивать чтобы грузится с одним шнурком от магнитофона.
У оригинального спектрума джеки вроде были, а у тех что с кассетой шли вообще не было разъёма Tape. Кемпстона, кстати на одном моём компе вообще не было.
Второе - питание и его гальваноразвязка
Для одной "микросхемы" городить гальваноразвязанное питание - это как-то не по людски.
Года два назад подключал как-то свой ПК к телеку по HDMI. Не показывает.
Думаю всё, писец, смертоубийство, спалил материнку или разъём в телеке.
Оказалось, что в разных розетках у меня разные фазы. На HDMI почему-то не выведена земля, а "земли" на разных фазах у импульсных источников питания получаются разными и более того - ползут относительно друг друга.
То есть нужно гарантировать чтобы хоть у одного устройства (у спектрума или у нашей схемы) а лучше у обоих сразу будет гальваноразвязка от сети. Иначе маловероятны, но вполне возможны пиротехнические эффекты.
Третье - конденсаторы в цепях Tape.
Во первых они нам срежут постоянку, а во вторых сильно понизят скорость. Да и длинные провода в разъём кемпстон могут повлиять на ВЧ.
Так что разъём Tape превращает проект в бессмыслецу.
можно читать полубайт и ждать следующего, а можно считать несколько полубайтов влет и потом уже синхрануться
Синхранутся можно когда мы примерно знаем период синхронизации. Почитайте ветку про состязательную и несостязательную оперативу (http://zx-pk.ru/threads/27384-vopros-pro-quot-sostyazatelnuyu-nesostyazatelnuyu-quot-pamyat.html). Я вот с удивлением узнал, что четырёхтактовая инструкция при определённых условиях запросто может до 10 тактов растянутся. Так что первый полубайт мы примем правильно, второй полубайт со смещением до 50% (думаю тут угадать реально), А вот третий приём уже не гарантируется. С четвёртым же - наверняка пролетите.
PS. И ещё раз напоминаю:
Устройство задумывается как максимально простое. Не ставится задачи загрузится за полсекунды. Пусть загрузка программы будет происходить не за 5 секунд, а за 8 или даже 10. Зато четыре раза ткнуть паяльником и приклеить термоклеем ардуинку.
Те кто любит спектрум и впадает в бешенство, если игра грузится дольше полсекунды - тот давно уже сидит на спектруме-мутанте с процом частотой в 20 мегагерц или даже зашитым в ПЛИС и работающим до 100 мегагерц.
тогда, если синхрит ардуинка, что-то такое будет? ;)
load:
ld a,e
out (#fe),a ;ардуинка, дай ещщо
in a,(#1f)
rld
dec bc
ld a,d
out (#fe),a ;ардуинка, дай ещщо
in a,(#1f)
rld
inc hl
ld a,b
or c
jr nz,load
Lethargeek
02.03.2017, 01:32
но синхримся же, так что лучше два rld, все же
если непременно с точностью до такта, то можно так:
in a,(#1f)
ret m
inc hl
ld (hl),a
in a,(#1f)
rld
но и железка может уметь сыпать ниблы неравномерно
да и настраиваться на различное торможение
тогда, если синхрит ардуинка, что-то такое будет? ;)
load:
ld a,e
out (#fe),a ;ардуинка, дай ещщо
in a,(#1f)
rld
dec bc
ld a,d
out (#fe),a ;ардуинка, дай ещщо
in a,(#1f)
rld
inc hl
ld a,b
or c
jr nz,load
load:
ld a,e
out (#fe),a ;ардуинка, дай ещщо
;тут, возможно, понадобятся паузы
in a,(#1f)
rld
dec bc
ld a,d
out (#fe),a ;ардуинка, дай ещщо
;тут, возможно, понадобятся паузы
in a,(#1f)
rld
inc hl
ld a,b
or c
jr nz,load
in a,(#1f)
rld
dec bc
in a,(#1f)
rld
inc hl
И сравниваем что предложил krt17
dup 8
in a,(#fe)
add c
rl e
edup
ld (hl),e
inc hl
59 тактов против 191. Разница в 3 раза.
Добиваем сюда синхронизацию. Добиваем сюда контрольную сумму. Учитываем задержки при чтении с флешки.
И получаем разницу в полтора-два раза.
Спрашивается, нафига козе баян?
В 2 раза усложняем схему, рискуем коротким замыканием через кемпстон-джойстик... и ускоряемся всего ничего.
Из дополнительных проводков я считаю, что полезен будет сигнал IORQ - по нему засинхронизироваться можно.
Поверьте, последовательная схема с синхронизацией по IORQ будет быстрее чем кемпстон-вариант с синхронизацией по пятому биту. Особенно это проявится в состязательной памяти (если процедуру хранить в буфере принтера)
нехер припаиваться внутрь компа, этим будут заниматься единицы
устройство же, которое можно тупо воткнуть (или максимум перепаять разъем), - более распространяемо.
ld a,e
out (#fe),a ;ардуинка, дай ещщо
;тут, возможно, понадобятся паузы
in a,(#1f)
Да, идея "дай ышо" примерно такая.
кстати "дай ышо" можно через OUT (BC),C: OUT (BC),B делать (экономятся и байты и такты)
Ну просто не нравится мне кемпстон-порт.
Радикального ускорения он не добавит.
Если хочется побыстрее, то вон, на EvgenRU наехать и раскрутить его на тему эмулятора AY-8910 на Atmega8
Прицепить к этой меге SD-карту и сделать синхронный байтовый обмен (команды INIR/INI OTIR/OTI) Тогда загрузка будет мгновенной.
Хотя нет. Вру. Чтобы была мгновенной надо вместо меги чип побыстрее ставить, STM какой-нибудь, чтобы через DMA работать с флешкой.
Но мне хочется максимально просто сделать.
Чтобы повторить можно было не вдаваясь в схемотехнику и за копейки.
- - - Добавлено - - -
нехер припаиваться внутрь компа, этим будут заниматься единицы
устройство же, которое можно тупо воткнуть (или максимум перепаять разъем), - более распространяемо.
Про "более распространяемо" - согласен. Только вот без пайки оно не заработает.
Без пайки это просто цифровой магнитофон у которого и схему и прошивку выложили, тут действительно повторятся не стоит.
Так что тут выбор простой - либо паять / либо вообще нах не делать.
короче, будет коробочка, из которой два провода на разъемы кемпстона и магнитофона, даже я куплю, шоббыла
а присобачивание внутрь компа - нафиг не нужно
- - - Добавлено - - -
и пусть там герконы какие-нибудь замыкаются как будто параллельный джойстик нажимается, никак это на комп не повлияет...
Lethargeek
02.03.2017, 02:43
59 тактов против 191. Разница в 3 раза.
как-то криво такты считаешь, на самом деле 58 (с одним rld) против 197 ~3.4 раза
(если ниблы отдавать неравномерно - retm не нужна и 53 такта ~3.7 раза)
Добиваем сюда синхронизацию
однократно перед запуском пакета - задаём через сколько тактов начать и на сколько байт развёрнут цикл приёма
Добиваем сюда контрольную сумму
на весь пакет, после передачи, необязательно
Учитываем задержки при чтении с флешки.
буферить
И получаем разницу в полтора-два раза.
в 3+
как-то криво такты считаешь, на самом деле 58 (с одним rld) против 197 ~3.4 раза
(если ниблы отдавать неравномерно - retm не нужна и 53 такта ~3.7 раза)
Считаю с округлением :) И ошибся всего на один такт. Для любителя не видящего спектрум с прошлого века - неплохо.
Про контрольную сумму:
на весь пакет, после передачи, необязательно
Её в любом случае считать. И лучше не простым XOR. Ну или хотя бы двумя вариантами.
Это сразу 10+ тактов на байт, а то и все 30.
буферить
Какая разница как это обозвать: чтение с флешки или чтение с флешки в буфер? Оно всё равно одно и то же.
В любом случае ардуинка не может отдать больше чем прочитает, а на прочтение нужно время.
Мы просто про разные вещи говорим: я говорю про суммарное время загрузки программы (программу надо поделить на "сектора", прочитать с флешки, загрузить в спектрум, сверить контрольные суммы, и запустить наконец), а вы про время загрузки одного байта.
Т.е. если считать общее время, то значительная часть операций у обоих алгоритмов будет одинаковая. Соответственно если какая-нить хня будет занимать 5% в однобитном решении, то она вырастет до 5*3.7 = 18.5 % в четырёхбитном. И будет уже не 3+, а уже 3-
Ну и даже если соглашусь с вами: если время загрузки игры - 8 секунд в последовательном режиме и 3 секунды в параллельном, но надо отключать нормальнозамкнутый джойстик. А в игре - управления с кемпстона. Вопрос - кто быстрее начнёт в эту игру играть и у кого быстрее сломается разьём? :)
И вообще не понимаю, почему так привязались к этому кемпстону. Он даже не во всех клонах присутствует.
Кроме того, почему-то вы не учитываете человеческий фактор. У меня вон на SSD винда грузится чуть больше 8 секунд. И я с пеной у рта не критикую микрософт, что можно было бы грузится за две секунды. На спектруме люди привыкли к тёплому ламповому ожиданию загрузки. Пока выберешь программу, пока отхлебнёшь кофе - глядишь уже всё загрузилось. Кстати, для унификации предполагалось что программы будут предварительно сжиматься упаковщиком, а при запуске - распаковываться. Это ещё 2-5 секунд, так что выбор будет между 10-13 и 5-8 секундами... короче экономия на спичках.
Ну и когда нормально вся система в целом заработает - то можно будет поиграться с вариантами. Вдруг окажется что большинство программ можно будет за 5 секунд загружать последовательно, зачем тогда ускорять если даже джойстик в руки взять и откинутся на спинку стула не успеешь? Как бы с дисковода дольше грузились и что-то никто его в окно не выкинул с криками - убью тормоза :)
Ну и даже если соглашусь с вами: если время загрузки игры - 8 секунд в последовательном режиме и 3 секунды в параллельном, но надо отключать нормальнозамкнутый джойстик. А в игре - управления с кемпстона. Вопрос - кто быстрее начнёт в эту игру играть и у кого быстрее сломается разьём? :)
не надо нихера отключать-переключать, коробочка один раз втыкается в комп, обычный джойстик в коробочку, коробочка работает как параллельный джойстик, можно кнопку autofire даж добавить и т.д. вплоть до прохождений :D
Lethargeek
02.03.2017, 04:37
Её в любом случае считать.
в честь чего так обязательно-то в любом? не мафон небось! как опцию для параноиков разве что
причём считать можно как раз в то "время, которое нужно ардуинке на прочтение" очередного блока
Кроме того, почему-то вы не учитываете человеческий фактор. У меня вон на SSD винда грузится чуть больше 8 секунд. И я с пеной у рта не критикую микрософт, что можно было бы грузится за две секунды. На спектруме люди привыкли к тёплому ламповому ожиданию загрузки. Пока выберешь программу, пока отхлебнёшь кофе - глядишь уже всё загрузилось. Кстати, для унификации предполагалось что программы будут предварительно сжиматься упаковщиком, а при запуске - распаковываться. Это ещё 2-5 секунд, так что выбор будет между 10-13 и 5-8 секундами... короче экономия на спичках.
не нутришь потенциала для запиляторов :v2_dizzy_punk:
не надо нихера отключать-переключать, коробочка один раз втыкается в комп, обычный джойстик в коробочку, коробочка работает как параллельный джойстик, можно кнопку autofire даж добавить и т.д. вплоть до прохождений
кемпстон-хаб! :eek:
кстати, в тему похожее
http://zx-pk.ru/threads/25615-fast-pc-loader.html
кстати, в тему похожее
http://zx-pk.ru/threads/25615-fast-pc-loader.html
Да, спасибо, почитаем. В принципе микросхемы почти те же самые, только они объединены в одну "супермикросхему" - ардуино нано.
Только с тех времён микросхемы стали более доступными, да и мелкие флешки - тоже. Пусть даже не по цене - просто появилось больше примеров и больше опыта стало.
На самом деле проект - это только прикидка (проверка скоростных характеристик).
Людям совершенно не важна скорость: главное сервис.
Ведь если будет игра загружатся 10 секунд из облака (куда накидают кучу софта все кому не лень) и за 1 секунду, но локально и при этом на каждую игру надо потратить час и перепаять полкомпа...
dr-nimnul
03.03.2017, 21:16
я вот что-то не понимаю, нафига все это? Таким образом можно только загрузить игру. Но ничего никуда не сохранишь.
А для загружания есть K7Zx. С нормально настроенным магнитофонным компаратором снапшот 48к грузился у меня 35 секунд. и никакого софта писать не нужно.
- - - Добавлено - - -
И не забываем, что для того, чтоб заработал загрузчик с Андруино - сначала на стандартной скорости нужно загрузить бейсик программу с кодовой вставкой. Что вовсе не мгновенно.
С тем же успехом так можно загружать из компа со звуковой картой и ЛПТ портом.
С принтерного порта 4бита + синхронизация пятым.
и в любом случае -ничего кроме снапшота так не загрузишь. Или полностью переделывать игру, как это сделано в разделе про искоренную заргузку ленинграда 2012.
petrov1962
04.03.2017, 08:07
С тем же успехом так можно загружать из компа со звуковой картой и ЛПТ портом.
С принтерного порта 4бита + синхронизация пятым.
А можно поподробнее по это?
я вот что-то не понимаю, нафига все это? Таким образом можно только загрузить игру. Но ничего никуда не сохранишь.
Безусловно, сохранить прогресс в игре (в той же элите) не получится.
А вот для бейсика планируется функция сохранения (там разница-то с чтением небольшая, процедуры на 80% совпадают)
А для загружания есть K7Zx. С нормально настроенным магнитофонным компаратором снапшот 48к грузился у меня 35 секунд. и никакого софта писать не нужно.
Во первых тут надо настроить компаратор.
А во вторых - 35 секунд. По совету <b>krt17</b> (Пост в начале темы) Скорость достигает до 210 тактов на байт - это 16 килобайт в секунду. То есть снапшот загрузится за 3-4 секунды.
И не забываем, что для того, чтоб заработал загрузчик с Андруино - сначала на стандартной скорости нужно загрузить бейсик программу с кодовой вставкой. Что вовсе не мгновенно.
Правильно. Только бейсик-программа из одной команды, а кодовая вставка тоже не велика - тройка дюжин байт. Если на пилоттоне сэкономить, то секунд за 5 загрузится.
С тем же успехом так можно загружать из компа со звуковой картой и ЛПТ портом.
С принтерного порта 4бита + синхронизация пятым.
Да, примерно так. Может быть незначительно быстрее. Только комп не нужен.
и в любом случае -ничего кроме снапшота так не загрузишь. Или полностью переделывать игру, как это сделано в разделе про искоренную заргузку ленинграда 2012.
Да.
Но во первых 80% программ для спектрума ничего не сохраняют и не подгружают, имеют вид LOAD "" CODE: RANDOMIZE USR - их переделать можно за 5 минут.
А во вторых копеечной доработкой (сча даже кабель для телефона в некоторых магазинах сравнимо стоит) получить возможность гораздо быстрой загрузки и без телефона/mp3-плеера/компьютера и т.п.
- - - Добавлено - - -
С тем же успехом так можно загружать из компа со звуковой картой и ЛПТ портом.
С принтерного порта 4бита + синхронизация пятым.
Про звуковую карту не скажу, а про LPT - пишется программа в несколько строк на любом языке, которая выводит в LTP полубайты с "мигающим" пятым битом
А спектрум ловит это дело через порт Kempston-джойстика.
Там главное чтобы скорость вывода в LPT была в 3-4 раза медленнее чем цикл ввода на спектруме: Если цикл меньше 70..100 тактов, то может и подглючивать.
В общем, ориентировочная скорость - 17 килобайт в секунду, а на коротких проводах и с квитированием IORD можно и вдвое ускорить
И присоединяюсь к просьбе, про звуковую карту - тоже интересно про софт который умеет работать с ней.
P.S. тема родилась как возможное решение проблемы загрузки бета-бейсика , а также сохранением программ на флешку.
Как бы если есть вариант проще и дешевле - рекомендуйте. И с чистой совестью похороним эту тему.
Думаю, лучше всего было бы сделать эмулятор микродрайва на ардуино+SDcard, чтоб и чтение и запись, и прочие команды работы с микродрайвом работали.
Подключать - через порт расширения, ведь при его отсутствии необходимые проводочки можно прямо к процу подпаять, если я не ошибаюсь.
Про эмуляцию BetaDiskInterface на ардуино я даже мечтать себе не позволяю.
У меня есть раздолбанная плата BDI, на которой нет ни ВГ93, ни ПЗУ, сохранилось лишь немного микросхем логики. Восстановить её не смогу, ввиду отсутствия у меня ВГ93 и ПЗУ.
Поэтому занимаюсь мечтаниями о ром-диске или подключении ардуино, а пока что гружу со смартфона турбированные версии бета-бейсика, паскаля и ZEUS ассемблера, программки сохраняю приложением Супер Диктофон.
Думаю, лучше всего было бы сделать эмулятор микродрайва на ардуино+SDcard, чтоб и чтение и запись, и прочие команды работы с микродрайвом работали.
Возможно и лучше. Только бяка в том что микродрайв - это ZX-Interface I, то есть эмулировать придётся не "проводочек" а целую плату размером со спектрум.
У меня есть раздолбанная плата BDI, на которой нет ни ВГ93, ни ПЗУ, сохранилось лишь немного микросхем логики. Восстановить её не смогу, ввиду отсутствия у меня ВГ93 и ПЗУ.
ВГ93 вернее какие-то их аналоги продавались на форуме. С ПЗУ тоже проблем не должно быть, в крайнем случае выковырять из старых материнок от ПК. Про эмулятор дисковода на AVR была великолепная тема (http://zx-pk.ru/threads/26328-planiruyu-sdelat-fdd-emulyator-na-atmega8.html?highlight=arduino+%D0%92%D0%9393)
Про эмуляцию BetaDiskInterface на ардуино я даже мечтать себе не позволяю.
На ардуино невозможно ничего хорошего сэмулировать.
дело в том, что внутри "всего хорошего" имеется ПЗУ, а у шины данных тайминги-наносекундные. За сотни наносекунд Ардуинка банально не успеет начать прерывание,прочитать два байта адреса, найти данные в своей памяти, скормить их Z80 и закончить прерывание. Разве только разогнать её до 28 мегагерц и засинхронизировать со спектрумом.
Вот у 32битного STM это вполне получится.
Поэтому занимаюсь мечтаниями о ром-диске
ROM-диск это вообще неправильная концепция (может применяться только как костыль). Правильно это когда программа работает напрямую с ПЗУ. Как пример - ни 48, ни 128 бейсик, ни даже TR-DOS не грузятся в оперативу, а работают прямо из ПЗУ. Ни на денди ни на сеге, кстати, картриджи тоже в оперативу не грузятся :) Разумеется, в наших с вами реалиях проще поставить костыль, чем адаптировать программы к ПЗУ.
В теории можно сделать простой ром-диск из кнопки и большой ПЗУ... но там думать надо много и программировать.
пока что гружу со смартфона турбированные версии бета-бейсика, паскаля и ZEUS ассемблера, программки сохраняю приложением Супер Диктофон.
К сожалению, спектрум мне обещали только через месяц. Ну и в железках я не очень, не факт что быстро разберусь даже с пятью проводками.
UncleDim
05.08.2023, 22:44
mmxdmv, с четырьмя справитесь?)
Апну тему, ибо тут про "простые решения"
Прикрутил сегодня SD к своему ленградоподобному просто на резисторах, без микросхем вообще. С порта fe взял пару бит с бордюра на cs и clk, данные на tape in и out. Согласующие резюки, питание 3.3 на транзисторе с диодом - железо готово!
На основе софта из темы про контроллер путника - наваял пзушку с загрузкой картинки, прям с 0 сектора карты в экран. Про скорость вообще при написании не думал, абы как да чтоб заработало (под zilog вообще ничего длиннее десятка байт не писал, да и сейчас не сильно продвинулся)) - как итог - на 6.75 безвейтовых МГц .scr грузится чуть больше секунды.
кагбэ пруф: https://www.youtube.com/watch?v=feVyd9lImbI
Как замена магнитофону вполне имеет право на жизнь, как считаете?
- - - Добавлено - - -
источник "вдохновения" тут:
https://zx-pk.ru/threads/30904-cf-mod-(c).html?p=1052424&viewfull=1#post1052424
- - - Добавлено - - -
Про скорость вообще при написании не думал
собсно ключевые изменения вот:
SD_FIN: ld A,0FFh ;
SD_PUT: push af ;
call SD_IO ;
pop af ;
ret ;
SD_GET:
ld a,0ffh
SD_IO: ;in and out values in A
push bc ;
LD B,8 ;
LD C,A ;
sd_iob: in a,(0FEh) ; we are @mode 0, isn't it?
rlca ;
rlca ; sd_in -> CY
ld a,008h ;
bit 7,c ;
jr nz, sdpb ;
res 3,a ; msb out prepared
sdpb: rl c ; msb in shifted into C reg
out (0FEh),a ; bit 7 outed,
set 2,a ;
out (0FEh),a ;
res 2,a ;
out (0FEh),a ; and clocked
djnz sd_iob ;
ld A,C ;
pop bc ;
ret ;
doleynikov
10.08.2023, 16:56
А можно схему привести, как подключена SD карточка?
UncleDim
10.08.2023, 19:31
А можно схему привести
ее нарисовать еще надо)
а пока буду рисовать - встречный вопрос: прошивку (рабочую т.е., с бейсиком) где возьмете?)
зы. приложил схему
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot