dlcorp.nedopc.com (ZX-Форум) (21+, запрещено для детей)

Дык в инкбине укажи длину с точностью до байта. И вставляй хоть один байт.

Вообще бы надо как то наебать шестнадцатибитность адреса зетника.
Допустим длинный JP вполне реально реализовать, теми же префиксами или неиспользуемыми командами.

Code: Select all

db 0x40
db 0xXX ;страница озу, это надо перехватить, а зетнику выдать nop
JP 0хNN ;здесь надо выдернуть старшие два бита адреса, чтоп знать куда подключить страницу


JP z,NN etc, тоже самое.
JP (hl) невозможно реализовать, но не особо нужно.

Длинный CALL тоже самое, но надо запоминать страницу возврата. И нужен длинный RET.
Основная проблема сохранить страницу, причём не одну. Поэтому нужен аппаратный стек, байт на шестнадцать как минимум.
При RET надо опять же перехватить адрес возврата, чтоп знать окно замены страницы.

Согласен, что оное проще реализовать программно, но спектрумы бывают с разными мемманагерами. Да и начинающим кодерам(вроде меня) будет проще.

а вот что делать с данными хз, из постов fk0 ничё не понял, ввиду отсутствия вышки. Но понял одно, определённо нужны короткие адреса переключения страниц. Хотя бы один адрес

Code: Select all

ld a,0bnnpppppp ;n-окно,p-страница
out (xx),a

Но лучше четыре. А то придётся юзать еще что то, чтоп получить доступ ко всем четырём мегабайтам.

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

IX и IY работают со всей ОЗУ. Только надо назначать им сегменты. Сегменты соответственно по 64кб.

замапить ВСЕ(по возможности) порты на память зетника.

Отделить данные - дело хорошее. Можно будет работать с текстурами и экранами по 64 КБ. Это можно решить и за счёт сегментных префиксов.
Правда, есть способ ещё эффективнее, применён на V9990 - данные кидаются в порт, а видеоконтроллер сам их расфасовывает в прямоугольный блок видеопамяти (и наоборот, можно подсасывать данные из прямоугольного блока видеопамяти). Тогда можно работать с экранами любого размера.

alone wrote:Правда, есть способ ещё эффективнее, применён на V9990 - данные кидаются в порт, а видеоконтроллер сам их расфасовывает в прямоугольный блок видеопамяти (и наоборот, можно подсасывать данные из прямоугольного блока видеопамяти). Тогда можно работать с экранами любого размера.

Тоже интересно. Как вижу:
Два байта в памяти(или один, но лучше два), так называемый буфер(с автоинкрементом адреса естественно). Реальный стартовый адрес указывать аутом, или там же рядом в памяти. Т.е.

Code: Select all

struct
{
  unsigned char segment; //0-64
  unsigned short offset; //0-32768
  unsigned char data[2];
};


автоинкремент адреса срабытывает по чтению\записи старшего байта.
желательно чтоп offset был доступен и на чтение, на всякий случай, чтоп знать где сейчас указатель, но необязательно.

alone wrote:прямоугольный блок

вот это хз. чую отжрёть кучу LE. Да и применимо только к графике. А тут у нас нелинейность

Тут как посмотреть:

OUTI - 16 тактов на байт
POP HL:LD (data),HL - 13 тактов на байт, но выигрыш только если пишем всегда словами (т.е. Wolfenstein в пролёте) и стек не занят, гм, стеком.

INI - 16 тактов на байт
LD HL,(data):PUSH HL - 13.5 тактов на байт, приходится писать задом наперёд и надо иметь перед записываемым блоком буфер под запарывание стеком.

Чтобы определить запись в порт, достаточно пары битов.
Чтобы определить запись в структуру, нужно дешифровать адрес по всем битам.

А зачем сегмент и оффсет, а не просто 22 бита адреса?

Таким макаром восьмибитных портов не напасёшся. Хотя согласен портами проще в железе реализовать.

Про такты, тут дело как раз таки не в тактах, а в удобстве. Бывает что не знаешь в какое окно страницу воткнуть, ибо всё занято, особенно на сях.

alone wrote:А зачем сегмент и оффсет, а не просто 22 бита адреса?

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