Вектор Турбо+

[perestoronin]

Вектор Турбо+

http://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80-06%D0%A6

Полный концепт.
Фотографии.
Прошивки.
Герберы.
Адаптированное ПО.

Все кто чем богат. Поделитесь пожалуйста. Есть желание в первом квартале реанимировать этот проект в железе.

Также не менее интересны реплики Вектор-06Ц.
Вот здесь есть сканы платы http://sensi.org/~svo/scalar/ware/877/ и еще много описаний различных доработок и заводских схем http://sensi.org/~svo/scalar/categories/hardware/

[Elvys]

Вектор турбо - миф, как и пк "Эрик".:smile:
Сканы и схемы смотрел. Глаза сломать можно, пока разберешь что какой цифрой там обозначено. С таких сканов схемы перерисовывать в diptrace - ад и сотона. Человек, который делал платки вектора, вероятно имел бумажные оригиналы документации. С куда более высоким качеством.

[ivagor]

Есть свидетельство очевидца
http://zx-pk.ru/showpost.php?p=158679&postcount=84

[Error404]

Да, было дело. Два рабочих экземпляра были точно, а уж на 6 Мгц то налепить наверное никакой вообще проблемы не было бы при наличии спроса выраженного в СКВ (сейчас россиянам дико вспоминать такое, но тогда все было в баксах :) ). У меня у самого был 10-мегагерцовый Орион.
Думаю, у Вектора главная проблема была та же что и у Ориона - большая часть пользователей была мало продвинутыми, не чувствовашими разницы в качестве ПО, но в цене - выньтенате.

[Napoleon1]

Вектор Турбо+ не миф, но в своё время существовал только в форме прототипа. Слишком уж поздно его разработали чтобы имело смысл начинать производство.
Тем не менее, я года полтора назад нашёл свои старые записи и наброски схем этого проекта и решил завершить проект.
На данный момент есть законченная рабочая схема и две собранных платы. В целом всё вроде как работает.
Сейчас я в процессе написания загрузчика, потом за ОС возьмусь.
77800 77801

Если кому интересно - во вложении описание компьютера (пока незавершённое)
77802

[Improver]

На данный момент есть законченная рабочая схемаА можно увидеть эту схему?

[Napoleon1]

А можно увидеть эту схему?

Конечно, только она в Альтиуме. Сюда почему-то не получается загрузить, видимо из-за размера (1,5Мб). Могу выслать на почту или через телеграм.

[CodeMaster]

юда почему-то не получается загрузить, видимо из-за размера (1,5Мб)
Не такой и большой. Сейчас непонятно есть ли какие-то ограничения по расширениям файлов, вроде бы только суммарный объём вложений ограничен.

[Napoleon1]

Ограничение 640кб для zip-файлов. Видимо сам Билл Гейтс тут руку приложил :-)

[Improver]

Конечно, только она в Альтиуме.Будет повод изучить Альтиум... :)


Сюда почему-то не получается загрузить, видимо из-за размера (1,5Мб). Могу выслать на почту или через телеграм.Моя почта [email protected]. Если в телеграм, то можно прямо в канал t.me/VECTOR_06C (https://t.me/VECTOR_06C).

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

[Napoleon1]

Будет повод изучить Альтиум... :)

