Просмотр полной версии : Потроха CP/M 2.2
В "океанской" CP/M 2.2 Rel.7 таблица DISK PARAMETER TABLE состоит из трех записей DPH (Disk Parameter Header) по числу поддерживаемых устройств A:, B: и C:, и располагается с адреса 0xd90d (ПЗУ):
XLT
-
-
-
DIRBUF
DPB
CSV
ALV
DPH1
0000
0000
0000
0000
BB3F
BB0E
BBDE
BBBF
DPH2
0000
0000
0000
0000
BB3F
BB1D
BC05
BBEE
DPH3
0000
0000
0000
0000
BB3F
BB1D
BC2C
BC15
DPB1 начинается с адреса 0xbb0e, DPB2 с адреса 0xbb1d (оба в ОЗУ):
SPT
BSH
BLM
EXM
DSM
DRM
AL0
AL1
CKS
OFF
DPB1 (A:)
0010
03
07
00
003F
1F00
80
00
0800
0000
DPB2 (B:,C:)
0024
04
0F
01
00B3
3F00
80
00
1000
0000
Из DPB1 закономерно вытекает формат квазидиска A: - 16 секторов на дорожку (1 сектор = 128 байт), полная емкость 63Кбайт.
Формат дисков B: и C: - 36 секторов на дорожку, 179 Кбайт.
А я вроде как слышал, что логическая структура всех дисков CP/M одинакова сектора по 128 байт не помню сколько их...
Логический сектор да, 128 байт. С одной стороны, это удобно, потому что одинаково везде. С другой стороны, не всегда хорошо ложится на физический сектор, который на дискете может быть и 512 байт, и вообще 1024 байта. С третьей стороны, начинаются проблемы при поддержке дисков больших размеров.
В "Океане-240" встроенные в БИОС процедуры переноса блока между основной памятью и квазидиском оперируют размером 128 байт.
- - - Добавлено - - -
Полезная по многим причинам ссылка - https://zx-pk.ru/threads/23229-pk8000-zagruzka-s-vneshnikh-nositelej.html?p=900680&viewfull=1#post900680
Насколько я знаю почти ко всем вариантам CP/M в дистрибутиве идёт конфигуратор, который позволяет настраивать данную версию CP/M под конкретный экран и дисководы (например, в Роботроне 1715 вроде было именно так, потому что дисководы могли быть разные, да еще в том числе и внешние).
Соответственно никто не мешает подредактировать DPB2 под используемые модели дисководов
>36 секторов на дорожку, 179 Кбайт
А разве число блоков (DSM+1=180) не надо умножить на размер блока, который для B: и C: по приведенным Вами данным виден как 2k?
Итого объем диска 180*2=360 килобайт (без вычета под служебку).
BSH and BLM are determined by BLS, the block size or data allocation size
BLS BSH BLM EXM
----- --- --- DSM<256 DSM>=256
1024 3 7 0 n/a
2048 4 15 1 0
4096 5 31 3 1
8192 6 63 7 3
16384 7 127 15 7
- - - Добавлено - - -
Мне было всегда интересно как CP/M отличает дисковод 40 дорожек 2 стороны от 80 дорожек одна сторона. Может кто подскажет.
Насколько я знаю почти ко всем вариантам CP/M в дистрибутиве идёт конфигуратор, который позволяет настраивать данную версию CP/M под конкретный экран и дисководы (например, в Роботроне 1715 вроде было именно так, потому что дисководы могли быть разные, да еще в том числе и внешние).
Соответственно никто не мешает подредактировать DPB2 под используемые модели дисководов
Океанические DPB да, хранятся в ОЗУ, но редактировать его придется ручками, так как дистрибутива океанского CP/M в видимой части Вселенной не наблюдается.
>36 секторов на дорожку, 179 Кбайт
А разве число блоков (DSM+1=180) не надо умножить на размер блока, который для B: и C: по приведенным Вами данным виден как 2k?
Итого объем диска 180*2=360 килобайт (без вычета под служебку).
Очень может статься, что это так. Однако в ПЗУ жестко прошит размер дисковода 180К (как и квазидиска в 64К, но к этому мы еще вернемся).
>Очень может статься, что это так.
36 секторов *128 байт * 40 дорожек=180К для одностороннего дисковода. И 360К для двухстороннего. И мы снова возвращаемся к вопросу как CP/M отличает односторонний дисковод от двухстороннего....
Ну и в DPB явно прописано 180 блоков по 2К.
И мы снова возвращаемся к вопросу как CP/M отличает односторонний дисковод от двухстороннего
BDOS-у CP/M фиолетово, у него своя абстракция: номер диска / номер дорожки / номер сектора (128 байт, всегда). А вот BIOS CP/M должен уже сам решать. У Океана-240, насколько я помню, фиксированная привязка типа дисковода к букве диска. У Корвета (вроде бы) в первом секторе нулевой дорожки в самом начале есть информация о количестве дорожек, секторов, типе сектора (тут полагаемся на юзверя, который не должен совать не те дискеты в дисковод). А во многих реализациях - вообще только один тип поддерживается.
Да, похоже это именно BIOS'ом отрабатывается. У Роботрона есть отдельная табличка, в которой, кроме всего прочего есть два параметра: кол-во секторов на дороже и общее кол-во секторов на дорожке. Соответственно второй параметр как раз и будет отличаться от первого в два раза для двухстороннего дисковода.
В начале 1-го сектоpа 0-ой доpожки дисков, используемых
в "КОРВЕТЕ" и "КВОРУМЕ" записывается таблица, паpаметpы котоpой
используются начальным загpузчиком пpи запуске, и самой
опеpационной системой пpи pегистpации дискет. Стpуктуpа таблицы
пpиведена ниже. В гpафе данные пpиведены значения для системной
дискеты "КВОРУМА" фоpмата DS/DD/96 TPI, соответствующего фоpмату
s6 "Robotron 1715".
┌──────────┬────� �───┬────────────� ��──────────────── ────────────────� �
│ Смещение │ Данные │ Назначение │
│ (HEX) │ (HEX) │ │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 00H..01H │ A880H │ Начальный адpес в ОЗУ для загpузки ОС. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 02H..03H │ A980H │ Адpес в ОЗУ точки входа для запуска ОС. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 04H..05H │ 0014H │ Количество физических сектоpов отведенных │
│ │ │ под ОС на диске ( < 256). │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 06H │ 00H │ 00H - Дискета фоpмата 5,25". │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 07H │ 01H │ 00H - одинаpная плотность записи (SD) │
│ │ │ 01H - двойная плотность записи (DD) │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 08H │ 01H │ 00H - 48 TPI │
│ │ │ 01H - 96 TPI │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 09H │ 01H │ 00H - Данные вектоpа пеpевода сектоpов │
│ │ │ используются. │
│ │ │ 01H - Данные не используются. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 0AH │ 03H │ Объем физического сектоpа: │
│ │ │ 00H - 128 байт │
│ │ │ 01H - 256 байт │
│ │ │ 02H - 512 байт │
│ │ │ 03H - 1024 байта. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 0BH │ 01H │ 00H - одностоpонний диск, сектоpа от 1 до N.│
│ │ │ 01H - двухстоpонний диск. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 0CH..0DH │ 0005H │ Количество физических сектоpов на доpожке. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 0EH..0FH │ 0050H │ Количество доpожек на одной стоpоне диска. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 10H..11H │ 0028H │ Количество логических (128 байт) сектоpов │
│ │ │ на доpожке (SPT). │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 12H │ 04H │ Фактоp сдвига блока (BSH). │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 13H │ 0FH │ Маска блока данных (BLM). │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 14H │ 00H │ Маска pазмеpа блока (EXM). │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 15H..16H │ 0185H │ Количество блоков данных на диске -1 (DSM). │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 17H..18H │ 007FH │ Число элементов оглавления -1. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 19H..1AH │ 00C0H │ Маска блоков оглавления. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 1BH..1CH │ 0020H │ Размеp вектоpа контpоля оглавления. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 1DH..1EH │ 0004H │ Количество доpожек * количество стоpон │
│ │ │ отведенных под системную область. │
├──────────┼────� �───┼────────────� ��──────────────── ────────────────� �
│ 1FH │ 4BH │ Контpольная сумма таблицы. │
└──────────┴────� �───┴────────────� ��──────────────── ────────────────� �
b2m, небольшой оффтопик: по-моему, в эмуляторе неправильно отображаются цвета:
67189
по-моему, в эмуляторе неправильно отображаются цвета
Предлагаешь красный с зелёным поменять? Я давно предполагал, что красные буквы на чёрном фоне - это как-то нестандартно. Но сравнить не с чем было. Или уже есть фотки с рабочего оригинала?
b2m, я думаю речь идет вот об этой ютубе с труъ:
https://youtu.be/M6C2gXHD-to
Предлагаешь красный с зелёным поменять? Я давно предполагал, что красные буквы на чёрном фоне - это как-то нестандартно. Но сравнить не с чем было. Или уже есть фотки с рабочего оригинала?
Есть фотки с реплики. Правда, в оригинальной раскраске CP/M цвета вырвиглазные, типа зеленый на малиновом, но все ж таки море на картинке с пароходом должно быть синее.
b2m, а как в emu сделана поддержка дополнительной памяти "Океана"?
Никаких специальных примочек нет, всё описано в конфиге.
Смотрю конфигурацию:
mem : Memory {
size=20000
frame[0].size=8000
frame[1].size=10000
}
Полное отключение ПЗУ в нулевой странице не поддерживается?
И если хочется добавить поддержку 256К, то нужно просто дописать frame[2] и frame[3]?
Полное отключение ПЗУ, судя по конфигу, это страница 1
mm : MemMap {
map[0][0000-7FFF]=mem.frame[0]
map[0][8000-BFFF]=mem.frame[1][8000]
map[0][C000-DFFF]=cpm
map[0][E000-FFFF]=bios
map[1][0000-7FFF]=mem.frame[0]
map[1][8000-FFFF]=mem.frame[1][8000]
map[2][0000-DFFF]=bios
map[2][E000-FFFF]=bios
map[3][0000-DFFF]=bios
map[3][E000-FFFF]=bios
initpage=3
}
ppaC0 : K580ww55 {
portA=vid.scroll.y
portB[0-3]=mem.frame[0].page
portB[1-3]=mem.frame[1].page
portB[4-5]=mm.page
portC=vid.scroll.x
}
Несколько "хитро" сделано переключение страниц ОЗУ (отмечено золотисто-берёзовым), но (видимо) так надо было.
- - - Добавлено - - -
И если хочется добавить поддержку 256К
Достаточно просто увеличить размер ОЗУ size=40000, количество бит порта конфигурации позволяет.
Полное отключение ПЗУ, судя по конфигу, это страница 1
Вроде нет, отключить ПЗУ можно и в странице 0 (первые 64 килобайта), выставив бит ~ENROM в единицу:
67281
- - - Добавлено - - -
Несколько "хитро" сделано переключение страниц ОЗУ (отмечено золотисто-берёзовым), но (видимо) так надо было.
Синтаксис mmap я как-то не в силах постичь.
Синтаксис mmap я как-то не в силах постичь.
Не парься, всё сконфигурировано как у тебя на картинке. Сложность была в том, чтобы в области 8000-FFFF младший бит B0 не переключал страницы, пришлось сделать окно в 64Кб (которое frame[1]) переключаемое только битами B3-B1.
- - - Добавлено - - -
Слово "страница" мы с тобой, по-моему, понимаем по-разному.
- - - Добавлено - - -
И да, биты B5,B4 (REST, ~ENROM) в конфиге используются вместе, формируя номер карты памяти от 0 до 3. Именно это я назвал "страницей".
Слово "страница" мы с тобой, по-моему, понимаем по-разному.
Скорее всего. Для меня "страница" - это 64К ОЗУ. С набивкой 128К памяти имеем 2 страницы (0 и 1), с удвоением соответственно 4 страницы. Штатные процедуры BIOS для переноса сектора между основной (адрес 00000-0FFFF) и дополнительной (10000-1FFFF) страницами захардкожены на 128К.
В терминологии "Океана" дополнительная страница - это "квазидиск" объемом 64К. При установке 256К памяти можно поправить пару бит в процедурах и получить квазидиск в 128К, а если поправить чуть умнее, то 192К.
Достаточно просто увеличить размер ОЗУ size=40000, количество бит порта конфигурации позволяет.
А доступ к новым страницам нужно прописывать? сделал так:
mem : Memory {
size=40000
frame[0].size=8000
frame[1].size=10000
frame[2].size=10000
frame[3].size=10000
}
Пропатчил процедуры чтения-записи блока (ANI 3; ADI 2), но этого явно недостаточно. Сюда нужно что-то еще дописать, чтобы frame [2] и frame [3] были видны? какой смысл все-таки несет индекс map [x]?
mm : MemMap {
map[0][0000-7FFF]=mem.frame[0]
map[0][8000-BFFF]=mem.frame[1][8000]
map[0][C000-DFFF]=cpm
map[0][E000-FFFF]=bios
map[1][0000-7FFF]=mem.frame[0]
map[1][8000-FFFF]=mem.frame[1][8000]
map[2][0000-DFFF]=bios
map[2][E000-FFFF]=bios
map[3][0000-DFFF]=bios
map[3][E000-FFFF]=bios
initpage=3
}
А доступ к новым страницам нужно прописывать?
Нет, ничего не надо. frame это окно доступа ко всему ОЗУ, таких окон может быть несколько, поэтому frame[0],frame[1],... и т.д. В конфиге описаны два окна, одно размером 32Кб, второе 64Кб. При выводе в portB биты 0-3 используются как номер страницы 32Кб-окна, а биты 1-3 как номер 64Кб-окна (этот номер в два раза меньше, но т.к. окно в два раза больше, то окно будет открыто на том-же месте). Я уже говорил, для чего нужно второе окно.
какой смысл все-таки несет индекс map [x]
Номер карты памяти. В зависимости от того, какие из бит 4-5 порта В установлены, получим число от 0 до 3, это и будет индекс (номер) установленной карты. Например, если установлен только В4, то двоичное число 01 соответствует индексу 1. Тогда раскладка будет:
0000-7FFF mem.frame[0] окно в 32Кб ОЗУ, номер которого (mem.frame[0].page) управляется битами 0-3 порта В
8000-FFFF mem.frame[1][8000] окно в 64Кб (но со смещением 8000, т.е. только вторая половина) ОЗУ, номер которого (mem.frame[1].page) управляется битами 1-3 порта В
- - - Добавлено - - -
но этого явно недостаточно
Конечно, надо ещё увеличить размер диска в DPB
- - - Добавлено - - -
Посмотрел БИОС CP/M, выводы неутешительные:
1. процедура рассчёта адреса сектора квазидиска расчитана только на 64Кб
2. процедуры обмена с расширенной памятью в БИОСе также рассчитаны только на 64Кб максимум (т.е. адрес расширенной памяти 16-битный и передаётся в регистровой паре, никакого номера страницы не предусмотрено).
Сообщение от tnt23
но этого явно недостаточно
Конечно, надо ещё увеличить размер диска в DPB
Это само собой, но пока и оно не дает результата, ясно почему:
Посмотрел БИОС CP/M, выводы неутешительные:
1. процедура рассчёта адреса сектора квазидиска расчитана только на 64Кб
Можешь дать ссылки на адреса?
2. процедуры обмена с расширенной памятью в БИОСе также рассчитаны только на 64Кб максимум (т.е. адрес расширенной памяти 16-битный и передаётся в регистровой паре, никакого номера страницы не предусмотрено).
А здесь все не так плохо. В регистровой паре DE передается номер 128-байтового блока, которых в 64К влезает как раз 0x200. Как я уже выше писал, достаточно поправить пару команд в процедурах чтения-записи блока с "ANI 1; ORI 2" на "ANI 3; ADI 2", и сможем нормально щелкать линиями A16 и A17:
RDSEC: ;F2A0
PUSH H
PUSH D
MOV A,D
ANI 1 ; меняем на ANI 3
ORI 2 ; меняем на ADI 2
ORI 0
MOV B,A
XRA A
MOV A,E
RAR
MOV D,A
MVI A,0
RAR
MOV E,A
Можешь дать ссылки на адреса?
А, так там не адрес, а номер сектора? Тогда отбой тревоги :) Адрес процедуры D712. Невнимательно посмотрел, там просто номер дорожки умножается на 16 и прибавляется номер сектора-1.
Тогда действительно, достаточно подправить, как ты сделал (можно даже с рассчётом на будущее ANI 7). Увеличить размер диска можно подправив байт 3Fh на 7Fh в ПЗУ cpm80.bin по адресу 1796h.
- - - Добавлено - - -
но пока и оно не дает результата
Я тебе один умный вещ скажу, только ты не обижайся: встроенная команда DIR, которую они подправили, чтобы она размер свободной области выдавала, неправильно работает со 128Кб. Если через отладчик записать на кваз XDIR.COM, то он всё правильно покажет. Я попробовал после него записать два файла по 32Кб, а затем текстовый, так вот текст правильно выдаётся командой TYPE, т.е. всё работает.
tnt23, b2m, а вы же знакомы с сорцами cp/m 2.2, прямыми (http://www.retroarchive.org/cpm/archive/unofficial/download/cpm2-plm.zip) и отревершенными (http://www.retroarchive.org/cpm/archive/unofficial/download/cpm2-asm.zip)?
Сорцы не глядел, видел код в отладчике эмуля. :)
Я тебе один умный вещ скажу, только ты не обижайся: встроенная команда DIR, которую они подправили, чтобы она размер свободной области выдавала, неправильно работает со 128Кб. Если через отладчик записать на кваз XDIR.COM, то он всё правильно покажет. Я попробовал после него записать два файла по 32Кб, а затем текстовый, так вот текст правильно выдаётся командой TYPE, т.е. всё работает.
XDIR надо попробовать. Еще бы надыбать маленькую утилитку под CP/M, способную посчитать CRC или как-нибудь еще уникальность для произвольного файла, набить квазидиск да хоть бы копиями BIOS и проверить. А то текст может правильно выдаваться командой TYPE, и при этом из-за неверной адресации сидеть поверх тех двух файлов по 32Кб.
- - - Добавлено - - -
svofski, не далее как вчера скачивал и задумчиво глядел в PLM. Океанский CCP имеет отличия, начиная с команды DIR и заканчивая READ и WRITE.
- - - Добавлено - - -
Поправил 2 байта в BIOS и 1 байт в DPB:
67327
(Фон цвета тины морской)
- - - Добавлено - - -
Увеличить размер диска можно подправив байт 3Fh на 7Fh в ПЗУ cpm80.bin по адресу 1796h.
Пробовал получить кваз на 192К (ок, на 191) методом правки 3Fh на BFh - нет, что-то не срастается.
из-за неверной адресации сидеть поверх тех двух файлов по 32Кб
Не, я смотрел куда записалось, у меня было 21000h, т.е. после границы памяти 128Кб
методом правки 3Fh на BFh - нет, что-то не срастается
Не забыл ANI 7 сделать? 192Кб это страницы 2-7, т.е. до ADI 2 это будет 0-5.
Не забыл ANI 7 сделать? 192Кб это страницы 2-7, т.е. до ADI 2 это будет 0-5.
А чёрт. Точно!
67328
В штатной команде DIR размер квазидиска жестко прописан по адресу DB29h (для версии CP/M REL.5). Чтобы DIR рапортовала размер правильно, туда следует прописать то же значение, что и в DPB (https://zx-pk.ru/threads/29823-potrokha-cp-m-2-2.html?p=991122&viewfull=1#post991122).
67331
В REL.7 чуть иначе (DC57h):
67332
Кстати, для дисковода B: там прошит размер 360К.
Еще бы надыбать маленькую утилитку под CP/M, способную посчитать CRC или как-нибудь еще уникальность для произвольного файла
CRC.COM из дистрибутива Aztec C. например.
67358
67368
Ух ты, ты освоил Aztec C?
Ух ты, ты освоил Aztec C?
Да, у меня такое ощущение, что мы с ним старинные знакомые. Смог собрать hello.c в 9 килобайт, а с либой Tiny аж в 2 килобайта.
На квазидиске работает быстро, каких-нибудь полторы минуты компиляция, ассемблирование и линковка.
На квазидиске работает быстро, каких-нибудь полторы минуты компиляция, ассемблирование и линковка.
Есть же консольные эмуляторы CP/M, на современных процессорах это полсекунды будет. Даже я такой писал, работает с каталогом на хосте, можно пользоваться любимым редактором для редактирования текста. Правда, результат компиляции внутрь эмулятора всё равно переносить надо, но и тут можно что-нибудь придумать.
- - - Добавлено - - -
Вот тут выкладывал: post970016 (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=970016&viewfull=1#post970016)
А я пользовался aliados (http://ninsesabe.arrakis.es/aliados/). Но по-моему tnt23 не торопится никуда ;)
Меня в такой разработке под CP/M больше угнетает цикл запуска текстового редактора. Полторы минуты компиляции даже на современном компе -- дело привычное, темплейтные библиотеки такое могут. Но вот выходить каждый раз из редактора, чтобы запустить компилятор, это ад.
Я думаю, что чтобы полноценно испытать такой стиль разработки, надо распечатывать листинг на бумаге матричным принтером. Ромашковый тоже ок. А сишные сорцы писать с диграфами.
Я не то чтобы не торопился, просто хочется создать (воссоздать) более-менее рабочую среду, чтобы можно было на каком-нибудь ЦЦ-пати сесть и зафигачить нетленку. Ну или какие-нибудь мелкие тулзы сваять, не отходя к ноутбуку с виндой.
выходить каждый раз из редактора, чтобы запустить компилятор, это ад
Ну не знаю, обычно любимые программерские редакторы имеют возможность по горячей клавише запустить внешний make с выводом лога компиляции в какую-нибудь нижнюю док-панель. А то и ошибки прямо в тексте указывают (если компилятор вразумительно ругается).
b2m, под CP/M? Я помню пару редакторов, но они не очень сильны были по части запустить внешний make и особенно слабы были на док панели. Или я заблуждаюсь, мне пора уже выкинуть vim и запускать Любимый редактор через эмулятор CP/M?
Я не то чтобы не торопился, просто хочется создать (воссоздать) более-менее рабочую среду, чтобы можно было на каком-нибудь ЦЦ-пати сесть и зафигачить нетленку
У меня тоже перед каждым ЦЦ такие фантазии. Но на самой пати всегда стоит шум, от которого я не способен отключиться, в мозгах получается эхо-камера и сделать разумеется ничего не получается. Получается только рубиться в Рива Рейд и загружать ZX81 с кассеты.
Можно устроить такое компо в противовес синклеристам с их ассемблером. Лайв спидкодинг на Aztec C под Okeah-240. Гандикапы -- синий шрифт, без док панели, без матричного принтера.
b2m, под CP/M? Я помню пару редакторов, но они не очень сильны были по части запустить внешний make и особенно слабы были на док панели. Или я заблуждаюсь, мне пора уже выкинуть vim и запускать Любимый редактор через эмулятор CP/M?
А вот какой-нибудь нормальный микроскопический текстовый редактор под CP/M есть? я помню, мы с приятелем писали такой на кафедре ВТ ФАВТ ЛЭТИ в 1988 году, аккуратно влезал в 2К и был вполне себе экранным, без пантагрюэльных конструкций вида ESC O p 7 для вставки строки.
У меня тоже перед каждым ЦЦ такие фантазии. Но на самой пати всегда стоит шум, от которого я не способен отключиться, в мозгах получается эхо-камера и сделать разумеется ничего не получается. Получается только рубиться в Рива Рейд и загружать ZX81 с кассеты.
Можно устроить такое компо в противовес синклеристам с их ассемблером. Лайв спидкодинг на Aztec C под Okeah-240. Гандикапы -- синий шрифт, без док панели, без матричного принтера.
Можно нарыть полезных эксплоитов в океахском биосе. Например, если дать команду чтения сектора с номером более 7FFh, то аккуратно отрубается ПЗУ и пользователь остается один на один с безбрежными 64К ОЗУ.
А вот какой-нибудь нормальный микроскопический текстовый редактор под CP/M есть?
Под Вектором ReTex рулил. Кроме того, что он обладает всеми чертами вменяемости, в нем есть меню для казуальщиков. От него есть авторские сорцы (http://sensi.org/scalar/ware/156/).
Они изобилуют чудесными идентификаторами, начинающимися с @ и ?, которые по всей видимости были в то время в ходу. Я попытался привести их в что-то, что может скушать прекрасм, просто заменив адские символы на подчеркивания:
https://svofski.github.io/pretty-8080-assembler/?https://pastebin.com/raw/DYkGAJem
В сорцах не хватает процедуры RUNLIN. Кроме того я не вижу в них и шрифта. Редактор запускается, но кроме курсора ничего не рисует. Наверное потратив вечер-два можно из этих сорцов и рабочего rom-а склеить исправный сорец, который уже спортировать на Океан.
b2m, под CP/M?
Нет, конечно. Я просто не понял, что ты про работу под CP/M (после фразы про темплейтные библиотеки).
b2m, это было к тому, что само по себе ждать компиляцию полторы минуты не такое уж и необычное дело даже в наше время. Не принимая во внимание мое личное мнение о темплейтных библиотеках, разумеется.
Понятно, что в 64 кБ держать в памяти редактор и компилятор невозможно. Для редактора запоминать последний файл и позицию в тексте уже было бы хорошим подспорьем.
А вот это никто не пробовал?
http://www.floppysoftware.es/te.html
The te text editor is small, humble, and useful.It's screen oriented, and can be easily adapted to a lot of computers.
Originally designed for CP/M computers, it has been successfully ported to Windows, GNU/Linux and DOS.
It can be easily adapted to a wide range of machines and/or operating systems, by editing a small source code file, in order to tell the program the screen size, and to write three or four tiny C functions to clear the screen, etc.
в 64 кБ держать в памяти редактор и компилятор невозможно
Ассемблер+Микрон мог :)
- - - Добавлено - - -
А вот это никто не пробовал?
Я скептически отношусь к программам на С для КР580-процессора.
Я скептически отношусь к программам на С для КР580-процессора.
Я тоже, но если tnt23 адаптирует Mike's Enhanced Small C Compiler для генерации кода под 8080, я только за.
Я скептически отношусь к программам на С для КР580-процессора.
Видимо, следует понимать как "не пробовал".
tnt23, может быть вот этот более компилябелен доступными для 8080 средствами?
http://texteditors.org/cgi-bin/wiki.pl?Editor
Первым увлекательным упражением будет распаковать архив.
Первым увлекательным упражением будет распаковать архив.67367
Error404
18.12.2018, 16:39
Для редактора запоминать последний файл и позицию в тексте уже было бы хорошим подспорьем.
такое умеет SED.COM (https://github.com/serge-404/AltairDOS/blob/master/App/bin/SED.COM) - редактор написанный на 8-битном FORTH (исходников нет, к сожалению). :v2_dizzy_aaaaa:
ЕМНИП, должен работать и на 8080. Он также умеет файлы размера больше чем ОЗУ TPA (работает со свапом на диске) в отличие от упомянутого тут TE который не открывает файл размером более 40к.
Управление стандартное - WordStar (как у ТурбоПаскаль)
- - - Добавлено - - -
tnt23, может быть вот этот более компилябелен доступными для 8080 средствами?
http://texteditors.org/cgi-bin/wiki.pl?Editor
Первым увлекательным упражением будет распаковать архив.
ЕМНИП он тоже из серии "работаю только в ОЗУ".
Есть его патченая разновидность умеющая резать и скливать большие файлы из частей, но ввиду бесперспективности (т.к. не умеет править текст на границе двух кусков) и общей неудобности я ссылку на него не сохранял.
Вообще, я изучил все CP/M-редакторы во время борьбы с VI для UZIX, и из маленьких самый удобный это SED, притом умеющий файлы более чем ОЗУ (это мало кто умеет, почему-то считалось незазорным накрутить в редакторе функционал и при этом открывать файлы не более 10к т.к. не хватило тямы сделать своп)
Error404, а спортированного под CP/M vi случайно не завалялось? vi с jcuken изотрет моск в порошок, но в эмуляторе, или с подключенной PS/2 клавиатурой, могло бы получиться недурно.
- - - Добавлено - - -
Хм, сказал и тут же вот что нашел:
https://github.com/udo-munk/s
Правда, разумеется, проверено только под HITECH C для Z-80.
Error404, а спортированного под CP/M vi случайно не завалялось? vi с jcuken изотрет моск в порошок, но в эмуляторе, или с подключенной PS/2 клавиатурой, могло бы получиться недурно.
- - - Добавлено - - -
Хм, сказал и тут же вот что нашел:
https://github.com/udo-munk/s
Правда, разумеется, проверено только под HITECH C для Z-80.
Найти PS/2 клавиатуру с JCUKEN тоже надо постараться. Но VI вполне себе может быть тема!
Применительно к "Океану", however, есть некоторая проблема: неизвестны в точности команды управления курсором в нем.
tnt23, если конкурс по спидкодингу будет проводиться на Векторе-06ц, то vi будет с jcuken и это будет брутальный гандикап. Причем людям, которые обычно vi боятся, будет проще.
Error404
18.12.2018, 18:29
Вот тока как и все VI (в т.ч. и для "больших машин" - я и там искал), оно открывает только что влезает в ОЗУ, у меня при TPA=58к оно не смогло открыть даже файл размером в 15к - сругалось на "out of memory". В-общем, грусть-печаль с этими VI.
Еще для CP/M есть хороший редактор VEDIT - файлы любого размера, есть инсталлятор, меню, VI-like однобуквенные команды. В инсталляторе можно прописать практически всё: я лично делал для ESC-последовательностей (для скроллингов) и клавиатуры (переназначаются любые управляющие комбинации кнопок). Почему не стал им пользоваться: для CP/M у меня уже есть SED, а для ЮЗИКС (мысль была в том чтобы запускать VEDIT под эмуляцией CP/M) мне при всем богатстве настроек не хватило у VEDIT возможности включить обработку строк по UNIX-коду конца строки. Оно хотя в отличии от прочего CP/M-овского и не перекашивалось при недостающем LF, но бесит в редакторе такой вид строк:
строка1[CR]
строка2[CR]
строка3[CR]
А сохраняет оно при том по-прежднему с CR+LF как принято в CP/M. Так что если кто знает CP/M-редактор под файлы любого размера, при этом умеющий в строки оканчивающиеся CR (как в Ордос на Орионе), прошу поделиться.
у меня при TPA=58к оно не смогло открыть даже файл размером в 15к - сругалось на "out of memory". В-общем, грусть-печаль с этими VI
Да, не фонтан. С другой стороны вряд ли сишные компиляторы под CP/M способны переварить файлы большего размера.
Что-то мне казалось, что дисковые компиляторы тех лет (ASM80, C80 и кто там еще был) умели жрать с диска исходники сильно больше TPA и складывать результаты компиляции опять же на диск. Но это неточно.
Вот нашел кое-что, чего раньше как-то ускользало от моего внимания: David Dunfield Services Micro C compiler for 8085:
http://www.classiccmp.org/dunfield/dos/mc323d85.zip
Запускается из-под досбокса. Есть примеры и даже библиотека с printf(). Цепляется монитору-отладчику на таргете, который имеет 8051 на порту $80. Там есть даже IDE. В общем офонарительная вещь.
Один недостаток - это что эта вещь ничего не знает про CP/M и часть библиотеки придется писать самому.
Error404
18.12.2018, 23:41
А такие команды есть на 8080 (это из выхлопа компилера):
SUI IMM
SBI IMM
ACI IMM
Или это от 8085?
Совершенно не ради старого холивара, но понимать по мнемонике что оно могло бы делать нормальный человек не должен.
- - - Добавлено - - -
Т.е. вопрос в том насколько оно совместимо с 8080?
Вообще, учитывая что у David Dunfield Services Micro C compiler for 8085 из типов только самые примитивные, то его преимущество перед классическим BDS C от Борландов нативно работающим на 8080 (от которого кстати есть исходники) только в отладчике (что кстати не мало, но мне нужен long нормальный а не через строки char[])
А такие команды есть на 8080 (это из выхлопа компилера):
SUI IMM
SBI IMM
ACI IMM
Это обычный 8080, SUbtract Immediate, Subtract with Borrow Immediate и Add with Carry Immediate.
Вообще, учитывая что у David Dunfield Services Micro C compiler for 8085 из типов только самые примитивные, то его преимущество перед классическим BDS C от Борландов нативно работающим на 8080 (от которого кстати есть исходники) только в отладчике (что кстати не мало, но мне нужен long нормальный а не через строки char[])
У этого C есть структуры, что по идее возвышает его над BDS C. Но они, похоже, жутко захачены. Я уже напоролся на совершенно непробиваемую стену, пытаясь их использовать. Собственно, повторяется история как и со всеми предыдущими компиляторами как бы Си для 8080: они годятся как вещь в себе, но для переноса кода толку с них в конечном счете оказывается немного.
(Несущественно, но BDS C к Борланду не имеет отношения, его автор Leor Zolman (https://www.bdsoft.com/about-us.html)).
- - - Добавлено - - -
Ох ну и упоротая вещь. Структуры там -- одно название.
С грехом/2 скомпилил pack.c из rogue, получилось 4912 байт.
Дальше пришлось помучиться, чтобы тот же файл сделать компилябельным для SDCC. SDCC ест совершенно здоровый Си, но не k&r, пришлось дописывать все прототипы (че-то не нашлось под рукой protoize). SDCC для Z80 дал 4478 байт.
Мучительно, но в общем неплохо, для 8080 то. Интересно было б сравнить с Ацтеком, но сил больше нет.
svofski, ацтека поддерживает структуры. Давай пример попроще, попробую собрать.
tnt23, мне трудно выкатить готовый пример, потому что у меня тут все уже давно в виде фарша. Если охота самому испытать удовольствие без купюр,
https://britzl.github.io/roguearchive/
Кажется, я корпел над lrogue-5.3.zip
Ацтек проглотил жертвенный сорец без единого ругательства, за что ему зачет. Но выкатил 5152 байта наигустейшего DAD SP. Код немножко напоминает результат работы movfuscator (https://github.com/xoreaxeaxeax/movfuscator)-а. Могила.
- - - Добавлено - - -
Пример:
исходный код
is_pack_letter(c, mask)
short *c;
unsigned short *mask;
{
if (((*c == '?') || (*c == '!') || (*c == ':') || (*c == '=') ||
(*c == ')') || (*c == ']') || (*c == '/') || (*c == ','))) {
switch(*c) {
case '?':
*mask = SCROLL;
break;
case '!':
*mask = POTION;
break;
case ':':
*mask = FOOD;
break;
case ')':
*mask = WEAPON;
break;
case ']':
*mask = ARMOR;
break;
case '/':
*mask = WAND;
break;
case '=':
*mask = RING;
break;
case ',':
*mask = AMULET;
break;
}
*c = LIST;
return(1);
}
return(((*c >= 'a') && (*c <= 'z')) || (*c == CANCEL) || (*c == LIST));
}
результат
2512 10d3 .112 EQU 0
2513 10d3 PUBLIC is_pack__
2514 10d3 11 xx xx is_pack__: lxi d,.116
2515 10d6 cd xx xx call csave
2516 10d9 21 xx xx LXI H,8-.116
2517 10dc 39 DAD SP
2518 10dd 5e MOV E,M
2519 10de 23 INX H
2520 10df 56 MOV D,M
2521 10e0 eb XCHG
2522 10e1 5e MOV E,M
2523 10e2 23 INX H
2524 10e3 56 MOV D,M
2525 10e4 21 3f 00 LXI H,63
2526 10e7 cd xx xx CALL .eq
2527 10ea c2 xx xx JNZ .118
2528 10ed 21 xx xx LXI H,8-.116
2529 10f0 39 DAD SP
2530 10f1 5e MOV E,M
2531 10f2 23 INX H
2532 10f3 56 MOV D,M
2533 10f4 eb XCHG
2534 10f5 5e MOV E,M
2535 10f6 23 INX H
2536 10f7 56 MOV D,M
2537 10f8 21 21 00 LXI H,33
2538 10fb cd xx xx CALL .eq
2539 10fe c2 xx xx JNZ .118
2540 1101 21 xx xx LXI H,8-.116
2541 1104 39 DAD SP
2542 1105 5e MOV E,M
2543 1106 23 INX H
2544 1107 56 MOV D,M
2545 1108 eb XCHG
2546 1109 5e MOV E,M
2547 110a 23 INX H
2548 110b 56 MOV D,M
2549 110c 21 3a 00 LXI H,58
2550 110f cd xx xx CALL .eq
2551 1112 c2 xx xx JNZ .118
2552 1115 21 xx xx LXI H,8-.116
2553 1118 39 DAD SP
2554 1119 5e MOV E,M
2555 111a 23 INX H
2556 111b 56 MOV D,M
2557 111c eb XCHG
2558 111d 5e MOV E,M
2559 111e 23 INX H
2560 111f 56 MOV D,M
2561 1120 21 3d 00 LXI H,61
2562 1123 cd xx xx CALL .eq
2563 1126 c2 xx xx JNZ .118
2564 1129 21 xx xx LXI H,8-.116
2565 112c 39 DAD SP
2566 112d 5e MOV E,M
2567 112e 23 INX H
2568 112f 56 MOV D,M
2569 1130 eb XCHG
2570 1131 5e MOV E,M
2571 1132 23 INX H
2572 1133 56 MOV D,M
2573 1134 21 29 00 LXI H,41
2574 1137 cd xx xx CALL .eq
2575 113a c2 xx xx JNZ .118
2576 113d 21 xx xx LXI H,8-.116
2577 1140 39 DAD SP
2578 1141 5e MOV E,M
2579 1142 23 INX H
2580 1143 56 MOV D,M
2581 1144 eb XCHG
2582 1145 5e MOV E,M
2583 1146 23 INX H
2584 1147 56 MOV D,M
2585 1148 21 5d 00 LXI H,93
2586 114b cd xx xx CALL .eq
2587 114e c2 xx xx JNZ .118
2588 1151 21 xx xx LXI H,8-.116
2589 1154 39 DAD SP
2590 1155 5e MOV E,M
2591 1156 23 INX H
2592 1157 56 MOV D,M
2593 1158 eb XCHG
2594 1159 5e MOV E,M
2595 115a 23 INX H
2596 115b 56 MOV D,M
2597 115c 21 2f 00 LXI H,47
2598 115f cd xx xx CALL .eq
2599 1162 c2 xx xx JNZ .118
2600 1165 21 xx xx LXI H,8-.116
2601 1168 39 DAD SP
2602 1169 5e MOV E,M
2603 116a 23 INX H
2604 116b 56 MOV D,M
2605 116c eb XCHG
2606 116d 5e MOV E,M
2607 116e 23 INX H
2608 116f 56 MOV D,M
2609 1170 21 2c 00 LXI H,44
2610 1173 cd xx xx CALL .eq
2611 1176 ca xx xx JZ .117
2612 1179 .118:
2613 1179 21 xx xx LXI H,8-.116
2614 117c 39 DAD SP
2615 117d 5e MOV E,M
2616 117e 23 INX H
2617 117f 56 MOV D,M
2618 1180 eb XCHG
2619 1181 5e MOV E,M
2620 1182 23 INX H
2621 1183 56 MOV D,M
2622 1184 eb XCHG
2623 1185 c3 xx xx JMP .119
2624 1188 .121:
2625 1188 21 04 00 LXI H,4
2626 118b e5 PUSH H
2627 118c 21 xx xx LXI H,12-.116
2628 118f 39 DAD SP
2629 1190 5e MOV E,M
2630 1191 23 INX H
2631 1192 56 MOV D,M
2632 1193 eb XCHG
2633 1194 d1 POP D
2634 1195 73 MOV M,E
2635 1196 23 INX H
2636 1197 72 MOV M,D
2637 1198 c3 xx xx JMP .120
2638 119b .122:
2639 119b 21 08 00 LXI H,8
2640 119e e5 PUSH H
2641 119f 21 xx xx LXI H,12-.116
2642 11a2 39 DAD SP
2643 11a3 5e MOV E,M
2644 11a4 23 INX H
2645 11a5 56 MOV D,M
2646 11a6 eb XCHG
2647 11a7 d1 POP D
2648 11a8 73 MOV M,E
2649 11a9 23 INX H
2650 11aa 72 MOV M,D
2651 11ab c3 xx xx JMP .120
2652 11ae .123:
2653 11ae 21 20 00 LXI H,32
2654 11b1 e5 PUSH H
2655 11b2 21 xx xx LXI H,12-.116
2656 11b5 39 DAD SP
2657 11b6 5e MOV E,M
2658 11b7 23 INX H
2659 11b8 56 MOV D,M
2660 11b9 eb XCHG
2661 11ba d1 POP D
2662 11bb 73 MOV M,E
2663 11bc 23 INX H
2664 11bd 72 MOV M,D
2665 11be c3 xx xx JMP .120
2666 11c1 .124:
2667 11c1 21 02 00 LXI H,2
2668 11c4 e5 PUSH H
2669 11c5 21 xx xx LXI H,12-.116
2670 11c8 39 DAD SP
2671 11c9 5e MOV E,M
2672 11ca 23 INX H
2673 11cb 56 MOV D,M
2674 11cc eb XCHG
2675 11cd d1 POP D
2676 11ce 73 MOV M,E
2677 11cf 23 INX H
2678 11d0 72 MOV M,D
2679 11d1 c3 xx xx JMP .120
2680 11d4 .125:
2681 11d4 21 01 00 LXI H,1
2682 11d7 e5 PUSH H
2683 11d8 21 xx xx LXI H,12-.116
2684 11db 39 DAD SP
2685 11dc 5e MOV E,M
2686 11dd 23 INX H
2687 11de 56 MOV D,M
2688 11df eb XCHG
2689 11e0 d1 POP D
2690 11e1 73 MOV M,E
2691 11e2 23 INX H
2692 11e3 72 MOV M,D
2693 11e4 c3 xx xx JMP .120
2694 11e7 .126:
2695 11e7 21 40 00 LXI H,64
2696 11ea e5 PUSH H
2697 11eb 21 xx xx LXI H,12-.116
2698 11ee 39 DAD SP
2699 11ef 5e MOV E,M
2700 11f0 23 INX H
2701 11f1 56 MOV D,M
2702 11f2 eb XCHG
2703 11f3 d1 POP D
2704 11f4 73 MOV M,E
2705 11f5 23 INX H
2706 11f6 72 MOV M,D
2707 11f7 c3 xx xx JMP .120
2708 11fa .127:
2709 11fa 21 80 00 LXI H,128
2710 11fd e5 PUSH H
2711 11fe 21 xx xx LXI H,12-.116
2712 1201 39 DAD SP
2713 1202 5e MOV E,M
2714 1203 23 INX H
2715 1204 56 MOV D,M
2716 1205 eb XCHG
2717 1206 d1 POP D
2718 1207 73 MOV M,E
2719 1208 23 INX H
2720 1209 72 MOV M,D
2721 120a c3 xx xx JMP .120
2722 120d .128:
2723 120d 21 00 01 LXI H,256
2724 1210 e5 PUSH H
2725 1211 21 xx xx LXI H,12-.116
2726 1214 39 DAD SP
2727 1215 5e MOV E,M
2728 1216 23 INX H
2729 1217 56 MOV D,M
2730 1218 eb XCHG
2731 1219 d1 POP D
2732 121a 73 MOV M,E
2733 121b 23 INX H
2734 121c 72 MOV M,D
2735 121d c3 xx xx JMP .120
2736 1220 .119:
2737 1220 cd xx xx CALL .swt
2738 1223 08 00 DW 8
2739 1225 21 00 xx xx DW 33,.122
2740 1229 29 00 xx xx DW 41,.124
2741 122d 2c 00 xx xx DW 44,.128
2742 1231 2f 00 xx xx DW 47,.126
2743 1235 3a 00 xx xx DW 58,.123
2744 1239 3d 00 xx xx DW 61,.127
2745 123d 3f 00 xx xx DW 63,.121
2746 1241 5d 00 xx xx DW 93,.125
2747 1245 xx xx DW .120
2748 1247 .120:
2749 1247 21 2a 00 LXI H,42
2750 124a e5 PUSH H
2751 124b 21 xx xx LXI H,10-.116
2752 124e 39 DAD SP
2753 124f 5e MOV E,M
2754 1250 23 INX H
2755 1251 56 MOV D,M
2756 1252 eb XCHG
2757 1253 d1 POP D
2758 1254 73 MOV M,E
2759 1255 23 INX H
2760 1256 72 MOV M,D
2761 1257 21 01 00 LXI H,1
2762 125a c9 RET
2763 125b .117:
2764 125b 21 xx xx LXI H,8-.116
2765 125e 39 DAD SP
2766 125f 5e MOV E,M
2767 1260 23 INX H
2768 1261 56 MOV D,M
2769 1262 eb XCHG
2770 1263 5e MOV E,M
2771 1264 23 INX H
2772 1265 56 MOV D,M
2773 1266 21 61 00 LXI H,97
2774 1269 cd xx xx CALL .ge
2775 126c ca xx xx JZ .130
2776 126f 21 xx xx LXI H,8-.116
2777 1272 39 DAD SP
2778 1273 5e MOV E,M
2779 1274 23 INX H
2780 1275 56 MOV D,M
2781 1276 eb XCHG
2782 1277 5e MOV E,M
2783 1278 23 INX H
2784 1279 56 MOV D,M
2785 127a 21 7a 00 LXI H,122
2786 127d cd xx xx CALL .le
2787 1280 c2 xx xx JNZ .129
2788 1283 .130:
2789 1283 21 xx xx LXI H,8-.116
2790 1286 39 DAD SP
2791 1287 5e MOV E,M
2792 1288 23 INX H
2793 1289 56 MOV D,M
2794 128a eb XCHG
2795 128b 5e MOV E,M
2796 128c 23 INX H
2797 128d 56 MOV D,M
2798 128e 21 1b 00 LXI H,27
2799 1291 cd xx xx CALL .eq
2800 1294 c2 xx xx JNZ .129
2801 1297 21 xx xx LXI H,8-.116
2802 129a 39 DAD SP
2803 129b 5e MOV E,M
2804 129c 23 INX H
2805 129d 56 MOV D,M
2806 129e eb XCHG
2807 129f 5e MOV E,M
2808 12a0 23 INX H
2809 12a1 56 MOV D,M
2810 12a2 21 2a 00 LXI H,42
2811 12a5 cd xx xx CALL .eq
2812 12a8 c2 xx xx JNZ .129
2813 12ab 21 00 00 LXI H,0
2814 12ae c3 xx xx JMP .131
2815 12b1 .129:
2816 12b1 21 01 00 LXI H,1
2817 12b4 .131:
2818 12b4 c9 RET
Тут конечно нельзя не поехидничать и над оригинальным стилем исходника.
- - - Добавлено - - -
... то есть одна функция is_pack_letter() =481 байт.
BDS C эту же процедуру переварил в 316 байт. Переписанную с использованием index() - 177. Кстати, структуры в нем в каком-то виде все-таки есть. Это не повод для оптимизма, конечно же. Ничего сложнее этой функции скомпилировать им решительно невозможно.
Ацтек проглотил жертвенный сорец без единого ругательства, за что ему зачет. Но выкатил 5152 байта наигустейшего DAD SP.
Это в чистом виде код, без примеси fprintf, lseek и проч.?
результат
Ничем не отличается от С-80. Всё честно, без единого намёка на оптимизацию.
Это в чистом виде код, без примеси fprintf, lseek и проч.?
В чистом, по ассемблерному листингу.
- - - Добавлено - - -
Ничем не отличается от С-80. Всё честно, без единого намёка на оптимизацию.
И все операции приводятся к 16-битным, даже сравнение char константы и переменной типа char. Против такого даже ручками код не повертишь.
В частном случае именно rogue, не грех было бы и саму программу переписать. Игровое поле у них массив short 80x25, все барахло хранится в связных списках, хорошо, что не двунаправленных. При том, что там 3-10 элементов, dadfuscator-ного кода на их обслуживание получаются десятки килобайт. Ну и перлы вроде вот этого свича с двойной перепроверкой, хотя их не так много наверное. Я изначально наугад взял функцию, которая не ссылается на внешние типы.
А кстати, известно хоть что-нибудь про этот C-80? Откуда он родом?
Игровое поле у них массив short 80x25
Уж так обидно, так обидно. Хорошие программы под CP/M позволяли как-то хоть приноравливаться к разным диким сочетаниям количества строк и столбцов, характерным для эпохи бурного расцвета терминалов и заката эпохи хиппи.
Плохие программы вроде LADDER хотят именно 80x25.
Уж так обидно, так обидно. Хорошие программы под CP/M позволяли как-то хоть приноравливаться к разным диким сочетаниям количества строк и столбцов, характерным для эпохи бурного расцвета терминалов и заката эпохи хиппи.
Плохие программы вроде LADDER хотят именно 80x25.
rogue родом с pdp-11, о терминалах с меньшим числом столбцов никто там не слышал. Я больше переживаю, что памяти и так нет, а массив в котором заведомо буковки огроменный и объявлен как short. Впрочем, это не оригинальный rogue. Это наиболее древний из доступных в сорцах, при этом может быть ни на чем меньше линукса 0.93 его никогда не собирали.
А что, Okeah не умеет 80х25?
И все операции приводятся к 16-битным, даже сравнение char константы и переменной типа char. Против такого даже ручками код не повертишь.
Дык там вроде short *c, а это далеко не char. Попробуй изменить на char.
rogue родом с pdp-11, о терминалах с меньшим числом столбцов никто там не слышал. Я больше переживаю, что памяти и так нет, а массив в котором заведомо буковки огроменный и объявлен как short. Впрочем, это не оригинальный rogue. Это наиболее древний из доступных в сорцах, при этом может быть ни на чем меньше линукса 0.93 его никогда не собирали.
А что, Okeah не умеет 80х25?
Максимум 64x25 или 24 в одноцвете. Зато у Океана есть квазипамять.
Максимум 64x25 или 24 в одноцвете.
Может готового драйвера под 80x25 нет, но принципиальная возможность (разрешение>480x200) есть. А то так можно сказать, что и у вектора и корвета максимум 64 символа в строке. Хотя надо признать, что несмотря на принципиальную возможность ее вряд ли реализуют на практике.
Дык там вроде short *c, а это далеко не char. Попробуй изменить на char.
Я пробовал и объявлять как char *, и кастить к чару чаровые константы, нет. Если char, он просто загружает нулем старшие байты и дальше делает тот же call .eq.
Может готового драйвера под 80x25 нет, но принципиальная возможность (разрешение>480x200) есть. А то так можно сказать, что и у вектора и корвета максимум 64 символа в строке. Хотя надо признать, что несмотря на принципиальную возможность ее вряд ли реализуют на практике.
Это совсем уж принципиальная возможность. В видеовыхлопе Океана стоит РТ4, для расширения строки за счет бордюра надо похачить ее, а заодно немножко переписать драйвер вывода на экран. Впрочем, последний все равно бы неплохо переписать хотя бы для поддержки какого-нибудь популярного стандарта на позиционирование курсора (VT52/VT100/ANSI).
- - - Добавлено - - -
Я пробовал и объявлять как char *, и кастить к чару чаровые константы, нет. Если char, он просто загружает нулем старшие байты и дальше делает тот же call .eq.
В жизни каждого ретропрограммиста рано или поздно наступает момент, когда С компилятор под любимую мертвую платформу проще уже написать самому.
Может готового драйвера под 80x25 нет, но принципиальная возможность (разрешение>480x200) есть. А то так можно сказать, что и у вектора и корвета максимум 64 символа в строке. Хотя надо признать, что несмотря на принципиальную возможность ее вряд ли реализуют на практике.
Что опять напомнило мне про давнюю мечту написать новый драйвер терминала 80x25 для Вектора. Вряд ли конечно получится что-то трансцендентное, потому что даже если ускорить в два раза, это все равно будет очень медленно. Но все же хочется попробовать.
- - - Добавлено - - -
Это совсем уж принципиальная возможность. В видеовыхлопе Океана стоит РТ4, для расширения строки за счет бордюра надо похачить ее, а заодно немножко переписать драйвер вывода на экран. Впрочем, последний все равно бы неплохо переписать хотя бы для поддержки какого-нибудь популярного стандарта на позиционирование курсора (VT52/VT100/ANSI).
Там же битмапный вывод? Сколько точек по горизонтали Океан рисует?
- - - Добавлено - - -
В жизни каждого ретропрограммиста рано или поздно наступает момент, когда С компилятор под любимую мертвую платформу проще уже написать самому.
Я периодически так тоже думаю, но реалистично смогу выкатить в самом оптимистичном случае тот же dad sp. Эти компиляторы такие печальные не от хорошей жизни.
Это совсем уж принципиальная возможность. В видеовыхлопе Океана стоит РТ4, для расширения строки за счет бордюра надо похачить ее, а заодно немножко переписать драйвер вывода на экран.
Зачем трогать РТ4? Штатных возможностей видео вполне достаточно, проблема только в отсутствии программной реализации.
Может быть у Океана есть какая-то аппаратная подмога в рисовании букв?
Что опять напомнило мне про давнюю мечту написать новый драйвер терминала 80x25 для Вектора. Вряд ли конечно получится что-то трансцендентное, потому что даже если ускорить в два раза, это все равно будет очень медленно. Но все же хочется попробовать.
Если писать портируемо в разумных пределах, то, глядишь, и в океанской воде можно будет его обмыть?
Сообщение от tnt23
Там же битмапный вывод? Сколько точек по горизонтали Океан рисует?
Вывод там битмапный, если ты имеешь в виду засовывание байт знакоместа в столбик в экранную память. По горизонтали у Океана 512 монохромных точек.
- - - Добавлено - - -
Зачем трогать РТ4? Штатных возможностей видео вполне достаточно, проблема только в отсутствии программной реализации.
Насколько я понимаю, гашение области бордюра (до строки и после строки) сделано как раз в РТ4.
- - - Добавлено - - -
Может быть у Океана есть какая-то аппаратная подмога в рисовании букв?
Я время от времени начинаю ковырять океанический биос (и быстро устаю и бросаю это дело; так же обстоит и с ковырянием океанских бейсиков, из которых можно было бы почерпнуть крупицы знаний о нижних придонных слоях), так оттуда ничего аппаратного не видно. Да и на схеме не видно. Не считать же аппаратной подмогой бит в порту ВВ55, который мапит недоступную обычно видеопамять из старших 32К в младшие, чтобы код мог в экран писать.
Насколько я понимаю, гашение области бордюра (до строки и после строки) сделано как раз в РТ4.
Я пишу о том, что для 80 символов в строке минимально достаточно 480 точек (что как раз демонстрируют вектор и корвет), аппаратную часть можно оставить как есть.
Вывод там битмапный, если ты имеешь в виду засовывание байт знакоместа в столбик в экранную память. По горизонтали у Океана 512 монохромных точек.
В таком случае нету принципиальных отличий от Вектора и Корвета, которые вполне себе запихивают в эти 512 точек 80 колонок шириной 6 пикселей. Рисуются они, конечно, завораживающе медленно.
- - - Добавлено - - -
P.S. Бордюр не надо как-то особенно при этом трогать. По-моему на Векторе картинка просто центруется, так что если не задумываться о том, как получаются 80 колонок, можно и не знать, что используются только 480 пикселей.
Про 6 пикселей я как-то не подумал. Действительно, жили же во времена оны с символами 5x7, и ничего.
- - - Добавлено - - -
У Океана среди разных рабочих ячеек ОЗУ есть одна, в которой прописан видеорежим. 0 = цветной низкого разрешения, 1 = монохром высокого, на этом многообразие режимов заканчивается.
При этом код вывода символа на экран проверяет видеорежим командой ANI 7.
(в ПЗУ Монитора есть свободные 2800 байт в конце)
Error404
20.12.2018, 14:34
Я пишу о том, что для 80 символов в строке минимально достаточно 480 точек (что как раз демонстрируют вектор и корвет)
и Орион :cool:
480/512 точек - одна из первейших доработок что делал каждый второй CP/M-щик, а в Орионе-ПРО оно уже из коробки есть
и Орион :cool:
480/512 точек - одна из первейших доработок что делал каждый второй CP/M-щик, а в Орионе-ПРО оно уже из коробки есть
Отлично, шрифты 5x7 можно дернуть с Ориона :)
А вот еще интересное из мира Корвета: https://zx-pk.ru/threads/24900-korvet-rezhim-80x25.html
(обожаю эксгумировать лежалые топики)
встроенная команда DIR, которую они подправили, чтобы она размер свободной области выдавала
Пришлось вспомнить, как работать с ghidra (спойлер: весьма комфортно) и заново отдизелить океанские MONITOR, BIOS, BDOS и CCP.
Монитор (0xe000-0xffff) после минимальной инициализации смотрит, прошит ли CPM (0xc0000-0xdfff), и передает управление загрузчику по адресу 0xd600.
Загрузчик немножечко колдует, затем копирует CCP из ПЗУ (0xc000-0xc809) в RAM по адресу 0xb200, куда после недолгих раздумий прыгает сам.
CCP почти один-в-один соответствует исходникам CP/M 2.2, за несколькими мелкими исключениями:
- процедура проверки серийного номера на месте, но аварийный выход из нее забит NOP-ами
- встроенных команд 6 ($DIR, ERA, TYPE, SAVE, REN, USER), к имени команды DIR добавлен доллар. Интересно, будет ли работать, если написать $DIR
- после адресов обработчиков встроенных команд обычно идет адрес обработчика транзитных команд userfunc. В нашем случае там вбит адрес обработчика дополнительных команд из ПЗУ CP/M (0xdb00)
- каковой добавляет еще 4 встроенные команды (DIR, READ, WRITE, EXIT). Ну и в конце ссылается обратно на штатный обработчик userfunc (0xb8a5).
(обожаю эксгумировать лежалые топики)
Интересно, будет ли работать, если написать $DIR
79994
достаточно поправить пару команд в процедурах чтения-записи блока с "ANI 1; ORI 2" на "ANI 3; ADI 2", и сможем нормально щелкать линиями A16 и A17
В Мониторе неизвестной версии, который подогнали коллеги из Североморска (https://zx-pk.ru/threads/14176-kompyuter-quot-okean-240-quot.html?p=1187126&viewfull=1#post1187126), процедуры уже пропатчены:
WBLOCK XREF[2]: ram:e01e(c), RAM2TAP:fa61(c)
ram:fb43 e5 PUSH HL
ram:fb44 d5 PUSH DE
ram:fb45 7a MOV A,D
ram:fb46 e6 07 ANI 0x7
ram:fb48 c6 02 ADI 0x2
ram:fb4a f6 00 ORI 0x0
В версии "ОКЕАН-240 CP/M (V2.2) REL.8'" DPT длиной 57 байт (три DPB по 19 байт каждый) копируется загрузчиком из ПЗУ с адреса 0xd9f8 в ОЗУ по адресу 0xbade.
DPB 1 задает параметры RAM-диска А: (192 блока по 1К), итого 192К.
DPB_1_rom XREF[1]: ram:d715(*)
ram:d9af 10 00 03 struct
07 00 bf
00 1f 00
ram:d9af 10 00 dw 16 SPT Number of 128-byte Sectors Pe XREF[1]: ram:d715(*)
ram:d9b1 03 db 3 BSH Block Shift. 3=1K, 4=2K, 5=4K
ram:d9b2 07 db 7h BLM Block Mask. 7=1K, f=2K, 1f=4K
ram:d9b3 00 db 0h EXM Extent Mask
ram:d9b4 bf 00 dw 191 DSM Number of blocks on disk - 1
ram:d9b6 1f 00 dw 31 DRM Number of directory entries - 1
ram:d9b8 80 db 80h AL0 Directory allocation bitmap,
ram:d9b9 00 db 0h AL1 Directory allocation bitmap,
ram:d9ba 08 00 dw 8h CKS Checksum vector size, 0 for a
ram:d9bc 00 00 dw 0h OFF Offset, number of reserved tr
DPB 2 и 3 для дисков B: и C: определяются в зависимости от плотности как 180 или 360 блоков по 2К, итого 360К или 720К.
d725 21 26 bb LXI HL,DPB_2
d728 0e 0f MVI C,15
d72a 11 dc d9 LXI DE,DPB_2_rom_Single
d72d 3a 48 d6 LDA (Drive_B)
d730 fe 01 CPI 0x1
d732 ca 38 d7 JZ LAB_ram_d738
d735 11 cd d9 LXI DE,DPB_2_rom_Double
Я не прошивал соответствующую версию BIOS, поэтому стартовый экран выглядит забавно. Встроенная команда SDIR исправно поддерживает 192К рам-диска, уж не знаю, подсчитывает или захардкожено, как в ранних версиях.
80036
Взял на посмотреть Rel.6. Подправил константы в DPB и у встроенной команды DIR для 128К.
80038
Но как XDIR умудряется нащупать 256К?
При прописанных в DPT для квазидиска А: 447 1-килобайтных блоках имеем следующую картину:
80095
Встроенный DIR пропатчен показывать 448К свободных, но записать очередной CHUNK5 весом 64К не получается. На диске образуется его обрезок весом 32К и выдается сообщение NO SPACE.
Внешняя команда STAT, по-видимому, показывает более похожий на правду результат.
Есть подозрение, что для размеров квазидиска более 192К (а конкретно DSM больше 256К) нужно переходить на другой размер BLS (2,048 байт) и, соответственно, указывать BSH = 4 и BLM = 15, ну и EXM = 0.
Собственно, как это и сделано для дискет:
DPB_2_rom_Double
d9cd 24 00 dw 36 SPT Number of 128-byte Sectors Pe
d9cf 04 db 4h BSH Block Shift. 3=1K, 4=2K, 5=4K
d9d0 0f db Fh BLM Block Mask. 7=1K, f=2K, 1f=4K
d9d1 00 db 0h EXM Extent Mask
d9d2 67 01 dw 359 DSM Number of blocks on disk - 1
d9d4 7f 00 dw 127 DRM Number of directory entries - 1
d9d6 c0 db C0h AL0 Directory allocation bitmap,
d9d7 00 db 0h AL1 Directory allocation bitmap,
d9d8 20 00 dw 20h CKS Checksum vector size, 0 for a
d9da 00 00 dw 0h OFF Offset, number of reserved tr
Прописываем BSH=4, BLM=15, EXM=0, DSM=223:
80099
Забиваем квазидиск мусором (SAVE позволяет сохранять в файл максимум 255 блоков):
80100
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot