26 Отредактировано Voldemar0 (27-08-2021 08:29)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

> Используется линейный неэфективный поиск в массиве двухбайтовых значений которые, как мне казалось, могли бы храниться и отсортированными чтобы использовать двоичный поиск итд.

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

Если прикинуть, что у нас прога будет занимать 16 кб (64 блока), то при средней строке 32 байта в программе будет всего 500 строк.
Этот размер - уже довольно приличный для реальных агатовских програм.
Чтобы проанализировать очередной номер строки нужно изучить 4 байта: номер текущей строки и и указатель на следующую строку.
Т.е. чтобы найти нужную строку нужно перебрать около 500/2 * 4 = 2000 байт. Это займет где-то десятую секунды.
Для бейсика - неплохая скорость. Мы ж не трёхмерную графику реального времени в нём делаем?

> Документ правда писался под Агат-7 и с тех пор могло что-то измениться в том же BasicMaster95.

Не могло. Для бейсиков агата важнее совместимость по формату файлов. А делать отдельно текстовый формат файла для совместимости. отдельно бинарный... Или делать какой-то конвертор для чтения старого формата и преобразования в более эффективный, а при сохранении файла всё обратно... может кто-то и мечтал об этом, но у меня нет такой информации ни в каком виде.

И твоя оценка в сто операторов GOSUB, так же как и пятизначный номер строки - это из области фантастики для бейсик-прог агата.
Далеко не каждая прога заходила за три цифры в номере строке, а уж 5 цифр .... Наверное они встречались изредка, но чаще это был какой-то небольшой кусочек в конце программы. 5 цифр использовали для визуального отделения какого-то логически обособленного куска.

Тут всё просто: когда программер способен спроектировать код такого объёма, а потом даже реализовать его, несмотря на все проблемы агатовской надёжности как аппаратной, так и программной (читай: не потерять эту прогу при очередном внесении правок прямо из бейсика, при сохранении-чтении файла...) - он уже готов к тому, чтобы запроектировать какой-то собственный ускоритель-улучшайзер на ассемблере. Который в корне решит кучу проблем бейсика в узких местах. А там, где бейсика хватает - вполне эффективно его использует.

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

Делать на бейсике более крупные программы не имея возможности процедурно- или структурно-ориентированного программирования - так себе развлечение. Тут даже приличный ассемблер начинает обгонять бейсик по удобству.

И ещё: бейсик, как и дос - это же всё таки изначально коммерческий продукт. Это был компромис сложности разработки, затраченного времени на отладку, а не академическое соревнование.

Тебя не устраивает скорость вызова подпрограммы? Ну так перенеси её в начало, это же всяко проще, чем делать сложный алгоритм поиска. Если бы была важна скорость вызова, можно было бы, например, просто кешировать адреса последних вызванных процедур и переходов. Но - - балланс !

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

Хотя даже на эпле был компилирующий бейсик. Где-то у нас он даже есть (в эпловской версии).
Не знаю, насколько эффективен, но уж переходы-то там явно должны быть быстрыми :))

--

Недавно попался на глаза проект FreeBASIC - убойная вещь :) Хотя не знаю, для чего мне бы она сейчас понадобилась.

27 Отредактировано vvhitevvizard (27-08-2021 09:54)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Voldemar0 пишет:

И твоя оценка в сто операторов GOSUB, так же как и пятизначный номер строки - это из области фантастики для бейсик-прог агата.
Далеко не каждая прога заходила за три цифры в номере строке, а уж 5 цифр .... Наверное они встречались изредка, но чаще это был какой-то небольшой кусочек в конце программы. 5 цифр использовали для визуального отделения какого-то логически обособленного куска.

Серым цветом я выделял цитаты из документа. Но увы, авторы правы - пример с пятизначными строками взят не с потолка. Сама суть нумерации строк подразумевает задание номеров с резервированием на случай последующих правок через вставку без изменения нумерации всей программы. А когда кол-во строк и их крайние номера заранее неизвестны - как в моем случае в виде включаемой универсальной части кода с общими процедурами? Или более обособленный случай когда над программой работали несколько человек и по EXEC обьединяли свои программы в одну? Здесь и появляются пятизначные значения.

Делать на бейсике более крупные программы не имея возможности процедурно- или структурно-ориентированного программирования - так себе развлечение. Тут даже приличный ассемблер начинает обгонять бейсик по удобству.

Он и обгоняет. Как мы выяснили, модульного программирования в семействе местных Бейсиков нет. ;)
И я имею в виду не модульность ООП как напр., namespace (отдельное прпостранство имен для включаемых модулей) в Visual Basic но банальный INCLUDE частей программы с непересекающимися номерами строк на этапе выполнения

Хотя даже на эпле был компилирующий бейсик. Где-то у нас он даже есть (в эпловской версии).

И что, действительно создавал машинный код для циклов/переходов/целочисленной арифметики, а для прочих операторов прицеплял статический код независимый от версии Бейсика в ПЗУ? В таком была бы практическая полезность даже сейчас. Чтобы создавать черновой дизассемблер для последующего редактирования.

28

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

> И что, действительно создавал машинный код...

Hayden Applesoft compiler plus

An Applesoft compiler, TASC (The AppleSoft Compiler)

Поищи описания этих компиляторов. Я стараюсь эпловской темы не касаться.

29

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Я на "Правце" пользовался TASC. (Ну, в смысле, пару раз запускал.)
Статический код он конечно не цепляет, бинарники без Бейсика в ПЗУ работать не будут.
Демонстрационная программа на Бейсике после компиляции занимала блоков 20, кажется.
Скорость росла раз в 5.

К Агату это все, к сожалению, никак не применимо, поскольку версий Бейсика много, а гарантии, что хоть какой-то Бейсик будет присутствовать в памяти - никакой.

30 Отредактировано vvhitevvizard (28-08-2021 17:48)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

avivanov76 пишет:

К Агату это все, к сожалению, никак не применимо, поскольку версий Бейсика много, а гарантии, что хоть какой-то Бейсик будет присутствовать в памяти - никакой.

