SDOS

[Shaos]

Чото наверное пора отдельную тему создать тут

https://zx-pk.ru/threads/29892-sd-karta-i-sdos-dlya-8i-bitnykh-pk.html

Что же такое SDOS?
SDOS это компактная консольная оболочка позволяющая читать, запускать на исполнение файлы с SD карты, отформатированной в FAT16, и записывать обратно на карту данные из ОЗУ компьютера. Это позволяет очень просто переносить файлы с 'больших' ПК в наши ретрокомпьютеры и обратно.
В основе кода SDOS взят код уважаемого b2m, который я обрамил дополнительным функционалом и возможностями.
Код системы построен таким образом, что его очень просто можно адаптировать к любому ПК и к любому варианту аппаратного интерфейса и носителя (те, вообще говоря, это не обязательно должна быть SD карта, а может быть и HDD).

На данный момент SDOS:
код самой SDOS занимает от 2 до 2.5КБ (может размещаться как в ПЗУ так и в ОЗУ), плюс для работы с FAT16 нужно еще 2КБ ОЗУ.

собиралась и проверялась как минимум в эмуляторе emu, а в некоторых случаях и в реале на следующих ПК: Специалист std(реал) и MX2(реал), RK-86(реал), Апогей, Партнер-01, Galaksija(реал), Orion(реал), TRS-80(реал), ЮТ-88.

поддерживает три базовых аппаратных интерфейса SD: HWM_PVV, msx, n8vem, и их производные варианты.

поддерживает SD и SDHC карты, те карты с размером больше 4ГБ.

поддерживает следующие базовые директивы:

- CD ИМЯкаталога - перейти в каталог с указанным именем;
- DIR - вывести список файлов и каталогов;
- ИМЯфайла.RKX(RKS для std, RKR для RK-86, GTP для Галаксии, RKO - Орион, CAS - TRS-80 ) запустить файл, при этом расширение можно не набирать, будет произведена автоподстановка;
- R ИМЯфайла.РАСШИРЕНИЕфайла,АДРЕСкуда,СКОЛЬКОбайт - прочитать не запуская файл, начиная с указанного адреса в памяти и сколько байт пример: R TEST.BIN,0ACD,5FE0 - читает файл TEST.BIN в память начиная с адреса 0х0ACD и до адреса 0х0ACD+0х5FE0=0х6AAD. Ограничение - нет проверки на фактическую длину файла и запрошенную на чтение, те можно запросить прочитать больше чем размер файла, поведение не определено
- W ИМЯфайла.РАСШИРЕНИЕфайла,АДРЕСоткуда,СКОЛЬКОбайт - записать в файл данные из памяти, начиная с указанного адреса в памяти и сколько байт пример: W TEST.BIN,0ACD,5FE0 - пишет в файл TEST.BIN из памяти начиная с адреса 0х0ACD и до адреса 0х0ACD+0х5FE0=0х6AAD. Ограничение - нет проверки на фактическую длину файла и запрошенную на запись, те можно запросить записать больше чем размер файла, поведение не определено. Записать больше чем существующий размер файла нельзя, если записать данных меньше чем размер файла, то размер файла не меняется и остается прежний
- X - перейти в монитор, из которого был запущен SDOS;
- I - запуск повторной инициализации карты;

только Galaksija:

- WB ИМЯфайла.РАСШИРЕНИЕ - запись BASIC программы в файл на SD в формате GTP;

только СпецециалистМХ:

