Важная информация
Страница 6 из 6 ПерваяПервая ... 23456
Показано с 51 по 54 из 54

Тема: Ленинградский монитор и другие программы для СПЕЦИАЛИСТА

  1. #51
    Guru Аватар для HardWareMan
    Регистрация
    26.02.2011
    Адрес
    Павлодар
    Сообщений
    2,569
    Благодарностей: 1270

    По умолчанию

    Цитата Сообщение от fifan Посмотреть сообщение
    Если эта фотка - то я сохранил.
    Да, это одна из них. Именно про него я и говорил.

    - - - Добавлено - - -

    barsik, в противовес я бы предложил поставить 245 буфер, например. Но если есть ВВ55 то почему бы и нет? А методику подключения большого ОЗУ и/или ПЗУ мы уже обкатали.


    4 5ти вольтовых 512КБайт флешки (2МБайта) с возможностью записи. Подключается ко второму ППА. Запоминается средний байт адреса (A[15:8]), так же как и у вас. Детали проекта где-то у fifan'а.
    Последний раз редактировалось HardWareMan; 30.03.2017 в 09:39.

  2. #52
    Activist
    Регистрация
    05.04.2013
    Адрес
    с. Починки, Нижегородская обл.
    Сообщений
    257
    Благодарностей: 166

    По умолчанию

    Не следил за обсуждением с самого начала, так что подключаюсь к обсуждению только сейчас.
    Во-первых, спасибо за интересные материалы, ну и несколько комментариев.

    Цитата Сообщение от barsik Посмотреть сообщение
    Сначала попробовал эмулятор EMU80 V4.0. И тут обнаружилось, что файлы в формате ORD этот эмулятор СПЕЦИАЛИСТА не грузит. Это безобразие, ведь формат ORD - это универсальный формат для 8-ми разрядок, непривязанный к формату на ленте и позволяющий иметь все параметры блока - имя, адреса и контрольную сумму. Поиски в дистрибутивах конвертора ORD в RKS результата тоже не дали.
    Я никогда не работал с реальным Специалистом, даже не думал, что для него может понадобиться орионовский формат ORD. Какой софт для Специалиста использовал ORD? В каком виде сделать нужно его загрузку в эмуляторе?


    Цитата Сообщение от barsik Посмотреть сообщение
    в эмуляторе EMU80, если я правильно понял, вообще не поддерживается формат загрузки по сбросу
    В эмуляторе по умолчанию для удобства подключен патченый Монитор, в котором заблокирована загрузка по сбросу. Если подключить оригинальный, то загрузка rk(s)-файлов по сбросу будет доступна. Но тогда для выхода в Монитор каждый раз после сброса придется нажимать функциональную клавишу для прерывания попытки загрузки. С другими Мониторами, надеюсь, тоже будет работать, нужно только при необходимости поправить адреса перехвата процедур работы с магнитофоном (адрес ret в emu80 не нужен, только адрес начала).

    Цитата Сообщение от barsik Посмотреть сообщение
    стати, конфига и эмулятора СПЕЦИАЛИСТА в варианте КООП SP-580 тоже не нашёл,
    Пока вообще ничего про этот вариант знаю, не видел даже в эмуляторах. Буду благодарен, если подскажете ресурсы, где можно узнать поподробнее про SP-580.


    Цитата Сообщение от barsik Посмотреть сообщение
    впечатляет, что возможен ввод из WAV-файла, как из магнитофона. Это очень крутое свойство и в эмуляторе EMU80 его явно не хватает.
    Будет. Чуть позже - когда руки дойдут.

    - - - Добавлено - - -

    Цитата Сообщение от HardWareMan Посмотреть сообщение
    Я имею одну идею как сохранить их так, чтобы это был не тупой WAV, но который мог бы быть восстановлен в случае необходимости. Но для работы мне нужны записи. И это не TAP/TZX, т.к. те заточены под Спектрум.
    Цитата Сообщение от NEO SPECTRUMAN Посмотреть сообщение
    нужно для эмуляторов РК-шек приспособить расово верный .tzx
    Цитата Сообщение от DDp Посмотреть сообщение
    Напрямую непойдёт, другой формат бита и байта. Но можно сделать свой, "по мотивам". А расширение, например, .TRK
    Очень интересная тема, тоже давно уже думаю об этом.
    В принципе, можно и TZX использовать с ID блока, кажется, 15 - direct recording. Но TZX все-таки больше спектрумовский, некрасиво это. Можно создать свой. Или, быть может, уже существуют какие-то подобные форматы для замены WAV? В общем, хотелось бы обсудить...
    Последний раз редактировалось Pyk; 30.03.2017 в 13:52.

  3. #53
    Activist
    Регистрация
    14.05.2013
    Адрес
    г. Москва
    Сообщений
    229
    Благодарностей: 54

    По умолчанию

    Цитата Сообщение от Pyk Посмотреть сообщение
    Буду благодарен, если подскажете ресурсы, где можно узнать поподробнее про SP-580.
    http://www.spetsialist-mx.ru/schemes/SP580.png
    http://www.spetsialist-mx.ru/Soft/SP580.rar

  4. Этот пользователь поблагодарил uart за это полезное сообщение:
    Pyk (30.03.2017)

  5. #54
    Master Аватар для barsik
    Регистрация
    05.10.2016
    Адрес
    г. Санкт-Петербург
    Сообщений
    717
    Благодарностей: 199

    По умолчанию

    Привожу описание эл.диска из документации для ACP/M 1.55E ОРИОНА. Это версия ДОС позволяющая обходиться без дисковода. С МГ-ленты грузится файл, он автоматически стартует, форматирует эл.диск и записывает на него программу обмена с МГ и выходит в CP/M 60К. Здесь вся необходимая программисту информация. Вообще-то это текст из письма пользователю ACP/M 1.55E, но использовался как ДОК к эл.диску (потому сохранился).

    Скрытый текст



    ............... ЭЛЕКТРОННЫЙ ДИСК, УСТРОЙСТВО И ИСПОЛЬЗОВАНИЕ

    Электронный диск представляет собой узел регенерации ОЗУ типа 565РУ7 и интерфейсную БИС типа 580ВВ55 для связи с центральным компьютером. Плата обладает своим задающим генератором и все сигналы для своей работы вырабатывает сама. Тем самым плата полностью независит от основного компьютера, что позволяет выключать его питание, без потери информации на диске. Потребление при отсутствии обращений к диску не превышает 300 мА (на 555, при 155 серии намного больше). При наличии буферной ёмкости в 50.000 МКФ не страшны провалы питания до 2 секунд.

    На плате эл.диска установлены две банки ОЗУ 565РУ7 и ещё две банки могут быть напаяны сверху (методос "PACK-UP), позволяя иметь в максимуме 1 мбайт. Также на плате располагается панелька под ПЗУ 27127/27256 (16/32 кб). Кроме такой платы варианта 1990 года, была выпущена партия плат 1989 года, без ПЗУ и с всего одной банкой РУ7.

    Данная конструкция разрабатывалась для СПЕЦИАЛИСТА , где во-первых нет излишних портов (как на ОРИОНЕ) и не буферизованы шины процессора. Поэтому весь интерфейс осуществляется через одну единственную ППА 580ВВ55, нагружая шину (D0-D7, A0,A1) нагрузкой всего одного входа порта. На СПЕЦИАЛИСТЕ с тактом 2.0 МГЦ допускается длина соединительного кабеля до 35 см, без ухудшения надёжности. На СПЕЦИАЛИСТЕ с тактом 2.5 или 2.75 МГЦ длина кабеля не должна превышать 15 см, причём в случае применения ИМС 155-й серии и большого количества ПЗУ РФ2 (более 3-х) шина будет перегружена и нельзя будет одновременно подключить контроллер НГМД.

    Рекомендуется установка 580ВК28, благодаря чему удаётся поднять такт на 580-м процессоре (!) до 3.75 МГЦ и даже 4.0 МГЦ (это достигается за счёт ВК28, а также понижения питания КР580 до 4.75 В, - только процессора, питание ОЗУ: >= 5.0 В). Длину кабеля при ВК28 можно сделать 35 см. При применении в СПЕЦИАЛИСТЕ Z80 проблем с перегрузкой шин не наблюдалось до частоты 4.25 МГЦ. Что касается ОРИОНА, то здесь проблем подключения меньше - у некоторых работает уже несколько месяцев и на такте 5.0 МГЦ.

    Исходя из вышеизложенного, рекомендуется применять в СПЕЦИАЛИСТЕ Z80 с большей мощностью выходов, а именно 'GOLDSTAR' с буквой А. Можно также - GOLDSTAR-B или даже SHARP с любой буквой, что конечно решает все проблемы с перегрузкой шин, но глупо из-за их печкообразности. На ОРИОНЕ наоборот, целесообразно применять Z80 с хилыми выходами: ZILOG, TOMPSON, NEC, MME, TOSHIBA или их КМОП-варианты (8C0004) или даже SU880 (10 мА), т.к процессор в ОРИОНЕ буферизован.

    Для интерфейса с компьютером используются следующие сигналы системной магистрали:

    D0-D7 ... шина данных
    A0,A1 ... шина адреса
    /WR ..... запись (в память, т.е /MEMW)
    /RD ...... чтение (/MEMR)
    /CS ...... чип-селект (СПЕЦИАЛИСТ - FD00, ОРИОН - F780)
    RESET .. сброс (прямой не инверсный)
    GND ..... GROUND, системная земля.

    Всего в кабеле 15 проводков МГТФ-0.03 (для земли лучше провод потолще).

    Принцип работы: Для адресации в 512К требуется 19 адресов A0...A18. Для хранения этого адреса на плате имеются 3 регистра: младшего байта адреса (N байта в секторе), старшего байта адреса (N сектора в банке), и регистр хранящий адреса A16...A18 (N банки). Эти регистры непрерывно сохраняют этот текущий адрес (даже после сброса), - тем самым процессор может читать или писать данные из этой ячейки диска. Первые два из этих регистров 8-ми разрядные, выполнены на счётчиках с переносом 155ИЕ7.

    С помощью сигнала с выхода PC3 ППА формируется так называемый строб инкремента адреса, от которого счётчики увеличивают свое состояние на 1. Таким образом при чтении/записи в пределах 64-х кбайт (одной условной банки) существует возможность не устанавливать при обращении к последующей ячейке новый адрес. Достаточно выдать строб инкремента и читать/писать далее.

    Установка старшего и младшего байта адреса (А0-А15), т.е запись в эти счётчики также осуществляется стробами адреса: старшего (PC5) и младшего (PC4). Что касается адресов A16...A18, то они формируются по разному для вариантов 256/512К и для варианта 1 мбайт, а именно: в варианте 1 мбайт также используется регистр на ИЕ7 и строб для его записи (PC6). В вариантах же диска 1989 и 1990 годов на 256 и 512К эти адреса формируются непосредственно портом (это позволяет с'экономить одну ИЕ7). Т.е в твоей плате адресам A16...A18 соответствуют выходы PC0...PC2.

    Все данные вводятся в диск через порт A, а считываются через порт B БИС ВВ55. Выходы порта C формируют управляющие сигналы. Таким образом назначание портов и разрядов такое:

    PA0-PA7 - данные для ввода в диск (ВВ55 - на вывод)
    PB0-PB7 - данные с диска (ВВ55 всегда на ввод)

    Порт 'C' программируется на вывод и управляется поразрядно:

    PC0-PC2 - это адреса A16...A18
    PC3 - строб инкремента адреса
    PC4 - строб записи младших 8-ми разрядов адреса (A0-A7)
    PC5 - строб записи старших 8-ми разрядов адреса (A8-A15)
    PC6 - блокировка записи диска 256К и сигнал ROM/RAM в дисках 512К (с ПЗУ 27256)
    PC7 - строб записи в ячейку

    Сигналы стробов должны быть постоянно в 1. При формировании строба на эти выходы выводится на короткое время 0, затем возврат в 1. Запись осуществляется по уровню, т.е если держать стробы =0 и менять данные в порту A, то в регистрах будет то же, что на выходах порта A. Если адреса равны, то стробы можно выдавать одновременно (т.е установить адреса A0-A18=0 и записать в эту ячейку 0, - можно всего одной командой STA PORTC,040H). Строб инкремента (PC3) работает по переднему фронту.

    Рассмотрим работу с диском. Для записи надо:

    1. Вывести в порт A адреса A0-A7
    2. Выдать строб PC4
    3. Вывести в порт A адреса A8-A15
    4. Выдать строб PC5
    5. Вывести в разрядах PC0-PC2 адреса A16-A18
    6. Вывести в порт A подлежащие записи данные
    7. Выдать строб записи

    При этом, если сигнал ROM/RAM (или защита от записи) был равен 1, то данные будут записаны. Если надо записывать в следующую ячейку, то пункты 1-5 не выполняются, а выдаётся строб инкремента.

    Для чтения надо:

    1-5. Установить адреса (как при записи, см.выше)
    6. Просто считать с порта B данные

    Далее можно выдать строб инкремента и считать следующий байт и т.д. Для диска 256К значение разряда PC6 не важно - это просто блокировка и защита от записи, на чтение не влияет. В диске 512К значение сигнала на выходе PC6 определяет считывается ROM или RAM. При PC6=0 считывается ПЗУ 27256, при PC6=1 считывается ячейка RAM-диска. Естественно этот сигнал выполняет и старую вункцию, т.к записать в ROM нельзя.

    Пара слов о программах для RAM-диска. Немного истории. Первый RAM-диск появился в конце 1988 и имел всего 64К. В 1989 использовались эл.диски на 128К (уже именно такой конструкции, с ППА в качестве интерфейса). В конце 1989 удалось изготовить партию печ.плат на 128/256К.

    Первую простую файловую систему написал А.Кузнецов. RAMDOS версии 1.0 была написана легендарным программистом В.Ивинских в конце 1989. Также был доработан для работы с файлами его редактор SCREEN и уже в начале 1990 была сделана первая версия программы RAMDOS-COMMANDER. Летом 1990 В.Ивинских доработал RAMDOS до версии 1.4 и коммандер версии 1.3, ставшие классикой программирования для КР580. И вскоре, пользуясь RAMDOS, В.Ивинских адаптировал для СПЕЦИАЛИСТА MANIC-MINER от Синклера, работу которую без эл.диска сделать было бы невозможно. В дальнейшем В.Ивинских в конце 1990 разработал новую версию RAMDOS-COMMANDER, использовав специально написанный им графический интерфейс с открывающимися окнами (получить представление о нём можно посмотрев ROM-WRITER В.Ивинских, есть его и ОРИОН-версия).

    К несчастью, наступили времена дисководов. Осенью 1990 уже 5 пользователей СПЕЦИАЛИСТ-а имели CP/M, хотя платы КНГМД были выпущены только в конце 1990 года (потому достались уже орионщикам). Несмотря на это, эл.диски нашли отличное применение и в среде CP/M, т.к до появления первых программ копирования на одном НГМД (А.Новгородов 08.1991) эл.диск был единственным способом скопировать файл размером более TPA (36К).

    Для RAMDOS, из-за полного упадка СПЕЦИАЛИСТА, ухода в начале 1991 В.Ивинских в профессиональные программисты, и появления CP/M, - ничего серьёзного создано не было. К 1992 "спецов" осталось ~5 человек и они не пишут сами (чисто пользователи). Можно упомянуть форт-систему работающую с файлами RAMDOS, граф редактор Е.Якубовского V4.0, DISK DOCTOR Максима Белова и мои программки TX_FORM (делает 2 колонки по 48/60 символов с выравниванием краёв для печати текстов мелкошрифтом), FILE MANAGER и SPRITE_EDITOR. Хотя планируется адаптировать ассемблер Z80 А.Балдина для ОРИОНА для RAMDOS (его орионовские ассемблеры для КР580 и Z80 позволяют, при наличии в ОРИОНЕ 256К, транслировать программы с объёмом исходника до 180К за счёт использования INCLUDE). К сожалению, владельцы ОРИОНА используют эл.диски исключительно для CP/M, не имея никакого представления о RAMDOS.

    На мой взгляд, наличие эл.диска обьёмом в 512К и турбо-среды программирования на ассемблере (прошитой в ПЗУ ЭД) для программиста полезнее, чем наличие CP/M и КНГМД. В турбо-среде переход между программами (редактор-ассемблер-отладчик) осуществляется мгновенно (загрузка 32К - 0.3 сек).

    Сравните, в RAMDOS, закончив редактирование программы, - хлоп на кнопку - и Вы в ассемблере и уже идёт ассемблирование, через 30 секунд (тест в 36 кб) - готово, хлоп по кнопке - программа загружена в рабочие адреса, текст программы записан в файл и Вы в отладчике, можете начинать прогон или отладку.

    А как то же делается в CP/M? В редакторе, закончив редактирование, записываете файл на диск. Запускаете ассемблер, ждёте (лязг дисковода 10 минут), и если дискета не сдохнет (что бывает часто с дискетами ИЗОТ и ГМД), то вскоре выясняется, что в тексте куча ошибок. Опять загружаете редактор (каждый раз пишете имя редактора, затем имя файла). Редактирует и снова трранслируете. Если наконец ошибок нет, загружаете компоновщик, - опять 10 минут износа дискет и головок и... бац. Готово. Теперь с помощью программы LOAD делаете из HEX-файла COM-файл. Затем запускаете ZSID3, командой R загружаете Ваш файл и, наконец, начинаете отладку и... - конечно ничего не работает. В злобе Вы вырываете последние волосы с головы... Надо снова запускать редактор и загружать исходник на редактирование. Но прошло 25 минут и Вы уже забыли, какие изменения Вы делали в тексте и потеряли нить Вашей программистской мысли.

    Писать программы, когда на один цикл изменения и проверки уходит пол-минуты, или когда на то же самое тратится пол-часа? Мы выбираем первое, даже если в RAMDOS ассемблере нет макро-команд, отладчик сильно уступает ZSID3 или ZBUG, а редактор не имеет команд работы с блоками. Всё это искупается скоростью работы и отсутствием потерь времени. Именно так можно работать с RAM-диском, а не для копирования файлов при одном НГМД.

    Кстати, подобную среду турбо-ассемблирования можно иметь и на ОРИОНЕ, если адаптировать RAMDOS для внутреннего эл.диска ОРИОНА из излишнего ОЗУ. На Вашу кассету я записал Вам базовые подпрограммы чтения и записи байта и сектора, а также ещё несколько полезных подпрограмм для работы с диском на физическом уровне (выдранные из RAMDOS В.Ивинских). Если необходимо могу прислать Вам исходники RAMDOS, для её конверсии на ОРИОН. Что сделать совсем просто. Но вот конвертировать программы RAMDOS, сделанные под железо СПЕЦИАЛИСТА - так просто не получится. Версия CP/M 1.55E поддерживает, кроме эл.диска и дисковод. Потому рекомендую Вам купить плату КНГМД для ОРИОНА.

    (c) barsik. Текст написан, предположительно, в середине 1992.
    .
    [свернуть]


    Цитата Сообщение от Pyk
    Не думал, что для Специалиста может понадобиться орионовский формат ORD. Какой софт для Специалиста использовал ORD? В каком виде сделать нужно его загрузку в эмуляторе?
    А разве формат ORD Вы где-то поддерживаете? В эмуляторе ОРИОНА формат ORD только на дискетах.

    Я предпочёл бы, чтобы формат ORD читался бы как основной TAPE-формат данного компьютера. Это избавит меня и всех остальных пользователей эмулятора от необходимости вручную заносить адреса, считать КС блоков и подставлять их в TAPE-файл (GAM, RKS, RKA, RKP, RKO, RKR). А файл ORD остаётся пригодным и для дисководной версии, отчего число копий файла в разных форматах не плодится.

    Формат ORD лишь изначально был орионовским в 1991, когда его впервые стали использовать на дисководах. Но ОРИОН не единственный компьютер, у которого адреса старта файлов произвольные, а не ровно 100H. Вместо того чтобы "разводить" море разных форматов для разных компьютеров удобно использовать один единственный формат ORD, что я и делаю. У меня на винте все файлы разных компьютеров - в формате ORD.

    Любая команда загрузки с ленты должна понимать формат принятый на данном компьютере, а также формат ORD. Поэтому, если в эмуляторе СПЕЦИАЛИСТА при загрузке по I выбрать ORD-файл, он тоже должен загрузиться и стартануть, как RKS файл с именем. Эмулятор должен сам конвертировать файл ORD в формат RKS. Тогда мне не придётся это делать вручную. Т.е по умолчанию, ORD формат должен соответствовать формату с именем принятому на данном компьютере, а если такого формата нет, как например для РК86, то естественно, единственному формату, что принят для РК86. Тогда мне не придётся вручную считать КС блоков и подставлять их в GAM-файл.

    Кстати, какое расширение имеют файлы СПЕЦИАЛИСТА в формате без имени? Т.е те файлы, что грузятся по сбросу (это файлы созданные древним волковским монитором и те, что используются командами R/W орловского монитора). Такой формат тоже должен быть. Т.к, если я по сбросу попытаюсь загрузить файл в формате RKS (т.е с именем), то будет улёт. Если особого имени ещё нет, то для таких файлов в имени можно вставлять слово (auto), что значит, что это программа и она грузится по сбросу.

    Как я понимаю, загрузка TAPE-файлов работает так:

    При первом (за 5 секунд) обращении к RDBYTE запрашивается имя и открывается файл. Затем по каждому вызову RDBYTE из открытого файла читается очередной байт, пока файл не кончится или пока после последнего обращения к RDBYTE не пройдёт 5 секунд. Тогда файл закрывается. Потому если за 5 секунд запустить новую загрузку, то происходит чтение из конца открытого файла (когда размер файла не точно равен размеру блока указанному в заголовке).

    Как поведёт себя эмулятор в такой ситуации? ROM-BIOS загрузив блок по сбросу, запускает его. Этот блок включает другой формат МГ-ленты, двухчастотку и начинает загрузку второго блока, записанного в реале в формате MSX. По первому же вызову RDBYTE мы попадём уже на другую точку отлова (для формата MSX). Что произойдёт? Эмулятор будет продолжать чтение из открытого файла, или запросит имя нового файла (файла второго блока идущего в другом формате записи)? Правильно читать из первого файла.

    PS. Раз уж зашла речь о формате ORD, то очень неудобно реализовано в трёх эмуляторах ОРИОНА использование ROM-диска и квазидисков ORDOS.

    Требуется с помощью хитроумных ухищрений вручную формировать ROM/RAM диски (а также дискеты), что крайне неудобно и неоперативно. В моём эмуляторе ОРИОНА это сделано удобнее. Файлы с расширением ORD автоматически грузятся из каталогов ORDOS.A, ORDOS.B, ORDOS.C, ORDOS.D (и точно также формируется и "дискета" - все файлы автоматически перегружаются туда из каталога FILES.DOS). Поэтому легко набить все 4 квазидиска ORDOS-файлами и менять набор файлов в квазидисках оперативно.

    Кстати, у Вас и оперативной замены ПЗУ ROM-BIOS без разрушения ОЗУ тоже нет. Это неудобно.

    Цитата Сообщение от Pyk
    В эмуляторе по умолчанию патченый Монитор, в котором заблокирована загрузка по сбросу. Если подключить оригинальный, то загрузка RKS-файлов по сбросу будет доступна
    Это хорошая новость, т.к плохо переношу стандартные мониторы.

    Цитата Сообщение от Pyk
    Если поставить оригинальный монитор, то тогда для выхода в Монитор каждый раз после сброса придется нажимать функциональную клавишу для прерывания попытки загрузки по сбросу
    Но так и должно быть. Так и есть на реальном СПЕЦИАЛИСТЕ. Хотя есть мониторы, которые сами (без нажатия клавиш) выходят на C800, если нет сигнала.

    Цитата Сообщение от Pyk
    С другими Мониторами, надеюсь, тоже будет работать, нужно только при необходимости поправить адреса перехвата процедур работы с магнитофоном (адрес возврата из подпрограмм RDBYTE/WRBYTE в EMU80 не нужен, только адрес начала)
    То, что адрес возврата не нужен это хорошо, т.к адрес входа у меня один C377 (это же стандартный вход), а выходы меняются в зависимости от формата. Получается, что эмулятор B2M удобно использовать для WAV-файлов а EMU80 для обычных RKS файлов.

    Цитата Сообщение от Pyk
    Цитата Сообщение от barsik
    впечатляет, что возможен ввод из WAV-файла, как из магнитофона... этого свойства в эмуляторе EMU80 явно не хватает
    Будет. Чуть позже.
    При этом нельзя ли сделать так, чтобы я видел WAV-файл при работе магнитофона. Не имя файла (хотя имя тоже надо видеть), а картинку его частотно-временной диаграммы (или осцилограммы на медленной развертке), также как это выглядит в программе "Звукозапись" Windows. Можно в отдельном окне отображать картинку стилизованного аудио магнитофона, как это делают в программах проигрывателях MP3 и WAV. Можно отображать счётчик ленты и в отдельном окне, как 'Play list' в проигрывателях список файлов данной кассеты. Тогда вообще всё будет выглядеть близко к реалу.

    И кстати, в реальном магнитофоне есть клавиша ПАУЗА. И иметь её и в эмуляторе не помешает. Например, у меня есть блоки WAV-файлов (неизвестно что). Так вот, чтобы не пришлось нарезать большой файл на фрагменты (а как это сделать, если идёт многоблочная загрузка, отчего не ясно, - это новый файл или блок от предыдущей многоблочной программы). Тогда и нужна пауза. Считал WAV файл в ОЗУ, нажал на паузу, выгрузил считанный файл в обычном виде (в смысле байтами, не звуками), а затем снова запустил команду ввода и "отпустил" клавишу ПАУЗА для считки очередного файла.
    Последний раз редактировалось barsik; 30.03.2017 в 20:33.

Страница 6 из 6 ПерваяПервая ... 23456

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. PS/2 адаптер клавиатуры для Специалиста
    от fifan в разделе Специалист
    Ответов: 220
    Последнее: 24.03.2017, 22:53
  2. Ответов: 143
    Последнее: 02.01.2017, 22:51
  3. Ответов: 46
    Последнее: 15.03.2014, 17:56
  4. Есть 3 кассеты для Специалиста...
    от Bolt в разделе Специалист
    Ответов: 60
    Последнее: 27.10.2013, 15:24
  5. Изучается спрос на плату для Специалиста
    от Павел Рябцов в разделе Барахолка (архив)
    Ответов: 109
    Последнее: 30.11.2010, 12:16

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •