A давайте разработаем собственный Z80 на VHDL.

[WingLion]

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

Есть только одно но. Желающих что-либо делать - круглый ноль - вся тема зафлужена, куча никчемных советов - а реально откликнувшихся на первый пост - НОЛЬ.
Так что, смысл в нем вообще пропадает. И у меня желание пропадает им заниматься.

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

[Advertiser]

[Vadim]

1001-й раз пишу. Мне нужен новый проц. С новыми командами. С 32 бит режимом. С возможностью переводить проц в режим z-80 (16 бит адрес). Нужна новая машина под этот проц, а не панелька с 40-а выводами вставляемая в любой спектрум. Новый клон нужен, на подобии спринтера. Расширенная система команд уже известна. Это Z-380, она была продумана и вполне логична. Можно конечно её и расширить. Желателен мат.сопроцессор. Я разработкой заниматься не могу, т.к. не владею ни VDHL ни Verilog.

Ну естественно проги требующие больше памяти, расчитанны уже на десятки мегабайт RAM,

Как же быть с фрагментацией ОЗУ? Как грузить эти проги и как они будут взаимодействовать с ОС?

частоты шины\проца >50Mhz на них претендовать можно только при условии совершенно НОВОЙ архитектуры. Но откуда возмется эта архитектура?

Её надо разработать. Только надо быть осторожными, что бы не сделать велосипед (PC), но на системе команд z80.

Топикстартер задумал ввести в ядро T80 команды управления акселем и ищет того, кто поможет ему в разработке. Никаких идей он и слышать не желает. Модель он уже разработал. Ну пусть делает, его идеи мне неинтересны.

[bigral]

Как же быть с фрагментацией ОЗУ? Как грузить эти проги и как они будут взаимодействовать с ОС?

На самом деле malloc в виртуальном пространстве каждой задачи тоже плодит фрагментацию RAM-a, правда значительно меньше изза того что один процесс значительно меньше раз обращается к malloc/free чем куча процессов под ucLinux\MacOS\AmigaOS. Только спец виртуальная машина решает этот вопрос радикально (которая знает где указатели).

Про RISC cpu - возможно новый проц нужно делать таким изза того что скорость будет большой, НО режим совместимости с оригинальным Z80 нужен по любому иначе проц будет мало кому тут интересен.

---------- Post added at 23:29 ---------- Previous post was at 23:05 ----------

помощи я уже ни от кого не жду. Ибо, очевидно (из этой темы), что ее и не будет.

Ну а хотябы проект завести для начала можно? На google code или source forge? Выложить исходники того что есть, может пару доков по соглашениям, FAQ и т.д. Ато как бы процес пока не инициирован совсем.

[WingLion]

Топикстартер задумал ввести в ядро T80 команды управления акселем

Только не не надо приписывать мне то, чего я не делал. Глюко-Т80 идет в сад.

п.с. и помощи я уже ни от кого не жду. Ибо, очевидно (из этой темы), что ее и не будет.

[ZEK]

расчитанны уже на десятки мегабайт RAM, и на частоты шины\проца >50Mhz на них претендовать можно только при условии совершенно НОВОЙ архитектуры.

в low cost fpga на такие частоты в сколько нибудь сложном ядре можно не надеяться, тот же ez80 если сделать из к примеру из однотактового NextZ80 (при его 25-30мгц), максимум что можно ожидать 10-15мгц, так что архитектуру выдумать что бы она была простая (risc) и хорошо конвееризуремая и мало занимала ресурса, это задача для исследовательских центров, а потом, проц без компилятора это бесполезная поделка...

Можно было бы каралич WingLion причесать (я бы ему компилер оберона нарисовал бы), но афтар неадекватен, не желает править детские косяки, и воспринимает критику как личную обиду.

[WingLion]

Всем неверующим закрыть глаза и нажать на RESET...

Процессор 6E16 сегодня зафурычил на частоте 200MHz...
и разводится на 250MHz на более быстром циклоне.
А на стратиксе - выдает все 500MHz.

6Е16 - это шестиголовый (шестиядерный) процессор EQUINOX, переработанный на более высоком уровне...

Kоманду ADC в новой версии принципиально не добавлял, чтобы крЫтики еще больше опоносились...

[ZEK]

Kоманду ADC в новой версии принципиально не добавлял

на зло бабушке отморожу себе уши

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

[vlad]

Идея в следующем...

Есть у меня заготовка для проектирования процессоров.
Чтобы сделать из нее Z80 не хватает самой малости.
Надо ее наполнять контентом, а именно, писать HDL коды для всех-всех-всех команд. У меня терпения не хватило после первых 40 штук...