Ты про несовместимость A-псевдокода? Можно попытаться ввести через EXEC текстовое представление программы.
Если этот Apple][ компилятор переваривает какие-то структурные части из бейсик программ (а у нас в общем все Бейсики придерживаются синтаксиса "ANSI 1978 что-то там") - то это уже что-то.
Непонятно, какого качества код генерируется - не превращается ли все в бесконечный каскад вызовов подпрограмм? Попробую покопать по этим двум Бейсикам. :)
-------------------
Здесь можно запустить онлайн и посмотреть авторскую (Hayden compiler 4.0 1984) демку скорости выполнения Бейсик программы до и после конверсии:
https://archive.org/details/a2_Hayden_A … n_Software
-----------
Нашлись еще два компилятора для Applesoft Бейсика: the Beagle compiler (1987) и Einstein compiler (aka "Expediter II").
Для TASC (Microsoft compiler, 1981) сохранилась огромная подробная документация. В аттаче. Имеет много технической информации по реализации Бейсика в целом.

Expediter II и Hayden цепляют все в один бинарник, TASC и Beagle требуют предварительной загрузки по BLOAD run-time модуля - но итоговый обьем кода самый маленький как раз у Beagle.

Что именно они генерируют пока не смотрел еще, но in-line эффективность наверное все же будет низкой - я только что вспомнил, что AppleSoft Бейсик не имел целочисленной арифметики - все переменные фигачил с плавающей запятой и все это обязательно выльется в спам JSR при компиляции.

Из документации TASC:
Compiled programs can only be executed when the Apple-soft interpreter is in memory. Compiled programs will not work with Integer BASIC.
...
TASC is designed to be as accurate an implementation of Applesoft as possible.

Документация TASC преподносит как большой плюс то, что cкомпилированный код вызывает ПЗУшный Бейсик - типо это гарантия высокой совместимости с Apple Soft интерпретатором.
И видимо остальные 3 компилятора руководствуются тем же. Но посмотрим.

Post's attachments

Attachment icon TASC (The AppleSoft Compiler) Manual.txt 146.74 kb, 140 downloads since 2021-08-28 

31 Отредактировано vvhitevvizard (28-08-2021 18:29)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Интересные возможности появляются у cкомпилированных Бейсик программ - возможность запускать из них параллельно обычные A-программы через RUN:
Compiled programs preserve TXTTAB (the beginning-of-basic-program pointer) so that a compiled program can easily RUN an interpreted program using DOS.
а также связывать несколько скомпилированных бинарников запускаемых последовательно общими переменными (a-la CHAIN):
Compiled programs are linked using the BRUN command. To facilitate linking, TASC allows COMMON variables, a powerful extension that is not available in the Applesoft interpreter. Programs executed in sequence can use COMMON variables to pass information.

Ну почему подобного компилятора не появилось для Агатовского Бейсика? :(
---------------
Ужастик по поводу внутреннего представления integer переменных в AppleSoft:
The Applesoft interpreter includes the use of integer variables, but it does not actually perform integer operations. All integers are converted to floating point numbers before being operated on. Since this conversion is necessary each time the variable is accessed. operations on integer variables are actually slower than operations on floating-point variables.
и
The interpreter does not allow integer variables denoted by a percent sign (%) to be used as loop variables in FOR/NEXT loops.
У агатовских Бейсиков так же???

И решение TASC добавлением "костылей" - дополнительного ключевого слова при декларации:
Converting a program by adding a % sign to each variable name is time-consuming. To eliminate this problem, TASC includes the declaration statement INTEGER. INTEGER allows variables to be defined as integers without the addition of the normal % sign. As an example, the real variable I can be declared as an integer by simply including the statement INTEGER I:
10 REM! INTEGER I

Или просто INTEGER *, чтобы обьявить все вещественные переменные как integer. Очень удобно.

32

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

У агатовского бейсика есть явные целочисленные переменные, маркируются суффиксом "%", тип int16_t.

33

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Сейчас написал в эмуляторе девятки (Бейсик ИКП) программку:

10 N% = 1
20 FOR I = 0 TO 1000
30 N% = N% + 5
40 NEXT I

Запустил три раза. Среднее время выполнения 4,7 секунд.

Написал вот так:

10 N = 1
20 FOR I = 0 TO 1000
30 N = N + 5
40 NEXT I

Запустил три раза. Среднее время выполнения 4,2 секунды :)

Похоже, что все работает так же как в Applesoft - вычисления с целочисленными переменными идут через конверсию в плавучку и потому работают чуть-чуть медленнее.

Кстати, еще и умножение с целочисленными переменными косячит.
Написал в первой версии сначала N%=N%*2, запустил, и интерпретатор выругался:

?ОШ.ЗНАЧЕНИЕ В
30 N% = N% * 2

34 Отредактировано vvhitevvizard (29-08-2021 03:55)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Voldemar0 пишет:

У агатовского бейсика есть явные целочисленные переменные, маркируются суффиксом "%", тип int16_t.

Загвоздка в том, что у Applesoft внешне ТОТ ЖЕ синтакс (если не считать изменений операторов по графике/тексту). :)
Речь о внутренней логике "под капотом". Грубо говоря, бОльшая часть команд интерпретатора (работа с физическими адресами и вызовами ассемблерных подпрограмм, графические функции, манипуляции со строками итд принимают целочисленку, но внутреннее представление каждой числовой переменной - real (вещественное), в независимости от наличия или отсутствия суффикса %! Глупая конверсия типов происходит в каждом операторе (а то и по нескольку раз - на входе и на выходе). Документация от Майкрософт заявляет, что такие конверсии обходятся двойным замедлением каждого оператора.
Единственный плюс указания % - для хранения в массивах (int занимает 2 байта, real занимает 5).

И в том же посте: интерпретатор не позволял задавать переменные с суфиксом % для организации циклов FOR/NEXT.

Эти нелепости в дизайне меня и возмутили. Явная типизация вроде как есть, а по факту ее преимуществами не пользовались или наоборот, навязывали нелогичное использование типов. Интересно, агатовские Бейсики унаследовали все ЭТО? :)

avivanov76 пишет:

Похоже, что все работает так же как в Applesoft - вычисления с целочисленными переменными идут через конверсию в плавучку и потому работают чуть-чуть медленнее.

