Ну насколько я понимаю, пока DMA перебрасывает данные процессор остановлен и прерывание тоже не приходит. Отличие в том, что во время переброски данных z80DMA всегда DI на Z80, а это очень неудобно. И я думаю в zxnDMA более упощенный, хотя не проверял, но вряд ли там всё возможности реализованы.
Это если развернуть фразу — значит в оригинальном z80DMA — этого делать нельзя?? хмм… И в чем же проявляется отличие, если на пальцах?
Так то я все демки для z80DMA написанные пересмотрел, работают в большинстве своем наверное правильно, как авторы задумывали. Но большинство работает и в режиме zxnDMA, иногда даже лучше, чем в нативном.
В эмулях работает DMA пока плоховато :( Хотелось бы поточнее эмууляцию.
c push моя идея… уж больно нравилась она мне в x86. test тоже полезная)
Главное отличие, что в burst mode можно теперь с прерыванием im2 работать. Я очень долго за это бился (:
P.S. Да по названию и «hidden message» легко гуглится второй вариант тут: soranews24.com/2012/12/19/obscene-messages-from-developer-discovered-in-1980s-nes-game/
И надо сказать он во многих очень важных вещах отличается от данного, но проясняет некоторые моменты. Такое ощущение что переводчики с японского были сильны в разных предложениях.
А это сообщение есть на английском? :)
Не понял вопроса. Английские тексты по ссылке в посте можно прочитать.
Причём замечу, что основа моего перевода взята по ссылке, но некоторые обороты речи были настолько непонятными, что я нашёл еще один вариант перевода на второго сообщения и понял из него что имеется ввиду, но ссылку на него потерял в итоге. Хотя если искать наверняка вылезет опять в результатах поиска.
Найсу!

Любой кто наткнулся на это — извращенец! Есть еще одно сообщение в Pachi–Com на (компьютере) MSX… Если ты извращенец — купи и посмотри! Однако, там окинавский диалект!

А это сообщение есть на английском? :)
К слову о Си и 8-битных процессорах буквально на днях наткнулся на KickC: forums.nesdev.com/viewtopic.php?f=2&t=20187
Пытаясь максимально сохранять синтаксис Си компилятор просто возвращается к корням — ЭВМ из 60-х и не поддерживает рекурсию. И всё начинает работать гладко и шелковисто и компилироваться в бодрый и довольно рабочий код.
Тот же CC65 на следующем коде (очень для него неудачном):

void str_cpy( char *dst, char const *src ) {
   while ( *dst++ = *src++ ) {}
}

Рожает следующий тихий ужас:

.proc   _str_cpy: near
.segment        "CODE"
        jsr     pushax
L0006:  ldy     #$03
        jsr     ldaxysp
        sta     regsave
        stx     regsave+1
        jsr     incax1
        ldy     #$02
        jsr     staxysp
        lda     regsave
        ldx     regsave+1
        jsr     pushax
        ldy     #$03
        jsr     ldaxysp
        sta     regsave
        stx     regsave+1
        jsr     incax1
        ldy     #$02
        jsr     staxysp
        ldy     #$00
        lda     (regsave),y
        jsr     staspidx
        tax
        bne     L0006
        jmp     incsp4
.endproc

А вот KickC в своём асмосинтаксисе (как можно догадаться KickAssembler) делает почти оптимально:

str_cpy: {
    .label dst = 4
    .label src = 2
  __b1:
    // *dst++ = *src++
    ldy #0
    lda (src),y
    sta (dst),y
    // while ( *dst++ = *src++ )
    lda (dst),y
    inc.z dst
    bne !+
    inc.z dst+1
  !:
    inc.z src
    bne !+
    inc.z src+1
  !:
    cmp #0
    bne __b1
    // }
    rts
}