Цель - получение не абсолютной копии Zilog-овского Z80, а быстрой версии (в пределе 1 такт на команду), в которую при желании можно вставлять свои команды (я вот, хочу прямо вставить в него команды акселератора Sprinter-a)

Тем, кому интересно, прошу на e-mail admin@winglion.ru (в теме письма писать - Z80, чтобы в спаме не затерялось сообщение).

Плюсы для участников
1. Получение конечного результата (если он будет) - VHDL кода для Z80 и его возможных расширений.
2. Формально, бесплатный тренинг по VHDL и Quartus II на примере конкретного проекта.

Транслировал на VHDL софт-ядро NextZ80 (verilog) v1.0.0. Теперь ядро собирается и в Quartus , занимает около 1700 LE на Cyclone III, есть тестовый проект для ReVerSE.
Может кто нить знает как работает конвейер команд в eZ80? Может получиться добавить, возможно удастся ещё увеличить его производительность. Сейчас ядро в 3-ри с лишним раза быстрее Z80 (T80 режим compatibility) на той же частоте.

[b2m]

Теперь ядро собирается и в Quartus

А с верилогом-то какие проблемы были?

Может кто нить знает как работает конвейер команд в eZ80? Может получиться добавить, возможно удастся ещё увеличить его производительность.

Никакой конвейер не поможет, если за один такт считывать ровно один байт. Нужно увеличить разрядность шины данных, а потом думать, как за один такт обрабатывать сразу несколько байт (как несколько команд подряд, так и параметры команды). Очень помог бы кэш и SDRAM-контроллер, работающий на более высокой частоте (чтобы считывать несколько байт за один такт процессора). Кстати, есть ли готовые кэш+sdram контроллеры?

[specorg]

Может кто нить знает как работает конвейер команд в eZ80? Может получиться добавить, возможно удастся ещё увеличить его производительность.

Нашёл только такое упоминание (картинки прикрепил к посту)

http://www.zilog.com/docs/um0077.pdf

Pipeline Description

The CPU pipeline reduces the overall cycle time for each instruction. In principle, each instruction must be fetched, decoded, and executed. This process normally spans at least three cycles. The CPU pipeline, however, can reduce the overall time ofsome instructions to as little as one cycle by allowing the nextinstruction to be prefetched and decoded while it executes the current instruction as displayed in Figure 2. The CPU operates on multiple instructions simultaneouslyto improve operating efficiency.

In Figure 3, the pipelining process is demonstrated using a series of nstructions. The first LD instruction prefetches its opcode and first operand during the decode and execute phases of the preceding INC instruction. However, the second LD instruction in the sequence only prefetches its opcode. The bus WRITE during the execute phase of the first LD instruction prevents the pipeline from prefetching the first operand of the next instruc-tion. Thus, the number of bytes prefetched is a function of the command currently execut-ing in the CPU.
When a control transfer takes place, the Program Counter (PC) does not progress sequen-tially. Therefore, the pipeline must be flushed.All prefetched values are ignored. Control transfer can occur because of an interrupt or during execution of a Jump (JP), CALL, Return (RET), Restart (RST), or similar instruction. After the control transfer instruction is executed, the pipeline must start over to fetch the next operand.

Хотел бы ещё добавить к обсуждению части участников в теме - всё это только теория, не судите строго.

Кто-то в этой теме предлагал вариант, процессора на базе команд Z380 с шиной 16/32 бит. Хороший вариант, все возможности процессора Z380 имитировать не нужно на 100%. Сложность заключается в том что нужно переделать T80 или NextZ80:
- шина данных к памяти 16/32 бит SD-RAM;
- шина адреса к памяти 32 бит (или меньше в целях экономии выводов, если не планируется ставить все 4Гб);
- система команд, регистров, прерываний? Z380;

Ещё момент, Z380 поддерживает проц Z180, нужна ли поддержка команд Z180 в 32 битном режиме? Может "отсеять" ненужные вещи?

Насчёт модели памяти и совместимости с Z80 машинами, такие мысли - поскольку Z80 использовался нами в компьютерах типа Spectrum 48K/128K и т.п. и это является можно сказать эталоном, то почему бы не создать так называемый виртуальный VZ80?

Как это выглядит - выделяем каждому процессу память страницами по 16Кб/64Кб/1Мб. Как раз хватит для режима совместимости Z80 для запуска виртуальных машин 48Кб/128Кб а доступ к памяти до 1Мб по стандарту Pentagon или другой (например).

