↓
 ↑
Регистрация
Имя/email

Пароль

 
Войти при помощи
Временно не работает,
как войти читайте здесь!
Marlagram
3 ноября в 09:34
Aa Aa
#ретрокомпьютеры #цитаты

О разработке.
... As an example of a large product for an 8-bit machine, I worked on the BitStik CAD software for Apple II and BBC Micro systems from 1984 to 1986. That used Apple II machines with Z80 CP/M cards for coding (with WordStar) and assembling and linking (with Microsoft's M80 assembler, using its .6502 directive). We had a very simple networked hard disk system for source code, which used ribbon cables to connect machines to the disk cabinet.

Executables would be written onto bootable Apple DOS disks, and then you'd reboot into Apple DOS and try out your changes. This meant we were using the same machines for coding and testing, but frequently switching between OSes on them.

We had machines with hardware debugger cards (can't remember the name) for difficult problems. It worked pretty well, all things considered.

Since WordStar has attracted attention, this was "Classic" WordStar 3.3 IIRC. It has a "Non-Document" mode where it works as a plain text editor, and if you turned off the menus and delays, it was decently fast on a 3.58MHz Z80. Its "Column Mode", which lets you define and operate on a rectangular block of text that doesn't have to contain complete lines, was pretty useful when writing assembler code.

Source control was entirely manual. There was a big wallchart for developers to claim control of source files. They had the copies they were working on in their personal areas of the hard disk, and would put their changed versions back into the shared area and cross out their initials on the chart. Backups were taken weekly, and before any major changes. More copies than that would have been hard work: the hard disk was only 20MB for five developers.

This did give each developer enough hard disk space for a full set of object files, so linking from hard disk to hard disk was possible. That was a lot faster than doing it with floppies. The linker script was fairly complicated, because the Apple II's memory map is quite fragmented. We were using all the space we could get, plus overlays in the multiple "language cards" that were provided by 128KB expansion cards. The Apple //e memory map was less easy to exploit, and the //c seemed like an exercise in perverted ingenuity to me. We'd mostly moved onto programming with C on MS-DOS by then.

There were a lot of floppy disks around, and we had to be disciplined with them. After one new developer was a problem with that, the rule became that any unlabelled disk was subject to summary destruction, by anyone who felt like it.
Отсюда

... In the way of introduction, I was the PDP-8 Software Development manager in the late 1960's during the time when PS/8, later called OS/8, was created. I started working for DEC in the summer of 1967. At that time, Roger Pyle was the PDP-8 Software Development supervisor. Roger, another person whose name was John, and one or two others whose names elude me right now, and I, developed the 4K Disk Monitor system and its associated software. At some point, Roger moved on to another project, and I became the PDP-8 Software Development manager (or supervisor, not sure which.) I moved into PDP-8 Marketing (I think it was in 1970) and then Dennis (Denny) Pavlock became the PDP-8 Software Development manager for several more years. This was a challenging and interesting period; and the development of PDP-8 software remains, in my opinion, unique in the history of computing.

The reason for its uniqueness is that all of Digital's PDP-8 system software was developed by an unusually small group of creative, highly motivated and productive people in an environment where there were no standards and very few rules. It was also unique because, as I'm sure you know, PDP-8 code had to be constructed out of subroutines that consisted of no more than 128 12-bit words, and programs had to be able to fit in 4K words of memory, so code had to be extremely compact.

Prior to about 1969, almost all DEC software development for the PDP-8 family of computers was done using a cross assembler. Initially that was done on a PDP-6 computer, and I think the cross-assembler was called PAL6. Some programmers would write their programs on coding sheets, give those pages to the "Tape Prep" group, which consisted of a group of typists who would type the code, typically on a PDP-5 computer with an ASR-33 Teletype using the editor. The Tape Prep person, when finished, would output the program on the "high-speed" paper tape punch and then return the coding sheets and tape to the programmer. The programmer would then load that tape into the PDP-6, run PAL6, copy the binary file to the high speed paper tape punch, and save the program source on a DECtape. We would then load the binary paper tape on one of the development PDP-8 computers and try to run the program.

Of course it was likely that the program would have assembly errors, so the programmer would edit the code using TECO, and try again, from time to time saving the latest version on DECtape. The PDP-6 was not very reliable then, maybe on a good day only "crashing" a few times. So moans and groans would periodically be heard coming from the PDP-6 computer room each time the system crashed, as programmers thought about how much editing they would have to do over again. Also in those days, disk storage was extremely limited. The PDP-6 that we used in the Maynard mill had a drum memory with a capacity that would have looked small on a PC in the early 1980's. So DECtapes would constantly be spinning on the front of the PDP-6 as programmers copied their code to or from the tapes. The PDP-6, by the way, was DEC's 36 bit computer and was roughly equivalent to a mainframe that supported time-sharing.

Once PS/8 became useable, assembly language software development on the PDP-8 became common. Prior to the development of PAL8, the symbol table in PAL III was too limited to assemble anything other than small and medium size programs. The MACRO-8 symbol table was even smaller. PAL8, however, was derived from the MACRO-8 paper tape assembler (maybe a descendent of MACRO-8.) The macro features were removed, and the symbol table was moved to extended memory, vastly expanding its size. But PAL8 was still very slow until someone, I think Richie Lary, implemented a binary search on the PAL8 symbol table. That remains, in my mind, a defining moment, where the PDP-8 became a useful computer rather than an interesting toy. Subsequently, OS/8 and all associated system software and DEC PDP-8 programming languages could be developed entirely on the PDP-8 using OS/8 and the PAL8 assembler.
...
Отсюда
3 ноября в 09:34
1 комментарий
Ну не будь таким жестоким:
.. В качестве примера крупного продукта для 8-разрядной машины я привел разработку программного обеспечения BitStik CAD для Apple II и BBC Micro systems с 1984 по 1986 год. В нем использовались компьютеры Apple II с картами Z80 CP/M для кодирования (с помощью WordStar), сборки и компоновки (с помощью ассемблера Microsoft M80, использующего его директиву .6502). У нас была очень простая сетевая система хранения исходного кода на жестком диске, которая использовала ленточные кабели для подключения компьютеров к дисковому шкафу.

Исполняемые файлы записывались на загрузочные диски Apple DOS, а затем вы перезагружались в Apple DOS и пробовали свои изменения. Это означало, что мы использовали одни и те же машины для кодирования и тестирования, но часто переключались между операционными системами на них.

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

Поскольку WordStar привлек к себе внимание, это был "классический" WordStar 3.3 IIRC. У него есть режим "Без документов", в котором он работает как обычный текстовый редактор, и если вы отключите меню и задержки, он будет работать достаточно быстро на Z80 с частотой 3,58 МГц. Его "Режим столбцов", который позволяет вам определять прямоугольный блок текста, необязательно содержащий полные строки, и работать с ним, был очень полезен при написании кода на ассемблере.

Управление исходным кодом было полностью ручным. На стене была большая диаграмма, позволяющая разработчикам управлять исходными файлами. Копии, над которыми они работали, хранились в их личных разделах жесткого диска, и они помещали измененные версии обратно в раздел общего доступа и зачеркивали свои инициалы на графике. Резервные копии создавались еженедельно и перед внесением каких-либо серьезных изменений. Большее количество копий потребовало бы больших усилий: на жестком диске было всего 20 МБ для пяти разработчиков.

Это дало каждому разработчику достаточно места на жестком диске для полного набора объектных файлов, так что стало возможным создание ссылок с одного жесткого диска на другой. Это было намного быстрее, чем делать это с дискет. Сценарий компоновщика был довольно сложным, поскольку карта памяти Apple II довольно фрагментирована. Мы использовали все свободное пространство, которое могли получить, плюс наложения в нескольких "языковых картах", которые были предоставлены платами расширения на 128 КБ. Карту памяти Apple //e было сложнее использовать, а карта //c показалась мне проявлением извращенной изобретательности. К тому времени мы в основном перешли на программирование на C в MS-DOS.

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

... Для начала, я был менеджером по разработке программного обеспечения для PDP-8 в конце 1960-х годов, когда была создана PS/8, позже получившая название OS/8. Я начал работать в DEC летом 1967 года. В то время Роджер Пайл руководил разработкой программного обеспечения для PDP-8. Роджер, еще один человек по имени Джон и еще один или двое, имена которых я сейчас не помню, и я разработали систему мониторинга дисков 4K и связанное с ней программное обеспечение. В какой-то момент Роджер перешел к другому проекту, а я стал менеджером по разработке программного обеспечения PDP-8 (или супервайзером, не уверен, каким именно). Я перешел в отдел маркетинга PDP-8 (по-моему, это было в 1970 году), а затем Деннис (Denny) Павлок стал менеджером по разработке программного обеспечения PDP-8 еще на несколько лет. Это был сложный и интересный период, и разработка программного обеспечения PDP-8 остается, на мой взгляд, уникальной в истории вычислительной техники.

Причина его уникальности заключается в том, что все системное программное обеспечение PDP-8 от Digital было разработано необычно небольшой группой творческих, высоко мотивированных и продуктивных людей в среде, где не существовало стандартов и очень мало правил. Это было также уникально, потому что, как, я уверен, вы знаете, код PDP-8 должен был быть составлен из подпрограмм, которые состояли не более чем из 128 12-разрядных слов, а программы должны были помещаться в память объемом 4 тыс. слов, поэтому код должен был быть чрезвычайно компактным.

Примерно до 1969 года почти все разработки программного обеспечения DEC для компьютеров семейства PDP-8 велись с использованием кросс-ассемблера. Первоначально это делалось на компьютере PDP-6, и, по-моему, кросс-ассемблер назывался PAL6. Некоторые программисты писали свои программы на листах с кодировкой и отдавали эти страницы группе "Подготовки ленты", которая состояла из группы машинисток, которые набирали код, как правило, на компьютере PDP-5 с телетайпом ASR-33, используя редактор. Специалист по подготовке ленты, закончив, выводил программу на "высокоскоростной" перфоратор для бумажной ленты, а затем возвращал листы с кодировкой и ленту программисту. Затем программист загружал эту ленту в PDP-6, запускал PAL6, копировал двоичный файл на высокоскоростной перфоратор для бумажной ленты и сохранял исходный код программы на видеокассете. Затем мы загружали бинарную бумажную ленту на один из компьютеров разработки PDP-8 и пытались запустить программу.

Конечно, была вероятность, что в программе будут ошибки при сборке, поэтому программист редактировал код с помощью TECO и повторял попытку, время от времени сохраняя последнюю версию на DECtape. PDP-6 тогда был не очень надежен, возможно, в удачные дни он всего несколько раз "выходил из строя". Поэтому каждый раз, когда система выходила из строя, из компьютерного зала PDP-6 периодически доносились стоны, поскольку программисты думали о том, сколько правок им придется вносить заново. Кроме того, в те времена объем дискового пространства был крайне ограничен. PDP-6, который мы использовали в Maynard mill, имел барабанную память с объемом, который в начале 1980-х годов на ПК казался бы небольшим. Таким образом, на передней панели PDP-6 постоянно крутились кассеты DECtape, когда программисты копировали свой код на кассеты или с них. PDP-6, кстати, был 36-разрядным компьютером DEC и был примерно эквивалентен мэйнфреймам, поддерживающим разделение времени.

Как только появилась возможность использовать PS/8, разработка программного обеспечения на языке ассемблера на PDP-8 стала обычным делом. До разработки PAL8 таблица символов в PAL III была слишком ограниченной для сборки чего-либо, кроме программ малого и среднего размера. Таблица символов MACRO-8 была еще меньше. PAL8, однако, был создан на основе ассемблера MACRO-8 paper tape assembler (возможно, являющегося потомком MACRO-8). Функции макросов были удалены, а таблица символов перенесена в расширенную память, что значительно увеличило ее размер. Но PAL8 по-прежнему работал очень медленно, пока кто-то, по-моему, Ричи Лэри, не внедрил бинарный поиск по таблице символов PAL8. На мой взгляд, это стало определяющим моментом, когда PDP-8 стал полезным компьютером, а не интересной игрушкой. Впоследствии OS/8 и все связанное с ней системное программное обеспечение и языки программирования DEC PDP-8 могли быть полностью разработаны на PDP-8 с использованием OS/8 и ассемблера PAL8.
...
Показать полностью
ПОИСК
ФАНФИКОВ











Закрыть
Закрыть
Закрыть