- L ИМЯфайла.РАСШИРЕНИЕфайла - прочитать данные файла формата RKX с SD в RAM диск МХа; пример: L TEST.BIN - читает файл TEST.BIN в память начиная с адреса 0х0000 и до адреса его длины, создает в RAM диске файл TEST.BIN с стартовым адресом и размером взятыми из 4х первых байт файла на карте, при том, что имя файла в хеадере отсутствовало (в 5м байте 0хЕ6).
Или: L TEST.BIN - читает файл TEST.BIN в память начиная с адреса 0х0000 и до адреса его длины, создает в RAM диске файл TEST_MX.HEX, с стартовым адресом и размером считанные из 4х первых байт файла на карте, и именем файла в хеадере TEST_MX.HEX.
- S ИМЯфайлаНаRAMдиске.РАСШИРЕНИЕ,ИМЯфайлаНаSD.РАСШИРЕ НИЕ - записать данные файла из RAM диска МХа на SD в формате RKX; пример: S TEST.BIN - читает файл TEST.BIN из RAM диска в память начиная с адреса 0х0000 и до адреса его длины, после записывает его на SD карту в существующий файл с таким же именем TEST.BIN, размер не изменяется, формат RKX!
Или: S TEST.BIN,TEST_MX.HEX - читает файл TEST_MX.HEX в память начиная с адреса 0х0000 и до адреса его длины, после записывает его на SD карту в существующий файл с именем TEST.BIN.

только Orion:

- L ИМЯфайла.РАСШИРЕНИЕфайла - прочитать данные файла формата RKO с SD в RAM диск; пример: L TEST$.RKO - читает файл TEST$.RKO в память начиная с адреса 0х0000 и до адреса его длины, создает в RAM диске файл TEST$ с именем, стартовым адресом и размером взятыми из хеадера RKO файла на карте.

- S ИМЯфайлаНаRAMдиске,ИМЯфайлаНаSD.РАСШИРЕНИЕ - записать данные файла из RAM диска на SD в формате RKO. пример: S TEST$,TEST1$.BIN -читает файл TEST$ из RAM диска в память начиная с адреса 0х0000 и до адреса его длины, после записывает его на SD карту в существующий файл с таким же именем TEST1$.BIN, размер не изменяется, формат RKO!.

При выводе каталога по DIR печатается имя, расширение файла и его размер(что бы можно было использовать директивы R и W), а на директории пишется DIR в поле размера файла.

При запуске файла пишется стартовый и конечный адреса куда будет считан файл с карты.

Нажатие любой клавиши (пробела) при выводе по DIR приостанавливает вывода списка файлов.

Для СпециалистМХ2 сделана возможность запускать не только файлы с расширением RKX, но и RKS, для чего в том же каталоге, где находится RKS файл нужно поместить файл монитора M2_C000.MON (взят из проекта Vinxru). Кроме того, есть возможность загружать произвольные мониторы.

[Shaos]

По исходникам:

SDOS написана в мнемониках ВМ80, и без проблем запускается на Z80.
Каждый раз при добавлении какого либо функционала и новых платформ (ПК) я увеличивал номера версий и подверсий. Актуальная на данный момент версия 8.9, но практически это 8.6, тк 8.7 - 8.9 это лишь сборки под разные платформы с подвариантами SD интерфейса, и на этом этапе я понял, что так быть не должно, конечный пользователь сам должен собирать SDOS под свои требования и это не должно влиять на версию системы.
Соответственно, я хочу объяснить, как собирается, конфигурируется или портируется на другую платформу SDOS.