Моя почта [email protected]. Если в телеграм, то можно прямо в канал t.me/VECTOR_06C (https://t.me/VECTOR_06C).

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

Выслал проект на почту.
И ссылка на Google Диск
https://drive.google.com/drive/folders/0B73-hUaKmVHCWWRxM0xHWlBzbW8?resourcekey=0-jVcvC-LCt3Y9MkT6zStmTg&usp=sharing

[Improver]

Выслал проект на почту.Спасибо, получил и успел уже бегло посмотреть... Что сразу порадовало:

замена к155ру2. Возможно это было сделано в первую очередь для режимов с 64 и более цветами, но всё равно это шаг вперёд.
замена видеоЦАП на резисторах на ADV7120(7125) -- я об этом думал, но так и не решился опробовать... (не в обиду адептам 100% совпадения цветов палитры, но это должно давать хорошую равномерность градиента по цветам)
выход на cxa2075. Пожалуй, лучший вариант для вывода на телевизор, в том числе, думаю, и по rgb на скарт.


И что огорчило:

организация видеопамяти осталась в 32 бита, как на стандартном Векторе. Можно было бы сделать 16 бит, как в схеме ПК-6128, а то и вообще сократить до 8 бит.



Буду изучать схему дальше...

[Napoleon1]

Спасибо, получил и успел уже бегло посмотреть... Что сразу порадовало:

замена к155ру2. Возможно это было сделано в первую очередь для режимов с 64 и более цветами, но всё равно это шаг вперёд.
замена видеоЦАП на резисторах на ADV7120(7125) -- я об этом думал, но так и не решился опробовать... (не в обиду адептам 100% совпадения цветов палитры, но это должно давать хорошую равномерность градиента по цветам)
выход на cxa2075. Пожалуй, лучший вариант для вывода на телевизор, в том числе, думаю, и по rgb на скарт.


И что огорчило:

организация видеопамяти осталась в 32 бита, как на стандартном Векторе. Можно было бы сделать 16 бит, как в схеме ПК-6128, а то и вообще сократить до 8 бит.



Буду изучать схему дальше...

Выходную видеопамять я сначала искал двухпортовую, это было бы проще, но подходящей не нашёл. Пришлось ставить обычную с громадным избытком по объёму. Заодно использовал её же в других местах.
ЦАП сначала тоже хотел городить на резисторах, но получилось очень громоздко - с готовым ЦАПом гораздо компактнее и проще.
А насчёт битности памяти - чем это плохо? Учитывая время выборки принципиально можно было бы сделать 16 бит, но понадобились бы промежуточные регистры и другие мультиплексоры адреса. А суммарно всё равно микросхем ОЗУ столько же, поскольку требуются однобитные микросхемы, чтобы работал механизм маски записи в ОЗУ.
Поэтому не удалось применить современные микросхемы. Зато получилось аутентично :-)

[Improver]

Выходную видеопамять я сначала искал двухпортовую, это было бы проще, но подходящей не нашёл. Пришлось ставить обычную с громадным избытком по объёму.Да, я замелил избыток, но он не критичен. Хотя, избыток можно было бы использовать под хранение нескольких наборов цветов палитры и быстро их переключать, но оставим это улучшение на потом. :) А с двухпортовой памятью может и было бы проще, но смысла там в ней нет -- это же не видеопамять, когда нужно писать и читать одновременно по разным адресам, тут просто палитра, которая иногда пишется между кадрами.


А насчёт битности памяти - чем это плохо?Это не плохо, просто сокращение битности до 16 позволит сократить количество корпусов памяти вдвое, и можно будет применять более ёмкую память, а то и вовсе перейти полностью на статику... :)


