Spartan-6 XC6LX16 и старенький ACEX EP1K50 совсем в разных весовых категориях, у LX16 2278 слайсов, а слайс Xilinx грубо в 4 раза больше чем LE у Альтеры. При том что у Spartan-6 LUT — 6 входовой, а у ACEX 4-х. Ну и блочная память, тут совсем все неважно у ACEX. Даже если представить себе, что часть нововведений Z80N можно «пришить» сбоку имеющегося в Evo Z80, то скорее всего всю остальную часть логики засунуть уже будет некуда.
Спасибо за подробный рассказ! Некоторые эффекты были для меня новыми (например, интерполяцию я не встречал, и про капли я не заметил что они были из целых квадратов, на глаз казалось что сделано пикселями). Ну и в целом, всегда интересно какие технические решения были приняты и почему. Мне не понравилась палитра, поэтому отдельное спасибо за честное объяснение почему именно такая :)
Всё вместе получилось, ОК, я согласен что не восторг, но сделано крепко. Мне было интересно увидеть демо в чём-то очень олдскульное, но в чём-то ещё и с элементами ньюскула (хотя, как я сейчас понял из пояснений, фикса в ней было меньше чем мне тогда показалось). Но любое успешное «надурил» — всегда в плюс авторам и в плюс демо.
Next очень жирная конфа — в LX16, используемый там лезет с хрустом. Там даже синтез не то, чтобы стабильный выходит. На LX25(например, gomaDOS+/ZXDOS+) куда стабильнее.
Есть вероятность сделать устройство совместимое и с конфой, и с некстом. Если один хороший человек портанет на ZXDOS+ конфу.
Это если прошивку tsconf запускать на железе Next. А я спрашиваю о противоположном, перенести прошивку Next требующую 2 Мб на железе Evo с 4 Мб. Точнее не перенести, а оседлать совместимую с Next прошивку.
Уже после релиза я узнал, что с этим треком связана некоторая teh dorama,…
Нет Слава, никакой дорамой тут и не пахнет. Просто есть хороший музыкант, но этого не менее отличный распиздяй и балабол. Человек написал трек по конкретной просьбе для конкретного проекта и так же без зазрения совести его отдал другому. И полбеды если бы он его выложил в паблик, а ты его взял не зная предыстории создания, так нет он ещё и навязал на его основании создать работу.
С флагами открытия в F_OPEN прям какая то «бида». Крутил-вертел, но так и не смог заставить работать по документации из ссылки выше флаг
MODE_OPEN_CREAT = $08; Open existing or create new
Вот всё остальное работает:
Может открыть существующий файл и выдать ошибку если его нет.
Может создать файл если его нет или стереть его содержимое если он есть и открыть.
И даже может создать новый файл если такого еще нет, но выдать ошибку если он есть.
Но блин создать новый или открыть на запись старый (не стирая предыдущего содержимого) — нифига, даёт ошибку.
Хотя технически это можно реализовать двумя попытками открытия, но как то странно. Надеюсь детские болезни.
У меня есть просьба к зубрам уже хорошо соприкоснувшимся с ZX Spectrum Next проверить черновик моей обзорной статьи про архитектуру Next OS: gamedev.ru/flame/forum/?id=231961&page=17&m=5253430#m241 на предмет актуальности, неверных сведений и так далее. Надеюсь она и тут станет полезной в итоге.
Жаль. Было бы неплохо если бы это стало стандартом и в самом esxDOS. Как я понял документация по работе в «командной строке/бейсике» esxDOS сама говорит, что вместо имени текущего диска можно подставлять символ *, т.е. тут есть некая монолитность.
Откопал крайне любопытный документ по NextOS + esxDOS для Next: raw.githubusercontent.com/z88dk/techdocs/master/targets/zx-next/nextos/nextzxos_api.pdf
Например, в разделе про esxDOS там есть очень ценное замечание, что не обязательно всякий раз вызывать функцию GetSetDrv чтобы получить номер текущего диска когда нужно вызвать функцию которой нужно передать номер диска. Оказывается в аккумуляторе можно передать символьные значения:
A='*' для текущего диска и
A='$' для системного диска (где установлена NextOS или, видимо, сама esxDOS)
Так же там есть важное замечание, что к любым вызовам надо относится так, что они уничтожают AF,BC,DE,HL, но сохраняют все остальные регистры (например тот же IX).
В общем полезно почитать…
Таким образом переход к виртуальной машине дает возможность переноса на множество других платформ. А никогда не возникало ощущения, что аппаратные возможности платформы (ядра процессора) могли бы способствовать эффективному исполнению инструкций ВМ? Например у DEC в его последнем CISC-е VAX новые инструкции могли вносится как микрокод и нативно расширяли систему команд. В случае VM это конечно в большей степени касается вызова шитого кода.
Не могу точно сказать насчет первенства в JIT компиляции, DEC тоже делала шаги в эту сторону, кроме всего прочего снабжая ядро виртуальной машины профилировщиком, принимающим решение на определенной итерации начать «инлайнить код», то есть приложение становилось шустрее и шустрее, в зависимости от времени его работы.
У МК-85, приходилось читать Отрохова, разработчик Бейсика пошел на применение шитого кода для плавающей арифметики. Формально это тоже некая часть VM. Я хочу сказать что в определенный момент, когда сложность написания процедур, даже в такой удобной и интуитивно понятной
системе команд как PDP-11, начинает достигать пределов возможностей человеческого мозга. В таком случае уйти в форт-машину или еще какую либо VM, в конечном счете связано даже не с борьбой за плотность или переносимость кода, а за возможность продолжать вести разработку.
Там можно завести уже сейчас и ZXUno, и Next, я думаю скоро можно будет и TSConf.
esxDOS там доступен и на zxuno, и на next ядре.
А ZXDOS+ хорош тем, что там жирная ПЛИС, 4мб SRAM, нормальный VDAC(6 бит на канал), ну и можно просто взять и купить.
Всё вместе получилось, ОК, я согласен что не восторг, но сделано крепко. Мне было интересно увидеть демо в чём-то очень олдскульное, но в чём-то ещё и с элементами ньюскула (хотя, как я сейчас понял из пояснений, фикса в ней было меньше чем мне тогда показалось). Но любое успешное «надурил» — всегда в плюс авторам и в плюс демо.
Есть вероятность сделать устройство совместимое и с конфой, и с некстом. Если один хороший человек портанет на ZXDOS+ конфу.
Это если прошивку tsconf запускать на железе Next. А я спрашиваю о противоположном, перенести прошивку Next требующую 2 Мб на железе Evo с 4 Мб. Точнее не перенести, а оседлать совместимую с Next прошивку.
3. Кто это будет делать?
Вопрос, можно ли.
1. Чип в нексте жЫрнее.
2. Раму в нексте зажали (нужно 4 метра против 2х)
3. Кто это будет делать?
Нет Слава, никакой дорамой тут и не пахнет. Просто есть хороший музыкант, но этого не менее отличный распиздяй и балабол. Человек написал трек по конкретной просьбе для конкретного проекта и так же без зазрения совести его отдал другому. И полбеды если бы он его выложил в паблик, а ты его взял не зная предыстории создания, так нет он ещё и навязал на его основании создать работу.
А самое смешное, что после выхода твоей работы, он клятвенно обещал, что тут же напишет другой, не менее крутой — «только для вас здесь и сейчас». Как не трудно догадаться — «а трек у нас на подходе» ©
Мы бы отлаживали игры для Next, а буржуи бы покупали более дешевую Еву.
MODE_OPEN_CREAT = $08; Open existing or create new
Вот всё остальное работает:
Может открыть существующий файл и выдать ошибку если его нет.
Может создать файл если его нет или стереть его содержимое если он есть и открыть.
И даже может создать новый файл если такого еще нет, но выдать ошибку если он есть.
Но блин создать новый или открыть на запись старый (не стирая предыдущего содержимого) — нифига, даёт ошибку.
Хотя технически это можно реализовать двумя попытками открытия, но как то странно. Надеюсь детские болезни.
Поэтому я рекомендую все таки вызывать функцию, можно один раз и сохранять результат. Этот вариант проверено работает везде.
Например, в разделе про esxDOS там есть очень ценное замечание, что не обязательно всякий раз вызывать функцию GetSetDrv чтобы получить номер текущего диска когда нужно вызвать функцию которой нужно передать номер диска. Оказывается в аккумуляторе можно передать символьные значения:
A='*' для текущего диска и
A='$' для системного диска (где установлена NextOS или, видимо, сама esxDOS)
Так же там есть важное замечание, что к любым вызовам надо относится так, что они уничтожают AF,BC,DE,HL, но сохраняют все остальные регистры (например тот же IX).
В общем полезно почитать…
Таким образом переход к виртуальной машине дает возможность переноса на множество других платформ. А никогда не возникало ощущения, что аппаратные возможности платформы (ядра процессора) могли бы способствовать эффективному исполнению инструкций ВМ? Например у DEC в его последнем CISC-е VAX новые инструкции могли вносится как микрокод и нативно расширяли систему команд. В случае VM это конечно в большей степени касается вызова шитого кода.
Не могу точно сказать насчет первенства в JIT компиляции, DEC тоже делала шаги в эту сторону, кроме всего прочего снабжая ядро виртуальной машины профилировщиком, принимающим решение на определенной итерации начать «инлайнить код», то есть приложение становилось шустрее и шустрее, в зависимости от времени его работы.
У МК-85, приходилось читать Отрохова, разработчик Бейсика пошел на применение шитого кода для плавающей арифметики. Формально это тоже некая часть VM. Я хочу сказать что в определенный момент, когда сложность написания процедур, даже в такой удобной и интуитивно понятной
системе команд как PDP-11, начинает достигать пределов возможностей человеческого мозга. В таком случае уйти в форт-машину или еще какую либо VM, в конечном счете связано даже не с борьбой за плотность или переносимость кода, а за возможность продолжать вести разработку.