Первое, нужно определиться с размещением в адресном пространстве целевой платформы. Нужно определить, где будет размещаться как код самой SDOS, в ОЗУ или ПЗУ, так и ее служебная область 2048-256=1792 байт и в каких адресах. Нужно выбрать такие адреса, которые для большей части программ не задействуются. Здесь нужно выбрать оптимальный компромисс. Если на целевой платформе существует внешний РОМдиск, то достаточно логично разместить SDOS там, и переписывать его в ОЗУ штатными средствами. (При портировании на новую платформу на первом этапе можно выбрать практически любые доступные адреса, и лишь на финишном этапе определить оптимальное размещение в памяти). Если на целевой платформе есть Свободное место в адресном пространстве, в котором можно разместить ПЗУ (пример Специалист и Галаксия), то SDOS размещается в таком участке, и работает сразу из ПЗУ и нужно лишь выбрать доступный участок под служебную область.
Второе, пересекается с первым, это выбор адресов для портов SD интерфейса. Нужно два адреса, это могут быть как адреса в пространстве памяти, так и адреса в IO портах. Для тех платформ, в которых существует внешний РОМдиск, проблема выбора может упроститься. По ссылкам выше есть два варианта такого подключения. Иначе нужно опять искать варианты и компромиссы.
Третье, выбрать вариант SD интерфейса. HWM_PVV - это самый быстрый и, в добавок, его программная поддержка самая компактная, что на общем фоне компактной SDOS(напомню ~2КБ всего!) весьма заметно. 7 корпусов 555 серии . msx - более медленный и программная поддержка +150 байт к коду, а по числу корпусов примерно как предыдущий вариант, по тому я его особо не рассматриваю. n8vem - самый медленный, +250 байт к коду, но очень прост в реализации, а по тому, вполне имеет право на рассмотрение. Для наших ретроПК даже скорость n8vem не столь плоха , тк в большей части файлы имеют не большой размер, что не критично и все лучше, чем просто магнитофон. Любые подварианты этих интерфейсов, к примеру, подключенные через ВВ5, будут соответственно чуть медленнее и будут чуть раздувать программный код.
На этом этапе, для уже существующих вариантов платформ, нужно лишь правильно определить в дефайнах нужные возможности и запустить сборку bat файлом.
Если же нужно портировать SDOS на новую платформу, то тут нужно провести определенные изыскания.
В файле defs.inc нужно сделать секцию с новой платформой, в которой нужно определить такие функции (пример от РК-86):
GETC EQU 0F803H <-ожидать символ с клавиатуры
PUTC EQU 0F809H <-вывести один символ на экран
PRINT EQU 0F818H <-вывести строку на экран
PRHEX EQU 0F815H <-вывести число в HEX формате
IfKeyPress EQU 0F81BH <- проверка ввода с клавиатуры, не зависающая в проверке
входные и выходные параметры этих функций можно посмотреть, к примеру, здесь
из них основными являются первые две, тк PRINT делается из PUTC, PRHEX как опция, есть уже в коде самой SDOS и использует PUTC, а IfKeyPress можно за комментировать и не использовать (не будет функции приостановки вывода списка файлов по DIR по нажатию любой клавиши, забыл об этой возможности упомянуть в первом сообщении).
GETC и PUTC на целевой платформе так или иначе реализованы, значит нужно их формат вызова подстроить под требуемый SDOS (так было сделано при портировании на Галаксию и TRS-80).

Вот какие дефайны есть в файле defs.inc и что они означают (наличие точки с запятой ';' в начале строки означает исключение этого дефайна, а отсутствие, включение):
#define SDOS_VER "SDOS_V8.9N" - в v8.9 вынес строку с текстом приветствия SDOS в этот дефайн

#define SD_DBG_PRINT0 - тоже в v8.9 разделил один дефайн SD_DBG_PRINT на три, для
#define SD_DBG_PRINT1 - более гибкой подгонки размера SDOS, что очень актуально при сборке компактного кода
#define SD_DBG_PRINT2 - для размещения в ПЗУ на 2КБ (все эти печати 'съедают' до 100 байт кода).

;#define SD_HWM_PVV - это группа из 8 дефайнов определяет тип SD интерфейса для сборки, соотв. HWM_PVV
;#define SD_msx - msx
;#define SD_n8vem - n8vem
;#define RK86_WW55_SD_HWM_PVV - это вариант HWM_PVV подключенный на портах ВВ55, проверялся на реальном РК-86, по тому такое название
;#define RK86_WW55_SD_n8vem ; APOGEE and RK86 memmap - это вариант n8vem подключенный на портах ВВ55, где ВВ55 размещается в адресном пространстве, а не портах, собирался но еще не проверялся на реале, для РК86
#define STD_WW55_SD_n8vem ; Specialist - это полная копия(!?!) RK86_WW55_SD_n8vem варианта, собирался но не проверялся на реале, для Специалиста (Std) - в следующей версии сведу в один дефайн WW55_ADDR_SD_n8vem
;#define UT88_WW55_SD_n8vem ; ports IN - OUT - это вариант n8vem подключенный на портах ВВ55, где ВВ55 размещается в портах IO, собирался но не проверялся на реале, для ЮТ-88 - в следующей версии дефайн переименую в WW55_IO_SD_n8vem
;#define GAL_AY_SD_n8vem - это вариант n8vem подключенный на портах AY3-8910(YM2149F), где AY размещается в портах IO, проверялся на реальной Галаксии - в следующей версии дефайн переименую в AY_IO_SD_n8vem