Подпрограмма преобразования из real в int и/или обратно занимает c полкилобайта. И наверное львиную долю процессорного времени для каждого оператора (особенно если параметров несколько).
У тебя "NEXT I" в цикле самый медленный - идет возврат к строке, а это судя по всему лидер в хитпараде неоптимизированных особенностей наших Бейсиков. :) IMHO, чтобы сам цикл сильно не влиял на скорость замера какого-то оператора внутри цикла, оператор лучше продублировать хотя бы десяток раз - чем больше тем точнее.
Кстати, как ты замеряешь скорость исполнения программы в эмуляторе? Есть какая-то фича?

PS: Мне кажется, тут сработала злая маркетология. Из цитаты самого Возняка по ссылке в этой же теме: Воз делал-делал свой оптимизированный Integer Бейсик, но Джобсу, готовящемуся показать компьютер на большой выставке, показалось, что недостаточно быстро. И было принято решение купить готовый floating point Бейсик под 6502 у Майкрософт. И не имея много времени на редактирование, выпустили, прошив в ПЗУ. Ну а там уже прижилось ради совместимости.. Наверняка Воз проклинал его (приобретенный Бейсик) в своих мемуарах.

Проверил в BasicMaster95:
https://pic.maxiol.com/thumbs2/1630190310.787614445.clipboard01.png
Упорно заставляет использовать переменные с плавающей запятой для счетчика циклов. :)

35 Отредактировано Voldemar0 (29-08-2021 06:09)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

> Написал в первой версии сначала N%=N%*2, запустил, и интерпретатор выругался:

А что ты рассчитывал увидеть?
У тебя фактически получилось возведение 2 в степень 1000.
16384, дальше ошибка.

> У тебя "NEXT I" в цикле самый медленный - идет возврат к строке, а это судя по всему лидер в хитпараде неоптимизированных особенностей наших Бейсиков. :

next'у достаточно иметь стек адресов возврата. Он же возвращается не по номеру строки, может вернуться внуть строки.

К тому же прога мелкая, тут любой goto будет быстро работать.

--

Ловите прогу без goto и циклов.
У меня одинаковое время -9 секунд на оба варианта (xb и x2b).
Образ с бейсиком для семёрки.
Но проги должны в любом бейсике пойти, попробуйте их в разных бейсиках.
cr.sh - скрипт, которым они создавались (Shell)

Post's attachments

Attachment icon cr.sh 157 b, 120 downloads since 2021-08-29 

Attachment icon x.dsk 140 kb, 113 downloads since 2021-08-29 

36 Отредактировано vvhitevvizard (29-08-2021 06:54)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Voldemar0 пишет:

Ловите прогу без goto и циклов.

Да да, именно такой тест я и имел в виду. :)

next'у достаточно иметь стек адресов возврата. Он же возвращается не по номеру строки, может вернуться внуть строки.

Покопался еще. Был неправ - в стеке сохраняется 16ти байтное окно на каждый FOR/NEXT цикл. Но все равно в почти холостом цикле сама организация цикла занимает подавляющую часть времени.
------
Кстати, попутно наткнулся на еще одну заложенную мину - команда PRINT в Applesoft использует 16 байт на первой странице где находится стек для временных данных (cокращая максимальный размер стека до 240 байт).

У меня одинаковое время -9 секунд на оба варианта (xb и x2b).

Но тестируем ли мы целочисленку в первом варианте? Согласно заявлению Microsoft, изначально написавшей Applesoft Бейсик, для N и N% внутренее представление одинаковое (=любой int16 операнд автоматически конвертируется в real и только потом с ним происходят арифметические операции?). Во что на самом деле разворачиваются N=N+1 и N%=N%+1 в том же Бейсик-60? Практическая задача для тех, кто любит копаться в коде. :)

37 Отредактировано Voldemar0 (29-08-2021 08:33)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Вопрос-то был о том, будет ли целочисленное быстрее?
И ответ : неа.

38 Отредактировано vvhitevvizard (29-08-2021 08:59)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Voldemar0 пишет:

Вопрос-то был о том, будет ли целочисленное быстрее?
И ответ : неа.

aaa. тогда все верно. :) Вычисляем с плавающей запятой, PRINT отформатирует результат в зависимости от типа переменной. :)
-------
Читаю про Beagle "compiler", этот перекодирует один псевдокод в другой псевдокод и называет это "выполнение со скоростью машинного кода" (ускорение в 2...15 раз). Акцентируется на создании самого компактного псевдокода и встраивании в ProDos резидентом, так, что A-файл может "компилироваться" на лету за несколько секунд/десятков секунд при обычном запуске (RUN). Также автоматом оптимизирует в целые числа все, что может быть представлено как целое и не выходит за границы 32767/-32767).
Основной выигрыш всех бейсик-компиляторов - избавление от поиска строки и от вещественной арифметики там, где она не нужна.

39 Отредактировано Voldemar0 (29-08-2021 10:18)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Для меня ещё остался вопрос о формате хранения вещественных переменных.
Когда-то пытался в нём разобраться, но терпения не хватило. Помню только, что там 5 байт под значение.

Вроде там не фикспоинт и не какой-то из более-менее стандартных флоатпоинтов.

Тут у нас баг давно уже висит не решенный:
http://forum.agatcomp.ru//viewtopic.php?id=136
и упирается он, отчасти, как раз в формат хранения.

40 Отредактировано vvhitevvizard (30-08-2021 07:27)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Нашел потрясающую штуку - эмулятор Applesoft Бейсика через JavaScript:
https://www.calormen.com/jsbasic/
Исходники тоже доступны (запускается и оффлайн):
https://github.com/inexorabletash/jsbasic/

Проглатывает Агатовский Бейсик если убрать русский текст в кавычках, специфические операторы типа TEXT=15 итд
В исходниках можно посмотреть много интересного, в том числе и реализацию вещественных чисел. Проверяет валидность всего кода (проверяются строки, до которых исполнение не доходит). Бейсик программа транслируется в js перед запуском.
Если у кого-то будет желание и нужное настроение, может попробовать переделать под поддержку Агата (знакогенератор и текстовые/графические режимы).
----
Формат вещественных (в документации упоминается как "real"): Single-precision floating point variables with an 8-bit exponent and a 31-bit significand. =5 байт.
Вышеупомянутый эмулятор не заморачивается эмуляцией 5 байт и использует явовский "float" (32 бита).

41

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Написал в проге
10 PRINT "Hello World"
20 call 65385
Запустил, он говорит "неподдерживаемый POKE"

