Специалист: прошивки ПЗУ.

[rw6hrm]

Программы, работающие из ПЗУ, мне нужны для возможно полного освобождения ОЗУ под результаты работы. Иначе смысла работы с 6К текста нет вообще. Как и с компьютером в таком виде.

Что за МОНИТОР-3 для СПЕЦИАЛИСТА ?

Кажется в своём посте я упомянул, что в этом мониторе использована кодировка КОИ-8. А это была третья публикация Монитора (т.н. Набор системных программ)
http://www.spetsialist-mx.ru/Docs/mk1990_02.djvu
http://www.spetsialist-mx.ru/Docs/mk1990_03.djvu
Других Мониторов для стандартной схемы Специалиста с расширенным знакогенератором на то время не было, я его и имел в виду.

бейсик из верхнего ПЗУ (чтобы освободить ОЗУ для текста бейсик-программ) работать не может

Да ладно! OSI BASIC тому примером, http://www.qsl.net/rw6hrm/html/soft.htm . Перезапилить его для 8080 несложно, но о графике на начальном этапе придётся забыть.

А о поддержка файлов, вообще всяких, возможна только если есть ДОС

Без ДОС база данных невозможна

Следующий пример - Epson HX-20 в базовом варианте, с кассетой. ОСи, как таковой, нет, однако поддержку последовательных файлов допилили. И использовался он в некоторых случаях на складах для учёта товара. А без БД, сами понимаете, на складах никак.

Так что где-то что-то существует

В виде старческого бурчания: говорили мне, что 8080 и поделки на нём есть брошенные, никому не нужные дети, надо было оставаться на 6502/6800...

[Advertiser]

[barsik]

смысла работы с 6К текста нет вообще

Как Вы получили цифру в 6 кб для буфера текста текстового редактора? Я использовал на СПЕЦИАЛИСТЕ редактор SCREEN с объёмом кода в 2 кб (и кстати из верхнего ПЗУ). Версия для ОЗУ отнимает 2 кб области TPA в 36 кб, оставляя под буфер текста 34 кб, причём благодаря ДОС в ПЗУ (тоже всего 2К) в коде редактора в 2К сохранена и работа с МГ и чтение/запись файлов на эл.диск RAMDOS. Причём, загрузка/сохранение кусков текста в виде файлов на эл.диске полностью заменяет отстутствующие блочные операции.

Теперь ситуация с бейсиком. Журнальный бейсик имеет размер в 8 кб, оставляя для кода программ на нём 36-8=24 кб. Даже в CP/M бейсик Microsoft с объёмом кода в 28 кб оставляет для текстов программ меньший объём.

в Epson HX-20 ОС, как таковой, нет, однако поддержку последовательных файлов допилили.

У Вас неверна терминология. Под последовательным файлом в ДОС понимают файл доступ к которому делается последовательно, в отличие от функций LOAD/SAVE, когда читается/пишется весь файл зараз, что ограничивает максимальный размер файла в объём дискетного буфера. Так сделано в RKDOS и там в общепринятом смысле нет последовательного доступа, а есть только LOAD/SAVE целого файла. Но во всех профессиональных ДОС и, кстати, в трёх моих ДОС есть последовательный доступ.

Должен отметить, что RK-DOS вовсе не такая убогая, как кажется на первый взгляд. В RK-DOS тоже можно создавать и работать с файлами размера большего, чем объём буфера в ОЗУ. Но механизм для этого там другой. Для этого открывают файл как канал вывода и побайтово пишут в канал функцией KANW.

Последовательный доступ позволяет иметь файлы любого размера, не ограниченные размером ОЗУ. Тогда файл перед работой с ним сначала открывают. Открыть файл можно для записи, чтения и дополнения (APPEND). После открытия, например на запись, можно вызвать любое число раз функцию WRITE, которая добавляет в конец файла очередной сектор. И так до тех пор пока не закончится диск или файл не будет закрыт функцией CLOSE. В неграмотных ДОС можно открыть только один файл. В грамотных ДОС можно одновременно открыть несколько файлов (читать из одного файла и писать в другой).

Так что поддержка работы с магнитофоном это вовсе не последовательный доступ к файлам. Кроме последовательного доступа есть ещё и прямой доступ позволяющий сразу считать или перезаписать любой сектор внутри файла. Этого тоже нет в RK-DOS, но есть в моих ДОС. В RAMDOS и даже в ORDOS тоже есть последовательный доступ, но там они побайтовые.

К сожалению такие более развитые ДОС имеют обьём кода такой же как CP/M, т.е 10 кб и даже более. А компактные 2-х килобайтовые ДОС не имеют ни прямого, ни последовательного доступа, а только цельно файловые LOAD/SAVE.

Для многих задач достаточно таких примитивных DOS, где вся работа с файлами заключается в поиске, чтении и записи файла целиком. К сожалению, известные дискетные ДОС размером в 2 кб имеют существенные недостатки. В частности файлы не фрагментируются и хуже того, удаление файла не приводит к освобождению места на диске (т.к файлы пишутся только в конец занятого на диске места). В RAFOS/FODOS для этого использовали SQEEZE, очень опасную и долгую операцию выполняющую сдвижку всех файлов чтобы "схлопнулись" пустоты, оставшиеся от удаления файлов.

Интересно написать свою дискетную компактную ДОС лишённую недостатков уже известных версий. Надеюсь, что мне удастся сделать ДОС размером в 3 кб, с свойствами чуть получше, чем известные 2-х килобайтовые ДОС.