;#define FAT12_ON - включение поддержки FAT12 на карте, актуально для карт или раздела на карте меньше 32МБ, для экономии размера кода обычно выключен
#define FAT16_ON - включение поддержки FAT16 на карте, является основным

#define RWR - включение поддержки записи на карту, занимает 200-300 байт

;#define UT88 - это группа из 8 дефайнов определяет тип платформы, для которой собирается SDOS. ЮТ-88
;#define APOGEE - Апогей
;#define RK86 - РК-86
#define STD - Специалист
;#define MX2 - СпециалистМХ2 - актуально для оригинального SD_HWM_PVV, там задействуется бит сигнализирующий 'занятость' SPI автомата BUSY (во всех 'моих' вариациях этого интерфейса я выбросил этот бит, тк зная скорость работы ЦП с SD интерфейсом можно NOP_ами, буквально от 1 до 3 штук, подобрать нужную задержку)
;#define GAL - Галаксия
;#define ORION - Орион
;#define TRS80 - TRS80

дальше идут секции включаемые дефайнами типа платформы, на примере от РК-86:
;================================================= =========
#ifdef RK86
GETC EQU 0F803H - ожидать символ с клавиатуры
PUTC EQU 0F809H - вывести один символ на экран
PRINT EQU 0F818H - вывести строку на экран
PRHEX EQU 0F815H - вывести число в HEX формате
IfKeyPress EQU 0F81BH - проверка ввода с клавиатуры, не зависающая в проверке
SD_DATA_PORT EQU 0d000H - адрес, по которому размещается SD интерфейс, его порт данных
SD_CONF_PORT EQU SD_DATA_PORT+1 - адрес, по которому размещается SD интерфейс, его порт конфигурации
SD_DATA_PORT_WW55 EQU 0a000H - адрес, по которому размещается SD интерфейс, его порт ВВ55 для вариантов SD с ВВ55
#define SD_ROM - актуально только в РК-86, если не выбран, то по адресу F000 стоит jmp F800h
#ifdef SD_ROM
START_ADDR EQU 06000H - стартовый адрес для размещения кода самой SDOS (который читается из ROMdisk РК)
#else
START_ADDR EQU 0f000H - стартовый адрес для размещения кода самой SDOS, если он записан в ПЗУ
#endif
BUF EQU 06900h - стартовый адрес для размещения служебной области (буфферов для работы с fat), занимает 2048-256=1792 байт
#endif
;================================================= =========

Исходные коды SDOS находятся в нескольких файлах:

defs.inc - здесь хранятся все дефайны описанные ранее
dos_rk.asm - основной файл, в нем реализация всего интерфейса взаимодействия SDOS и пользователя
это 6 файлов, для каждой из поддерживаемых платформ, в которых реализована функция чтения и запуска файла на выполнение, плюс специфичные возможности для определенной платформы (работа с РАМдиском в СпециалистМХ2 или Орион, запись basic файлов в Галаксии).
При сборке используется файл той платформы, дефайн которой определен в файле defs.inc. Подключение файла идет в файле dos_rk.asm.
При добавлении новой платформы нужно будет добавить такой файл.
dos_gal_RUNF.inc
dos_mx_RUNF.inc
dos_orion_RUNF.inc
dos_rk_RUNF.inc
dos_std_RUNF.inc
dos_trs_RUNF.inc

sd_proc.inc - здесь все функции для работы с самой SD картой
fs_proc.inc - здесь все функции для работы с файловой системой fat12 и fat16.
кроме вышеописанных файлов в архиве с SDOS еще есть:
asm_std.cmd - текстовый BAT файл, в котором описаны опции сборки SDOS, вот его и надо запускать для сборки после конфигурирования всех дефайнов.
ReadMe.txt - текстовый файл, с очень кратким описанием возможностей SDOS
TASM.EXE - это ассемблер, которым все и собирается
TASM85.TAB - это служебный файл ассемблера