С таким отношением к оригиналу он мало что сможет выполнить из агатовских прог.

42 Отредактировано vvhitevvizard (30-08-2021 08:39)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Voldemar0 пишет:

20 call 65385
Запустил, он говорит "неподдерживаемый POKE"

Поддержка известных машинных адресов ограничена в нем, но есть. Можно посмотреть в его исходниках. поддержка большинства операторов Бейсик (кроме тех, что меняют текст программы - List, Del итп) и DOS 3.3 директив есть.
Эмулятор точно не декларировал эмуляцию диалогового режима "Системного Монитора". ;)
Ожидать поддержки всех документированных и недокументированных машинных адресов системы тоже вряд ли стоит - их достаточно много:

Spoiler

memorytx
APPLE CALL, PEEK, POKE LIST CALL 144 SCAN THE INPUT BUFFER CALL 151 ENTER THE MONITOR NORM

            APPLE  CALL, PEEK, POKE LIST

------------------------------------------------------------------------------
CALL  -144     SCAN THE INPUT BUFFER
CALL  -151     ENTER THE MONITOR NORMALLY
CALL  -155     ENTER THE MONITOR & SOUND BELL
CALL  -167     ENTER MONITOR AND RESET
CALL  -198     RING BELL (SIMULATE CONTROL G)
CALL  -211     PRINT "ERR" AND RING BELL
CALL  -259     READ FROM TAPE
CALL  -310     WRITE TO TAPE
CALL  -321     DISPLAYS A, S, Y, P, & S REGISTERS
CALL  -380     SET NORMAL VIDEO MODE
CALL  -384     SET INVERSE VIDEO MODE
CALL  -415     DISASSEMBLE 20 INSTRUCTIONS
CALL  -458     VERIFY (COMPARE & LIST DIFFERENCES)

CALL  -468     MEMORY MOVE AFTER POKING   60,61 OLD START - 62,63 OLD END
                          64,65 NEW END   - 66,67 NEW STAR

CALL  -484     MOVE
CALL  -517     DISPLAY CHARACTER & UPDATE SCREEN LOCATION
CALL  -531     DISPLAY CHARACTER, MASK CONTROL CHAR., & SAVE 7 REG. & ACCU
CALL  -550     DISPLAY HEX VALUE OF A-REGISTER (ACCUMULATOR)
CALL  -656     RING BELL AND WAIT FOR A CARRIAGE RETURN

