как реализовать новую строку

#assembly #x86

#сборка #x86

Вопрос:

я работаю в текстовом режиме 80×25 и ожидаю, что для печати будет напечатана некоторая строка символов, заканчивающаяся 0 (ранее CRLF не было). как я могу затем перейти к следующей строке? что мне действительно нужно, так это выровнять смещение es: edi (0: b8000) до следующего множителя 160, но я понятия не имею, как это сделать как-то умно. если вы уже делали это или у вас есть какие-либо идеи, пожалуйста, поделитесь ими со мной или дайте мне подсказку. я не хочу никаких прерываний, и предпочтительнее решения без разделения. спасибо stu

1. На самом деле я не программист на ассемблере, но не могли бы вы добавить 160 к смещению, вычислить остаток с помощью DIV и вычесть его из смещения?

2. да, я думал об этом как о варианте, но это перезаписывает как минимум 2 регистра, и у меня их немного не хватает, но да, если нет способа добиться этого, я сделаю это таким образом

3. Другой подход заключается в простом использовании таблицы поиска на 2000 байт, смещение -> следующее 160-кратное.

4. это должно вписаться в загрузчик 🙂 то, что я использовал раньше, было обычной процедурой, подобной этой L1: переместить edi,0xb8000 160 добавить слово [L 1], 160 которое не работает, если вы печатаете целую строку..

5. почему бы вам не использовать прерывание?

Ответ №1:

Как сказал Андерс, я бы сделал что-то вроде:

 nextlineoffset = offset   (160 - ((offset   160) mod 160))

Это,

Добавьте строку в смещение
Вычтите лишнее смещение

Она использует одно деление, но устраняет необходимость в умножении.

1. я скорее подумал, не мог бы я воспользоваться тем фактом, что 160 равно 128 32, которые всегда являются двумя одинаковыми битами, поэтому каким-то образом замаскируйте их, затем, если они установлены / очищены, оставьте их / обнулите их и все справа, затем добавьте 160.

Ответ №2:

Как насчет switch подобной конструкции? Если вас интересуют только фрагменты размером 160 символов на экране размером 80×25, необходимо учитывать только тринадцать случаев, и это должна быть управляемая (и визуализируемая) последовательность CMP и условных переходов.

1. идея приятная, к сожалению, видеопамять заполнена не блоками по 160 символов, а парами цветовых символов, так что получается 25 случаев, и это 25*(5 5 2) (5 для cmp, 5 для mov и 2 для перехода на ветку) байт, и я получаю только 512 байт пространства в загрузчике, и у меня все еще есть работа, которую нужно выполнить. для того, что я пробовал, способ разделения был бы равен 14 байтам при каждом разрыве строки.

2. я думаю, что в конце подсчет напечатанных символов и проверка, было ли уже 80, является наиболее эффективным для памяти. это сравнение не из приятных, но оно постоянно составляет 9 байт, чего я вроде как и хотел.