Подключение через MAX232 к COM порту компьютера.
тыц.
Просто хочу поковырять прерывания.
Вид для печати
Подключение через MAX232 к COM порту компьютера.
тыц.
Просто хочу поковырять прерывания.
Ну вот, долго ли коротко ли, запилил новый вариант с прерываниями и новыми непонятками. Подключил RxRDY от ВВ51 к INT процессора и прошил EEPROM.
FASMG я для себя открыл только сегодня :) , поэтому еще не разобрался как обработчик прерываний штатно прикрутить к 38H, просто напихал нужное количество RST 7. Прошил, заработало. Прием данных идет по прерываниям. Только не понимаю, откуда взялась "очередь" из двух байтов? Вот пример: ввожу последовательно "ASDFG "(3 пробела в конце), а железка отвечает такой последовательностью (в шестнадцатеричном виде) "4B 40 4B 40 41 40 53 40 44 40 46 40 47 40 20 40". Откуда взялись первые два байта? Я не догоняю.Код:include "8085.inc"
;| ПРОГРАММА НАСТРОЙКИ И ПРОВЕРКИ УСАПП ВВ51А
;
INIT: DI
LXI SP,RAMTOP
MVI A,01H; УСТАНОВКА_УСАПП_В_ИСХ._СОСТОЯНИЕ
OUT CW51
OUT CW51
MVI A,IR
OUT CW51
MVI A,4FH; ЗАПИСЫВАЕМ_ИНСТРУКЦИЮ_РЕЖИМА
OUT CW51
MVI A,TXEN+DTR+RXE+RTS;27H; ЗАПИСЫВАЕМ ИНСТРУКЦИЮ КОМАНДЫ
OUT CW51
EI
HLT
;____ПОДПРОГРАММА ПЕРЕДАЧИ БАЙТА ИЗ РЕГИСТРА С_
;
TXD: PUSH PSW
;_______ЖДЕМ_ГОТОВНОСТИ_________________________
TX1: IN CW51
ANI TXRDY+DSR
CPI TXRDY+DSR
JNZ TX1
;_______ПЕРЕДАЕМ_БАЙТ___________________________
MOV A,C
OUT DAT51
POP PSW
RET
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
;__________ПОДПРОГРАММА ОБРАБОТКИ ПРЕРЫВАНИЙ____
INT: DI
IN DAT51; ЧИТАЕМ БАЙТ ИЗ ПОРТА
MOV C,A
CALL TXD; ВОЗВРАЩАЕМ ПРОЧИТАННЫЙ БАЙТ В ПОРТ
MVI C,40H
CALL TXD; ОТПРАВЛЯЕМ ПРИЗНАК ОТВЕТА (@)
EI
RET
;
;_____________ВНЕШНИЕ МЕТКИ И КОНСТАНТЫ_______
RAMTOP=87FFH ;
;
;___АДРЕСА_РЕГИСТРОВ_УСАПП______________________
DAT51=00H ; РЕГИСТР ДАННЫХ
CW51=01H ; РЕГИСТР КОМАНД
;
;___КОМАНДЫ ВВ51________________________________
TXEN=01H ; ПЕРЕДАТЧИК ВКЛЮЧЕН
DTR=02H ; УСТРОЙСТВО ГОТОВО
RXE=04H ; ПРИЕМНИК ВКЛЮЧЕН
SBRK=08H ; ПРЕРЫВАНИЕ ПЕРЕДАЧИ
ER=10H ; СБРОС ОШИБОК ПРИЕМА
RTS=20H ; ПЕРЕДАЧА РАЗРЕШЕНА
IR=40H ; ПРОГР. СБРОС УСАПП
EH=80H ; РАЗРЕШЕНИЕ ПОИСКА СИНХРОСИМВОЛА
;
;__РЕГИСТР СОСТОЯНИЯ ВВ51_______________________
TXRDY=01H ; ПЕРЕДАТЧИК ГОТОВ
RXRDY=02H ; ПРИЕМНИК ГОТОВ
TXE=04H ; ПЕРЕДАЧА ЗАКОНЧЕНА
PE=08H ; ОШИБКА ЧЕТНОСТИ
OE=10H ; ПЕРЕПОЛНЕНИЕ ПРИЕМНИКА
FE=20H ; ОШИБКА ФОРМАТА
SYNDET=40H ; СИНХРОСИМВОЛ НАЙДЕН
DSR=80H ; ПЕРЕДАТЧИК ДАННЫХ ГОТОВ
;
Что-то никто не ответил на мой прошлый пост, повторю с вариациями...
Ткните носом в стандарт СР/М по организации страниц в ОЗУ. В каких адресах это должно делаться, размер страниц, порт для переключалки/маппера... Если это делалось в отечественных компах (тот же Орион), то насколько совместимо с большинством зарубежных программ получилось (чтот я сомневаюсь, что было что-то отечественное, заслуживающее внимания, если вообще что-то было),.. ну и какой может быть вменяемый оптимум памяти, чтобы можно было работать с базами данных.
Насколько я понимаю, страницы должны располагаться между адресами 100Н и С400Н, но как и где... Просто не хочу ваять заранее нерабочую отсебятину.
Всем пасиб и печенек.
А не было никакого стандарта. Если кто и делал под себя на уровне ОС, то это было сугубо индивидуальное. И программ стандартных для СР/М работающих со страничной организацией тоже не встречал. СР/М 3 позволяла свой код хранить выше 64КБайт на этом и все.
Если не прав поправьте.
- - - Добавлено - - -
Для менеджмента памяти на уровне ОС, нужны хотя бы наличие соответствующих функций в ней. В СР/М 3 я такого не припомню.
Да о каком стандарте может идти речь, когда каждый компьютер содержащий более 64 Кб имел сугубо свою организацию памяти.
На вскидку в Орионе есть такая допиленная СР/М - Альтаир ДОС v3.x. MSX тоже такой системой обзавелся - MSX-DOS 2.2. Но опять софта для этих ОС с гулькин нос. Померло так и не успев родиться.
Хм... т.е. смысла делать машинку с памятью свыше 64К нет? Выше версии 2.2 не хочу лезть...
Может и есть смысл делать свыше 64Кбайт. В то время вся эта расширенная память уходила под рам-диск, что значительно ускоряло работу в ОС.
Вам не ответили, потому что никто не знает ответа. В СССР и СНГ никто не имел CP/M 3.0, тем более в банковом варианте. И всё-же раз CP/M 3.0 поддерживает многобанковость, то значит какой-то механизм управления памятью там был. ЕМНИП помню, что читал, что там был какой-то RSX (возможно расшифровывается, как Resident System eXtension).Цитата:
Сообщение от rw6hrm
Чтобы разобраться, Вам придётся самому читать документацию по CP/M 3.0 вот здесь. И по-прежнему остаётся вопросом, есть ли компиляторы хоть каких-то ЯВУ, позволяющие писать программы использующие многобанковость (неважно, управляя ей стандартно, т.е функциями ДОС или по железу конкретной машины). Если ни компиляторов, ни программ для многобанковости нет, то зачем она?
Существует HI-TECH Z80 C Compiler 7.80PL2 c поддержкой менеджера памяти Z180 (и не только) и еще были. Только какой в них прок для ОС которая не видит больше 64 Кбайт. Другое дело применять эти компиляторы для различных специализированных систем, но это уже другая история.
rw6hrm, если и подключать дополнительно банки, то страницами по 64к. Только таким образом можно хоть как-то адаптировать систему под расширение памяти. Можно хотя бы выделить системе и приложению(ям) разные страницы. Этот принцип и с z180 должен быть совместим.
Страницы по 64 кбайт не очень удобно. Надо бы иметь общий участок памяти.
Вот модель памяти для Z180 с настраиваемым менеджером в нем. Неплохо ложится на компиляторы Си с поддержкой банковой модели памяти.
Нижний и верхний общий участок можно убрать в настройках менеджера.Код:ffffh
4 кбайт min - common
---
.
. 4 кбайт
. ... - bank
. 56кбайт
.
---
4 кбайт min - common
0000h
Не совсем понял про указатель стека. Если стек хранить - другое дело. Но я не зря упомянул про ЮТ-88 ;)
А что рам-диск, он в адресном пространстве ЦПУ не лежит. Как я понял обмен с ним идет через стек и порт 40H. Для хранения данных оригинальное решение, но программу в нем не запустить. Если мы об одном и том же рам-диске говорим.
Речь ведь шла о страницах памяти в адресном пространстве ЦПУ.
За то, через него можно организовать обмен данными. А программу все равно не запустишь в нескольких страницах.
Ну как не запустишь... Цельным куском, конечно, проблематично.
Но делать вызовы процедур (функций) размещенных на разных страницах вполне возможно.
В MSX есть такое понятие как "межслотовый вызов", а "слот" там та-же страница памяти суть и есть.
Другое дело как скрестить ежа с ужом.
маленький оффтоп: а есть ли владельцы компа Altair?
Можно еще поверху ОС такую штуку накатать (это для MSX). Так сказать такой вариант менеджера памяти TSR. Есть готовая графическая библиотека для Турбо Паскаля 3.0, как некий модуль, загружаемый выше 64кб в среде TSR. Пишешь программку на Паскале в обычной ОС (макс 64 кб) и вызываешь графические функции из памяти выше 64 кб. Красота:)
Так что и для CP/M (MSX-DOS1) память выше 64кб полезна.
Чего только не придумывали, чтобы обойти ограничение в 64кб:v2_dizzy_roll:
- - - Добавлено - - -
Да MSX-DOS1 - это по сути CP/M-2.2. Честно спионерили одни, а потом другие еще раз продали спионеренное:biggrin: известной компании (не ASCII).
И первому пионеру, вторые трубу и барабан вручили за "работу":smile: Исторический факт таки.
Все ноги растут из СР/М:D
Из CP/M Били стартонул (смотрим чуть выше) и программил он бейсик на Altair (а может и нет).
Да и основа всего линейка логарифмическая (это мой видимо старт. Двигал двигал ребенком и поломал. Значит, был интерес).
Уходим от темы друзья.
Речь идёт о выборе наиболее удобного аппаратного диспетчера памяти.Цитата:
Сообщение от Xrust
В чистом виде цельнобанковая коммутация по 64 кб невозможна, даже если для переключения использовать команду OUT. Потому что тогда нет никакого способа как программе или данным попасть из основной банки в дополнительные. Коммутацию можно делать только если дополнительные банки имеют хоть немного ПЗУ или некоммутируемый фрагмент ОЗУ (или хотя-бы имитацию некоммутируемости участка ОЗУ, путём загрузки в банки одинаковых кодов).
Чтобы всё-же получить диспетчер с коммутацией в 64К, необходимо разбить 64К на несколько коммутируемых окон, что позволяет одновременно включить в адресное пространство фрагмент основной банки памяти и фрагмент дополнительной банки. После загрузки в дополнительные банки подпрограммы для коммутации (для имитации некоммутируемого участа) в дальнейшем можно коммутировать ОЗУ уже не в окне, а целыми банками по 64К. Кстати, первый в СССР диспетчер памяти был применён в ИРИШЕ (1984) и он был именно такого типа. В нём коммутировалось всё адресное пространство в 64К, но оно было разбито на 4 независимо коммутируемых окна по 16К, что позволяет осуществить начальную произвольную загрузку доп.банок, и после загрузки в доп.банку небольшого куска кода (программы коммутации) можно использовать и цельнобанковую коммутацию по 64К.
Таким образом без некоммутируемого ПЗУ (или имитацией этого в ОЗУ) невозможно переключать банки целиком. В то же время наличие некоммутируемого фрагмента ОЗУ, как это сделано в ОРИОНЕ, совершенно не является обязательным, хотя и упрощает жизнь программисту (освобождает от необходимости переставлять стек при включении очередной банки). Исходя из этого, а также установившихся в бытовых ЭВМ стандартов на входы в ПЗУ и по принципу, что "чем проще, тем лучше", самой удобной будет коммутация с окном в 62 кб, оставляя окно F800...FFFF некоммутируемым в виде ПЗУ. Особенно это справедливо, если доп.банки используются только как VDISK, а не как полноценное ОЗУ для хранения программ или данных.
Что касается того, чтобы установить границу окна коммутации на уровне C400, CC00 или D000 (т.е на уровне BDOS CP/M), чтобы при переключениях памяти сам код CP/M не изменялся, отчего вызов функций CP/M был бы возможен из любой банки, то это также совершенно не требуется. Во-первых, уровень BDOS в разных версиях ДОС меняется, а во-вторых, даже если это и требуется, то легко скопировать в доп.банки весь код CP/M BDOS+BIOS, с'имитировав тем самым некоммутируемость.
Ещё одной идеей для коммутируемости может быть некоммутируемость ZERO-page CP/M, т.е 256 байт ОЗУ 0000...00FF. Это позволяет получить, как максимально высокий TPA до FF00 (перегрузив исполняемый код CP/M 2.2 в доп.банки), так и позволяет использовать в каждой банке максимум, а именно - 63.75 килобайт памяти.
barsik, есть еще возможность перемещать данные между банками при помощи ПДП или одновременная запись в несколько банков.
Это свежая идея.Цитата:
Сообщение от Xrust
Хорошую экономию деталей и удобство программирования эта идея даёт, если иметь ПЗУ F800 только в основной банке 0, т.е имея в банке 1 FULL RAM, и заносить туда "программу коммутации" путём записи байтов в адреса F800...FFFF нулевой банки (т.к в этой области в банке 0 ПЗУ, так что запись сюда ничего не испортит). Это позволяет тратить на "интерфейс" в каждой дополнительной банке только 16 байтов (FFF0...FFFF), оставляя для полезного использования всё основное пространство каждой доп.банки.
Тогда исполнительные части подпрограммы RDBYTE (FFF0) и WRBYTE (FFF8) для чтения и записи байтов в доп.банках, удобно сделать аналогично подпрограммам ПЗУ ОРИОНА F836/39, но только с учётом их фатальной ошибки (не позволяющей вызывать эти п/п-ммы из других банок кроме нулевой). Для этого достаточно в регистре 'B' передавать номер банки, откуда был вызов и куда надо сделать возврат.
А вот идея использовать ПДП для межбанкового обмена не годится.Цитата:
Сообщение от Xrust
Определитесь какого грамматического рода у Вас банки памяти. Женского или мужского? То есть "банка памяти" или "банк памяти". Я всегда применяю термин женского рода - банка (потому что слово "банк" в предложении менее информативно, т.к хуже склоняется).
Нет смысла ставить БИС ПДП и кучу микросхем обрамления для реализации логики, что к тому же бесполезно нагружает шину, если ту же задачу решает просто наличие общего ПЗУ в банках. Это ПЗУ в доп.банке может быть размером не в 2 кб, а всего в 16 байт, где и располагаются всего две п/п-ммы RDBYTE и WRBYTE, похожие на п/п-ммы ОРИОНА F836/39.Цитата:
Сообщение от Xrust
Цитата:
Сообщение от Xrust
Согласен, что причину я придумал неудачную. Т.к речь идёт о пересылках, имелось ввиду, что слово банк в ответе на вопрос куда, звучит точно также как в именительном падеже, т.е не склоняется. Тогда вот другая причина, - чтобы не путать с финансовым понятием банк. А что общего у микросхем памяти со скамейками?Цитата:
Сообщение от Википедия
Этому удовлетворяет и банка и банк :)
А вообще было бы не плохо свести куда нибудь в одно место "словарик" терминов и зафиксировать хотя бы в рамках данной темы такие понятия как "банк" (банка), "страница", "окно" и т.п.
А то в разных контекстах они порой перемешиваются между собой.
Вот в этих книжках (раз, два) есть множество интересных идей вообще и по управлению памятью в частности.
Ну не скажите. Эта микросхема ПДП тратит на пересылку одного байта всего 4 такта, причём, т.к когда активна ПДП, то CPU находится в "захвате шины", то такт ПДП может быть иным, чем такт CPU. Т.е может быть выше, чем такт CPU (т.е столько, сколько ПДП физически тянет при максимальном оверклоке), что ещё более ускоряет пересылку. Если мне не изменяет память (ЕМНИП), то КР580 при программной петле пересылки блока тратит 56 тактов на байт, что в 14 раз медленнее. А Z80 ЕМНИП в командах типа LDIR тратит 26 тактов на байт, т.е вдвое быстрее КР580, но всё-равно намного медленнее, чем ПДП.Цитата:
Сообщение от Xrust
Но для применения ПДП для загрузки блока в 16 байтов из основной банки в дополнительную скорость вообще не играет роли. Тем более, что такая процедура выполняется всего один раз по сбросу. И ставить только для этого ПДП глупо. Кроме того придётся использовать микросхему Z80-DMA (не факт, что она удобна для КР580) или же ПДП типа 8237. Потому что ставить для этого ВТ57 бесполезно, т.к она не умеет качать данные из памяти в память, а делает обмен только с портами.
Может быть доп.корпуса (особенно КМОП) и не особо грузят выходы током, т.е в статике. Но в динамике важен не только ток нагрузки, а ёмкость входа. Каждый доп.вход любой микросхемы грузит шину паразитной ёмкостью порядка 20 пф.Цитата:
Сообщение от Xrust
Убедился в этом на практике. В РК86 слабая шина. РК86 с извлечённой из панельки доп.ППА D14 без сбоев "скворчит" с кварцем 30 МГЦ (такт КР580 ~3.1 МГЦ), а если поставить назад ППА, то уже тянет только кварц 26...27 МГЦ, а если добавить ещё и РК-КНГМД, где нагрузка шины также всего в один вход ППА (потерь на ёмкость соединит.проводов нет, т.к РК-КНГМД вставляют в слот, а с длинными косами идущими к КНГМД ситуация будет ещё хуже), приходится снижать кварц ещё ниже до ~22...24 МГЦ. Тут тоже два ППА всегда в 3-ем состоянии, т.к КНГМД используется только когда работает RK-DOS, а доп.ППА D14 только когда работает программа прошивателя УФ-ПЗУ или идёт печать на принтер.
Нагрузка на шины при том, что чем она больше, тем меньший оверклокинг удастся выжать.
barsik, учитывая все перечисленные вами плюшки, я и собирался пощупать 8237, в том числе и для межбанкового обмена.
Да, это я не учел. Но я в любом случае собирался буферизовать шины, а не экономить на спичках, как в РК. Все-таки не те времена. Сейчас БИС из МК кр580 продают на вес.Цитата:
Каждый доп.вход любой микросхемы грузит шину паразитной ёмкостью порядка 20 пф.
И да, почему ПДП обмен должен происходить только при сбросе? Им можно постоянно самые разные задачи решать.
Немного отвлекусь от железа: на сборнике Walnut Creek CPM CD-ROM (November 1994) нашел интересную прогу, позволяющую запускать код для 6502 на процессорах 8080/Z80. http://www.retroarchive.org/cpm/cdro...02/6502SIM.LBR если кому интересно. Да и вообще сборник полезный. http://www.retroarchive.org/cpm/cdrom/ и https://archive.org/download/cdrom-1..._cpm_cdrom.iso
Тоже понравилась идея одновременной записи в несколько банков. Но вопрос как реализовать это аппаратно, если используются ОЗУ-шки размером более 64к (например когда в компе всего одна SRAM или планка DIMM) на 512кб или более, и страницы памяти все в ней (выбираются по 64к старшими адресными ножками ОЗУ)?
- - - Добавлено - - -
А что можно было бы в нем запустить? как там с терминалом и т.п.? Если кто-то пробовал, поделитесь - никогда не имел дела с 6502.
Ну только если несколько корпусов использовать. Редко может потребоваться писать одновременно больше, чем в 2 страницы. Еще вариант для основной памяти использовать объемы не более 64к, а для рамдиска любые подойдут. Но мне милее всего режим, когда ПДП будет перебрасывать данные между страницами: чтение из одного банка, а запись в другой. В этом случае объем чипа не важен.
Напрямую это невозможно, т.к разная система команд. А значит используется принцип эмуляции, когда программа анализирует код команды (естественно таблично) и для каждой команды выполняет подпрограмму имитирующую работу команды 6502. Конечно, благодаря тому, что у 6502 очень мало регистров такая эмуляция проста (а вот эмулировать наоборот 8080, не говоря уже о Z80, на 6502 очень сложно, т.к 6502 вообще не поддерживает 16-ти разрядность). Но любая эмуляция фатально тормозит, и минимум в 25-30 раз. Поэтому для использования на Z80 программ (или просто участков кода) написанных для 6502, желательно иметь такт Z80 в 20 МГЦ. Что уж говорить о КР580 с тактом 2.5 МГЦ. При таком такте программа 6502 эмулируется с эквивалентым тактом в 100 КГЦ.Цитата:
Сообщение от rw6hrm
Кстати, есть C8080A с тактом в 4 МГЦ, которые очень удобны для турбирования СПЕЦИАЛИСТА, в котором базовый такт 2 МГЦ. Тогда СПЕЦИАЛИСТ легко турбировать на 200% (когда ОЗУ тоже на 4 МГЦ) или на 142% (по схеме с WAIT, когда ОЗУ остаётся на низком такте).
Разработчики 6800 не стремились увеличивать число регистров, введя вместо этого адресацию ZERO-page, потому, что затем они выпустили 6802 в котором 128 ячеек ZERO-page включено внутрь микропроцессора, т.е получился микропроцессор с реальными 128+3 регистрами (что ускорило работу), а 6502 в итоге так и остался со своими всего 3-мя регистрами.
Впрочем, это не трагедия, т.к благодаря адресации в ZERO-page в 6502 есть как бы 256 регистров, т.е реально программист для 6502 не особо страдает от малого числа регистров непосредственно внутри CPU (потеря только на том, что команды для ZERO-page не однобайтовые, а двухбайтовые, т.е реально лишь вдвое медленнее, чем регистровые команды). Но 6502 неудобен от того, что он вообще не поддерживает 16-ти разрядность и нет адресации к ОЗУ через (HL) или (IX), (IY).
Да все возможно. Другой вопрос как это работает и кому это интересно в 21 веке.
У меня тоже жил на Орионе, маленький ZX-Basic:v2_dizzy_punk:
https://www.youtube.com/watch?v=D4Oc9zyedwo
- - - Добавлено - - -
А, Enterprise 128 при своей жизни аппаратно-программной эмуляции продвинулся дальше всех.
- - - Добавлено - - -
А, вот пример Franky projects SMS<>MSX. Из нашей жизни.
https://www.youtube.com/watch?v=sNyKAOKoFUI&feature=youtu.be
- - - Добавлено - - -
Эмуляция это отлично. Тема то не про это:D
Нет невозможно. Не говорите ерунды. Код неродного процессора можно только эмулировать. А адаптация программы от другого компьютера с тем же процессором - это совсем из другой оперы. Речь о разных процессорах и не модифицированном оригинальном коде.Цитата:
Сообщение от OrionExt
Не надо вставлять видео, это неудобно смотреть, если скорость Интернета не 100 мбод, а лишь 3.6 мбод, вставляйте скрин-шоты. И вставка видео загромождает и тормозит просмотр страницы.