Весь процесс сборки для пользователя заключается в конфигурировании дефайнов в файле defs.inc и запуска на выполнение asm_std.cmd. В результате получится требуемый файл SDOS.BIN.

По типам карточек:

В FAT16 можно отформатировать раздел не более 4ГБ, соответственно для карт больше 4ГБ нужно делать один первичный (обязательно именно первичный!) раздел на 4ГБ, а остальное сейчас не используется. (задел на будущее, можно доработать SDOS до 4х таких разделов)

[Black_Cat]

Никогда бы не догадался искать DOS в подразделе INTEL

Вопросы к PVV:
1) Почему частота такая маленькая, вон на Спектруме в ZSD контроллере сдвиговый регистр на 14МГц работает (минимум 400 рабочих экземпляров) и не жужжыт . Кстати, там и BUSY нету за ненадобностью, т.к. при такой частоте всяко проц медленнее будет, да и управления частотой нет.

2) К куче компов наадаптировали, а к самому главному - Спектруму нету . Нет планов?

3) Под команды Z80 нет планов адаптировать? Типо там INIR/OTIR заюзать для блочных пересылок, и т.д.

[Shaos]

Никогда бы не догадался искать DOS в подразделе INTEL

Ну дык "SDOS написана в мнемониках ВМ80" то бишь 8080 от Intel

[PVV]

Вопросы к PVV:
1) Почему частота такая маленькая, вон на Спектруме в ZSD контроллере сдвиговый регистр на 14МГц работает (минимум 400 рабочих экземпляров) и не жужжыт . Кстати, там и BUSY нету за ненадобностью, т.к. при такой частоте всяко проц медленнее будет, да и управления частотой нет.

так если и на меньшей скорости процу ждать не надо, так зачем быстрее? принципиальных ограничений нет, просто незачем. Меньше частота, меньше требований к монтажу, выше помехозащищенность, примитивней=дешевле элементная база. В реализации этой схемы на ПЛИС используют 10МГц, все ок.

2) К куче компов наадаптировали, а к самому главному - Спектруму нету . Нет планов?

схема и карта памяти Спектрума весьма самодостаточна, внести что то свое сложно. Просто портировать SDOS проблем нет (скажу больше, я это как то давно уже сделал, но перспектив в таком виде не увидел и забросил). Вот тут есть мои идеи по подключение SD к Спектруму.
Код SDOS будет выполнять монтирование образов с SD, а работать с ними, как с дисками, уже в TrDos.

3) Под команды Z80 нет планов адаптировать? Типо там INIR/OTIR заюзать для блочных пересылок, и т.д.

и отсечь весь парк на ВМ80?! нет уж . Да и не стоит овчинка выделки, ну сократиться код с 2.4КБ до 2.2КБ и что это даст? Скорость? ждать загрузку 16КБ данных 1.4с или 1.1с ? При портировании на ПК с Z80 на борту я использую опкоды z80, но очень ограниченно.

[Black_Cat]

так если и на меньшей скорости процу ждать не надо, так зачем быстрее? принципиальных ограничений нет, просто незачем. Меньше частота, меньше требований к монтажу, выше помехозащищенность, примитивней=дешевле элементная база. В реализации этой схемы на ПЛИС используют 10МГц, все ок.
схема и карта памяти Спектрума весьма самодостаточна, внести что то свое сложно. Просто портировать SDOS проблем нет (скажу больше, я это как то давно уже сделал, но перспектив в таком виде не увидел и забросил). Вот тут есть мои идеи по подключение SD к Спектруму.
Код SDOS будет выполнять монтирование образов с SD, а работать с ними, как с дисками, уже в TrDos.

А если рассмотреть ещё более дешёвый способ - заюзать SDOS под существующий на Спеке отечественный контроллер ZSD? По самым скромным подсчётам их от 400 до 600 шт. на руках