Учитывая время выборки принципиально можно было бы сделать 16 бит, но понадобились бы промежуточные регистры и другие мультиплексоры адреса.Посмотрите схему ПК-6128 (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1160605&viewfull=1#post1160605), там это элегантно решили всего одной микрухой-триггером, делая задержку на 1 бит по двум каналам, что позволило читать данные последовательно по 16 бит.

Второй вариант -- использовать 74HCT597, там сдвиговый регистр дополнен защёлками на параллельном входе, можно асинхронно записать туда байт, а потом, в нужный момент, загрузить его в регистр. Как это работает можно глянуть в схеме моей графической платы (https://zx-pk.ru/threads/31273-graficheskaya-plata-vektora.html?p=1129987&viewfull=1#post1129987).


А суммарно всё равно микросхем ОЗУ столько же, поскольку требуются однобитные микросхемы, чтобы работал механизм маски записи в ОЗУ.А что за "механизм маски записи в ОЗУ", извиняюсь?

[ivagor]

что за "механизм маски записи в ОЗУ"
"46h - порт маски записи", 12я страница Вектор Турбо.docx (https://zx-pk.ru/threads/20615-vektor-turbo.html?p=1163221&viewfull=1#post1163221). На мой субъективный взгляд околоEGAшные возможности (порты 45h и 46h) в том виде, в котором они сделаны, приносят проекту больше вреда чем пользы. Другое дело, если бы они были поддержаны большим количеством ПО, но на это вряд ли можно рассчитывать.

[Napoleon1]

"46h - порт маски записи", 12я страница Вектор Турбо.docx (https://zx-pk.ru/threads/20615-vektor-turbo.html?p=1163221&viewfull=1#post1163221). На мой субъективный взгляд околоEGAшные возможности (порты 45h и 46h) в том виде, в котором они сделаны, приносят проекту больше вреда чем пользы. Другое дело, если бы они были поддержаны большим количеством ПО, но на это вряд ли можно рассчитывать.

Ну вообще-то этот механизм минимум в 3 раза ускоряет вывод символов и спрайтов не кратных по ширине байту или со сдвижкой по горизонтали не кратной байту.

[ivagor]

этот механизм минимум в 3 раза ускоряет вывод символов и спрайтов не кратных по ширине байту или со сдвижкой по горизонтали не кратной байту
Можете привести пример кода?

[Napoleon1]

Можете привести пример кода?

Как то так.

; Вывод символа на экран
; HL - адрес символа в знакогенераторе (символ шириной 6 пикселей в младших битах)
; E - младший байт адреса символа на экране (позиция строки)
; A - позиция символа в строке
; Принцип отображения для 40 символов в строке:
; 0 символ - сдвиг 2, символ в старших битах байта
; 1 символ - сдвиг 4, 2 бита в этом столбце, 4 - в следующем
; 2 символ - сдвиг 6, 4 бита в этом столбце, 2 - в следующем
; 3 символ - сдвиг 0, символ в младших битах байта
; Дальше всё повторяется

DrawSymb:
di
push hl
ld b,a
and 3ch
rrca
ld c,a
rrca
add a,c
add a,0e0h ; Выводить будем в верхнюю плоскость
ld d,a ; Получаем горизонтальный полуадрес левого байта из 3 байтов, где могут быть 4 символа
ld a,b
and 3 ; Выделяем биты, определяющие сдвиг символа
ld bc,0300h ; Маска для 0 символа
ld l,2 ; На сколько нужно сдвинуть влево байт символа при выводе на экран
jr z,DrawSymb1
dec a
ld bc,0fc0fh ; Маска для 1 символа
ld l,4
jr z,DrawSymb1
inc d
dec a
ld bc,0f03fh ; Маска для 2 символа
ld l,6
jr z,DrawSymb1
inc d ; в D получается полуадрес левого байта, где будет часть или весь символ
ld bc,0c000h ; Маска для 3 символа
ld l,0
DrawSymb1:
ld a,l
pop hl ; Восстанавливаем указатель на символ в знакогенераторе
or a,0c0h ; Добавляем 3 бита системных параметров
out (45H),a ; Включаем циклический сдвиг
ld a,с
ex af,af' ; Сохраняем маску для второго байта
ld a,b
out (46H),a ; Включаем маску для первого байта
ld bc,8 ; Высота символа
ldir ; Выводим левую часть символа
ex af,af' ; Восстанавливаем маску для второго байта
and a
jr z,DrawSymb2 ; Весь символ в одном байте
out (46H),a ; Включаем маску для второго байта
dec hl
dec e
ld bc,8
lddr ; Выводим правую часть символа
DrawSymb2:
xor a
out (46H),a ;
ld a,0e0h
out (45H),a ;
ei
ret

[ivagor]

Для сравнения переделал в софтовую процедуру вывода 40 символов в строке, принцип вывода аналогичный, надеюсь это не вызовет возражений.

DrawSymbSoft:
ld b,a
and 00111100b
rrca
rrca
add a,0e0h ; Выводить будем в верхнюю плоскость
ld d,a ; Получаем горизонтальный полуадрес левого байта из 3 байтов, где могут быть 4 символа
ld a,b
and 3 ; Выделяем биты, определяющие сдвиг символа
jp nz,DrawSymbSoft1
;0
ld b,00000011b
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rlca\ rlca\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ rlca\ rlca\ or c\ ld (de),a
ret
DrawSymbSoft1:
dec a
jp nz,DrawSymbSoft2
;1
ld b,11111100b
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ rrca\ rrca\ rrca\ rrca\ and 11b\ or c\ ld (de),a
inc d
ld b,00001111b
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ add a,a\ add a,a\ add a,a\ add a,a\ or c\ ld (de),a
ret

DrawSymbSoft2:
dec a
jp nz,DrawSymbSoft3
;2
ld b,11110000b
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ inc hl\ rrca\ rrca\ and 1111b\ or c\ ld (de),a\ inc e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ rrca\ rrca\ and 1111b\ or c\ ld (de),a
inc d
ld b,00111111b
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ dec hl\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a\ dec e
ld a,(de)\ and b\ ld c,a\ ld a,(hl)\ rrca\ rrca\ and 11000000b\ or c\ ld (de),a
ret
DrawSymbSoft3:
;3
ld b,11000000b
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ inc hl\ ld (de),a\ inc e
ld a,(de)\ and b\ or (hl)\ ld (de),a
ret
Точных растактовок для турбо я не знаю (тем более они вроде бы разные для активной области изображения и бордюра), поэтому посчитал для "стандартного z80" на векторе (т.е. с векторовским торможением) при 3 МГц. В зависимости от позиции получается 508/1168/1120/416 тактов. Позиции по горизонтали равновероятные, поэтому среднее значение 803 такта.
Чтобы подравнять силы в DrawSymb заменил ld bc,8\ ldir и ld bc,8\ lddr на 8 ldi и 8 ldd соответственно. Получилось 388/600/636/476 тактов. В среднем 525 тактов. 803/525=1.53
Полтора раза это хорошо, но это совсем не три раза (которые должны были быть минимумом).
И это не все.
1. Если добавить к процедуре вычисление адреса символа по его коду, то выигрыш еще уменьшится.
2. Процедуру софтового вывода можно заметно оптимизировать. Памяти много, можно хранить 4 предсдвинутых варианта символов. Выигрыш становится еще меньше.
3. Запрещение прерываний может еще приемлемо для вывода символов, но не для спрайтов в игре при наличии фоновой музыки.

[Napoleon1]

Насчёт трёх раз - я имею в виду соотношение: (обращения к портам + простая перепись данных) и (чтение символа + чтение байта с экрана + сдвиг + or/and + запись). И в целом программа получается компактнее.
Насчёт растактовки - все циклы, связанные с обращением к памяти, выравниваются на 4 такта. Скорость одинаковая в любой момент. Программирование расширенной палитры не тормозит процессор.

[ivagor]

все циклы, связанные с обращением к памяти, выравниваются на 4 такта
Насколько я понял из описания, при обращении к портам вне диапазонов xx40H-xx7FH и xxC0H-xxFFH добавляется дополнительная задержка. Соответствующие IN и OUT по 16 тактов?

[Napoleon1]

Насколько я понял из описания, при обращении к портам вне диапазонов xx40H-xx7FH и xxC0H-xxFFH добавляется дополнительная задержка. Соответствующие IN и OUT по 16 тактов?

Там по фронту и срезу сигнала IORQ добавляются импульсы WAITов от одновибратора. К конкретному количеству тактов привязки нет.

[ivagor]

Если по фронту и срезу IORQ добавляется одинаковое количество WAITов, то результатом будет фиксированная длительность команды. Если разное - то длительность будет меняться, но в определенных пределах.

[Napoleon1]

Если по фронту и срезу IORQ добавляется одинаковое количество WAITов, то результатом будет фиксированная длительность команды. Если разное - то длительность будет меняться, но в определенных пределах.

Там один одновибратор для этого - соответственно одинаково получается. Без них ВВ55 не работал на 12МГц и еле-еле успевал на 6МГц.

[Napoleon1]

Текущее состояние дел по загрузчику:
По Ввод+Блк при нажатом УС не производится очистка ОЗУ.
При нажатии СС - вход в режим выбора устройства загрузки кнопками вверх-вниз, выбор - ВК.
Реализована загрузка: с магнитофона; дисковода; квазидисков 238кб и 800кб; винчестера с FAT16.
После загрузки по комбинации УС+1...8 можно просмотреть содержимое основного ОЗУ блоками по 8кб (простое отображение соответствующего блока как экранной плоскости)
По Ввод+Блк при удержании УС+СС+РУС запуск теста всей памяти. Алгоритм - сначала во всю память заносится тестовая маска, после чего производится многократное чтение, потом записывается другая маска и снова читается. Отображение текста и микросхем выполнено атрибутами и в целом тест будет работать даже без микросхем ОЗУ.
При выполнении программы в ОЗУ, при нажатии Fn+Блк запускается окно отладчика, где отображается содержимое всех регистров процессора, текущий исполняемый код и несколько последующих команд (ассемблерной мнемоникой), содержимое памяти по адресам из регистров DE, DE', HL, HL', SP, IX, IY в виде чисел и графически, последние значения, записанные в порты.
Выход обратно - по УС. При входе в отладчик фиксируются режимы работы с памятью и графикой, сохраняется массив атрибутов. При выходе всё восстанавливается как было, в том числе содержимое портов. К сожалению восстановить палитру, программируемую через порт 0C невозможно. Тут или надеяться, что отлаживаемая программа сама это исправит, или записывать левую палитру, чтобы что-то видно было.
Ассемблерный код реализован также для недокументированных команд.
Позже добавлю возможность более интерактивного просмотра и модификации содержимого регистров.
Ещё непонятно что делать с режимом прерываний IM2.

[Improver]

Реализована загрузка: с <...> винчестера с FAT16.А можно про это узнать по-подробнее? Такого ещё не было на Векторах...

[Napoleon1]

А можно про это узнать по-подробнее? Такого ещё не было на Векторах...

В корневом каталоге ищется файл с именем OS.COM, после чего читается. Файл может не обязательно быть первым.
FAT16 по моему даже несколько проще организован чем CP/Mный формат.

[Napoleon1]

Загрузчик в целом готов, далее только отлов багов и небольшие модификации.
Принялся за операционку. Основная идея - обеспечить максимальную совместимость с CP/M 4.1 и Микродос (насколько это возможно), соответственно добавится поддержка FAT16 и подкаталогов, поддержка винчестера без нарезки на размер ГМД, квазидиска на 800кб.
Пользовательским программам будет предоставляться адресное пространство с 0100 по F7FF. Сама ОС будет размещаться в СОЗУ и (возможно) частично в ПЗУ.
Конечно же программы, взаимодействующие с аппаратурой напрямую корректно работать не будут.

На данный момент есть общая канва с блоками переходов BIOS и BDOS, программы инициализации, обработчик прерываний, мигающий курсор и ввод с консоли/вывод на экран с обработкой ESC-последовательностей.
Экранная плоскость - верхняя, разрешение 512х512 (64 символа х 32 строки). Символы выводятся в цвете (за счёт атрибутов). При выводе символов их коды и цвет сохраняются в "текстовом экране", за счёт чего возможно восстановление содержимого экрана.

[Error404]

Загрузчик в целом готов, далее только отлов багов и небольшие модификации.
Принялся за операционку. Основная идея - обеспечить максимальную совместимость с CP/M 4.1 и Микродос (насколько это возможно), соответственно добавится поддержка FAT16 и подкаталогов, поддержка винчестера без нарезки на размер ГМД, квазидиска на 800кб.
Пользовательским программам будет предоставляться адресное пространство с 0100 по F7FF. Сама ОС будет размещаться в СОЗУ и (возможно) частично в ПЗУ.
Конечно же программы, взаимодействующие с аппаратурой напрямую корректно работать не будут.

На данный момент есть общая канва с блоками переходов BIOS и BDOS, программы инициализации, обработчик прерываний, мигающий курсор и ввод с консоли/вывод на экран с обработкой ESC-последовательностей.
Экранная плоскость - верхняя, разрешение 512х512 (64 символа х 32 строки). Символы выводятся в цвете (за счёт атрибутов). При выводе символов их коды и цвет сохраняются в "текстовом экране", за счёт чего возможно восстановление содержимого экрана.

А что есть такое CP/M 4.1 ?
Гугл не знает, вроде.
Как планируете подкаталоги на уровне API BDOS? Стандартизированного решения для этого же так и не вышло, кто во что горазд.

[Napoleon1]

А что есть такое CP/M 4.1 ?
Гугл не знает, вроде.
Как планируете подкаталоги на уровне API BDOS? Стандартизированного решения для этого же так и не вышло, кто во что горазд.

Это одна из последних версий CP/M (и для x86 машин). В целом работа с подкаталогами выполнена через те же функции что и с обычными файлами (№15, 16,...), только с 1 в старшем бите номера диска в FCB.
http://www.seasip.info/Cpm/bdos.html
Ну и подкаталоги я хочу только для дисков с FAT16 сделать.

[Error404]

Т.е. готового BIOS в коде Z80/8080 нет и планируете писать его с нуля? Довольно трудоемко.

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

Опять же подкалоги - никакое классическое ПО про них не знает, никаких средств для передачи "длинного пути к файлу с подкаталогами" раньше не было (такого чтобы например его понял стандартный текстовый редактор и открыл такой файл для редактирования или что сложнее - сохранения в новый файл по пути из старого редактора, к примеру).
Не работал x86 последними CPM возможно там оно решается, но там и ПО было другое - более новодельное.

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

В эмуляторе CP/M для UZIX я это решал тупо устанавливая рабочий каталог на тот, какой был в первом пути первого параметра командной строки (а по выходу возвращая на изначальный), путь при этом из командной строки вырезался. Но это костыль, и очень примитивный. Но позволяло переваривать файлы с путём передавая полный пусть в строке Z80/8080 программами CP/M ничего не знающими про подкаталоги (которые из интересных и легендарных практически все), ведь большинство из них по минимуму с одним параметром.

[Napoleon1]

Я вообще всю ОС с нуля пишу. Дело в том, что Турбо+ имеет довольно специфическую архитектуру и напрямую использовать готовое не получится. Хотя, конечно, буду заимствовать хорошие алгоритмы.
Старое ПО будет работать с текущим каталогом, а для работы с подкаталогами на уровне ОС будут команды типа CD, MD из МСДОС. Ну и после, а может и параллельно с ОС нужно будет оболочку сделать чтобы удобнее было.
Я ещё добавил три новые функции по работе с текстовым экраном - регенерация экрана, чтение и отрисовка текстового окна. Это как раз удобно будет для оболочки. А регенерация - для восстановления системы после выполнения программ, которые напрямую с экраном работают.