Оберон/GCC для УКНЦ/БК

[Oleg N. Cher]

Встречайте GCC для УКНЦ в Оберон-одёжке, господа.



GCC для Windows берём отсюда.

Если кому ещё интересно это направление, буду рад. Особенно интересно, если кто-то пожелает помочь с разработкой библиотек. Особенно для графики.

Я пока что перетаскиваю свои наработки с OMSI Pascal в новое окружение.

Ссылка на подсистему:

• https://github.com/Oleg-N-Cher/Pdp11Dev

Трудности:

1. Сгенеренный файл .sav хотя и работает в эмуляторе Зимина, но не определяется IDA как .sav, что-то там со структурой не то. Генерил его по советам из статьи: http://ancientbits.blogspot.com/2012...nes-pdp11.html

2. Образ диска скомпонован Хоботом так, что программа с именем Demuk автостартует и зациклена. Как поменять имя в автостарте или как её расциклить - я не знаю, Хобот тоже не особо делился.

3. Краем уха слышал, что есть отличия между процем КМ1801ВМ2 и каноническим PDP-11, и это может всплыть в GCC. Пересобирать его я не умею.

[Advertiser]

[yu.zxpk]

GCC ничего не знает про ВМ1/ВМ2.
Я почти 3 года тому пытался чуть поковыряться с добавкой опций в компилятор и маппинг на "фичи": какие инструкции можно использовать в коде. Потом "застрял", начал переделывать с чистого листа на более свежем GCC, начал писать тесты под результат компиляции на pdp11.
Но, "забил" из-за загрузки по работе.
Надо бы освежить...

[Oleg N. Cher]

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

У меня есть в планах переносить игры на Оберон и пробовать собирать для разных платформ, наверное сюда включим и УКНЦ. Но - игры простенького вида, логические, разные шарики и прочие. Может карточные. Но для тестирования GCC вполне сгодятся.

yu.zxpk, а это не Вы собирали GCC 10 для PDP-11?

GNU C17 (GCC) version 10.0.1 20200318 (experimental) (pdp11-aout)
        compiled by GNU C version 7.3-win32 20180312, GMP version 6.1.0, MPFR ve
rsion 3.1.4, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Кстати, если не хочется ковыряться в потрохах GCC, есть вариант менять инструкции в сгенеренном GCC асм-файле. Если это конечно имеет смысл. Я знаю человека, который приспособил bkasm для такой замены. Только вот его связка не работает с библиотеками и объектниками в формате GCC. Просто асм в бинарь (для БК-0010).

[yu.zxpk]

Судя по дате (март 2020) - да, я собирал gcc с помощью mingw.
Нашел свои рабочие каталоги. Попробовал запустить тесты. Что-то падает на самых базовых тестах (работало на 1й версии патча).
Надо брать отпуск и ковыряться дальше.

[Oleg N. Cher]

Отпуск отпуском, это ж такое. Но контактами с Вами я бы обменялся, чтобы быть на связи.

Господа, не подскажете почему установка палитры влияет на нижнюю линию верхней служебной строки и на верхнюю нижней?

void PALET (void)
{
  asm("  .GLOBL  NEWPAL            \n"
      "  MOV     R0, NEWPAL        \n"
      "  MOV     R1, NEWPAL+2      \n"
      "  MOV     $BUF0, R0         \n"
      "  MOV     $5, R1            \n"
      "  MTPS    $0200             \n"
      "  BR      2$                \n"
"1$:     MOVB    (R0)+, @$0176676  \n"
"2$:     TSTB    @$0176674         \n"
      "  BPL     2$                \n"
      "  SOB     R1, 1$            \n"
      "  MTPS    $0                \n"
      "  RTS     PC                \n"
"BLK:    .WORD   020*0400, 032, 02470, NEWPAL, 2         \n"
"BUF0:   .WORD   BLK, -1                                 \n"
"NEWPAL: .WORD   0b1110111011001100, 0b1010101010001000  \n"
  );
} // PALET

void SetPalette (int c0, int c1, int c2, int c3)
{
  asm("  BICB    $0177760, 8(SP)  \n"
      "  BICB    $0177760, 6(SP)  \n"
      "  MOVB    6(SP), R0        \n"
      "  ASH     $4, R0           \n"
      "  ADD     6(SP), R0        \n"
      "  ASH     $4, R0           \n"
      "  ADD     8(SP), R0        \n"
      "  ASH     $4, R0           \n"
      "  ADD     8(SP), R0        \n"
      "  BICB    $0177760, 4(SP)  \n"
      "  BICB    $0177760, 2(SP)  \n"
      "  MOVB    2(SP), R1        \n"
      "  ASH     $4, R1           \n"
      "  ADD     2(SP), R1        \n"
      "  ASH     $4, R1           \n"
      "  ADD     4(SP), R1        \n"
      "  ASH     $4, R1           \n"
      "  ADD     4(SP), R1        \n"
  );
  PALET();
} // SetPalette

[BlaireCas]

почему установка палитры влияет на нижнюю линию верхней служебной строки и на верхнюю нижней?

Судя по всему код пытается установить два слова палитры подряд в памяти ПП начиная с адреса @#2470 (переслать их туда). На дефолтной системе адрес верный.
А чего в ассемблерном листинге получилось после компиляции? Мож GCC как-то не так компильнул