и отсечь весь парк на ВМ80?! нет уж . Да и не стоит овчинка выделки, ну сократиться код с 2.4КБ до 2.2КБ и что это даст? Скорость? ждать загрузку 16КБ данных 1.4с или 1.1с ? При портировании на ПК с Z80 на борту я использую опкоды z80, но очень ограниченно.

Ну, при портировании на разные платформы всё равно происходит отсечение по архитектуре, так что если произойдёт ещё и отсечение по опкодам, то это никто и не заметит . Просто я смотрю, раз уж пошла такая пьянка, что у тебя уже на кучу платформ наадаптировано (я например узнал через адаптацию аж на Юпитер Айс ), что логичным шагом было бы сделать ещё вторую версию под Z80. Тем более, что многие старые компы, особенно отечественные, как раз стараются перевести с 8080 на Z80. Ну, будет две ветки SDOS, чо тут такого, раз уж получилось такое распространение, подумай об этом

[Black_Cat]

Каждый раз при добавлении какого либо функционала и новых платформ (ПК) я увеличивал номера версий и подверсий. Актуальная на данный момент версия 8.9, но практически это 8.6, тк 8.7 - 8.9 это лишь сборки под разные платформы с подвариантами SD интерфейса, и на этом этапе я понял, что так быть не должно

Ну, подверсии логично обозначать как 8.60-8.69-8.6F, или 8.6Jupiter, 8.6Orion и т.д.

[PVV]

А если рассмотреть ещё более дешёвый способ - заюзать SDOS под существующий на Спеке отечественный контроллер ZSD? По самым скромным подсчётам их от 400 до 600 шт. на руках

я как то смотрел на Zконтроллер, он упрятан в плисину или контроллер, кажется. Реализация обмена с SD интерфейсом близка к тому, что с SDOS используется. Застрял я в поиске ПО под этот Zконтроллер, за исходники и подавно разговора нет. А так, конечно же, прикрутить железку к уже имеющемуся ПО было бы хорошо (или с минимальными правками ПО).

[Black_Cat]

я как то смотрел на Zконтроллер, он упрятан в плисину или контроллер, кажется. Реализация обмена с SD интерфейсом близка к тому, что с SDOS используется. Застрял я в поиске ПО под этот Zконтроллер, за исходники и подавно разговора нет. А так, конечно же, прикрутить железку к уже имеющемуся ПО было бы хорошо (или с минимальными правками ПО).

Содержимое ПЛИС доступно, хотя оно тебе для SDOS и не надо, т.к. порты и назначение разрядов описаны. Очень похоже на твой контроллер, токо разряды статуса/управления разные. Для работы со SPI-интерфейсом используются два порта ввода-вывода:

1. Порт конфигурации 77h

На запись:

bit 0 – питание SD-карты (0 – выключено, 1 - включено)
bit 1 – управление сигналом CS
bit 2..7 – не используются

На чтение:

bit 0 – если 0 – SD-карта установлена, 1 – SD-карта отсутствует
bit 1 - если 1 – то на карте включен режим Read only, если 0 – режим Read only не включен
bit 2..7 – не используются.

2. Порт данных 57h

Используется как на запись, так и на чтение для обмена данными по SPI-интерфейсу. Тактирование осуществляется автоматически при записи какого-либо значения в порт 57h. При этом формируются 8 тактовых импульсов на выходе SDCLK, на выход SDDI поступают данные последовательно от старшего бита к младшему с каждым фронтом сигнала SDCLK. При чтении из порта 57h также автоматически производится тактирование. Буферный регистр порта 57h, используемый при чтении, заполняется данными со входа SDIN последовательно от старшего бита к младшему с каждым фронтом сигнала SDCLK. Отсылаемый байт тот же, что записан в этот порт (если цикл обмена инициирован записью), или #FF, если цикл обмена инициирован чтением порта.
Принятый байт запоминается во внутреннем буфере и доступен для последующего чтения из этого же порта. Данное чтение вновь инициирует цикл обмена и т. д.
Допускается читать/писать порт #xx57 командами INIR и OTIR. Пример чтения сектора:

LDC,#57
LDB,0
INIR
INIR

