Вид для печати
А если придумать механизм при котором подпрограммы вызывать по номеру ? А в таблице адреса физические.Цитата:
Сообщение от Valen
Или по глобальному адресу. При вызове подпрограммы сохранять в стеке номер блока и страницы. При возврате восстанавливать их из стека.
Наверно ты прав, можно что-то придумать
Делал такое в своем клоне CP/M. Для драйверов или крупных многостраничных программ писаных на ассемблере достаточно удобно пользовать, но компиляторы ЯВУ такое обрабатывать не умеют (если только не написать компилятор самому), а практически любое реалистичное портирование на наши 8 бит в современном мире - это С.Цитата:
Сообщение от zst
Кросс платформенный Си под Z80/180 вроде поддерживают Big модель памяти. Сам не пробовал. Но как я понял там заточено по простые маперы памяти. И понятно, что под наши зоопарки маперов не особо подходят.
Я как-то смотрел sdcc, максимум чего можно добиться это что оно просто будет само вставлять типа как "макрос" врубления нужной страницы при обращении в дальнюю память или при вызове far jmp... НО все это дело прийдется в проге самой уже планировать изначально, т.е. изначально указать компилеру какой сегмент кода в каком банке будет лежать или какие данные в каком банке. Возникает вообще вопрос это реально кто-то использует? или просто эксперементальная фича в альфа версии у которой нет шанса быть доведенной до ума.Цитата:
Сообщение от OrionExt
Ну короче, такого автоматизма какой был достигнут на системах pdp-11 или MS-DOS, там где просто пишешь код и хранишь данные в сегментах, а потом link-ер может это все слепить "по разному" (да еще и с overlay-ами) НЕТУ! Да оно и понятно почему - изза того что вся эта штука с overlay-ами очень сильно завязана на linker\loader встроенный либо в саму OS либо завязанным на железо и встраеваемый в exe-шник самим link-ером.
Остановился на том, что надо писать отдельные модули (код+данные), которые ничего не знают ни о памяти ни о страницах, они просто могут манипулировать своими локальными данными используя свои процедуры. После того как все нужные модули будут написанны прийдется написать отдельный мини-kernel который будет связывать все эти модули в кучу, он будет знать как, кого и куда загружать, кому и куда надо вписать адреса вызовов, где и сколько выделить стека. Таким образом делается все вручную от начала до конца, а раз так то про встроенный z180 мапер можно забыть (ну т.е. он то по моще может и такой же самый как у pdp-11 или i8088, но чтоб его применить надо написать по новой rt11 или msdos для z180).
ну отчего так сразуЦитата:
Сообщение от bigral
есть softotools -на 30 дней бесплатный.
есть IAR с таблеткой
bigral, почитывая мануалы к коммерческим компиляторам (sdcc не обсуждается) у меня сложилось мнение, что Z180 мапер таки можно использовать из коробки. Тут другое. Все эти компиляторы рассчитаны на генерирование кода для неких промышленных контролеров (в разрезе использования big модели памяти). А так да. Даже для CP/M (продвинутых клонах с ОЗУ > 64Kb) придется строить костыли разной сложности. И таких примеров костылей в интернете можно найти не мало.
в чем выражаются костыли? например?Цитата:
Сообщение от OrionExt
Например для eZ80, все из коробки и СP/M там уже давно есть. И других ОS и ZDS бесплатный.
И даже кабель отладочный уже давно "поломали"-он вообщем то нужен только для eZ80 c флэшем на борту.
что останавливает? отсутствие железок-платы?
C eZ80 не знаком даже поверхностно, да и нет желания знакомиться.Цитата:
Сообщение от Totem
ну если будет желание, то отладочная плата (фирмовая) у меня есть, как и камень отдельно.Цитата:
Сообщение от OrionExt