Весьма впечатляющий результат, хотя видно что еще есть куда работать.
Отсутствие локальных переменных еще позволяет производить оптимизацию с размещением переменных и параметров в одном и том же месте если они не пересекаются в callstack. Тоже недоступная для Си вещь даже если шлёпать static.
Вот такой эффект от того что как в древнем Fortran когда не было там еще ключевого слова RESURSIVE.
Если тебе реально нужны компиляторы Си, тебе нужно развивать другие вещи. Я бы начал с команд типа ld r,(rr+n), ld r,(rr+r), push nn (единственная стоящая команда выше, мне кажется), и всяких add rr,nn. Потому что я ещё никого не видел, кто бы сказал, что Си проще компилировать в 6502, чем в Z80. Но вообще заниматься компилятором Си сложнее, чем очень много чем другим.
Я это всё понимаю. Речь о другом. Даже если вы просто возьмёте и сделаете «Z80 на стероидах», просто с кучей однотактовых команд, ничего не меняя, это уже будет подразумевать что паттерны хорошего кода поменяются. Вот там выше aa-dav пишет про неэффективность LDIR, что зачастую правда, но только если речь идёт о скорости копирования. С точки зрения компактности кода LDIR очень эффективна, а по скорости — не более чем посредственна, так что вы не найдёте, например, декомпрессора на спектруме без LDIR. Т.е. даже медленная LDIR — очень даже пригождается.

Ваш перелопаченный Z80 потребует пересмотра вообще всех таких привычных соображений, во всяком случае с точки зрения хорошо оптимизированного кода. Поэтому невозможно вообще что-либо сказать, ни про твои доработки с сегментом регистров а-ля геймбой, ни про доработки некста. Без точной информации о скорости команд, разговор получится ни о чём.
  • avatar tsl
  • 0
По опкодам.
Либо префиксировать каждую команду, либо включать отдельный блок расширенной ISA. Префикс можно выбрать либо ED, либо из команд типа LD R,R — где реги одинаковые. Второй метод позволяет сильно экономить память — по объему и машциклам, а также дает неограниченную свободу воли в выборе опкодов. Для крайней совместимости предусмотреть защелку, блокирующую включение доп. опкодов.

По набору команд.
Основная цель — С компиляторы. Полагаю, 256 байт для регфайла достаточно. Должна быть общая арифметика, хотя бы 2-операндная, между любыми ячейками регистрового файла. Объединение соседних ячей в пары/четверки. Адресация ячеек как непосредственно, так и регистрами. Постинкремент и предекремент адресующих регов.

Над конкретным набором команд надо садиться и думать.
Ну и конечно, сначала опробовать все это в эмуляторе, что несложно.
  • avatar tsl
  • 0
Такты в ФПГА реализации не всегда боттлнек, кое-что можно значительно оптимизировать. В основном же существующие корки имеют растактовки для совместимости.
  • avatar tsl
  • 0
Я посмотрел, но там ВСЁ другое.
«Я тут пишу код и мне хотелось бы для этого иметь EX HL,HL', было бы удобнее, быстрее и компактнее». Это подразумевает, что мы берём быстрые циклы для Z80 и ищем как их ускорить. Но качественные реформы, вроде расширенного блока регистров предложенного выше, на самом деле радикально меняют весь подход к оптимизации кода.
радикально изменить подход может и одна-единственная команда
например, ex sp,hl вместо (или вместе с) ld sp,hl
То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.