[PVV]

Адреса портов я находил и биты внутри регистра управления очень похожи на изначальный вариант схемы SD интерфейса от HardWareMan_а. Проблема имено в ПО, кто с этим Zконтроллером работает? Исходники? Если ПО написано корректно, то можно его и в бинарном виде подправить, конечно.
а вот это:

При чтении из порта 57h также автоматически производится тактирование. Буферный регистр порта 57h, используемый при чтении, заполняется данными со входа SDIN последовательно от старшего бита к младшему с каждым фронтом сигнала SDCLK. Отсылаемый байт тот же, что записан в этот порт (если цикл обмена инициирован записью), или #FF, если цикл обмена инициирован чтением порта.
Принятый байт запоминается во внутреннем буфере и доступен для последующего чтения из этого же порта. Данное чтение вновь инициирует цикл обмена и т. д.

что и чтение из порта вызывает процесс сдвига, для меня новая информация. Хотя, похоже, аппаратно доработать SD интерфейс для этого не сложно. Сейчас у меня для чтения нужно предварительно что то в порт записать...

[Black_Cat]

Вот тут вроде есть кое-какие исходники: http://micklab.ru/My%20Computer/ZXMPhoenix.htm
1) ПЗУ TR-DOS 6.11P by Keeper
Версия с рам-диском размером 892Кб. Рам-диск всегда работает как диск D:
2) ПЗУ TR-DOS 6.11P + Fatall 0.23 Сборка by Keeper
Экспериментальная сборка с копировщиком Fatall 0.23 by savelij в свободной странице ПЗУ. TR-DOS версии 6.11P by Keeper.Версия с рам-диском размером 892Кб. Рам-диск всегда работает как диск D:
3) ПЗУ TR-DOS 6.10P + WDC 1.26 Сборка by Keeper
Экспериментальная сборка с копировщиком WDC 1.26 by Budder в свободной странице ПЗУ. TR-DOS версии 6.10P by Alsp

[PVV]

Спасибо, посмотрю. Я похожие исходники находил, и именно на их базе и собирался подключать SD интерфейс, о чем, по ссылке выше и писал.
Теперь бы еще знать как работать с Zконтроллером в этих модифицированных ТрДосах. Единственное, все это обсуждение вынести бы за пределы данной темы, в раздел Спектрума с темой SD карта к ZX, тк SDOS здесь лишь затравка к обсуждению .

[Black_Cat]

Спасибо, посмотрю. Я похожие исходники находил, и именно на их базе и собирался подключать SD интерфейс, о чем, по ссылке выше и писал.
Теперь бы еще знать как работать с Zконтроллером в этих модифицированных ТрДосах. Единственное, все это обсуждение вынести бы за пределы данной темы, в раздел Спектрума с темой SD карта к ZX, тк SDOS здесь лишь затравка к обсуждению .

Как понимаю, там в ПЗУ тырдоса добавлен электронный диск, а собсно работа с дисковым контроллером запихнута в нулевую ПЗУ, для которой исходников нет, и вместо которой по идее должен быть CDOS, если, конечно, CDOS не получится утрамбовать туда же в ПЗУ тырдоса, что было бы просто идеально .

Шаос, если будет что, перенесёт, ..было бы что переносить

[Shaos]

Давайте небудем оффтопить про всякие там зилоги

Мнемоники ВМ80 это наш родной язык

[Black_Cat]

Кстати, PVV, как концептолог, хочу заметить, что существует два пути прикрутить SDOS - отечественный и западный. Отечественный основан на применении клонов с расширенной памятью, в которой организовывается электронный диск, а сам DOS помещают либо в ПЗУ TR-DOS, либо в нулевую страницу ПЗУ. Западный вариант предполагает либо расширение синклеровского бейсика командами SDOS за счёт прерывания по ошибке синтаксиса и переключения на внешнюю ПЗУ+ОЗУ, либо переключением на внешнюю ПЗУ+ОЗУ по NMI, или по сбросу. ПЗУ при этом как правило занимает младшие 8к, а ОЗУ старшие 8к из младших 16к Z80.