RK-DOS занимает промежуточное место между примитивными и профессиональными ДОС и без сомнения, является оптимальным вариантом для ЭВМ стеснённых в объёме ОЗУ. На РК86 благодаря размещению в ПЗУ удаётся записывать файл размером с TPA минус 300H байт (для буфера VTOC 100H и буфера чтения сектора 200H).

Переделать OSI BASIC для 8080 несложно, но о графике на начальном этапе придётся забыть

Зачем графика в бейсике? Графика на бейсике это предел тормознутости, потому это никто никогда не использует. Ассемблерные вставки решают проблему. Из всей поддержки графики в бейсике, хоть какой-то смысл имеет лишь оператор CIRCLE для рисования кругов, т.к для кругов надо вычислять синусы, что можно сделать в программе поддерживающей плавающую точку (но есть выход - табличное вычисление синусов и есть соотв-щая ассемблерная процедура).

Гораздо полезнее не бейсик с графикой, а бейсик компилятор, существенно упрощающий вставку аассемблерных кусков (без идиотских DATA-операторов), дающий кроме того ускорение прогона бейсик программы в 5 раз. К сожалению бейсик компилятор требует CP/M для ОЗУ 60К, что невозможно на базовом СПЕЦИАЛИСТЕ, для которого применимы только небольшие ДОС типа RK-DOS или ещё более маленькие.

[rw6hrm]

barsik, всё это прекрасно. Терминология у меня верная, поскольку Эпсон стоит рядом и сравнительно активно используется с использованием оригинальной документации.
Каким по внутренней сути будет Бейсик - нет разницы, лишь бы уместился в 10К ПЗУ и работал с 32К ОЗУ. Графика обязательна.
Про СР/М разговора нет и не нужно. Нужны проги. Скажем так, - картриджные версии
Иначе Спец остаётся только как воспоминание о любимой в молодости женщине и подлежит утилизации.

[zx_]

Парни, для Специалиста был/есть легендарный бейсик Практик , даже пакет программ Практик)
и монитор 4 , вернее их есть штук 10 (?) восемь ? разных , както в этой теме форума считали

http://zx-pk.ru/threads/22900-arkhiv...-pavlodar.html

[zx_]

ничерта не понимаю! (с)
а оригинальный первый бейсик в двух пзу же был
http://www.spetsialist-mx.ru/index6.html

[rw6hrm]

а оригинальный первый бейсик в двух пзу же был

Был. Но потом его кассетной версии прикрутили расширитель графики, http://www.spetsialist-mx.ru/Docs/mk1988_06.djvu (громко сказано, но реально скорость отрисовки кругов стала несравнимо выше). А вот в ПЗУшную версию расширение не вставили...

[OrionExt]

Думается мне. Легендарные Бейсики и т.д. А бейсик перетранслировать в ром любой коих много за счет инета слабо?)

[zx_]

про могитор 1 и бейсик в пзу

http://zx-pk.ru/threads/24952-nashjo...l=1#post815332

[rw6hrm]

про могитор 1 и бейсик в пзу

Тут найдено только первое ПЗУ. А Бейсик трансферится в ОЗУ. Немного не то...

[barsik]

Есть бинарные файлы всех BASIC-ов для Альтаира (4К, 8К и дисковый вариант. Кроме того и разные версии). Tiny Basic версия 1.0 от 1976 года на ассемблере. Если интересует могу выложить.

Конечно интересует. Не для использования, а для изучения. Интересно дизассемблировать и изучать чужие программы. Любопытно узнать насколько умён был юный Билл Гейтс в 1975 году, когда написал бейсик для ЭВМ "Альтаир-8008".

Я не тащусь от бейсика, т.к интерпретатор на 8-ми разрядке неудобен, тормознут и занимает до 28 кб ОЗУ под код самого интерпретатора, а CP/M компилятор бейсика хоть и ускоряет в 3 раза, но скорость намного ниже, а объём результирующего кода намного больше, чем код генерируемый компиляторами СИ, что делает бессмысленным его использование. Но у бейсика всё же есть своя ниша - быстрое изготовление небольших вспомогательных программок.

Потому я занимался лишь CP/M бейсиком Microsoft и его компилятором. Даже в 1995 написал учебник по бейсику Microsoft для ОРИОНА. Может у кого-то сохранилось? А позднее полученный на этом опыт использовал на IBM PC.

С середины 90-х я писал на бейсике IBM PC небольшие инструментальные программки, типа конверторов. Это легче, а главное быстрее в отладке, чем использовать СИ. Проблемы скорости и объёма кода на PC уже не волнуют. Например, даже программы пересылки по линии я писал на бейсике. Компиляция бейсик программы и на PC ускоряет немного (не более 3-х раз). После отладки в интерпретаторе нет проблем откомпилировать в Quick BASIC, Turbo BASIC или Power BASIC.

Проблема самого бейсика - ограничение объёма данных в 64К и, даже, чтобы работать с файлами с размером более 32К, надо исхитряться. У бейсиков дурная работа с файлами, потому если бейсик допускает прилинковку ассемблерного фрагмента, то выгоднее использовать свой модуль работы с файлами. Точно также как и для работы с ОЗУ, где операторами DIM можно получить не более 64К, тогда как ассемблерный кусок легко получит у ДОС кусок ОЗУ в 600 кб.

А для 8-ми разрядки бейсики почти бесполезны. Но можно научиться выжимать и из бейсика максимум. Речь, конечно, о CP/M-компиляторе с использованием ассемблерных вставок. Это проще, удобнее и не намного хуже, чем использование СИ и ассемблера. У меня не было бейсика компилятора для 8-ми разрядки с 2000 года (погиб при крахе винта), о чём я сожалел, т.к было удобно делать инструментальное ПО на бейсике.

Во вложении примеры программ на бейсике для IBM PC.