А не, норм. с программой все в порядке. Можно проверить зайдя скажем в эмулятор. Нажать в стартовом меню УСТ затем УПР-@ это будет периферийный процессор, набрать 2470, стрелка вправо, ввести слово палитры первое, нажать стрелка вниз, ввести слово палитры второе, нажать стрелка вниз, нажать УПР-Ц, ИСП). Так и поменяет палитру вместе с верхней и нижней одними строчками. Нууу видимо так уж устроена дефолтная таблица строк. Главное что на экран действует.

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

[Oleg N. Cher]

А как закрасить весь экран цветом фона? Вот такая процедура не помогает:

void ClearDevice (void)
{
  asm("  MOV     R2, -(SP)     \n"
      "  MOV     $0176640, R0  \n"
      "  MOV     $0176642, R1  \n"
      "  MOV     $0100000, R2  \n"
      "  MOV     R2, @R0       \n"
"1$:     CLR     @R1           \n"
      "  INC     @R0           \n"
      "  SOB     R2, 1$        \n"
      "  MOV     (SP)+, R2     \n"
  );
} // ClearDevice

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

Мне вообще пока даже непонятно: почему при четырёхцветном режиме у служебных строк остаётся не тот же фон. Или для них надо отрубать третью плоскость отдельным кодом?

[BlaireCas]

не помогает

у служебных строк остаётся не тот же фон

Процедура на вид верная и очищает планы 1,2 видеопамяти. Просто из центрального процессора через 176640/176642 ты можешь поменять лишь два цветовых плана памяти. А третий (дефолтно он синий после загрузки компа) - поменять не выйдет через эти регистры.
После загрузки компа центральная часть экрана закрашена синим. А служебные строки - черным. Ты через 176642 делаешь очистку и очистишь только 2 байта из трех. А третий меняется через похожий регистровый способ, но только из периферийного процессора.
Вот поэтому и не очистить вышеприведенным кодом вообще весь экран.

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

Либо использовать (я сам не знаю какие) скажем ESC-команды терминала для того чтобы одна из процедур обработки терминала в ПП сама покрасила/очистила. Кстати этими ESC командами ЕМНИП можно линии кружки и пр. рисовать. Ну чтобы не изобретать велосипед и не реализовывать брезенхема или что-то навроде для линии. https://zx-pk.ru/threads/31436-kody-...ala-uknts.html

[nzeemin]

А как закрасить весь экран цветом фона?

Если из ЦП, то примерно любой мой проект на УКНЦ:

	MOV	#GAMESC, R1	; Строка для подготовки игрового экрана
	CALL	PRINT
	CALL	PAUSE		; подождём пока очистится экран
...
	MOV	#EXITSC, R1		; Строка очистки экрана перед выходом
	CALL	PRINT
	.EXIT

; Подпрограмма: Печать строки: R1 = адрес строки, строка завершается 0; портит R0
PRINT:
PR0:	MOVB	(R1)+, R0		; Конец строки?
	BEQ	PR2			; да => завершаем
PR1:	TSTB	@#177564		; Источник канала 0 готов?
	BPL	PR1			; нет => ждём
	MOV	R0, @#177566		; передаём символ в канал 0
	BR	PR0
PR2:	RETURN

;Подпрограмма: пауза после очистки экрана чтобы ПП закончил работу
PAUSE:	; Pause to let PPU finish the previous commands
	MOV	#177777, R5
PAUSE0:	NOP
	SOB	R5, PAUSE0
	RETURN

GAMESC:	; Строка подготовки игрового экрана
	.BYTE	033,246,62	; Формат экрана 40x24
	.BYTE	033,240,61	; Цвет символа
	.BYTE	033,241,60	; Цвет знакоместа 0
	.BYTE	033,242,60	; Цвет фона 0
	.BYTE	14		; Clear screen
	.BYTE	0
EXITSC:	; Строка очистки экрана перед выходом
	.BYTE	33,246,061		; Формат экрана 80x24
	.BYTE	33,240,67		; Цвет символа
	.BYTE	33,241,61		; Цвет знакоместа 1
	.BYTE	33,242,61		; Цвет фона 1
	.BYTE	14			; Очистить экран
	.ASCII	/BYE!/
	.BYTE	0
	.EVEN

[Oleg N. Cher]

Никита, это никак не решает мою проблему. После вывода GAMESC и установки цветного фона верхняя и нижняя линии как были - так и остаются.

Ваш вариант кода оставляет непогашенным курсор и надпись Лат. У меня есть коды, которые гасят и убирают:

"INIT$:  .BYTE   033, 0246, 062      \n"  // Screen mode 40x24
      "  .BYTE   033, 045, 041, 061  \n"  // Text mode 1
      "  .BYTE   033, 0133, 060, 073, 060, 0162  \n"
      "  .BYTE   033, 045, 041, 060  \n"  // Graph
      "  .BYTE   0                   \n"

Подробностей не знаю, но как-то работает.

Никита, BlaireCas, вы умные ребята. А я не ставлю цели изучить УКНЦ в потрохах, я просто хочу немного её потрогать. И мне нужна простая вещь: убрать эти дебильные линии и сделать фон служебных строк тем же цветом, что и остальной экран. По возможности не тыкайте в доки и не говорите много умных букаф, лучше кажите рабочий код. Спасибо за понимание.

Я всё ещё не понимаю почему нет графических процедур для нормального использования полной области экрана. Ведь это ж как бы напрашивается само собой. Но - нету так нету, я смиряюсь перед великой мощью гения замысела УКНЦ.