Я крайне с этим согласен!
И скорее всего сейчас начну говорить жуткую банальщину, но как раз эта вот растактовка меня давно уже не удовлетворяет в том же Z80.
Взять ту же самую LDIR. Блочная инструкция, двухбайтовая, пересылающая сразу блоки байт, но как?
А так что на каждый пересылаемый полезный по «ПН (полезной нагрузке)» байт сопровождается двумя считываемыми байтами инструкции и скорее всего еще больше тактов по общему смыслу.
Не сомневаюсь что это всё поднималось ранее тысячи раз.
Потому что ну реально концепция general processor на каждый байт обрабатываемых полезно данных нагрузки реально чаще всего даёт +10 байт инструкций, опкодов и адресов. Который нужно считывать.
В итоге LDIR работает полукалечно: просто выполняет LDI и делает JR -2, чтобы снова считывать 2 байта инструкции чтобы переслать 1 байт полезных данных.
И это дико бесит перфекциониста типа меня и рождает DMA-контроллеры. Просто потому что general processors сосут. Откровенно.
Понятно что там еще с прерываниями надо разобраться и тому подобное. Не всегда уместно блочить шины DMA-контроллером надолго. Может и звук защёлкать и так далее.
Но я хотел сказать лишь то что наверняка уже тысячи раз говорилось: хотелось бы чтобы в general processor были по настоящему эффективные инструкции могущие не пересчитывать байты инструкции x2-3 байта из памяти каждый раз пересылая лишь 1 байт полезных байт нагрузки.
А LDIR настолько такой не является, что её реально попают пушами.
Аааа…
Мне кажется, что думать в терминах конкретных инструкций бесперспективно. Потому что как выглядят большинство хотелок в обсуждениях этого типа? «Я тут пишу код и мне хотелось бы для этого иметь EX HL,HL', было бы удобнее, быстрее и компактнее». Это подразумевает, что мы берём быстрые циклы для Z80 и ищем как их ускорить. Но качественные реформы, вроде расширенного блока регистров предложенного выше, на самом деле радикально меняют весь подход к оптимизации кода. Например, мы привыкли что самая быстрая заливка на Z80 — серия команд PUSH. А на Sharp LR35902 команда PUSH занимает уже не 11, а 16 тактов, и это при том что добавлена новая 8-тактовая команда LD (HL+),A, которая по сути может залить байтами с той же скоростью что и PUSH.

То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.
в последнее время подумываю, как расширить зетник для работы с регистровым файлом по типу 6502
В Sharp LR35902 в последние 256 байт памяти замапили четыре иструкции LDH (imm8), a / LDH a, (imm8) / LDH (c), a / LDH a, (c), но блин увы, там обратная совместимость серьёзно была подпорчена и потому эти инструкции заняли место других из i8080 и будучи однобайтовыми опкодом действительно были судя по всему штукой интересной. А чтобы не ломать совместимость с Z80 тут надо тоже вклиниваться в ED-коды и 2 байта на опкод уже сильно ущемляют полезность потому что ничем не лучше однобайтного LD A,(imm6).
В связи с этим вопрос — какие то пути преодоления проблемы просматриваются? :)
  • avatar bfox
  • 2
посмотри в сторону 6309
  • avatar tsl
  • 1
В контроллерах, для которых разрабатывают свои ISA, специализированные инструкции для железа вполне норма. Раз некст «улучшенный», то почему не улучшить и проц? Говорить о том, что в з80 не хватает элементарных вещей, наверное излише. Но я не столько сами их инструкции не понимаю, сколько scope (забываю русский) ихнего дизайна. Что они хотят выносить на аксели, а что на проц? Выглядит как-то сумбурно.
Ну и щас скажу ужасное (instrospec, закрой глаза): в последнее время подумываю, как расширить зетник для работы с регистровым файлом по типу 6502.
«ну запилите вы прозрачную трансляцию адреса»

Чем больше размышляю над этой идеей тем больше нравится она мне. «Выпрямить» адресацию реально же можно просто анализом и перестановкой сигналов на шине адреса. Но с другой стороны у PIXELAD еще выполняются сдвиги, т.е. вычисляется уже готовый адрес по осмысленным готовым координатам в DE.
Я конечно согласен, что выглядит это FPGA-роскошество как изврат над самой идеей general processor, а сам слой ULA при наличии нормально скроллируемых тайлового слоя и 8bpp вообще непонятно зачем нужен кроме совместимости, но я всё-таки даже восхищаюсь этим непотребством, уже больно оно так сказать по мозолям топчется. :)