CALL  -657     GET LINE OF INPUT, NO PROMPT, NO L/F, & WAIT(COMMA,COLON OK
CALL  -662     GET LINE OF INPUT, WITH PROMPT, NO L/F, & WAIT
CALL  -665     GET LINE OF INPUT, WITH PROMPT, LINE FEED, & WAIT
THE ABOVE 3 CALLS (-657, -662, -665) REFER TO THE INPUT BUFFER FROM 512-767

CALL  -715     GET CHARACTER
CALL  -756     WAIT FOR KEY PRESS
CALL  -856     TIME DELAY (POKE 69,XX TO SET TIME OF DELAY)
CALL  -868     CLEARS CURSOR LINE FROM CURSOR TO END OF LINE
CALL  -912     SCROLLS TEXT UP 1 LINE
CALL  -922     LINE FEED
CALL  -936     CLEAR SCREEN (HOME)
CALL  -958     CLEAR SCREEN FROM CURSOR TO BOTTOM OF SCREEN
CALL  -998     MOVES CURSOR UP 1 LINE
CALL  -1008    MOVES CURSOR BACKWARD 1 SPACE
CALL  -1024    DISPLAY CHARACTER ONLY
CALL  -1036    MOVES CURSOR FORWARD 1 SPACE
CALL  -1063    SEND BELL TO CURRENT OUTPUT DEVICE
CALL  -1216    TEXT & GRAPHICS MODE
CALL  -1233    MOVE CURSOR TO BOTTOM OF SCREEN
CALL  -1321    CONTROL E
CALL  -1717    MOVES CURSOR DOWN 5 LINES
CALL  -1840    DISASSEMBLE 1 INSTRUCTION
CALL  -1953    CHANGE COLOR BY +3
CALL  -1994    CLEAR LO-RES SCREEN (TOP 40 LINES)
CALL  -1998    CLEAR GRAPHIC SCREEN (LO-RES)
CALL  -2007    VERTICAL LINE
CALL  -2023    HORIZONTAL LINE
CALL  -2458    ENTER MINI ASSEMBLER
CALL  -3100    TURNS ON HIRES PAGE 1, WITHOUT CLEARING IT
CALL  -3776    SAVE INTEGER
CALL  -3973    LOAD INTEGER
CALL  -6090    RUN INTEGER
CALL  -8117    LIST INTEGER
CALL  -8189    ENTER BASIC & CONTINUE
CALL  -8192    ENTER BASIC AND RESET (INTEGER BASIC KILL)
CALL  -16303       TEXT MODE
CALL  -16304       GRAPHICS MODE
CALL  -16336       TOGGLE SPEAKER
CALL   42350       CATALOGS DISK
CALL   54915       CLEANS STACK, CLEARS THE "OUT OF MEMORY" ERROR
CALL   64166       INITIATES A COLD START (BOOT OF THE DISK)
CALL   64246       BRAND NEW-YOU FIGURE IT OUT

CALL   64367       SCANS MEMORY LOC 1010 & 1011 & POKES VALUE INTO LOCATIONS
           1012 THAT IS EQUAL TO (PEEK(1011)-165)

------------------------------------------------------------------------------
PEEK   33      WIDTH OF TEXT WINDOW (1-40)
PEEK   34      TOP EDGE OF TEXT WINDOW (0-22)
PEEK   35      BOTTOM OF TEXT WINDOW (1-24)
PEEK   36      HORIZONTAL CURSOR POSITION (0-39)
PEEK   37      VERTICAL CURSOR POSITION (0-23)
PEEK   43      BOOT SLOT X 16 (AFTER BOOT)
PEEK   44      END POINT OF LAST HLIN, VLIN, OR PLOT
PEEK   48      LO-RES COLOR VALUE X 17

PEEK   50      TEXT OUTPUT FORMAT: 63=INVERSE   255=NORMAL
           127=FLASH ( WITH PEEK 243 SET TO 64)

PEEK   51      PROMPT CHARACTER
PEEK   74,75       LOMEM ADDRESS (INT)
PEEK   76,77       HIMEM ADDRESS (INT)
PEEK   103,104     FP PROGRAM STARTING ADDRESS
PEEK   104     IF 8 IS RETURNED, THEN FP IS IN ROM
PEEK   105,106     FP VARIABLE SPACE STARTING ADDRESS
PEEK   107,108     FP ARRAY STARTING ADDRESS
PEEK   109,110     FP END OF NUMERIC STORAGE ADDRESS
PEEK   111,112     FP STRING STORAGE STARTING ADDRESS
PEEK   115,116     FP HIMEM ADDRESS
PEEK   117,118     FP LINE NUMBER BEING EXECUTED
PEEK   119,120     FP LINE WHERE PROGRAM STOPPED
PEEK   121,122     FP LINE BEING EXECUTED ADDRESS
PEEK   123,124     LINE WHERE DATA BEING READ
PEEK   125,126     DATA LOCATION ADDRESS
PEEK   127,128     INPUT OR DATA ADDRESS
PEEK   129,130     FP LAST USED VARIABLE NAME
PEEK   131,132     FP LAST USED VARIABLE ADDRESS
PEEK   175,176     FP END OF PROGRAM ADDRESS
PEEK   202,203     INT PROGRAM STARTING ADDRESS
PEEK   204,205     INT END OF VARIABLE STORAGE
PEEK   214     FP RUN FLAG (AUTO-RUN IF >127)
PEEK   216     ONERR FLAG (>127 IF ONERR IS ACTIVE)
PEEK   218,219     LINE WHERE ONERR OCCURED
PEEK   222     ONERR ERROR CODE
PEEK   224,225     X-COORDINATE OF LAST HPLOT
PEEK   226     Y-COORDINATE OF LAST HPLOT
PEEK   228     HCOLOR VALUE  0=0   85=2  128=4  213=6
                42=1  127=3  170=5  255=7
PEEK   230     HI-RES PLOTING PAGE  (32=PAGE 1   64=PAGE 2   96=PAGE 3)
PEEK   231     SCALE VALUE
PEEK   232,233     SHAPE TABLE STARTING ADDRESS
PEEK   234     HI-RES COLLISION COUNTER
PEEK   241     256 MINUS SPEED VALUE
PEEK   243     FLASH MASK (64=FLASH WHEN PEEK 50 SET TO 127)
PEEK   249     ROT VLAUE
PEEK   976-978     DOS RE-ENTRY VECTOR
PEEK   1010-1012   RESET VECTOR
PEEK   1013-1015   AMPERSAND (&) VECTOR
PEEK   1016-1018   CONTROL-Y VECTOR
PEEK   43140-43271 DOS COMMAND TABLE
PEEK   43378-43582 DOS ERROR MESSAGE TABLE
PEEK   43607       MAXFILES VALUE
PEEK   43616,46617 LENGTH OF LAST BLOAD
PEEK   43624       DRIVE NUMBER
PEEK   43626       SLOT NUMBER
PEEK   43634,43635 STARTING ADDRESS OF LAST BLOAD
PEEK   43697       MAXFILES DEFAULT VALUE
PEEK   43698       DOS COMMAND CHARACTER
PEEK   43702       BASIC FLAG (0=INT  64=FP ROM   128=FP RAM)
PEEK   44033       CATALOG TRACK NUMBER (17 IS STANDARD)
PEEK   44567       NUMBER OF CHARACTERS MINUS 1 IN CATALOG FILE NAMES
PEEK   44611       NUMBER OF DIGITS MINUS 1 IN SECTOR AND VOLUME NUMBERS
PEEK   45991-45998 FILE-TYPE CODE TABLE
PEEK   45999-46010 DISK VOLUME HEADING
PEEK   46017       DISK VOLUME NUMBER
PEEK   46064       NUMBER OF SECTORS (13=DOS 3.2   16=DOS 3.3)
PEEK   49152       READ KEYBOARD (IF >127 THEN KEY HAS BEEN PRESSED
PEEK   49200       TOGGLE SPEAKER (CLICK)
PEEK   49248       CASSETTE INPUT (>127=BINARY 1, 127 IF BUTTON PRESSED)
PEEK   49250       PADDLE 1 BUTTON (>127 IF BUTTON PRESSGD)
PEEK   49251       PADDLE 2 BUTTON (>127 IF BUTTON PRESSED)
PEEK   49252       READ GAME PADDLE 0 (0-255)
PEEK   49253       READ GAME PADDLE 1 (0-255)
PEEK   49254       READ GAME PADDLE 2 (0-255)
PEEK   49255       READ GAME PADDLE 3 (0-255)
PEEK   49408       READ SLOT 1
PEEK   49664       READ SLOT 2
PEEK   49920       READ SLOT 3
PEEK   50176       READ SLOT 4
PEEK   50432       READ SLOT 5
PEEK   50688       READ SLOT 6  (162=DISK CONROLLOR CARD)
PEEK   50944       READ SLOT 7

PEEK   64899       INDICATES WHICH COMPUTER YOU'RE USING
           223=APPLE II OR II+, 234=FRANKLIN ACE OR ?, 255=APPLE IIE

POKE   33,33       SCRUNCH LISTING AND REMOVE SPACES IN QUOTE STATEMENTS
POKE   36,X    USE AS PRINTER TAB (X=TAB - 1)
POKE   50,128      MAKES ALL OUTPUT TO THE SCREEN INVISIBLE
POKE   50,RANDOM   SCRAMBLES OUTPUT TO SCREEN
POKE   51,0    DEFEATS "NOT DIRECT COMMAND", SOMETIMES DOESN'T WORK
POKE   82,128      MAKE CASETTE PROGRAM AUTO-RUN WHEN LOADED
POKE   214,255     SETS RUN FLAG IN FP & ANY KEY STROKES WILL RUN DISK  PROGRA
POKE   216,0       CANCEL ONERR FLAG

POKE   1010,3      SETS THE RESET VECTOR TO INITIATE
POKE   1011,150    A COLD START (BOOT)

POKE   1010,102    MAKE
POKE   1011,213    RESET
POKE   1012,112    RUN

POKE   1014,165    SETS THE AMPERSAND (&) VECTOR
POKE   1015,214    TO LIST YOUR PROGRAM

POKE   1014,110    SETS THE AMPERSAND (&) VECTOR
POKE   1015,165    TO CATALOG A DISK

POKE   1912+SLOT,1 ON APPLE PARALLEL CARD (WITH P1-02 PROM) WILL ENABLE L/F'S
POKE   1912+SLOT,0 ON APPLE PARALLEL CARD (WITH P1-02 PROM) WILL ENABLE L/F'S

POKE   2049,1      THIS WILL CAUSE THE FIRST LINE OF PROGRAM TO LIST REPEATEDLY
POKE   40514,20    ALLOWS TEXT FILE GREETING PROGRAM
POKE   40514,52    ALLOWS BINARY FILE GREETING PROGRAM

POKE   40993,24    THIS ALLOWS
POKE   40994,234   DISK COMMANDS IN
POKE   40995,234   THE DIRECT MODE

POKE   42319,96    DISABLES THE INIT COMMAND

POKE   42768,234   CANCEL ALL
POKE   42769,234   DOS ERROR
POKE   42770,234   MESSAGES
POKE   43624,X     SELECTS DISK DRIVE WITHOUT EXECUTING A COMMAND (48K SYSTEM)

POKE   43699,0     TURNS AN EXEC FILE OFF BUT LEAVES IT OPEN UNTIL A FP, CLOSE
POKE   43699,1     TURNS AN EXEC FILE BACK ON.      INIT, OR MAXFILES IS ISSUE

POKE   44452,24    ALLOWS 20 FILE NAMES (2 EXTRA)
POKE   44605,23    BEFORE CATALOG PAUSE

POKE   44505,234   REVEALS DELETED FILE
POKE   44506,234   NAMES IN CATALG

POKE   44513,67    CATALOG WILL RETURN ONLY LOCKED FILES
POKE   44513,2     RETURN CATALOG TO NORMAL
POKE   44578,234   CANCEL CARRIAGE
POKE   44579,234   RETURNS AFTER CATALOG
POKE   44580,234   FILE NAMES

POKE   44596,234   CANCEL
POKE   44597,234   CATALOG-STOP
POKE   44598,234   WHEN SCREEN IS FULL

POKE   44599,234   STOP CATALOG AT EACH FILE
POKE   44600,234   NAME AND WAIT FOR A KEYPRESS

POKE   46922,96    THIS ALLOWS DISK
POKE   46923,234   INITIALATION
POKE   46924,234   WITHOUT PUTTING
POKE   44723,4     DOS ON THE DISK

POKE   49107,234   PREVENT LANGUAGE
POKE   49108,234   CARD FROM LOADING
POKE   49109,234   DURING RE-BOOT

POKE   49168,0     CLEAR KEYBOARD
POKE   49232,0     DISPLAY GRAPHICS
POKE   49233,0     DISPLAY TEXT
POKE   49234,0     DISPLAY FULL GRAPHICS
POKE   49235,0     DISPLAY TEXT/GRAPHICS
POKE   49236,0     DISPLAY GRAPHICS PAGE 1
POKE   49237,0     DISPLAY GRAPHICS PAGE 2
POKE   49238,0     DISPLAY LORES
POKE   49239,0     DISPLAY HIRES
------------------------------------------------------------------------------

                48K MEMORY MAP

   DECIMAL    HEX            USAGE
------------------------------------------------------------------------------
    0-255    $0-$FF     ZERO-PAGE SYSTEM STORAGE
  256-511      $100-$1FF    SYSTEM STACK
  512-767      $200-$2FF    KEYBOARD CHARACTER BUFFER
  768-975      $300-$3CF    OFTEN AVAILABLE AS FREE SPACE FOR USER PROGRAMS
  976-1023     $3D0-3FF     SYSTEM VECTORS
1024-2047     $400-$7FF    TEXT AND LO-RES GRAPHICS PAGE 1
2048-LOMEM    $800-LOMEM   PROGRAM STORAGE
2048-3071     $800-$BFF    TEXT AND LO-RES GRAPHICS PAGE 2 OR FREE SPACE
3072-8191     $C00-$1FFF   FREE SPACE UNLESS RAM APPLESOFT IS IN USE
8192-16383   $2000-$3FFF   HI-RES PAGE 1 OR FREE SPACE
16384-24575   $4000-$5FFF   HI-RES PAGE 2 OR FREE SPACE
24576-38999   $6000-$95FF   FREE SPACE AND STRING STORAGE
38400-49151   $9600-$BFFF   DOS
49152-53247   $C000-$CFFF   I/O HARDWARE (RESERVED)
53248-57343   $D000-$DFFF   APPLESOFT IN LANGUAGE CARD OR ROM
57344-63487   $E000-$F7FF   APPLESOFT OR INTEGER BASIC IN LANGUAGE CARD OR ROM
63488-65535   $F800-$FFFF   SYSTEM MONITOR


PEEK:  TO EXAMINE ANY MEMORY LOCATION L, PRINT PEEK (L), WHERE L IS A DECIMAL
NUMBER 0-65535.  TO PEEK AT A TWO-BYTE NUMBER AT CONSEQUTIVE LOCATIONS L AND
L+1, PRINT PEEK (L) + PEEK (L+1) * 256

POKE:  TO ASSIGN A VALUE X (0-255) TO LOCATION L; POKE L,X.  TO POKE A TWO-BYT
NUMBER (NECESSARY IF X>255), POKE L,X-INT(X/256)*256, AND POKE L+1,INT(X/256).

CALL:  TO EXECUTE A MACHINE LANGUAGE SUB ROUTINE AT LOCATION L, CALL L.


JUST FOR FUN TRY THIS: POKE 33,90.  THEN TRY LISTING YOUR PROGRAM.  OR TRY:
0,99 OR POKE 50,250 OR POKE 50,127.  USE RESET TO RETURN TO NORMAL.

FOR TRUE RANDOM NUMBER GENERATION TRY THIS:X= RND(PEEK(78)+PEEK(79)*256)

TO LOCATE THE STARTING ADDRESS OF THE LAST BLOADED FILE USE: PEEK(-21902)+PEEK
(-21901)*256 (RESULT IS IN HEX)

TO DETERMINE THE LENGTH OF THE LAST BLOADED FILE USE: PEEK(-21920)+PEEK(-21919
*256 (RESULT IS IN HEX)

TO DETERMINE THE LINE NUMBER THAT CAUSED AN ERROR TO OCCUR, SET X TO: PEEK(218
+PEEK(219)*256

Разумеется, для Агатовских Бейсиков часть адресов будет другой.
-------
Lexer, parser есть - что уже может пригодиться для быстрых проверок, сама прога незаброшена, обновлялась последний раз в этом году.
Я ей скармливал эппловский бейсик - справилась даже с графическими функциями.
Напр., тестировал "Bresenham's Circle Algorithm" который избегает обращения к синус/косинус операторам для рисования окружностей :)

Spoiler

   10  GR
   20  COLOR= 7
  190 R1 = 18
  200 CX = 19:CY = 19
4000 D = 3 - (2 * R1): REM R1=RADIUS
4010 X = 0
4020 Y = R1
4030  REM  DRAW THE 8 CIRCLE PIXELS
4040  IF D < 0 THEN D = D + (4 * X) + 6: GOTO 4990
4050  IF D =  > 0 THEN D = D + 4 * (X - Y) + 10:Y = Y - 1
4990  COLOR= 1
4995  VTAB 21: HTAB 1: PRINT "X= ";X;" Y= ";Y;"  "
5000  PLOT CX + X,CY + Y
5020  PLOT CX + X,CY - Y
5040  PLOT CX - X,CY + Y
5060  PLOT CX - X,CY - Y
5080  PLOT CX + Y,CY + X
5100  PLOT CX + Y,CY - X
5120  PLOT CX - Y,CY + X
5140  PLOT CX - Y,CY - X
5149  IF X = Y THEN  GOTO 7000
5150 X = X + 1
5160  GOTO 4030
6000  END
7000  PRINT "THAT TAKES ABOUT 2 SECONDS ON 'REAL     MACHINE' SPEED IN APPLEWIN EMULATOR"

Поругалась изначально на "GR=", заменил на "GR" - заработало.
Эмулятор хороший. Главное в нем - можно видеть логику транслятора. C потенциалом шаг за шагом переделки для поддержки Агата.

43 Отредактировано vvhitevvizard (30-08-2021 09:28)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Кстати, вот кусок из "LET" STATEMENT Applesoft Бейсика. Для переменных, которые после "evaluate expr" получаются Real, но их "тип" запомнен Бейсиком как integer (или как индекс для FOR цикла?):

DA65- 20 72 EB 3480        JSR ROUND.FAC     INTEGER VAR: ROUND TO 32 BITS
DA68- 20 0C E1 3490        JSR AYINT         TRUNCATE TO 16-BITS

временно хранит их 16bit integer представление в ячейке на которую указывает (FORPNT), название которой указывает, что используется она для организации FOR циклов.
----------------
Кусок из RUN команды c ненавистной мне CLEAR. :)

D91B- 20 6C D6 1100 .1     JSR CLEARC   CLEAR VARIABLES

Не будь ее, можно было бы в диалоговом режиме установить переменные и сделать RUN [N]. А так все обнуляется... Да да, помню, что есть еще GOTO.
Я к тому, что зная эти адреса для Apple и узнав (что уже не так сложно имея код applesoft с комментариями) их для конкретной реализации Агатовского бейсика, можно подпатчивать Бейсик на ходу исправляя его "ненужные особенности" при начале работы из бейсик программы.

44 Отредактировано Voldemar0 (30-08-2021 09:09)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Проблема в том, что его придётся немало допиливать.

Ну начнём с простого: наверное 1/4 игровых прог агата с удовольствием дочитывались B- файл ЗВУК/ZWUK/ZZ и ещё куча вариантов, где была процедурка воспроизведения нот и пытались играть им музыку или просто похрюкивать.

Ещё ряд прог любил поиграть с ячейками 32-36 - размер окна.

Кой кто использовал ассемблерные вставки.

Нередко использовалась HEX-арифеметика в доступе к памяти, а у эпловского бейсика её не было.

Попадается в девяточных игрушках управление палитрами девятки.

Поддержка длиных имён.

Прямое чтение клавиатуры (чтобы получить код кнопки без ожидания) - ну это , наверное, и на эпле использовалось.
........

Я когда-то хотел сделать эмулятор агатовского бейсика, но когда прикинул список таких исключений, понял, что проще эмулятор агата запускать в режиме : бейсик + его программа сразу в памяти - получился почти эмулятор бейсика :)

45 Отредактировано vvhitevvizard (30-08-2021 09:30)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Не не. тут главное - конвертация Basic кода в Javascript :) Были же конвертеры BASIC -> C. Некрасивый код создавали (из-за "прямолинейного" стиля программ Бейсика), но тем не менее практическая польза была. Для ленивого программиста.