Можно пойти дальше, сделать параллельную работу этих VZ80 с контекстным переключением, которым будет заниматься менеджер процессов (программа).
Единственное что-то надо делать для разделения ресурсов: экран, порты устройств.
Дальше можно развить идею вывода экрана VZ80 в область окна ОС которая будет управлять системой в режиме VGA например в виде окна. Порты можно сделать у каждого процесса свои или общие и управлять ими при контекстном переключении.

Что касается использования возможностей z380 для работы, то для создания или портирования ОС необходимы механизмы эффективного управления памятью и процессами. Так же важна защита памяти от изменения другими процессами (ошибки, сбои и т.п.).

Можно как вариант взять за основу управления памятью в виде страниц 16Кб/64Кб/1Мб через специальные регистры страниц, в котором в виде битовой карты будет прописаны права доступа процесса к страницам
- 0 нет доступа
- 1 есть доступ

Охват области памяти при размере страницы:

16Кб

1 байт - 8 бит - 128Кб
2 байта - 16 бит - 256Кб
4 байта - 32 бит - 512Кб
2х4 байта - 64 бит - 1Мб
4х4 байта - 128 бит - 2Мб
8х4 байта - 256 бит - 4Мб
16х4 байта - 512 бит - 8Мб
32х4 байта - 1024 бит - 16Мб
64х4 байта - 2048 бит - 32Мб
128х4 байта - 4096 бит - 64Мб

64Кб

1 байт - 8 бит - 512Кб
2 байта - 16 бит - 1Мб
4 байта - 32 бит - 2Мб
2х4 байта - 64 бит - 4Мб
4х4 байта - 128 бит - 8Мб
8х4 байта - 256 бит - 16Мб
16х4 байта - 512 бит - 32Мб
32х4 байта - 1024 бит - 64Мб
64х4 байта - 2048 бит - 128Мб
128х4 байта - 4096 бит - 256Мб

1Мб

1 байт - 8 бит - 8Мб
2 байта - 16 бит - 16Мб
4 байта - 32 бит - 32Мб
2х4 байта - 64 бит - 64Мб
4х4 байта - 128 бит - 128Мб
8х4 байта - 256 бит - 256Мб
16х4 байта - 512 бит - 512Мб
32х4 байта - 1024 бит - 1Гб
64х4 байта - 2048 бит - 2Гб
128х4 байта - 4096 бит - 4Гб

Получается что для полного описания доступа страниц 4Гб по 1Мб на страницу нужно 128 регистров по 32 бита каждый. Но в целях экономии можно ограничится меньшим размером - например, при 8 регистрах по 32бита и размере страницы - охват области памяти:

16Кб - 4Мб
64Кб - 16Мб
1Мбайт - 256Мб

Как видно лучше конечно чтобы страница была равна 1Мб, т.к. позволяет больше памяти охватить, но может конечно в идеале лучше 64Кб, может процессу не нужен целый мегабайт, а только скажем 50Кб. Но для адресации скажем 64Мб в этом случае нужно будет 32 регистра по 32 бит. Возможно для оптимизации, в зависимости от размера памяти в целом нужно будет выбирать свой размер страницы.

Битовая карта будет своего рода указателем из каких страниц складывается (путём склейки) адресное пространство процесса. Нужно будет в процессе обработки команд и операций с памятью учитывать эту карту.

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

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

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

Кстати насчёт GUI для ОС можно предложить взять за основу FreeGEM http://www.seasip.info/Gem/History/freegem2.html

PS: Для тех кто не понял ничего по поводу страниц, то я описал идею не модели памяти какой-то новой или модификацию имеющиеся , а назначение физическим страницами памяти логических страниц процесса. Память процесса линейна и является логической и состоит из тех страниц которые указаны в битовой карте (где бит установлен в "1" единицу). Все операции процесса выполняются в логических страницах. Склейка - это объединение физических страниц памяти которые принадлежат процессу (по битовой каарте), чтобы у процесса логическая память была непрерывна. Процессу вообще будет не заметно какие его логические страницы назначены на физические - у него будет просто линейная память, без каких либо перерывов и всего механизма этого он не увидит никогда. Обратиться к другим процессам он не может, за исключением, если не указать другому процессу, что такая же физическая страница (или несколько) тоже принадлежит ему - таким образом можно вызывать функции из DLL или ПЗУ например. Программная поддержка тут никакая не нужна - используется обычный асм Z80,Z380 компиляторы есть.