Тема для всяких глупых вопросов

Цитата:

---

Сообщение от Sandro

Ну вот Unix date считается с 1972 года, и в 2036 юниксовы года закончатся. Это не решение проблемы, а заметание мусора под ковёр. Лучше всё-таки хранить дату, как есть.

---

Как раз решение вопроса. Вот из rexx:
(BORNDATE - дата рождения): возвращает количество полных дней (не включая текущий день), начиная от даты рождества Христова (Январь 1, 0001), включая её. Результат выдается в формате ДДДДДД (без начальных нулей). Это формат удобен тем, что выражение вида DATE(B)//7 в качестве результата будет всегда иметь число из диапазона 0-6, где 0 соответствует понедельнику, а 6 - воскресенью (то есть, по сути, является номером дня недели). Поскольку дата '1 Января 0001 г.' основана на Григорианском календаре, который не существовал до 1582 года, количество дней, истёкших ‘от рождества Христова’, вычисляется следующим образом: 365 дней в году плюс 1 дополнительный день на каждые четыре года (исключая годы, символизирующие век: 100, 200 и т.д.) плюс 1 дополнительный день на каждый 400-ый год (400, 800 и т.д.). В расчёт не принимаются ошибки в существовавшей ранее календарной системе, которые и привели к созданию Григорианского календаря.

Сегодня идёт 738143 день. И вообще ни каких проблем, и ни когда (во вменяемом будущем) их не будет. 6 байт или 3 байта + очень лёгкие расчёты с ней.

Цитата:

---

Сообщение от tae1980

6 байт или 3 байта + очень лёгкие расчёты с ней

---

Да, но тут задается лишь дата, без часов, минут и так далее. Юниксовый отсчет дается с точностью до секунды, а это (в день) 86400 тиков, что минимум + еще 2 байта.
Итого по критически важному (в те древние времена) количеству байт проигрываем юниксовому варианту. Расширив который на байт, можно было "уйти" в вечность.

Цитата:

---

Сообщение от reddie

Да, но тут задается лишь дата, без часов, минут и так далее.

---

Но, мы про дату и говорили.

Время так же задаётся числом секунд прошедших с полуночи (86400). Это ты указал правильно. Плюс ещё 3 байта. Итого получаем 6 байт и минимум гемора.
Но непосредственно в rexx'се, ситуация вообще другая, так как ему глубоко плевать на байты, он хранит все цифра в текстовом формате. Да, с точки зрения экономии - это кошмар, но зато можно, например, посчитать число пи до абсолютно любого знака (при желании хоть миллионного - дурная голова рукам покоя не даёт). Главное, что бы хватило физической памяти. Про то сколько он это будет делать - даже думать не хочу. И не только посчитать, но и корректно выполнять арифметические действии с ним. При этом положив болт и на разрядность проца.

Разные задача, разные решения. В настоящее время, лично мне, подход rexx гораздо ближе.

Касаемо даты.
Можно хранить число дней прошедших с начала текущего века. Получаем максимальное значение 365*100=36500. То есть влазим в 2 байта. А с двумя байтами работать у нас проще. А числа более максимально возможного числа можно рассматривать как даты в предыдущем столетии от начала нынешного (так сказать "до нашей эры"). Это ~29035 дней, которых хватит на 79 лет.
Для отдельных случаев можно добавлять третий байт - номер столетия. Думаю лучше всего -128...+127. Видеться, что этого периода хватит на все вменяемые даты.

А если время округлить до минут, то в сутках 1440 минут, так же для работы с ним хватит 2-х байт.
Нужны секунды, задействуем ещё один байт. Но храним там число секунд 0-59.

Такая схема избавит от необходимости иметь процедуры арифметики трёх байтных чисел.

1. Как в sjasm zoom сделать такую вещь:

Код:

---

ORG ADR1 [,ADR2]

ADR1 - где будет работать
ADR2 - куда положить код

---

2. Как делают проигрывание звука через ЦАП во время вывода картинки? А одновременно с чтением с карты? Через обычный ковокс. Или такое мало реально? Я думаю сложно.

Код:

---

org ADR2
phase ADR1
....
unphase

---

Цитата:

---

Сообщение от izzx

2. Как делают проигрывание звука через ЦАП во время вывода картинки?

---

Тут основная задача - равномерный вывод данных в ЦАПы, чтоб избежать т.н. джиттера. На компах, где есть всякие дма-режимы и прерывания с высокой частотой, это не проблема, но на Спектруме (стандартном) ничего этого нет. Всё задержки/растактовки нужно высчитывать и реализовывать кодом. Не прям до такта, но с более-менее выравнивать вполне можно.
Кстати, используя GS как ЦАП, задача упрощается, но надо писать свою загружаемую в его память процедуру. Которая будет по внутренним прерываниям читать порт, что даст вполне удобные тайминги. Максимальная частота, соответственно, 37 КГц, либо с делителями на 2, 4 и так далее. Остаётся вовремя подкидывать данные в порт, следя за их принятием. Для варианта с подгрузкой потока с быстрых носителей - самое то.

Цитата:

---

Сообщение от Sandro

Ну вот Unix date считается с 1972 года, и в 2036 юниксовы года закончатся. Это не решение проблемы, а заметание мусора под ковёр. Лучше всё-таки хранить дату, как есть.

---

Сейчас хранят не в 32 битах, а в 64х битах unix time. И на ближайшие миллиарды лет проблема решена:)

Кстати, юникс тайм хранит и отрицательные значения:)

2. Как делают проигрывание звука через ЦАП во время вывода картинки? А одновременно с чтением с карты? Через обычный ковокс. Или такое мало реально? Я думаю сложно.[/QUOTE]

Да вот так и делают. Good Apple выводит звук одновременно со чтением с карты. А The Craft ...

Да блин. У неё вообще ничего нет. Звукового адаптера у неё нет. Видеоадаптера у ней нет. У неё вообще ничего нет, кроме 20 МГц микроконтроллера и нескольких резисторов.

https://www.youtube.com/watch?v=sNCqrylNY-0

Цитата:

---

Сообщение от Sandro

У неё вообще ничего нет, кроме 20 МГц микроконтроллера и нескольких резисторов.

---

20 МГц AVR довольно мощная штука, ей вполне по силам программно всё это делать. Спектрум да и БК хоть до условных двухсот разогнать, но тв-картинку они генерить если и смогут, то без другого функционала. Программисту всё равно зачёт, хотя видос уже довольно древний боян.
Good Apple хороший пример, но большая часть времени у Manwe ушла, подозреваю, на подготовку данных для вывода =)
Там всё же не полнокадровые 30 фпс, что физически на БК невозможно, а смена кусков кадра. Просчитать это всё и совместить массив видеоданных с аудио, пусть и заранее, тоже работка не на пять минут.