Минимально просто хочется в этот эмулятор знакогенератор и текстовый режим Агата добавить.

46 Отредактировано vvhitevvizard (30-08-2021 11:44)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Voldemar0 пишет:

Прямое чтение клавиатуры (чтобы получить код кнопки без ожидания) - ну это , наверное, и на эпле использовалось.

Ну такие банальности автором эмулятора учтены. в файле basic.js

      0xC000: function() { return env.tty.getKeyboardRegister ? env.tty.getKeyboardRegister() : 0; },
      0xC010: function() { return env.tty.clearKeyboardStrobe ? env.tty.clearKeyboardStrobe() : 0; },
10 PRINT "Hello World"
20  IF PEEK($C000) > 142 THEN POKE $C010,0 : GOTO 10
30 GOTO 20

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

47

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Нашел еще 3 компилятора. Flash Integer Basic Compiler порадовал - первый, который создает автономные бинарники работающие без Бейсика:
FLASH! and its runtime package do not directly require Integer BASIC on your machine.  However, in order to edit Integer BASIC programs or to use the full capabilities of FLASH!, you should have Integer BASIC in ROM or a Language System Card or the  equivalent.

48

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Но Integer - это другой Бейсик. У него даже тип файла свой (I). Думаю, на уровне токенов он просто несовместим с Applesoft. Ну и конечно в нем некоторых фич нет. Плавучки, само собой, поддержки графики.

49 Отредактировано vvhitevvizard (31-08-2021 02:23)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

avivanov76 пишет:

Но Integer - это другой Бейсик. У него даже тип файла свой (I). Думаю, на уровне токенов он просто несовместим с Applesoft. Ну и конечно в нем некоторых фич нет. Плавучки, само собой, поддержки графики.

Другой внутри. Токены в файле другие. Без математических функций. Но основной набор операторов такой же, включая что-то из графических функций. Возняк придерживался распространенного синтаксиса. :)
https://www.landsnail.com/a2ref2.htm

Здесь интересна причина, почему в компиляторе не стали полагаться на вызовы бейсика (это бы сократило размер run-time модуля). Integer Basic был менее модульным, вместо RTS возврата с ошибкой (как Microsoft Бейсик) функции обработки операторов делали JMP в диалог интерпретатора... =)

Spoiler

In comparing FLASH! with other compiler products on the market you will note the size of the runtime package is larger than on other compiler systems. This is because the APPLESOFT compilers are able to utilize subroutines in the APPLESOFT ROM'S. The ROM routines of APPLESOFT are much easier to use from assembly language than those in Integer BASIC. Integer BASIC was written in a highly unstructured manner. The Integer BASIC ROM routines lack proper error returns in the code, in most cases they simply jump to error handlers which jump directly to the main interpretive loop. In the FLASH! runtime package the statement processing code is all new code optimized to support compiled programs in a more efficient manner than the Integer BASIC ROM routines.

50 Отредактировано vvhitevvizard (05-09-2021 11:18)

Re: Немного про одну заморочку бейсика (и последующий хитпарад глюков)

Отчитаюсь немного за опыт использования компиляторов Бейсик.
Упомнятый выше Flash имеет не только возможность выбора использовать ли runtime код в виде отдельного бинарника (общего для всех скомпилированных бинарников) или интегрировать код в сам бинарник. И не только возможность запускаться автономно от Integer Basic (проверено) и вообще на компьютерах всего лишь с 16Kb памяти.

Spoiler

The file B.RTP is necessary to run object programs which do not have the runtime code put in the object file (a user option on FLASH! prompts). The  compiled programs do not require Integer BASIC to be able to execute.

Spoiler

The programs compiled by FLASH! can be run on a 16k-48k machine with or without a disk drive.

И не только максимальное увеличение производительности среди остальных компиляторов (от x5).

Spoiler

Compiled programs can expect an execution speed increase of 5 to 20 times depending on the instruction mix. Indeed FLASH! compiled programs execute 3 to 6 times faster than compiled APPLESOFT programs do for applications which do not require floating point computations.

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

Первое отличие - компилятор выдает также ассемблерный исходник, с метками, символьными именами для всех вызовов из runtime и вставленными коментариями из исходника, чтобы можно было понять, к какой строке бейсик-программы относится данный фрагмент ассемблерного кода.

Второе отличие - мануал компилятора намекает, куда надо копать, чтобы добиться дальнейшего ускорения производительности. На втором комплектном диске находится Runtime Package Source code. И добрая половина мануала пусть кратко но описывает каждую вызываемую процедуру из runtime модуля.

Spoiler

The compiler assembly file can be assembled with the S-C Assembler II 4.0 if you have purchased the Runtime Package Source code. Even further improvements in execution time can be realized by recoding the inner loops of your program. All compilers generate inefficient code. A good assembly language programmer can always make some improvement in the coding produced by any automatic program. The 6502 machine language is somewhat badly organized to produce really good assembler code since 8 bits are too much of a limiting factor for most computations, you really need at least 16 bits to do any serious programming. This results in almost all of BASIC operations being a call to a runtime package subroutine, otherwise a program would be very large if 16 bit operations were performed inline in the generated code with complete error checking.
Therefore, with a little effort in recoding some of the code you will be able to get another twofold to fourfold increase in speed.

Абсолютно точно такой же подход, как в случае opensource CC65 компилятора.
-------------------------------
Теперь о трудностях встреченных на практике.
В аттаче обе дискеты с компилятором, на первую я еще поместил бинарник требуемого компилятора S-C Assembler II 4.0.
Если гружусь с комплектного диска:
https://pic.maxiol.com/thumbs2/1630824742.787614518.clipboard01.png
и ввожу простейшую программу 10 PRINT "HELLO"
затем запускаю компилятор BRUN FLASH
он ругается "NO PRGRAM IN MEMORY". Какого черта - мы ведь по идее запустились с демонстрационного диска компилятора где все настроено по умолчанию...
при попытке сохранить программу SAVE TEST - сохраняется A-файл (вместо ожидаемого I-файла). Ага...
Оказалось, что в DOS 3.3 (и позже ProDos) есть две команды для переключения между Integer Basic и Applesoft Basic: INT и FP соответственно. Курсор меняется между ">" и "]". Причем в памяти (ROM, RAM, Language Card) могут находиться как одна из версий Бейсика, так и обе одновременно. В эмуляторе Олега есть диск Apple ][+Integer. Где грузятся обе версии.
Посколько EXEC - команда DOS, то выгрузка applesoft Бейсик программы в text, а затем загрузка этого текста (после незначительных правок) в integer basic - не проблема - синтаксис в целом одинаковый. Но Integer Бейсик не имеет поддержки HOME, RIBBON и еще некоторых банальных команд. Которые впрочем всегда можно заменить на CALL *** вызовы или воспользоваться расширением языка в том же Flash, который через "REM ." (с точкой после REM) добавляет расширенный набор команд. В общем, при желании можно любую программу под Агат-Бейсики скомпилировать, заменив вызовы в результирующем ассемблере на подпрограммы Агатовского Бейсика/Монитора либо на свои собственные подпрограммы.
Компиляция медленная. Можно выбрать из программы в памяти и программы (I-тип) на диске.

В аттаче 2 диска: flash + демонстрационные программы + я доложил бинарник ассемблера (ASM B-файл длиной 22 блока),
исходники run-time модуля (файлы типа I, но это не бейсик - это псевдокод исходников на accемлере - подробнее далее).

продолжение следует...

Post's attachments

Attachment icon FLASH.DSK 140 kb, 113 downloads since 2021-09-05 

Attachment icon FLASHRTS.DSK 140 kb, 122 downloads since 2021-09-05